8 ms·

And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years. It is truly

And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years. It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?" In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct. I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app. A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.

koakuma-chan 7mo ago
People have no idea who they are hiring, so they hire people who have no idea what they are doing.
- mentalgear 7mo ago
  > they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. Indeed, Svelte is built directly on web standards so knowing it strengthens your command of core JS and the web-platform itself - not just a silo-specific layer like React. Also Svelte acts as a compiler: it outputs just clean, highly optimized JavaScript with no virtual DOM, that uses native web-APIs and results in minimal runtime overhead, smaller bundle sizes and overall excellent performance and DX.
pjmlp 7mo ago
It is very hard to avoid when you have Vercel doing partnerships with SaaS cloud providers that end up supporting only React and Next.js on their SDKs. Even if other programming stacks are supported, they tend to be 2nd or 3rd class versus anything React. Look into the ecosystem of headless products that have jumped into the whole MACH architecture hype cycle. Then you have to justify to upper management, and partner support when problems arise why you are not using their SDK.
- mvdtnz 7mo ago
  Why on earth would your cloud provider dictate your front end stack? My mind is in tatters trying to understand this thought process.
  - muvlon 7mo ago
    Because with Next.js, Vercel was able to turn the frontend stack into also a really shitty backend stack. And it's particularly shitty at being deployed, so they're in the business of doing that for you.
  - pjmlp 7mo ago
    Because they have these things called SDKs to extend their product, for specific programing languages. Here is an example, https://www.sanity.io/studio https://www.sanity.io/studio Want to extend the SaaS product for your backoffice users? Learn React or make Studio from scratch. Frontend stacks are also backend stacks in cloud products.
    - mvdtnz 7mo ago
      This looks like a SaaS vendor not a cloud provider?
      - pjmlp 7mo ago
        I wrote "SaaS cloud providers", I am yet to see a Saas solution on-prem.
Cthulhu_ 7mo ago
To add, the other dominant force is Angular, very popular in enterprise settings. I don't understand why per se, it's very... verbose, every component needing a number of files. It (and also React) gets worse if you add a state system like RxJS. My theory is that it's popular with back-end / OOP / Java / C# developers, because they're used to that kind of boilerplate and the boilerplate / number of files / separation of concerns gives them comfort and makes it "feel" good. But also, like React, it's easier to find developers for it, and on a higher level this is more important than runtime performance etc. And continuity beats performance. (I can't speak of its runtime performance or bundle size though)
- jonathanlydall 7mo ago
  Like all languages, C#, Java, etc have cargo-cultist developers who use them badly, and in the case OOP languages, doing things like overdoing the separation of concerns. However, speaking as someone who actually uses C# day in and day out and understands the trade-offs of different levels of (or even no) separation of concerns, it's not done for us to "feel" good. On very large projects running for a very long time with many developers coming and going with varying levels of competency, an appropriate amount of separation of concerns and decent "plumbing" can be the difference between a code base enduring decades or becoming essentially unmaintainable due to unchecked entropy and complexity.
  - jamesfinlayson 7mo ago
    Yep, agreed. I worked on two PHP codebases at a company many years ago - the "old" and the "new". The old was just frameworkless PHP with three different ways of doing controllers, partial templates with no closing tags so that they could be inserted anywhere without breaking the page, inline SQL in the templates etc. The new was hugely complicated with long inheritance chains and multiple classes with the same name but in different directories... but it was structured and you couldn't easily do anything wild.
