6 ms·

As the saying goes: while (React.isPopular) { React.isPopular = true } It's actually quite sad because there are objectively better models both

As the saying goes: while (React.isPopular) { React.isPopular = true } It's actually quite sad because there are objectively better models both for performance and memory including Preact, Svelte, Vue, and of course vanilla.

chipgap98 2y ago
Does that really matter to most companies/developers? I’d much rather have a good enough solution with a large ecosystem built around it. It also takes a lot of investment for companies to change their tech stack
- CharlieDigital 2y ago
  > Does that really matter to most companies/developers? If you're asking about performance and memory, then yes, it does. This is especially true in e-commerce where many studies have shown that overall page performance has a correlation to conversion. Add to that the fact that a lot of e-commerce has moved to mobile web, there's a strong case for picking the best performing technologies versus developer preference -- especially if AI is generating it. But even outside of e-comm, consider government websites where you may have low income users that are using cheaper, older, lower capability devices to access information and services using lower speed networks to boot. I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home; it's easy for developers to forget that many times, their end users can be on older devices, on low performing networks, and other factors that affect performance and usability of web applications. > ...with a large ecosystem built around it When you can generate whatever you want nearly instantly, what does "ecosystem" mean? Your possibilities are endless and infinite. Your mindset is in a world where it's necessary to depend on the work of others because it's too expensive for you to write your own component library. Yes, that was true 1 year ago; why would you waste time and energy to create your own calendar component? But if an LLM can generate any bespoke component that you need in < 3 seconds, do you still need a third party component library? In fact, you may be better off for not creating the added external dependency.
  - madeofpalk 2y ago
    So, if you're a large e-commerce company that's trying to juice out last percentage points of conversion, and are researching alternate javascript libraries, is it plausable that the only research a development team would be to ask ChatGPT?
    - CharlieDigital 2y ago
      Unfortunately not the case because of GPT's bias towards React (the point of the article).
  - nottorp 2y ago
    > I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home And you still pay a few cents extra in power used because of all those inefficient and memory hungry "applications". You just don't notice.
  - SiliconSplash 2y ago
    > If you're asking about performance and memory, then yes, it does. Most places just don't care. I've worked 15 years as a contractor and only in once place have the business cared about optimisation. As long as it wasn't unbearable than it was "good enough". > This is especially true in e-commerce where many studies have shown that overall page performance has a correlation to conversion. Add to that the fact that a lot of e-commerce has moved to mobile web, there's a strong case for picking the best performing technologies versus developer preference -- especially if AI is generating it. This may have been true back in 2014. 5G networks are pretty fast and the the mobile web is pretty bloated. Performance is way down the list of concerns typically even by places that should care. I can write blazingly fast custom JS frameworks, the number of times anyone cares is exactly one time. > I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home; it's easy for developers to forget that many times, their end users can be on older devices, on low performing networks, and other factors that affect performance and usability of web applications. I have a 2010 Dell E6410 with 8GB of ram and an i7 640M (Dual Core, 4 thread). Almost every modern phone is faster now. I am not arguing we should make things bloated. I am just saying there isn't an incentive to optimise for low end devices because low end is better than a reasonably power Business Laptop of 10-15 years ago. > why would you waste time and energy to create your own calendar component? But if an LLM can generate any bespoke component that you need in < 3 seconds, do you still need a third party component library? The code from the LLM probably hasn't been battle tested. The open source react component library with 1000s of stars on github definitely has been. If you run into a problem with the LLM code you are probably going to be by yourself fixing it. I will take the component library over the LLM code everyday of the week.
- wrsh07 2y ago
  Fwiw, I work at a saas company and we do have some performance issues. It's about 50/50 split between not using react optimally and slow backend. If we were using svelte we would still have performance issues, but they would probably be centered more on "is the data in a sane shape such that this page can query it?"
spacephysics 2y ago
React has become the Java of late 90’s to mid 2000’s. Loads of libraries, documentation, and developers which creates a flywheel that will grow those aspects over the next X years. Until something comes up that is magnitude better in performance/maintainability, and even then it’ll take years to dethrone the status quo. Good questions in these comments essentially asking, does the level of training data on these models now contribute to the inertia we see from libraries, documentation, developer support? I believe so, but then again I think we’ll soon have more niche models for specific areas of development (like openart has with a variety of image gen models)
- marcosdumay 2y ago
  Most of the alternatives on the GP's comment have more than one order of magnitude better performance. Maintainability doesn't even enter the question. React's way is to rewrite. All of the alternatives on the GP's comment are possible to maintain.
