b_e_n_t_o_n

Yeah, but when it's used in conjunction with js frameworks it ends up being more complicated than pure SPA or SSR.

Especially since they put effort into making it backward compatible. You can mix Svelte 4 components with Svelte 5 components. Which is pretty reasonable.

It does everything at runtime, Svelte compiles declarative code into imperative code via static analysis.

React also uses a declarative model, in fact React might be more declarative because it's still declarative at runtime, whereas Svelte et al. do a lot of static analysis to turn declarative UI into imperative targeted dom updates.

Hmmm, it's kind of complicated. A lot of the innovation in JS frameworks has been at the meta framework level, because the client-side framework itself can't really control how data is loaded or how the app is bundled. A lot of work has been done to begin data fetching as quickly and in parallel as possible, like you said because network latency is a big factor for performance. And there is a focus on bringing down bundle sizes. I think Svelte 5 is only a few kb, same with Solid.js. The meta frameworks bring some added weight because they contain the routing and data loading logic.

But especially on mobile, rendering throughput as you put it is still relevant. Especially in response to interactions which cause significant changes to the UI. The "issue" with React is that it's all done at runtime, which does bring significant benefits but loses out on opportunities to optimise things which is what stuff like Solid, Svelte, and Vue's in-development Vapor mode take advantage of via static analysis. The benefit is performance, but you lose out on the dynamic nature of React. That is a tradeoff you need to choose when picking a framework.

Solid and Svelte are so close to vanilla JS levels of performance that you start thinking about how to optimise as if you were directly manipulating the DOM itself. Which is cool, in comparison with React you end up trying to optimise for React instead of the DOM. You still need virtualisation in a lot of cases regardless if you use React or Svelte.

I think the bigger attraction with Svelte and Solid, as well as Vue et al. is the signals / reactivity aspect. You can still tie yourself up in issues with that but it's a better mental model for a lot of developers compared to the pseudo-pure functional approach React takes. React's model can be a pain when you do need to escape-hatch to the dom itself, like you often do with complex animations, or interactions like drag-and-drop. If you can stick to pure React it can often be pretty clean.

React's compiler is designed to minimise redundant rerenders and object instantiation. It seems to help if you look at benchmarks. Still not nearly as quick as the static analysis approach because it doesn't change the underlying semantics (it's just doing stuff you would otherwise do manually for the most part).

So I would say it's still an issue, but so is latency and bundle sizes and that's also seen a lot of innovation and improvements.

I was being a bit tongue in cheek, I doubt an AI wrote the whole article but it feels a bit off in a way that AI can do.

It automemoizes objects that would otherwise be recreated on each render, which would then cause rerenders down the tree. By memoizing these objects, they reduce the amount of rerendering done without actually changing the semantics of the code you write (unless you wrote code that only works because of frequent unnecessary rendering).

I think most are still using React with maybe React Router. Node and Pnpm aren't really complicated or difficult to use, neither is Vite.

Is this AI? How is Blazor a JS framework, let alone a popular one?

Also no Solid.js?

Both jquery and htmx style approaches lack the concept of components, data flow, template binding etc. At most you get string templates. You end up manually wiring up dom updates when state changes, and that kind of thing is brittle and is why stuff like React was invented in the first place.

React has been very stable throughout its life time. You can run 10yo react code in v19x without issues.

Bundlers will convert let/const to var, assign classes and functions to var etc but generally people don't write it themselves unless they want to (ab)use its semantics for performance reasons.

It sounds nice in theory but then eventually you wind up needing to implement a feature where you wish you had React et al to implement it.

Easier just to start with it from the beginning. Assuming you're a full stack / front end guy of course, or else I get the appeal of html only.

Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ

It's a reference to this:

https://news.ycombinator.com/item?id=8863

This is super nice!

and rsync works fine for people too, I guess that's why nobody uses Dropbox

I don't know to what extent that's true compared to the npm ecosystem, but the js ecosystem largely rejects the monolith framework approach. It's focused heavily on frontend / browser, and the most popular JS frameworks are really just backends for frontend. Its most common to have a separate backend, perhaps in a different language, and it's an approach I prefer.

Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.

What if you're building a highly interactive front end?

JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails...

The problems people solve with JS are different from the ones solved with Rails. Which is why the frameworks look different.

In practice you don't run into these issues often. I'm annoyed when you see different function declaration conventions in the same codebase, but generally () => is used for either one line functions or inline lambdas, and function foo(){} for everything else. Nobody uses var anymore.

The implicit conversions is a definite footgun tho.

We tried that last century.

Oh true.

No but a monopoly also doesn't mean a majority market share, or being so much better than the competition that everyone chooses you.

My point is that you don't need half of the things the author thinks you need for a JS frontend with Vite, TS, React, and Tailwind....

NPM comes with Node. And obviously you need to install node, just like you need to install Ruby....

If you're gonna rant about the JS ecosystem at least get it right. You can set up a Vite + React + Tailwind setup with two commands

   npm create vite
   npm i @tailwindcss/vite tailwindcss

If you want automatic code formatting and linting install biome, that's one more command.

You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does the author add husky?

Like, if you want to criticize JS fine, but chose valid criticisms. This just sounds like the author hasn't actually used modern js.

Does Microsoft actually have a monopoly on anything these days? Maybe gaming? I saw its like 95% windows on Steam.

How can the government regulate companies into providing good customer service when they can't even provide good customer service to their citizens?

You'd be surprised how far white sneakers and some $5 flip flops can take you. Unless you're in a situation where you need a suit, but then you aren't one bagging it anyways...