Comment by austin-cheney
12 hours ago
DOM templating is just like JavaScript classes. Classes in JavaScript were requested since the earliest of times and always rejected until ES6 (2014), because they are/were:
* always unnecessary
* always artificial
* only vanity
* only desired by insecure persons not familiar in the technology
* only qualified as bad idea but necessary because people were just going to do it anyways
So far the DOM has managed to escape this stupidity only because it is not a part of JavaScript. Java people ignorant of JavaScript desirous of features to make JavaScript feel more like Java has no bearing on the DOM, for example, because they are separate technologies managed by unrelated organizations.
None of the ergonomic reasoning mentioned in the article are qualified. Just because many people lack confidence in the technology and knowingly make poor design decisions doesn’t mean a familiar vanity layer will fix anything. Declarative comfort, for example, is not a resolution to performance and security problems just because other knowingly bad design decisions are worse. Two wrongs don’t make a right.
Furthermore the DOM already has a slow unnecessary declarative abstraction layer insecure people cannot live without called querySelectors. In other words this proposal is to React as querySelectors are to jquery, and classes are to Java. These are/were trends and trends die over time. We really should move past vanity as an alternative to an absence of training.
It is slightly different. Classes ended up being worse than what they were trying to supplement. Templating, if done right at least (a big if, granted), can bring small improvement. If classes were better, we wouldn't see them the same way now.