- re-thc 2y ago
  > React has become the Java of late 90’s to mid 2000’s. Not comparable. Java may not have had big releases during this time but there were patches and support. Java 8 had numerous versions (>400). You can get paid support from Sun/Oracle. In terms of frameworks Spring was constantly upgraded and supported. React has none of these. Older React versions rarely get upgraded and just look at the amount of minor/patch releases React gets these days. It's almost as though Meta no longer cares. Earlier (<16) React was constantly updated. Nowadays it's just to peddle Vercel.
- tobyhinloopen 2y ago
  At least Java is good. React is absolutely terrible.
9rx 2y ago
But equally impressive that the Javascript community has actually managed to continue to use a single framework for more than five minutes without jumping to the next.
- trgn 2y ago
  had to have hooks though. And vanilla-OO had to go in favor of trapping state in closures, which is cooler because it has functions and not methods.
  - Hasu 2y ago
    You can still use vanilla-OO React. Do you complain when other frameworks add new features without breaking backwards compatibility?
    - trgn 2y ago
      I certainly did complain! And I'm sure I'll do it again if the new features aimed to supplant the old ones are worse. If you search anything about React now, 90% of the docs are hook-based. Beginners of React in 2025 will be guided to use a default pattern which has worse runtime footprint and adds a whole suite of new tool-specific coding guidelines ("rules of hook"). After years with it, I struggle to see what it has added in terms of building front-end SPas, yet the pattern is now the default for all using React.
    - CharlieDigital 2y ago
      > You can still use vanilla-OO React What we want is signals-based React because it would singularly fix the issue that the compiler is solving for and remove the need to even have `useMemo` and `useCallback`, improve performance, and remove a huge footgun. Because it has such a huge marketshare, a fix like this would have tremendous positive effects in web dev. We are all "forced" to use React so it would do all of us a great service if the team would just backstep and say "Oops, we made a design mistake here!". Instead, they spent almost 3 years building the compiler to sprinkle in memoization primitives because enough devs cannot get it right.
- 2y ago
onion2k 2y ago
and of course vanilla That depends on who is writing it and what the app is. Most frontend code is written by people who don't have as much time to focus on performance and optimization as core framework developers, so their once their apps reach a critical mass of 'actually big enough to benefit from a framework' the app is worse than it would have been if it was written with a framework in the first place. The problem for all of us, and where frameworks often make the web suck, is that very few apps are actually that big. Frontend developers love to put React in a page that has one form input a button, which is dumb.
- CharlieDigital 2y ago
  Ostensibly, an unbiased, well-trained model would solve this because it would/could write fast, performant vanilla. As a product owner, you probably care more about the performance of the product over the specific technical implementation details. I take that to be the point of the article: the bias towards React and of course the training data being stale means that generated code will always have a bit of staleness and as we provide less context for the AI (e.g. StackOverflow), the bias towards staleness will amplify given the large body of stale information it has ingested and amalgamated.
sesm 2y ago
Doesn't Preact use the same model but prioritise bundle size over performance?
- CharlieDigital 2y ago
  It's not the same model. Many, many (if not most) devs probably do not realize that React has an "inverted" model of reactivity and is in fact the root cause of it's performance woes. To the extent that the React team spent 2+ (almost 3?) years working on a compiler to address the issue by adding in the correct memoization primitives in a compile phase (trading increased memory consumption for more runtime performance...). I wrote about it here with code examples that work in JSFiddle: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react/ https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo... The short of it is that by pointing the reactive callback to the component function, it means that state within the component function has to be managed carefully. This doesn't happen in Vanilla, Preact, Solid, Svelte, and Vue because they point the reactive callback (via "signals") to a handler function that captures the component state in a closure. This is also why they are all faster and consume less memory than React. Because React points the reactive callback to the component function, it effectively starts from a clean slate each re-render so the purpose of React Hooks is to move state out and inject them back (thus they are called "hooks") when it re-renders. In Preact, this is not the case since it uses signals: https://preactjs.com/guide/v10/signals/ https://preactjs.com/guide/v10/signals/ A short video of the same examples if you prefer: https://youtu.be/7OhyP8H7KW0 https://youtu.be/7OhyP8H7KW0
  - sesm 2y ago
    The blogpost in the first link doesn't mention Preact at all. Preact is mostly API-compatible with React, and it having a different underlying model is an extraordinary claim that requires extraordinary evidence. I've read the docs on Preact signals, and they look like React refs, but put outside of components. edit: the last paragraph about refs
    - CharlieDigital 2y ago
klysm 2y ago
I think react hits a really good sweet spot in the trade off space. Sure it’s not the best thing that can exist, but it really does solve a lot of problems in a way that isn’t overly restrictive. My personal opinion is that a lot of the hate directed at react is due to experiences with code bases that aren’t good react code.
tcoff91 2y ago
React is better than all of those because of the existence of React Native, React Three Fiber, Remotion, etc… It has the best ecosystem of libraries and it’s not even close. If you write your web app in Vue and decide you want mobile apps later you won’t be able to share much code there.
ge96 2y ago
it's my goto along with NodeJS on the backend and Electron as a wrapper or React Native NGINX for my server though recently I ran into an out of connections problem that was new on an Azure VM