- frogulis 7mo ago
  My current company uses Angular, and uses it reasonably well. Prior to working there, I'd never used Angular, so I feel well-equipped to comment on this. We've also recently absorbed a vanilla(-ish) JS codebase largely developed by one dev which provides a point of comparison. Angular has plenty of boilerplate and idiosyncrasy, but it being opinionated and "pattern-y" has advantages when you want devs who infrequently touch it to be able to jump in and make changes with some level of consistency. Additionally -- and this is anecdotal, but I suspect it's a common part of working with a plain JS codebase -- tracking the flow of data through the Angular application is usually soooo much more straightforward, even when it involves navigating through many layers and files. The Angular codebase only has N types of things, and they tend to relate to each other in the same ways, and they're often quite explicit (such as explicitly defined component element names in HTML templates). In contrast the JS app has whatever it has built up with very few constraints keeping it consistent. Obviously that could be improved with discipline and structure, but reducing that requirement is one of the things a framework gets you. I can't comment too much on React as my one experience working in a proper React codebase was in a team who were largely as clueless as me :)
likium 7mo ago
There's 3x more React libraries and code out there to reference. AI agents do _a lot_ better with React than, say, SolidJS. So productivity > performance is a tradeoff that many companies seem to happily take.
- benterix 7mo ago
  > AI agents do _a lot_ better with React Do you really think this is a solid argument in this particular discussion (about it being slow and introducing a mass of unnecessary complexity)?
  - 0xblinq 7mo ago
    Some people need ways to cope with the drawbacks of what they use, even if irrelevant to the conversation.
- Tade0 7mo ago
  There's so many React libraries because the framew... I mean library is extremely barebones. That is, in my view, the main issue with React (rendering model notwithstanding): every React application is composed of tens of tiny dependencies and since there are several competing libraries for even basic things like routing, no two projects are the same.
- endemic 7mo ago
  And the end users pay the price!
- yaku_brang_ja 7mo ago
  Umm, are we really taking "being AI friendly" as an account to choose framework now? I’ve seen this mentioned often enough lately that it’s making me uncomfortable. I fear if this will becomes epidemic. This will literally hault progress in improving and adopting better frameworks.
  - likium 7mo ago
    As a solo dev who picked SolidJS, yes, it is a big factor. Things like tldraw, node editors, wysiwyg editors, etc. Having to reimplement them is a huge time sink.
etler 7mo ago
React is slower than the alternatives, but next.js is really really slow.

koakuma-chan 7mo ago

People have no idea who they are hiring, so they hire people who have no idea what they are doing.

mentalgear 7mo ago
> they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. Indeed, Svelte is built directly on web standards so knowing it strengthens your command of core JS and the web-platform itself - not just a silo-specific layer like React. Also Svelte acts as a compiler: it outputs just clean, highly optimized JavaScript with no virtual DOM, that uses native web-APIs and results in minimal runtime overhead, smaller bundle sizes and overall excellent performance and DX.

pjmlp 7mo ago

It is very hard to avoid when you have Vercel doing partnerships with SaaS cloud providers that end up supporting only React and Next.js on their SDKs. Even if other programming stacks are supported, they tend to be 2nd or 3rd class versus anything React. Look into the ecosystem of headless products that have jumped into the whole MACH architecture hype cycle. Then you have to justify to upper management, and partner support when problems arise why you are not using their SDK.

mvdtnz 7mo ago
Why on earth would your cloud provider dictate your front end stack? My mind is in tatters trying to understand this thought process.
- muvlon 7mo ago
  Because with Next.js, Vercel was able to turn the frontend stack into also a really shitty backend stack. And it's particularly shitty at being deployed, so they're in the business of doing that for you.
- pjmlp 7mo ago
  Because they have these things called SDKs to extend their product, for specific programing languages. Here is an example, https://www.sanity.io/studio https://www.sanity.io/studio Want to extend the SaaS product for your backoffice users? Learn React or make Studio from scratch. Frontend stacks are also backend stacks in cloud products.
  - mvdtnz 7mo ago
    This looks like a SaaS vendor not a cloud provider?
    - pjmlp 7mo ago
      I wrote "SaaS cloud providers", I am yet to see a Saas solution on-prem.

Cthulhu_ 7mo ago

