Open danielearwicker opened 7 years ago
Thank you for the response. This helps clarify some nuance that I missed in the original. I'm editing things into a proper followup and I'll try to work this in. I appreciate the help!
I feel the same way you do about using JavaScript to build views versus using a template language. However I question whether there's objective superiority here - I think it's just an opinion. There are surely advantages that template languages enjoy over JavaScript-based views. Some common patterns can be expressed much more concisely and naturally with a declarative template language, even if it is obscure and framework-specific. There might be optimizations that aren't possible in JavaScript, or at least require much more advanced tooling, and I wonder if the rule of least power will lead to declarative templates actually having some neat benefits that JavaScript-built views are excluded from.
Of course there are tradeoffs in the other direction, where JavaScript-built views are almost inarguably better than templates in certain ways - debugging comes to mind. As a programmer with a lot of experience with React, it's hard for me to even consider going back the other way. My employer uses Blaze (and React to a lesser extent), and it reinforces my viewpoint every time I work with it.
I'd love to read more on this subject if you or anyone has some articles or talks to share. HTML in your JS or JS in your HTML...so many tradeoffs, so much unexplored and unproven.
The new language service stuff is great for users of templating frameworks, to be sure.
The reason React is still superior is because it only adds a syntax for declaring components, which is trivially transformable to object creation expresions.
Why is this superior to Angular-style templating? Because in React, all the other business of coding: conditionals, looping, modularity/naming, composition, is all done in the exact same ES/TS syntax and semantics as everywhere else. Whereas in Angular, they have to invent their own magic way of doing loops and conditions. They have to have a second module system for template components to use, that overlaps confusingly with the now-prevalent ES module system, their own menagerie of ways of referring to values, looping, conditions and chaining operations.
The most frustrating thing about any technology is when you have to ask "How do I do X in this technology?" where X is some very basic thing (such as conditionals, looping...) that everyone knows how to do in a bunch of mainstream languages. But the domain-specific technology has invented its own way of doing that thing that is not objectively any better; it's just different, and obscure. And so now everyone is a beginner again, but doesn't get any return on their investment.
This is what React avoids carefully. Let the surrounding language take care of all the stuff it can already do perfectly well. Just add a neat HTML-like syntax for building hierarchies of component instances, and let them intermingle according to extremely minimal rules.
This has nothing to do with static typing of course, so it doesn't defend your original point! 😎