[simonw]

Nobody is trying to convince you to build a chess app that doesn't use JavaScript.

More importantly, Alex is not arguing for you not to build things with JavaScript either!

He's arguing against writing inefficient JavaScript where you ship MBs of code to the browser to serve simple functionality.

Scroll to the footnotes and you'll find a big list of JavaScript frameworks which Alex does recommend, because they optimize for performance and low overhead.

[friedman23]

What do Solid, Svelte and Vue bring to the table exactly? None of those frameworks solve the dataflow problem and the performance benefits they bring do not make a dent. Also why would I want to use some DSL for html templating when I could use an actual programming language?

[Inviz]

I personally like the article and I respect author deeply, as he's one of the people who did a lot for the web. Many developers have been raised on his articles and materials.

However I agree these alternative frameworks section took me out of the piece, because these do not really solve most of the issues. They _just_ maybe get around by not having a virtual dom. But many of them still do a lot of css-in-js, still need rendering on the server (but lack the tooling), and do not solve the dataflow. I definitely have aversion towards new syntaxes of html as well (in parts because i built similar framework myself 10 years ago and it's really gnarly down the line)

[slightlyoff]

Hey; OP here. Thanks for taking the time to read.

Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.

But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.

This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:

https://infrequently.org/2022/05/performance-management-matu...

[mathgladiator]

> Also why would I want to use some DSL/html templating when I could use an actual programming language?

I feel like the core issue is that HTML is radically insufficient, so DSL/Templates come into play to alleviate the burden. What's generally worse is having everyone going their own way doing random stuff within an org, so best practices must emerge and that starts to feel like a DSL in a way.