chipgap98 2y ago

Does that really matter to most companies/developers? I’d much rather have a good enough solution with a large ecosystem built around it. It also takes a lot of investment for companies to change their tech stack

CharlieDigital 2y ago
> Does that really matter to most companies/developers? If you're asking about performance and memory, then yes, it does. This is especially true in e-commerce where many studies have shown that overall page performance has a correlation to conversion. Add to that the fact that a lot of e-commerce has moved to mobile web, there's a strong case for picking the best performing technologies versus developer preference -- especially if AI is generating it. But even outside of e-comm, consider government websites where you may have low income users that are using cheaper, older, lower capability devices to access information and services using lower speed networks to boot. I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home; it's easy for developers to forget that many times, their end users can be on older devices, on low performing networks, and other factors that affect performance and usability of web applications. > ...with a large ecosystem built around it When you can generate whatever you want nearly instantly, what does "ecosystem" mean? Your possibilities are endless and infinite. Your mindset is in a world where it's necessary to depend on the work of others because it's too expensive for you to write your own component library. Yes, that was true 1 year ago; why would you waste time and energy to create your own calendar component? But if an LLM can generate any bespoke component that you need in < 3 seconds, do you still need a third party component library? In fact, you may be better off for not creating the added external dependency.
- madeofpalk 2y ago
  So, if you're a large e-commerce company that's trying to juice out last percentage points of conversion, and are researching alternate javascript libraries, is it plausable that the only research a development team would be to ask ChatGPT?
  - CharlieDigital 2y ago
    Unfortunately not the case because of GPT's bias towards React (the point of the article).
- nottorp 2y ago
  > I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home And you still pay a few cents extra in power used because of all those inefficient and memory hungry "applications". You just don't notice.
- SiliconSplash 2y ago
  > If you're asking about performance and memory, then yes, it does. Most places just don't care. I've worked 15 years as a contractor and only in once place have the business cared about optimisation. As long as it wasn't unbearable than it was "good enough". > This is especially true in e-commerce where many studies have shown that overall page performance has a correlation to conversion. Add to that the fact that a lot of e-commerce has moved to mobile web, there's a strong case for picking the best performing technologies versus developer preference -- especially if AI is generating it. This may have been true back in 2014. 5G networks are pretty fast and the the mobile web is pretty bloated. Performance is way down the list of concerns typically even by places that should care. I can write blazingly fast custom JS frameworks, the number of times anyone cares is exactly one time. > I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home; it's easy for developers to forget that many times, their end users can be on older devices, on low performing networks, and other factors that affect performance and usability of web applications. I have a 2010 Dell E6410 with 8GB of ram and an i7 640M (Dual Core, 4 thread). Almost every modern phone is faster now. I am not arguing we should make things bloated. I am just saying there isn't an incentive to optimise for low end devices because low end is better than a reasonably power Business Laptop of 10-15 years ago. > why would you waste time and energy to create your own calendar component? But if an LLM can generate any bespoke component that you need in < 3 seconds, do you still need a third party component library? The code from the LLM probably hasn't been battle tested. The open source react component library with 1000s of stars on github definitely has been. If you run into a problem with the LLM code you are probably going to be by yourself fixing it. I will take the component library over the LLM code everyday of the week.
wrsh07 2y ago
Fwiw, I work at a saas company and we do have some performance issues. It's about 50/50 split between not using react optimally and slow backend. If we were using svelte we would still have performance issues, but they would probably be centered more on "is the data in a sane shape such that this page can query it?"

spacephysics 2y ago

React has become the Java of late 90’s to mid 2000’s. Loads of libraries, documentation, and developers which creates a flywheel that will grow those aspects over the next X years. Until something comes up that is magnitude better in performance/maintainability, and even then it’ll take years to dethrone the status quo. Good questions in these comments essentially asking, does the level of training data on these models now contribute to the inertia we see from libraries, documentation, developer support? I believe so, but then again I think we’ll soon have more niche models for specific areas of development (like openart has with a variety of image gen models)

marcosdumay 2y ago
Most of the alternatives on the GP's comment have more than one order of magnitude better performance. Maintainability doesn't even enter the question. React's way is to rewrite. All of the alternatives on the GP's comment are possible to maintain.
re-thc 2y ago
> React has become the Java of late 90’s to mid 2000’s. Not comparable. Java may not have had big releases during this time but there were patches and support. Java 8 had numerous versions (>400). You can get paid support from Sun/Oracle. In terms of frameworks Spring was constantly upgraded and supported. React has none of these. Older React versions rarely get upgraded and just look at the amount of minor/patch releases React gets these days. It's almost as though Meta no longer cares. Earlier (<16) React was constantly updated. Nowadays it's just to peddle Vercel.
tobyhinloopen 2y ago
At least Java is good. React is absolutely terrible.

