And in all variants, any library was designed to build application from a blocks (functions, classes), and render some GUI using OS calls or graphics libraries. Build Applications from the start to the very end.

NOT TO BUILD STRINGS. And today everything is built from strings.

Behold HTML era!

And here our story begins. And in the beginning our story, and our web was ugly. And tools to produce html were ugly. And HTML was also very ugly.

And then mankind starts to invent template engines. Next years I’v tried numerous Java templates, different StringBuilders, XSL XSLT, and other strange ways to produce a... string.

And yet again — it were ugly. Java(and C) way to work with strings is not very suitable to generate HTML code. Not very usable, not very performant. Not elegant.

And when someone showed me PHP, not as a new language, but as a better template engine, where you can use a full cream language inside a template…

I rewrote a few sites from Java Servlets to PHP next week, and found that they actually runs a bit faster :). And code was just more simpler.

Since that time I can’t understand why Smarty, a very popular PHP template engine, was even born. PHP is a quite good template engine by itself. 🤷‍♂️

Your template is your code. Your code is your template.

Today we have a lot of template engines — Jade, Handlebars, Thymeleaf and so on. Some of them may include very usable, from a programing point of view, things - like mixins in Pug, but they also often introduces their own language constructs, or just their own “language” and the way to compose result.

And in most cases that language was a very limited crap. Cos “template language” is not a “common programing language”. Template engines should “template”, not perform some generic computations. Thymeleaf (a thing in Java)— can’t even include another template by a relative path. 🤦‍♀️

And then, someone said that writing HTML is not a programer’s duty.

Next someone invented semantic HTML, BEM, and other right ways to do something “programmer shall not do”, and found better persons to do it, and call them “frontenders”, or even PSD-to-HTML converters.

“Frontenders” were just about writing a bit of HTML+CSS because, you know, there was no need of “much” HTML+CSS, and JavaScript was usually not their work. HTML+CSS was not “programming”, while JS was… not for the everyone, but was. And the “real” work still was on backend side.

MVC

And that was OK due to MVC . Huge Model , dumb View and over-smarted Controller .

Provide all the things, and render a simply markup. No logic inside views. Very usable, for static data. Separate programers from web-designers, code from view, flies from burgers.

And View stops being the Code. They are just templates now, written by someone else.

It was hard to create “MVC” application with Delphi, as Components are by their own. It was hard to create MVC application with MFC, as long “view” was a smart thing by itself.

But as long browser expects from us just strings — MVC was/is native to web. A Controller at the server, Model at Database, and a tiny View sent to the browser.

And View was more or less “dead”. Just a brainless reflection.

Flow?

In modern approach with redux — State is not a Model, or Controller. State is a Database. And each component is a Model, View and a (little) Controller.

Any reasons for this?

It is alive! MVC in most of cases on update you will start from the scratch, update models, and render everything from the single entry point .

Rerender all the thing. Oh crap.

In modern approach you can update small model, and it will rehydrate bounded view. Cos they are the same. Bingo!

It is more about decomposition than about architecture. Like vertical or horizontal scalability.

Not a silver bullet, but, imho, better fit SPA needs.

There is no difference what are you going to use — redux, mobx, revue — you are always going to update little pieces of an application, not a whole.

That is a corner stone of the Modern Frontend. Views now are smart, they are the Code.

React vs Vue

Vue is a framework. React is a library. Both “renders” HTML. Both “fuel” application. Vue can be faster than React out of the box, due to more smart optimizations it is doing. React letting you do whatever you want, but not helping to do it.

There is no difference how they handle states, or how they perform DOM manipulations. The difference, we are looking for, hidden in another place.

Vue is like Smarty, Jade or Angular — they have invented their own template language. Always limited language, even if it better fits for your needs.

Sometimes strict template language can enforce you to write a better code. Sometimes.

Each time I see Angular(1.x) or Vue code — I am wondering —

“Is javascript not good enough? Is it … bad?”.

Why they are trying to reinvent the wheel? Their “wheel” is ok. It it usable. But as result Angular and Vue acts as template engines, not as a code .

Vue and Angular, as templates, inherits “html” approach to make templates. The way I do not understand.

But React(with JSX) acts as part of the language, not separated from it. It may miss, as result, some build-in magics and optimizations the “real” templates could afford. It will alway do you told to do. No more — no less. That is, actually, not a good thing. It is good to have a smart framework looking after you and helping.

But you will also never get something…. Unexpected.

Magic out of the box

I prefer to create programs. And React — is not markup or template engine— it is a program, it is a code. I know how to code.

Your tests are the code. Your markup is the code. Templates are the code.

React, even as template engine, is much, much better than old school template engines.

More correct. More abstract. Still template. And very simple.

When?

React is better when you are better. Or you want to be better. By learning React, and writing good and optimized React code you can improve your skills. Because you have to write good code.

Good and optimized code, not just “React”

By writing something in Angular or Vue you can improve you Anguluar and Vue skills. Cos you may get (too) good and optimized results out of the box. There could be no room to improvement.

And you may lose a lot of important things, because you will not face the problems.

For example, a lot of “React Developers” did not hear about DOM. They don’t need DOM API to build good React applications.

A lot more Angular ones, did not hear about Javascript. They don’t need Javascript to build good Angular applications. 🤘

What else you may miss? What else you will just “dont need” and “not use”.

Magic must be inside.

Conclusion

So, to say they truth — Vue`s authors agree with me:

[In React] You can leverage the power of a full programming language (JavaScript) to build your view. This includes temporary variables, flow controls, and directly referencing JavaScript values in scope.

But they also pointing a little advantage of old-school templates — they are predictable:

In React, when a component’s state changes, it triggers the re-render of the entire component sub-tree, starting at that component as root. To avoid unnecessary re-renders of child components, you need to either use PureComponent or implement shouldComponentUpdate whenever you can. In Vue, a component’s dependencies are automatically tracked during its render, so the system knows precisely which components actually need to re-render when state changes.

So, out of the box React can be slower and harder. And will force you to learn how the things work.

Thats the goal.

But…

But I do have opposite example, when something like Vue is much better. Sometimes the only way to optimize things is hidden inside, and you cant control it from user space , I mean — from your code.

React might be better for you, but Vue could be better for the user, you are building application for.

There is no single truth, you know. My goal wasonly to show “all this” from another angle.

PS: A Year later

PS: PS: Another year later

React ecosystem right now is in crisis. Multi-threaded stuff like React-Native or Electron are facing performance/synchronization issues, as long there is no way to predict what React Application is doing, as long as it can do ANYTHING. Literally anything, and there is no way to explain to another thread/browser/native what that “anything” would be in next frame. It’s a huge problem to build a “bridge” between user-land-JS and the System itself.

Meanwhile — Angular and Vue “templates”, I don’t like so much, are free from this limitation, as long they could explain what they are, what they could do, and what they would do. Templates with their own language are more predictable and could be a Bridge between different spaces.

I may be wrong. And I want to be wrong. But, may be, template engines, ruled in the past, will rule in the future.

PS: PS: PS: Another year later

Svelte is a good example of this. A simple vue/angular like template language, with the same AOT(Ahead Of Time) complication, provides you a better way to expose your thoughts and let the “framework” do the rest. Where “the rest” is almost everything from updating View to tracking variable updates. Usually it just works due to the internal magic, and you don’t have to think why.

In the same time React Hooks are also a good way to declare how something should work, and it would. This time without any magic, so you have to think, and properly use hooks with right deps used in the right places.