FAQ

Table of Contents

1. How does Vieux compare to X framework?
2. How does Vieux compare to MVC, MVVM, MV*... erm... Flux?
3. How can I implement Vieux in Y?
4. Why are there so many roles?
5. Aren't the names confusing, though?

1. How does Vieux compare to X framework?

Vieux is not a framework. It's just a set of idea(l)s that you can implement in any framework. We actually provide examples in some.

Since Vieux is just a set of ideas, it doesn't come with an example implementation. But it's trivial to use, especially when you check out our examples.

2. How does Vieux compare to MVC, MVVM, MV*... erm... Flux?

Vieux takes inspiration from the life itself. It's easy to understand and easy to reason about. With contextual naming conventions and half-duplex information flow, you don't have any confusion about what goes where.

If you inspect it closely, you will see that Vieux reflects some of the roles in these approaches. With a striking difference, though; the story of Vieux makes sense. Although they share the same name, View in MVC is different than the View in MVVM. In contrast, everything is clear-cut in Vieux. Vieux is a distilled, humanitarian version of our combined experiences with these approaches. It's not yet-another-flavor-of-MVC. It's a different story that makes sense even if you tell to your kids, which then they would instantly understand and be able to reason about.

3. How can I implement Vieux in Y?

If Y is not something like jQuery, it would be pretty straightforward. EventEmitters and Singletons are the only off-the-shelf constructs you need. Refer to our examples to see how its implemented in various frameworks.

4. Why are there so many roles?

In fact, Vieux has only 4 core roles, and hacker-minded people could do well with only 3 (leaving Stereotype out). Let's put it this way. Developers don't like systems with a lot of different constructs and concepts (they often bash AngularJS for this). But the real problem is not the number of constructs but the clarity and the crispness of them.

If you manage to put out a set of very concise concepts, and those concepts are crystal clear even at first sight, then it's not a problem at all. It's just a natural extension to your train of thought.

We strive really hard to make Vieux easily approachable. The terminology we use derive from real world examples. Everybody knows what a Diplomat does, everybody knows what Representatives do. That Cultures have subcultures, and express behavior. That they are represented by Representatives of a parliament. Bureaucracy is everywhere in our lives.

With that out of the door, we should say that the goal of Vieux is not to be a toy. You can do huge applications with Vieux without ever increasing the complexity of your code. But huge applications that scale, need a scalable architecture. You can't do a scalable application with only two or three concepts. As your needs increase, the number of concepts you have to apply has to increase respectively, to carry the weight of complexity. We know that. We are building SPAs for the last 4 years. We have huge experience with state-of-the-art—and then some—frameworks. We know the pitfalls, the shortcomings, the advantages and the disadvantages. Vieux is a distillate of these, combined.

We offer you very distinct, single responsible roles which are easy to reason about and use in your code. That's how you will benefit in the long run.

5. Aren't the names confusing, though?

Are they? Can you tell what a Diplomat does in real life off the top of your head? Can you tell how certain Cultures express certain behavior? Can you tell how they breed subcultures, which are somewhat related to the parent Culture but express some contrasting behavior? What does a Representative do in a parliament? Can you tell that Cultures create—and choose—their own Representatives to negotiate with the Regime? Can you tell what a Union does? Can you tell the purpose of European Union, or the Soviet Union?

We bet you can. The names aren't confusing at all, they are concise and relate to everyday things in your life.

Now think about the names in other solutions. What is a Model, exactly? What does a Controller do? What information should a ViewModel hold? What is a Service? No, no one in the tech community can agree about the definitions and roles of these names. Oh, heck, what is a Store?