Cost/benefit. If 95% of your users are on Chrome, that's where the business wants you to spend most of your development effort. It's the same issue with game dev. Most games don't support Linux natively because the small user base doesn't justify the time sink for developers.
Not saying I like it, but I'm not surprised at the current state of the ecosystem.
All developers should understand basic web standards, particularly accessibility.
Have you worked with Angular much? I've built extensive component libraries (internal) for my org and maintaining the Angular one has been a nightmare. The frequency of breaking changes and conventions has been awful, particularly in the last few years. React, by contrast, has been a breeze ever since they introduced Context and Hooks.
On the app development side, we dealt with 3 major overhauls of PrimeNG's style system before we decided to invest in a custom library just to eliminate the risk of future upgrades. It took us 6 months to migrate our Angular 9 app to 18 because of the PrimeNG dependency. Granted, it's a massive application and they didn't maintain it properly, but I'd hardly call Angular stable regardless.
And then you have the Vue composition API, which was a major shift from Vue 2.
This isn't to say that React has been perfect. Depending on your stack, there are certainly a fair degree of breaking changes (looking at you, Next.js and react router). But that is far from abnormal in the JS world.
I don't think so. I have a P16 Gen2 and this thing sucks power like nobody's business. 13950hk and 128gb of RAM. I barely get 1 hour of light programming work. I mostly use it as a desktop though, and I have a separate M2 Mac for traveling.
> It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS?
Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though.
The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts.
That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.
> Right but what's the problem of someone writing an article to make a critic against React?
That's not the problem. I like React. I welcome criticism. The issue is that the author's criticism is shaky at best. Here are some snippets:
> The DOM and CSSOM as a rendering surface is just one big fucking yarn ball of interconnected side effects that have side effects of their own. This means the components themselves are largely meaningless when removed from their rendering context.
This is a weird statement to make. I'm not even sure what point he's trying to make. It's also wrong. Components can often be designed to be reusable and meaningful in various contexts. While some components may depend heavily on their rendering environment, others can be quite modular and independent.
> But React components are also intentionally abstracted away from their rendering contexts. Between the many different rendering engines, hooks, contexts, synthetic event system, server actions, and more, there really is no such thing as a genuinely “functional” React component.
The statement "there really is no such thing as a genuinely 'functional' React component" misrepresents what it means for a component to be functional.
While it's true that many React components are not pure functions (since they can have side effects and state), this does not mean they cannot adhere to functional programming principles. Functional programming does not require that every function be pure; rather, it encourages a declarative approach to managing side effects.
React’s design encourages managing side effects in a way that maintains the declarative nature of your UI. By using hooks, you can encapsulate side effects and state management within functional components without compromising their readability or predictability.
> Even if it looks like a function that just takes props and returns markup, it isn’t really. It is effectively impossible to fully understand what’s going on in any given component that’s a part of a big app just from looking at the component itself.
This is an overgeneralization. While it may be challenging to understand a component in isolation if it relies heavily on external context, this is not a problem unique to React. As previously mentioned, any developer can write shitty, garbled code.
The same could be said for a microservice, backend function, or component in any other UI framework / web app. This is the reality of any software development in a big organization.
This is where proper process, documentation, code review, and testing come into play.