> The problem with templates is
But the good part is that with natural templates you see stuff in a perspective and in a more plain/readable structure. It's like coding something in Assembler/low-level vs in Java/C#/JS.
I've used Angular - frankly, its template syntax is horrendous. I had to learn a ton of new semantics (`whatever` `(whatever)` `[whatever]` `#whatever` all have different execution contexts), and ultimately they've re-implemented most of JavaScript and* Angular inside of this HTML template syntax. Vue is about the same AFAICT. There's a lot of good in these frameworks, but templates is not one of them.
I don't understand your comparison to Assembler. How is this more like Assembly than a high level language?
React:
return (
<div>
<button onClick={onSave} />
{heroes.map(hero =>
<button onClick={deleteHero(hero)}>{hero.name}</button>)}
<form onSubmit={onSubmit}> ... </form>
</div>
);
<button (click)="onSave($event)">Save</button>
<button *ngFor="let hero of heroes"
(click)="deleteHero(hero)">{{hero.name}}</button>
<form #heroForm (ngSubmit)="onSubmit(heroForm)"> ...
</form>
Here's something neat about the React example, too: since it's a pure function, it can easily be unit tested without rendering to a DOM or doing some weird string stuff.
If you're using adjectives like "natural" without qualifying it with "in my opinion", it means you don't really understand the higher meta level discussion.
It is not objective fact that embedding a Turing Complete programming language inside of HTML via custom attributes such as Angular "ng-xxx" and Vue "v-xxx" is "natural". Many find it quite unnatural and unreadable![1].
If that's your personal preference, that's fine but be aware that many see HTML custom attributes to express a pseudo-language ("ng-for", "v-for", etc) is not really HTML. Yes, it's cosmetic HTML for appearances sake but not semantic HTML. The semantics is the pseudo-programming-language that's executed by Javascript. If you're unaware, the extending HTML with custom attributes for expressing code is an example of The Inner Platform Effect.[2] It doesn't matter whether you use new HTML custom tags[3] or custom attributes; that's just a difference in cosmetics.
[1] Examples:
https://news.ycombinator.com/item?id=10967000
https://news.ycombinator.com/item?id=10967789
[2] https://en.wikipedia.org/wiki/Inner-platform_effect
[3] tag soup to express a pseudo-programming language in HTML: https://blog.codinghorror.com/web-development-as-tag-soup/
The issue is that now you have a ton of code (it is code, btw) living in a templating language that probably doesn't have as good of debugging, documentation, performance, encapsulation, composition, etc. as the underlying language it's using to process the template. It's up to the maintainer of the templating system to handle re-implementing that, and if you end up in a situation where it doesn't actually meet your requirements, you either have to add these basic language features yourself or start from scratch.
That's why things like React and Hiccup (and even more advanced, something like Racket), etc. have gained huge popularity and mind share: instead of re-implementing the programming language in a template system to show HTML, let's implement an embedded DSL to conveniently write HTML.
Then suddenly we get away from managing gnarly data dependencies, stack traces through templating systems, and writing stuff like this:
To just: Once you are writing in an embedded DSL, you no longer need to worry about re-implementing all of the constructs of the underlying language; it's laid there at your feet.Furthermore, by modeling your view as simple functions and data, you get all the features of data manipulation (huge productivity gain; don't need to write to rewrite or relearn `map`, `reduce`, `for`, serializing, etc.) and function composition (this is HUGE. I could write a whole blog post on this).