To add, the other dominant force is Angular, very popular in enterprise settings. I don't understand why per se, it's very... verbose, every component needing a number of files. It (and also React) gets worse if you add a state system like RxJS. My theory is that it's popular with back-end / OOP / Java / C# developers, because they're used to that kind of boilerplate and the boilerplate / number of files / separation of concerns gives them comfort and makes it "feel" good. But also, like React, it's easier to find developers for it, and on a higher level this is more important than runtime performance etc. And continuity beats performance. (I can't speak of its runtime performance or bundle size though)

jonathanlydall 7mo ago
Like all languages, C#, Java, etc have cargo-cultist developers who use them badly, and in the case OOP languages, doing things like overdoing the separation of concerns. However, speaking as someone who actually uses C# day in and day out and understands the trade-offs of different levels of (or even no) separation of concerns, it's not done for us to "feel" good. On very large projects running for a very long time with many developers coming and going with varying levels of competency, an appropriate amount of separation of concerns and decent "plumbing" can be the difference between a code base enduring decades or becoming essentially unmaintainable due to unchecked entropy and complexity.
- jamesfinlayson 7mo ago
  Yep, agreed. I worked on two PHP codebases at a company many years ago - the "old" and the "new". The old was just frameworkless PHP with three different ways of doing controllers, partial templates with no closing tags so that they could be inserted anywhere without breaking the page, inline SQL in the templates etc. The new was hugely complicated with long inheritance chains and multiple classes with the same name but in different directories... but it was structured and you couldn't easily do anything wild.
frogulis 7mo ago
My current company uses Angular, and uses it reasonably well. Prior to working there, I'd never used Angular, so I feel well-equipped to comment on this. We've also recently absorbed a vanilla(-ish) JS codebase largely developed by one dev which provides a point of comparison. Angular has plenty of boilerplate and idiosyncrasy, but it being opinionated and "pattern-y" has advantages when you want devs who infrequently touch it to be able to jump in and make changes with some level of consistency. Additionally -- and this is anecdotal, but I suspect it's a common part of working with a plain JS codebase -- tracking the flow of data through the Angular application is usually soooo much more straightforward, even when it involves navigating through many layers and files. The Angular codebase only has N types of things, and they tend to relate to each other in the same ways, and they're often quite explicit (such as explicitly defined component element names in HTML templates). In contrast the JS app has whatever it has built up with very few constraints keeping it consistent. Obviously that could be improved with discipline and structure, but reducing that requirement is one of the things a framework gets you. I can't comment too much on React as my one experience working in a proper React codebase was in a team who were largely as clueless as me :)

likium 7mo ago

There's 3x more React libraries and code out there to reference. AI agents do _a lot_ better with React than, say, SolidJS. So productivity > performance is a tradeoff that many companies seem to happily take.

benterix 7mo ago
> AI agents do _a lot_ better with React Do you really think this is a solid argument in this particular discussion (about it being slow and introducing a mass of unnecessary complexity)?
- 0xblinq 7mo ago
  Some people need ways to cope with the drawbacks of what they use, even if irrelevant to the conversation.
Tade0 7mo ago
There's so many React libraries because the framew... I mean library is extremely barebones. That is, in my view, the main issue with React (rendering model notwithstanding): every React application is composed of tens of tiny dependencies and since there are several competing libraries for even basic things like routing, no two projects are the same.
endemic 7mo ago
And the end users pay the price!
yaku_brang_ja 7mo ago
Umm, are we really taking "being AI friendly" as an account to choose framework now? I’ve seen this mentioned often enough lately that it’s making me uncomfortable. I fear if this will becomes epidemic. This will literally hault progress in improving and adopting better frameworks.
- likium 7mo ago
  As a solo dev who picked SolidJS, yes, it is a big factor. Things like tldraw, node editors, wysiwyg editors, etc. Having to reimplement them is a huge time sink.

etler 7mo ago

React is slower than the alternatives, but next.js is really really slow.