I think the point is that React is a true programming language with syntactic sugar to make it look templates, vs templates that bolt on some language.
React is just JS as any other app using JS with templating. I really fail to see the benefit with the React approach. If anything it makes it more difficult to have a 100% match between design and the end product.
How much React have you written? Because React is just JavaScript, you can take traditional programming patterns and apply them to your UI, for example higher-order components. You can't do this with templating.
Hm, can you describe what do you mean by "can't do this with templating"?
Do you mean that since React/JSX kind of a superset of JS you can do higher order stuff in it, whereas in a simple templating language like Jinja2 you can't?
Isn't that a false equivalence? I mean I regularly use patterns similar to HOCs in Angular. It's easy to wrap components[0] and it's just as possible to project components into other components programmatically[1] with complete dynamism.
[0] depending on the use case there are different preferred ways: directives, which have access to the wrapped component and its template, and can interact with it in many ways, or you can do it from raw TS ( https://github.com/abumuawiyah/ng-ivy/blob/master/src/app/ap... see the withTheme and withStyles functions )
I wrote this on my phone. Hopefully it makes sense.
No templating language is going to beat a general purpose programming language as far as features go.
There’s no technical limitation of templated languages that would bar them from having the same functionality as a general purpose language. Whoever is designing the templated language is probably not going to design something as powerful as a general purpose language.
Angular built a specific set of keywords to include higher order components. React did no such thing — they exist for free because it’s all just JS. You could imagine that there are other patterns that exist in JS that you can’t express in Angular because it doesn’t have all of the flexibility of JS.
From your example you showed that you used TS to create your component, essentially using an escape hatch from Angulars templating language to do what you want. You don’t have to escape from React, because you’re already in JS.
I haven’t used Angular in a while, but I have been using Vue recently. The difference is huge. I can’t (easily) put a Vue component in a stack. I have to learn Vues syntax that will have zero transfer when I go to another framework, whereas React is just JavaScript (JSX does change some HTML attributes, but it is generally 1:1).
To close, I don’t think React is required to be productive or write good UI. I just really like it because there’s no magic going on. It’s just syntactic sugar over JS.
Hm. I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS. HTML is the templating. JSX is a super lightweight layer on HTML with its own weird rules.
I don't like Angular's default verbosity of separating the template from the logic, nor it's hijacking of the simple double quotes, but I disliked fighting with JSX and too too large files in React. Plus in my experience React projects grow their own verbosity too (in my last NextJS project every component had at least 2 files, one for wiring up the state and one for lowlevel view things, and it was awfully unclear what goes where). Plus the stringly typed state store :(
I don't think it's true that a general purpose language will be always better than a templating language. For one thing the template gets interpreted, there's already a context, it can be safer and more efficient. I mean JSX is great because it allows easy interpolation, in plain JS you would have to do backticks and ${} and the IDE/editor/linter would need to guess (or you would need to annotate the string like in Markdown) about the syntax and semantics of what you want to emit.
Of course making the jump from the host language to the target language too onerous leads to inefficient engineering, boundaries placed at convenient instead of optimal places, etc.
And it's very good that JSX allows stepping back to JS easily. Angular templates allow that too, but it's just not as fluid (probably because the syntax is just meh).
There are specific keywords to do things in template-land and there are non-template ways, that are more general and more messy. Because DSLs can be more effective for the things they were designed to express. The simple React HOC composition is similarly simple in Angular too, <ng-content /> and that's it. What's less appealing is that it happens in template land, and for some reason the wrapping in pure JS feels more powerful (to me too, don't get me wrong), but the actual hierarchy of components is defined in template - in JSX - in React too. It just feels closer to JS. (Rightfully so.)
People who use it from ClojureScript, for one. Due to the nicer Clojure syntax you don't need a templating language, just a data convention (hiccup in this case).
For those of us who hope JS will slowly become just a compile target, a downside of of JSX is that it's tooling is JS specific, and the syntax is tailored to JS. So it's great that React isn't married to JSX.
I wrote a GUI framework that uses React API directly.
It's more proof of concept than useable, the idea is that we don't actually have to write layouts, we can just describe the layout with code or a template language and let the computer work it out.
Yeah strangely it compiles to functions but they way they compose is not the way we compose function. Practically it's a template, compose via component mechanism. If it's a language it should be like Elm where attributes and children are also List and have return type, can be programed in function style.