9rx 2y ago

But equally impressive that the Javascript community has actually managed to continue to use a single framework for more than five minutes without jumping to the next.

trgn 2y ago
had to have hooks though. And vanilla-OO had to go in favor of trapping state in closures, which is cooler because it has functions and not methods.
- Hasu 2y ago
  You can still use vanilla-OO React. Do you complain when other frameworks add new features without breaking backwards compatibility?
  - trgn 2y ago
    I certainly did complain! And I'm sure I'll do it again if the new features aimed to supplant the old ones are worse. If you search anything about React now, 90% of the docs are hook-based. Beginners of React in 2025 will be guided to use a default pattern which has worse runtime footprint and adds a whole suite of new tool-specific coding guidelines ("rules of hook"). After years with it, I struggle to see what it has added in terms of building front-end SPas, yet the pattern is now the default for all using React.
  - CharlieDigital 2y ago
    > You can still use vanilla-OO React What we want is signals-based React because it would singularly fix the issue that the compiler is solving for and remove the need to even have `useMemo` and `useCallback`, improve performance, and remove a huge footgun. Because it has such a huge marketshare, a fix like this would have tremendous positive effects in web dev. We are all "forced" to use React so it would do all of us a great service if the team would just backstep and say "Oops, we made a design mistake here!". Instead, they spent almost 3 years building the compiler to sprinkle in memoization primitives because enough devs cannot get it right.
2y ago

onion2k 2y ago

and of course vanilla That depends on who is writing it and what the app is. Most frontend code is written by people who don't have as much time to focus on performance and optimization as core framework developers, so their once their apps reach a critical mass of 'actually big enough to benefit from a framework' the app is worse than it would have been if it was written with a framework in the first place. The problem for all of us, and where frameworks often make the web suck, is that very few apps are actually that big. Frontend developers love to put React in a page that has one form input a button, which is dumb.

CharlieDigital 2y ago
Ostensibly, an unbiased, well-trained model would solve this because it would/could write fast, performant vanilla. As a product owner, you probably care more about the performance of the product over the specific technical implementation details. I take that to be the point of the article: the bias towards React and of course the training data being stale means that generated code will always have a bit of staleness and as we provide less context for the AI (e.g. StackOverflow), the bias towards staleness will amplify given the large body of stale information it has ingested and amalgamated.

sesm 2y ago

Doesn't Preact use the same model but prioritise bundle size over performance?

CharlieDigital 2y ago
It's not the same model. Many, many (if not most) devs probably do not realize that React has an "inverted" model of reactivity and is in fact the root cause of it's performance woes. To the extent that the React team spent 2+ (almost 3?) years working on a compiler to address the issue by adding in the correct memoization primitives in a compile phase (trading increased memory consumption for more runtime performance...). I wrote about it here with code examples that work in JSFiddle: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-model-of-react/ https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo... The short of it is that by pointing the reactive callback to the component function, it means that state within the component function has to be managed carefully. This doesn't happen in Vanilla, Preact, Solid, Svelte, and Vue because they point the reactive callback (via "signals") to a handler function that captures the component state in a closure. This is also why they are all faster and consume less memory than React. Because React points the reactive callback to the component function, it effectively starts from a clean slate each re-render so the purpose of React Hooks is to move state out and inject them back (thus they are called "hooks") when it re-renders. In Preact, this is not the case since it uses signals: https://preactjs.com/guide/v10/signals/ https://preactjs.com/guide/v10/signals/ A short video of the same examples if you prefer: https://youtu.be/7OhyP8H7KW0 https://youtu.be/7OhyP8H7KW0
- sesm 2y ago
  The blogpost in the first link doesn't mention Preact at all. Preact is mostly API-compatible with React, and it having a different underlying model is an extraordinary claim that requires extraordinary evidence. I've read the docs on Preact signals, and they look like React refs, but put outside of components. edit: the last paragraph about refs
  - CharlieDigital 2y ago

klysm 2y ago

I think react hits a really good sweet spot in the trade off space. Sure it’s not the best thing that can exist, but it really does solve a lot of problems in a way that isn’t overly restrictive. My personal opinion is that a lot of the hate directed at react is due to experiences with code bases that aren’t good react code.

tcoff91 2y ago

React is better than all of those because of the existence of React Native, React Three Fiber, Remotion, etc… It has the best ecosystem of libraries and it’s not even close. If you write your web app in Vue and decide you want mobile apps later you won’t be able to share much code there.

ge96 2y ago

it's my goto along with NodeJS on the backend and Electron as a wrapper or React Native NGINX for my server though recently I ran into an out of connections problem that was new on an Azure VM