If not React, then what?(infrequently.org)
infrequently.org
If not React, then what?
https://infrequently.org/2024/11/if-not-react-then-what/
742 comments
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices.
> Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.
Again: I beg to differ. Anyone hoping that their site will rank well on Google needs to factor in site performance via core web vitals. Time and time again I’ve seen React-based sites perform horribly and it’s very difficult to dig your way out of the hole after the fact.
I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.
I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices.
> Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.
Again: I beg to differ. Anyone hoping that their site will rank well on Google needs to factor in site performance via core web vitals. Time and time again I’ve seen React-based sites perform horribly and it’s very difficult to dig your way out of the hole after the fact.
I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.
> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low-end devices.
The entire site may take multiple seconds to load, sure, but it's quite rare that this is a React issue. Typically, the real issue is something like the website making a bunch of API requests in serial rather than parallel. For instance, the issue of JSON parsing that you cited is actually an SSR issue; that's entirely orthogonal to React, and you can make the same error in any other popular web framework.
> I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.
I think you're saying "React is slow" when you mean to say "the entire frontend ecosystem is slow". To which I respond... sure? None of this is React-specific. If you don't use React, you'll still have to use state management (or manage it yourself; have fun!), figure out something to do with CSS, etc, etc.
The entire site may take multiple seconds to load, sure, but it's quite rare that this is a React issue. Typically, the real issue is something like the website making a bunch of API requests in serial rather than parallel. For instance, the issue of JSON parsing that you cited is actually an SSR issue; that's entirely orthogonal to React, and you can make the same error in any other popular web framework.
> I actually think most of the problem isn’t React itself, it’s the ecosystem and the philosophy that surrounds it so often. You’ll have React, you’ll have some extra state management library on top, you’ll have some hideous CSS in JS bulk on top because no one wants to actually learn CSS… it’s all prioritisation of developer experience over user experience. And it’s industry standard these days.
I think you're saying "React is slow" when you mean to say "the entire frontend ecosystem is slow". To which I respond... sure? None of this is React-specific. If you don't use React, you'll still have to use state management (or manage it yourself; have fun!), figure out something to do with CSS, etc, etc.
I worked at New Relic and focused specifically on improving page load performance for one of the products using our RUM data. Even after combining/parallelizing API calls then embedding the data into the page, I found there was still an average 3-6 second average page load cost using React vs an already rendered HTML page which was nearly instant. Not huge but frustrating to discover the constraint when it was my task to improve it and our company was trying to be an example of great performance.
If your page is taking 3-6 seconds to load, you are either doing something wrong, or not understanding where the problem is and blaming React incorrectly.
My React app is statically exported and cached by the browser. There is only a single graphql call that fetches all necessary data. Backend is my only bottleneck. Everything else happens in less than 10ms.
And yes it is entirely possible to shoot yourself in the foot with any language and any framework. Including React.
My React app is statically exported and cached by the browser. There is only a single graphql call that fetches all necessary data. Backend is my only bottleneck. Everything else happens in less than 10ms.
And yes it is entirely possible to shoot yourself in the foot with any language and any framework. Including React.
That depends heavily on the device and network being used for testing. In my experience 3-6 seconds isn't out of the question by any means for a decent sized react SPA loaded on an older device and mobile network.
That isn't necessarily specific to react, any client-side rendered framework will have issues. React tends to be noticeably worse in my comparisons though, and any client rendering is going to be worse than server rendering your HTML.
That isn't necessarily specific to react, any client-side rendered framework will have issues. React tends to be noticeably worse in my comparisons though, and any client rendering is going to be worse than server rendering your HTML.
You measured that after a warm cache, or did you measure loading all the JS bonanza vs loading an ssr html?
I would think that using React as an SPA application makes sense, but not if you want to sprinkle some interactivity inside some html pages.
I would think that using React as an SPA application makes sense, but not if you want to sprinkle some interactivity inside some html pages.
API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" should happen. Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen.
It doesn't matter what library or framework is used - even jQuery can score 100% page speeds on Google Lighthouse. It really only depends on following every single nitpicky thing that Google Lighthouse recommends, and finding a solution for it. I took a site (actually a few thousand sites) that was scoring about 5 to 35 out of 100 on Google Lighthouse (depending on the customiztions), up to 100/100 on Google Lighthouse. It took a lot of work, but the clients are happy now.
Where React doesn't do well is with lots of DOM elements. In another project I created a complex web application that had about 3000 div elements with drag-and-drop interface and all kinds of stuff going on. Well React couldn't handle it. The browser started crashing due to memory issues if the page was open longer than 20 minutes or so, it slowed to a crawl and eventually froze. I ended up switching that one component to a canvas based solution (Konva) and it solved the problem completely. I still use React for all the other simple UI stuff, but I learned my lesson about what React is really good at and what it's not.
It doesn't matter what library or framework is used - even jQuery can score 100% page speeds on Google Lighthouse. It really only depends on following every single nitpicky thing that Google Lighthouse recommends, and finding a solution for it. I took a site (actually a few thousand sites) that was scoring about 5 to 35 out of 100 on Google Lighthouse (depending on the customiztions), up to 100/100 on Google Lighthouse. It took a lot of work, but the clients are happy now.
Where React doesn't do well is with lots of DOM elements. In another project I created a complex web application that had about 3000 div elements with drag-and-drop interface and all kinds of stuff going on. Well React couldn't handle it. The browser started crashing due to memory issues if the page was open longer than 20 minutes or so, it slowed to a crawl and eventually froze. I ended up switching that one component to a canvas based solution (Konva) and it solved the problem completely. I still use React for all the other simple UI stuff, but I learned my lesson about what React is really good at and what it's not.
> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor.
On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really slow pages down, in my experience. Excess API calls are just one (very common) source of excess RTTs.
The obvious compromise would be to load 'below-the-fold' content ASAP once all 'above-the-fold' content is finished, unless it's unacceptably heavy for the target device. (Then again, some people still won't be happy: I recently talked to one person who derided the load times of a certain blog, but I found that all of its meaningful content was loaded and visible very quickly: they were only taking issue with the Disqus comment widget at the bottom at the page.)
On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really slow pages down, in my experience. Excess API calls are just one (very common) source of excess RTTs.
The obvious compromise would be to load 'below-the-fold' content ASAP once all 'above-the-fold' content is finished, unless it's unacceptably heavy for the target device. (Then again, some people still won't be happy: I recently talked to one person who derided the load times of a certain blog, but I found that all of its meaningful content was loaded and visible very quickly: they were only taking issue with the Disqus comment widget at the bottom at the page.)
> Not every visitor can just make further requests near-instantly
We use a "loading" spinner. People know they have a shitty computer, and they'll wait an extra second instead of spending $1000 on a new computer. That kind of page speed problem isn't one we could ever fix, and it's something the user is typically well aware of being on their end, because every site is slow, not just ours.
> completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences
We use a combination of lazy loading and SSR (not React SSR, it's hosted on a custom CMS). Content is SSR to maximize SEO. In some places we'll only render the first 3 or 4 items and then lazy-load the rest if it's a lot of data. Too many DOM elements at page load is also bad for the page speed score. Javascript is lazy-parsed, meaning the text of the script can be loaded in-line, but not parsed until the page is scrolled and the content is in view. Loading the text of a script isn't what slows the page down, it's the parsing of larger scripts that causes page speed issues. When the page scripts can be parsed in smaller chunks, the scrolling experience can be more fluid and the page speed test is satisfied. All images below the fold are lazy loaded. All 3rd party widgets are lazy loaded where possible, because they all suck and they mess with page speed pretty badly. There are lots of other tricks to get to a perfect 100 score on Google Lighthouse. Fortunately for us, "below the fold" is generally easy to accomplish across all of our sites, by the nature of the type of sites we are building. It doesn't work for all kinds of sites, but for ours it works very well.
We use a "loading" spinner. People know they have a shitty computer, and they'll wait an extra second instead of spending $1000 on a new computer. That kind of page speed problem isn't one we could ever fix, and it's something the user is typically well aware of being on their end, because every site is slow, not just ours.
> completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences
We use a combination of lazy loading and SSR (not React SSR, it's hosted on a custom CMS). Content is SSR to maximize SEO. In some places we'll only render the first 3 or 4 items and then lazy-load the rest if it's a lot of data. Too many DOM elements at page load is also bad for the page speed score. Javascript is lazy-parsed, meaning the text of the script can be loaded in-line, but not parsed until the page is scrolled and the content is in view. Loading the text of a script isn't what slows the page down, it's the parsing of larger scripts that causes page speed issues. When the page scripts can be parsed in smaller chunks, the scrolling experience can be more fluid and the page speed test is satisfied. All images below the fold are lazy loaded. All 3rd party widgets are lazy loaded where possible, because they all suck and they mess with page speed pretty badly. There are lots of other tricks to get to a perfect 100 score on Google Lighthouse. Fortunately for us, "below the fold" is generally easy to accomplish across all of our sites, by the nature of the type of sites we are building. It doesn't work for all kinds of sites, but for ours it works very well.
I generate a report in our software and 70.000 cells work like a breeze (1000 rows, 70 columns). React just can’t handle adding an input to a cell.
It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie.
React is better than all predecessors, but it’s still the wrong abstraction.
It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie.
React is better than all predecessors, but it’s still the wrong abstraction.
What about AG Grid? We have apps at work with 1M+ cells. I am pretty sure that AG Grid has React support.
> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor.
I really hope nobody takes this "advice". What are you trying to save me from?
I really hope nobody takes this "advice". What are you trying to save me from?
I'm not trying to save you from anything. Stop being dramatic. I honestly don't care what you do or what advice you take.
I'm with albedoa on this one. Loading things only when you scroll to them makes for a terrible scrolling experience.
You obviously didn't read what I wrote or understand it. I specifically said this:
>Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen."
I specifically said you could load a script in-line for stuff "below the fold" as long as the browser doesn't parse it until it's used. That's very different than doing an HTTP request for a script file while scrolling.
But you know what? Forget it. I'm done trying to explain things to people who think they already know it all and didn't even understand my original comment.
>Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen."
I specifically said you could load a script in-line for stuff "below the fold" as long as the browser doesn't parse it until it's used. That's very different than doing an HTTP request for a script file while scrolling.
But you know what? Forget it. I'm done trying to explain things to people who think they already know it all and didn't even understand my original comment.
You also said
> We use a "loading" spinner
> users can wait an extra second [every time they scroll to load new content]
which is exactly the bad experience the commenters above are talking about.
They understood your comment, and they disagree. This is not the good advice you think it is, unless your main goal is to score 100 on lighthouse for SEO purposes, not UX.
> We use a "loading" spinner
> users can wait an extra second [every time they scroll to load new content]
which is exactly the bad experience the commenters above are talking about.
They understood your comment, and they disagree. This is not the good advice you think it is, unless your main goal is to score 100 on lighthouse for SEO purposes, not UX.
The loading spinner is specifically for people with shitty internet connections when loading dynamic data after the initial page load. And you're completely misunderstanding practically everything I wrote and replacing what I wrote with your assumptions. Go ahead, it's the internet, bash away all you want. But I know what I did, I know it works, and I know it's not janky at all - it's your assumptions that are wrong. The advice is good, your understanding of it is not. You don't need to reply, I won't be trying to explain any of this any further just so you can misunderstand everything I wrote, again.
People scroll pages to skim. This also sounds like it might break CTRL-F.
If I can't skim your page instantly I will more than likely churn my visit.
Doesn't matter that I have a good computer on a 1Gbps connection, you ruined my experience. I'd rather wait 1 sec for the full page to load, than wait a series of 100msecs on what should've been a fully loaded page to actually load at an arbitrary point in time.
If I can't skim your page instantly I will more than likely churn my visit.
Doesn't matter that I have a good computer on a 1Gbps connection, you ruined my experience. I'd rather wait 1 sec for the full page to load, than wait a series of 100msecs on what should've been a fully loaded page to actually load at an arbitrary point in time.
Maybe you missed the part where I said we're using SSR for content? That solves the CTRL-F problem easily.
You (and a lot of others here) are making a ton of wrong assumptions, imagining things I never said, and making up your own problems that don't exist in my code just to try to bash me, without even really understanding anything that I wrote in my comment. This entire thread sucks and is full of low-quality trolls. I've been doing front-end for ~30 years, I know what I'm doing. Don't bother replying, I won't be responding to further wrong assumptions and bashing.
You (and a lot of others here) are making a ton of wrong assumptions, imagining things I never said, and making up your own problems that don't exist in my code just to try to bash me, without even really understanding anything that I wrote in my comment. This entire thread sucks and is full of low-quality trolls. I've been doing front-end for ~30 years, I know what I'm doing. Don't bother replying, I won't be responding to further wrong assumptions and bashing.
How do you know that was a React issue and not a memory leak, or an error in your own code perhaps?
This smells of a memory leak, particularly if you forgot to add a dependency to a hook for example, but there is plenty of non react related code that could go wrong with drag and drop interfaces too
This smells of a memory leak, particularly if you forgot to add a dependency to a hook for example, but there is plenty of non react related code that could go wrong with drag and drop interfaces too
Not using any hooks, it's simple old-school react started from create-react-app, then converted over to Preact, and then updated to use latest webpack and all libs updated to latest versions, so this project has gone through many changes and I have no doubt if I started it new today from the ground up things would be different. I think the problem was with the drag-drop library, react-dnd I think. But the point is that switching from DOM to a canvas solution fixed all the problems I was having.
>it’s all prioritisation of developer experience over user experience.
And I have been saying this for well over a decade. Hopefully it catches on.
I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, why not go back to Interactive Web Pages that is mostly Jank Free. I say mostly because it is still not Native Apps level.
Recently submitted, [1] why does liking a tweet re-render the entire screen? done using [2] React-scan.
[1] https://x.com/aidenybai/status/1862529226727121366
[2] https://github.com/aidenybai/react-scan
And I have been saying this for well over a decade. Hopefully it catches on.
I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, why not go back to Interactive Web Pages that is mostly Jank Free. I say mostly because it is still not Native Apps level.
Recently submitted, [1] why does liking a tweet re-render the entire screen? done using [2] React-scan.
[1] https://x.com/aidenybai/status/1862529226727121366
[2] https://github.com/aidenybai/react-scan
> why does liking a tweet re-render the entire screen?
They're probably using Redux, which has been the go-to for state management in React for nearly a decade. I've always been averse to it because it's implemented using contexts and triggers those full re-renders - it was designed during the class-based components era and relied on people actually implementing shouldComponentUpdate(), which isn't really a thing with modern function-based components.
If they were using modern hook-based state management like Zustand or Valtio, full rerenders wouldn't happen.
They're probably using Redux, which has been the go-to for state management in React for nearly a decade. I've always been averse to it because it's implemented using contexts and triggers those full re-renders - it was designed during the class-based components era and relied on people actually implementing shouldComponentUpdate(), which isn't really a thing with modern function-based components.
If they were using modern hook-based state management like Zustand or Valtio, full rerenders wouldn't happen.
Redux uses context but does not do full re-renders except if you are using it wrong. It does a shallow compare on the object resulting from your selector to decide whether or not to re-render a component.
That being said, none of the React projects I've had the chance of working on in the last 5 or 6 years has used Redux, so stating that it's been the go-to state management library for nearly a decade kind of sounds weird to me.
That being said, none of the React projects I've had the chance of working on in the last 5 or 6 years has used Redux, so stating that it's been the go-to state management library for nearly a decade kind of sounds weird to me.
> on an old or cheap Android device.
My Core-i5 24GB of RAM desktop PC that's 8 years old can pretty much do anything I used to do in 2016, except smoothly run React websites, some of which are verging on becoming unusable.
This is nuts. People should stop using their M3 Pro Macbook as a benchmark for what's 'fast enough.'
My Core-i5 24GB of RAM desktop PC that's 8 years old can pretty much do anything I used to do in 2016, except smoothly run React websites, some of which are verging on becoming unusable.
This is nuts. People should stop using their M3 Pro Macbook as a benchmark for what's 'fast enough.'
“Works on my machine” in general is a huge problem in dev culture.
I understand the desire to work on machines with lots of power and memory with a nice high res display and fiber connection. It makes the experience a great deal nicer. Even so, we should be keeping old and/or thoroughly mediocre devices around and testing on them periodically so we don’t succumb to illusions of good performance.
I understand the desire to work on machines with lots of power and memory with a nice high res display and fiber connection. It makes the experience a great deal nicer. Even so, we should be keeping old and/or thoroughly mediocre devices around and testing on them periodically so we don’t succumb to illusions of good performance.
It’s just embarrassing any image scrolling site will eventually just eat all the memory and crash and you lose your place. Used to kill me back in the Tumblr days and React perpetuates it.
That is an implementation issue, not a framework issue.
There are plenty of easy to use virtual scrolling libraries for React and vanilla JS. There is also `content-visibility` with CSS Containment now.
There are plenty of easy to use virtual scrolling libraries for React and vanilla JS. There is also `content-visibility` with CSS Containment now.
I’d love to see how those new options perform these days by replicating a large tumblr blog or instagram feed. Might be a fun project.
[deleted]
>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device.
that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor.
if that isn't enough for your react powered site, you are doing something very wrong.
that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor.
if that isn't enough for your react powered site, you are doing something very wrong.
Multiple times daily I encounter sites that are brutally slow not just on my beefy Android phone, but on my 3GHz+ 8-core 64GB desktop machine.
You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.
You need to take performance seriously or it will just be bad. Most of the industry has chosen to be bad.
Well, tracking and advertisement will be doing it, not react.
Keep in mind that React is very single threaded (as is nearly everything in javascript). These phones might have 8 cores; but they tend to have the same single thread performance as 10+ year old iPhones.
That assumes that the bottleneck is JS parsing/execution. The browser itself is not single-threaded and can load/parse resources in parallel.
And I don't buy that most websites would have react as the bottleneck, over the million other js libs, ads and tracking.
And I don't buy that most websites would have react as the bottleneck, over the million other js libs, ads and tracking.
No one is asking you to buy it, there is tons of empirical data you can analyze for yourself.
The performance of client-side web applications asymptotically approaches load times of "at most a few hundred milliseconds" on the high end phone models owned by developers.
React sites still feel janky on my 24cores and 48gigs or ram. Which is impressive for all the wrong reasons.
Which react sites? Are you sure you are not a victim of confirmation bias? How often do you check what framework does a smooth and performance website uses?
Because demo sites are snappy on even low-end devices. It's not react itself that causes slowness, but all the other libraries/tracking/ads.
Because demo sites are snappy on even low-end devices. It's not react itself that causes slowness, but all the other libraries/tracking/ads.
This answers your questions: https://astro.build/blog/2023-web-framework-performance-repo...
Which (correctly) doesn't even have react listed, only frameworks that (may) use react as a library.
So at least be specific what is problematic, is it a particular framework, a particular library, the whole idea behind react (v=f(s)) or what? Anything can be proven against something non-concrete.
So at least be specific what is problematic, is it a particular framework, a particular library, the whole idea behind react (v=f(s)) or what? Anything can be proven against something non-concrete.
Yes.
I largely agree with your points, but wish it’d be easier to have server side rendering that’s not as tightly coupled to the rest of the system.
What almost always happens is that with a SPA the core business logic is more or less separate from the bits that are shown in the browser, so that if AngularJS gets deprecated you still have an API that you can use for your Vue/React/Angular rewrite.
However, if JSF becomes too much of a maintenance burden, the chances of me migrating to HTMX or a similar technology, even a full on SPA are pretty close to 0% when I have only a similar amount of time as in the case above.
Why? Because the previous implementation is going to be in the same codebase and like it or not, as more time passes and as more people work on the codebase, there will be coupling. Those technologies will intertwine to such a degree, that a clear cut replacement will be really difficult.
I guess what I’m pondering is why we don’t have an RPC/IPC component as a central part of Django, Rails, Laravel, JSF and all the others - so I could have server side rendering but separate repos (with separately managed dependencies) for the back end and the front end.
Maybe even deploy them as separate containers that talk to one another and have resources managed separately, so the old JSF permission check logic for rendering components in a deep tree cannot eat the CPU time that’s needed for some scheduled processes in the back end.
What almost always happens is that with a SPA the core business logic is more or less separate from the bits that are shown in the browser, so that if AngularJS gets deprecated you still have an API that you can use for your Vue/React/Angular rewrite.
However, if JSF becomes too much of a maintenance burden, the chances of me migrating to HTMX or a similar technology, even a full on SPA are pretty close to 0% when I have only a similar amount of time as in the case above.
Why? Because the previous implementation is going to be in the same codebase and like it or not, as more time passes and as more people work on the codebase, there will be coupling. Those technologies will intertwine to such a degree, that a clear cut replacement will be really difficult.
I guess what I’m pondering is why we don’t have an RPC/IPC component as a central part of Django, Rails, Laravel, JSF and all the others - so I could have server side rendering but separate repos (with separately managed dependencies) for the back end and the front end.
Maybe even deploy them as separate containers that talk to one another and have resources managed separately, so the old JSF permission check logic for rendering components in a deep tree cannot eat the CPU time that’s needed for some scheduled processes in the back end.
> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on low end devices.
Try doing it on a flagship handset like a Pixel 8 Pro, and it's still a slow and miserable experience.
m.facebook.com, as an example.
Try doing it on a flagship handset like a Pixel 8 Pro, and it's still a slow and miserable experience.
m.facebook.com, as an example.
These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications".
In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time your users are on either Chrome or Safari on a relatively modern Mac or Windows machine. In many cases the application loads once at the start of at least 10+ minutes of work, so initial load times rarely matter much.
If you're building a website that needs SEO, then yeah, React is completely the wrong tool, and you should just make a proper static site or hook your marketing team up with WordPress (or whatever takes its place once Matt is finished blowing it up). But those use cases, while common, represent a tiny fraction of total engineering effort across the industry, so most web developers here don't have the design constraints that make React a bad choice.
In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time your users are on either Chrome or Safari on a relatively modern Mac or Windows machine. In many cases the application loads once at the start of at least 10+ minutes of work, so initial load times rarely matter much.
If you're building a website that needs SEO, then yeah, React is completely the wrong tool, and you should just make a proper static site or hook your marketing team up with WordPress (or whatever takes its place once Matt is finished blowing it up). But those use cases, while common, represent a tiny fraction of total engineering effort across the industry, so most web developers here don't have the design constraints that make React a bad choice.
I would also add that even in that last scenario React can be a great tool, there are many solutions that use React but make fully static exports (Nextjs/astro/gatsby/etc).
Pre-rendering everything has downsides of course, but it doesn't get much faster than that.
I think it's also a misconception that there is such a clear divide between app and content-oriented websites. Even the most content heavy websites, news sites for example, are highly interactive these days. Show me a popular content heavy site that doesn't have some sort of log in, interactive content, comment section, filtering, live blogs, alerts, notifications, search, and similar.
You also have to take into account the advantages of pre-fetching links, and only fetching and replacing the content instead of doing full page re-renders. All of these great things you can do easily with React and a React framework of your choice. You can even go further and have a hybrid of statically exported pages, SSR, and some SPA like highly interactive parts, reusing the same exact components in all these strategies.
All to say: React can be a great choice for a lot of use cases, also for content heavy websites.
Pre-rendering everything has downsides of course, but it doesn't get much faster than that.
I think it's also a misconception that there is such a clear divide between app and content-oriented websites. Even the most content heavy websites, news sites for example, are highly interactive these days. Show me a popular content heavy site that doesn't have some sort of log in, interactive content, comment section, filtering, live blogs, alerts, notifications, search, and similar.
You also have to take into account the advantages of pre-fetching links, and only fetching and replacing the content instead of doing full page re-renders. All of these great things you can do easily with React and a React framework of your choice. You can even go further and have a hybrid of statically exported pages, SSR, and some SPA like highly interactive parts, reusing the same exact components in all these strategies.
All to say: React can be a great choice for a lot of use cases, also for content heavy websites.
The top sites using react are all e-commerce or social sites. I would bet the majority of react sites and devs that use them are not building apps that require SPA or something like React. Which is the problem.
> I would bet the majority of react sites and devs that use them are [n]ot building apps that require SPA or something like React. [edited to restore what I assume is the ended meaning]
On what basis do you bet this, though?
Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see, because you're not the target demographic.
I don't have survey data one way or the other, but anecdotally everywhere I've worked on an SPA has been a clear case where trying to do it in backend+JQuery would have been a huge failure.
On what basis do you bet this, though?
Sure, you see sites that bug you by being slow in contexts where you'd choose something else, but most devs are working on sites and apps that you will never see, because you're not the target demographic.
I don't have survey data one way or the other, but anecdotally everywhere I've worked on an SPA has been a clear case where trying to do it in backend+JQuery would have been a huge failure.
But there is a wide gulf between backend + JQuery and SPA. The frustration often shown is people treating the extremes as the only options available. Having a use case for which backend + jQuery doesn't cut it doesn't require reinventing navigation state and history in JS, or loading every stat on the page via JSON. There are middle grounds.
What middle ground do you propose that's as efficient to get rolling as React in 2024? You talk about not reinventing state and history in JS, but at this point the reinvention is already done and React is the pragmatic choice that you pick when you don't want to reinvent the frontend.
There are a bunch of stacks that I prefer to work in for my own projects, but what I need at work is almost always the standard option that everyone is already used to.
There are a bunch of stacks that I prefer to work in for my own projects, but what I need at work is almost always the standard option that everyone is already used to.
Here is one middle ground https://hotwired.dev/
Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.
OK, let me restate something from my previous component explicitly: a site that’s concerned with SEO is not a “specialized domain”. It is very, very common.
So are web applications that are completely behind auth and never need to care about SEO.
They're quite different and it's a shame they're usually mixed up in these discussions.
They're quite different and it's a shame they're usually mixed up in these discussions.
Many sites have a two tier application with a CMS SEO “landing page” abd conversion funnel run by the marketing department and a user-login that takes you to a separate website that is SEO irrelevant.
So… a site that doesnt care about SEO and is not indexed and is purely for logged in users is also very common.
So… a site that doesnt care about SEO and is not indexed and is purely for logged in users is also very common.
I don’t really understand the disagreement here. I didn’t claim those sites are rare. I was specifically refuting the OPs claim that page load time only matters in a small number of specialized domains. I am saying it is very common for it to matter. It’s also very common for it to not matter, you’ll get no argument from me there.
With React Server Components, you can have your cake and eat it too, by sending only the necessary HTML to the browser (thereby having good performance and SEO) but also hydrating with more interactivity if necessary. And I'm not sure where you think CSS in JS means you don't learn CSS, I'm not sure how you'd use it otherwise... Either way, there are CSS in JS (TypeScript) libraries that compile down to regular CSS classes, like PandaCSS, so again, you can have your cake and eat it too.
React Server Components strikes me as React solving a React-caused problem with yet more React. Which is fine, I guess, if you’re already locked into the React ecosystem. But as someone that isn’t, looking at the whole proposition from the outside, it just screams vendor lock-in to me. There are too many devs out there only expert in the way React does things and can’t step outside of it. RSC is an additional crutch that allows this to continue but that doesn’t mean it’s healthy.
My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t.
If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t.
If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
Perhaps it is vendor lock in, but the concept as a whole is not that difficult to generalize, as other frontend frameworks have their own sorts of implementations of the concept. Phoenix in the Elixir world has LiveView, for example. It's just that React's is more seamless, especially with TypeScript, as you can run JS (TypeScript) on both the client and server, so that you have greater control over exactly which components you want to be on the client versus the server without having to do so manually if you were to use something like Rails or Django. Therefore, even if you are making something like blogs, you can still use React as essentially a templating language via JSX and also use React for interactivity, for example a comment form component.
> React Server Components strikes me as React solving a React-caused problem with yet more React.
This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it.
Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability.
I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites.
> There are too many devs out there only expert in the way React does things and can’t step outside of it.
This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day.
> But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.
This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it.
Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability.
I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites.
> There are too many devs out there only expert in the way React does things and can’t step outside of it.
This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day.
> But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.
> Maybe you write isomorphic javascript
I’m surprised to see people still misusing the word isomorphic.
I’m surprised to see people still misusing the word isomorphic.
it's been a term of art for a long time
That's technically true. Indeed, "isomorphism" has been a term of art for about 200 years.
More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.
More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.
It's been used to describe code that does A on server and B on client side, where A and B are deeply related but definitely not the same. It's not just code sharing, that's just a small part of it.
My argument is that it's a forced and silly misuse of the word.
I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?
I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?
Yeah, that's why everyone switched to "universal" after a year or two. But some people are not as up to date and some libraries kept their old names.
I wasn't aware that the favoured term had changed. I do think universal is clearer and much less silly.
The original problem was caused by PHP (see XHP) and this is just bringing the solution to full feature parity.
You literally cannot. You can bake two cakes. You can’t have your cake and eat it too.
Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)
Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)
One of the ways you know a project is going wrong is when it's using JS to do things that HTML and CSS should be doing.
> You literally cannot. You can bake two cakes. You can’t have your cake and eat it too.
It is a common saying, not to be taken "literally."
> The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged.
> Have you ever looked at the css output?
Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.
It is a common saying, not to be taken "literally."
> The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged.
> Have you ever looked at the css output?
Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.
I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.
I never said there weren't tradeoffs, just that RSCs enable greater functionality than before, such that one can "have their cake and eat it too," but it's not meant to mean that there are only two cakes in this entire analogical universe. Other frameworks (ie, cakes) have their own tradeoffs.
Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.
Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing.
The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks.
When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.
Likely many developers don’t even know how to build something without React. They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along and its siren song drew away many developers, and, worse, created an entire generation that fits the criteria I’m describing.
The author doesn’t need to describe an alternative any more than he did, because the alternative is supposed to be self-evident. If it’s not, the person is supposed to take the plethora of breadcrumbs in the article and figure out how we used to do things before bloated, convoluted, and typically unnecessary frameworks.
When you look at something like Remix and Next you see people trying go back to the simple (forms, server rendering) by adding additional complexity. It’s doubling down on complexity, rather than finding simplicity.
> Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.
The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.
> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along
Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.
The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.
> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along
Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.
> The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial)
Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers).
> with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket)
What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach. There are even more interactive applications like hey.com (a full-on email client) that is server rendered.
My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.
> Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.
Are you trolling? The things I listed are "over-complicated"? HTML is what React renders. You need to write something like it when you write your JSX. Sorry, you gotta know that. Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive or SEO. Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.
And, "debug some HTML"?
Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers).
> with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket)
What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach. There are even more interactive applications like hey.com (a full-on email client) that is server rendered.
My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.
> Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.
Are you trolling? The things I listed are "over-complicated"? HTML is what React renders. You need to write something like it when you write your JSX. Sorry, you gotta know that. Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive or SEO. Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.
And, "debug some HTML"?
> What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach.
As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.
Theoretically it's conceivable that someone might have a website that needed only flat forms with zero dynamism. But I've found that everyone thinks their website is like that, and they're always wrong. Every Rails/Django/Wicket/etc. site ends up needing one little piece of unmanaged JavaScript somewhere (unless you're lucky enough for a server roundtrip to be acceptable latency-wise). And then one more piece. And then you have a state management problem.
> My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.
You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them. Apart from anything else, how do you do handle the client-side state in the Rails case?
> HTML is what React renders. You need to write something like it when you write your JSX.
Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.
> Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive
I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.
> or SEO.
Perhaps - but not everyone needs SEO.
> Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.
It really isn't these days. Even a very inclusive baseline of browser support still gives you plenty to work with - e.g. flexbox is 12 years old at this point. It's entirely practical to set a reasonable baseline and just not do progressive enhancement (particularly since often the "worst" browser you're targeting - iOS Safari - is also the one that most of your customer base by value uses, so there's little to gain from progressive enhancement).
As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.
Theoretically it's conceivable that someone might have a website that needed only flat forms with zero dynamism. But I've found that everyone thinks their website is like that, and they're always wrong. Every Rails/Django/Wicket/etc. site ends up needing one little piece of unmanaged JavaScript somewhere (unless you're lucky enough for a server roundtrip to be acceptable latency-wise). And then one more piece. And then you have a state management problem.
> My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.
You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them. Apart from anything else, how do you do handle the client-side state in the Rails case?
> HTML is what React renders. You need to write something like it when you write your JSX.
Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.
> Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive
I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.
> or SEO.
Perhaps - but not everyone needs SEO.
> Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.
It really isn't these days. Even a very inclusive baseline of browser support still gives you plenty to work with - e.g. flexbox is 12 years old at this point. It's entirely practical to set a reasonable baseline and just not do progressive enhancement (particularly since often the "worst" browser you're targeting - iOS Safari - is also the one that most of your customer base by value uses, so there's little to gain from progressive enhancement).
> As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.
Yep, we have all this. Server round-trip is acceptably fast. Perhaps we are lucky because most users are in the US.
The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing. They only see that, and they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.
> You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them.
It wasn't our first app. We're actually very well versed in it. I just looked it up and the first app I worked on w/ React was in 2014. I worked in it exclusively for 7 years or so before making what I thought at the time was a the very risky switch, mid-stream with my current client to server rendering. Almost the whole team knew React better. Using Rails wasn't just a little bit more productive, or a little better, it was night and day.
> Apart from anything else, how do you do handle the client-side state in the Rails case?
There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple. Event hook, write to session storage. On load, read from session storage.
For everything else, it's a server round trip.
Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible. Yet, it's not.
> Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.
It's a flippant analogy here because you can't get away from the HTML. Sure, if you never look at the dev tools, or you always use the React dev tools, you always see your HTML wrapped in React components, but uhm, it's HTML wrapped in React components. You don't write assembly and give it a C function header. Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.
> I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.
Anything is possible. We would have to define fast, however. I mentioned TTI. The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers. Furthermore, in order to get reasonable TTI, you either need a small app, or you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.
> It really isn't these days.
Ok. Keep in mind it's always changing. Container queries? Clamp? Various things over the years have been useful to be able to use and worth doing progressively. I agree though that the gap is reducing. We hardly do any progressive enhancement. We are also not targeting markets that would benefit from it. We can luckily mandate an evergreen browser because of who our users are. Not everyone is in that situation.
Yep, we have all this. Server round-trip is acceptably fast. Perhaps we are lucky because most users are in the US.
The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing. They only see that, and they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.
> You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them.
It wasn't our first app. We're actually very well versed in it. I just looked it up and the first app I worked on w/ React was in 2014. I worked in it exclusively for 7 years or so before making what I thought at the time was a the very risky switch, mid-stream with my current client to server rendering. Almost the whole team knew React better. Using Rails wasn't just a little bit more productive, or a little better, it was night and day.
> Apart from anything else, how do you do handle the client-side state in the Rails case?
There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple. Event hook, write to session storage. On load, read from session storage.
For everything else, it's a server round trip.
Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible. Yet, it's not.
> Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.
It's a flippant analogy here because you can't get away from the HTML. Sure, if you never look at the dev tools, or you always use the React dev tools, you always see your HTML wrapped in React components, but uhm, it's HTML wrapped in React components. You don't write assembly and give it a C function header. Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.
> I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.
Anything is possible. We would have to define fast, however. I mentioned TTI. The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers. Furthermore, in order to get reasonable TTI, you either need a small app, or you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.
> It really isn't these days.
Ok. Keep in mind it's always changing. Container queries? Clamp? Various things over the years have been useful to be able to use and worth doing progressively. I agree though that the gap is reducing. We hardly do any progressive enhancement. We are also not targeting markets that would benefit from it. We can luckily mandate an evergreen browser because of who our users are. Not everyone is in that situation.
> The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing.
If you're making something users don't have much choice about using - either an internal business app (the article has a box about those), or a professional tool that adds major capabilities - then you can get away with it, just as you can get away with quite bad UI in general. But if you're making something that has to appeal to users, perceptible and even imperceptible latency when they click drives them away. I'm not claiming it's rational, but developers "fixate" on it because it matters to users; I wish I could just keep writing Wicket, but I can't argue with the numbers or even just my own experience of what using these UIs feels like.
> they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.
Why though? Like, there might be specific things React does wrong (and I know that Rails is very productive for some people, much as I hate it), but there's nothing fundamental about using an SPA framework rather than a server-side framework that should make it less productive. If I want a form with 2 dropdowns and 3 text fields, that's the same question in either context, and should take the same amount of code to answer.
> There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple.
Fair enough - you made it sound like there was a lot of client-server state that was relevant. If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users, you have state on the client in an unmanaged way and get horrible glitches when the server and client disagree (e.g. client is on one tab of the form but server thinks it's on another tab), or you have state on the client in a managed way and use an SPA framework (or something indistinguishable from one).
> Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible.
No, but I've used similar systems. Yes you can make them. Yes they feel fast enough, if you haven't used the alternative (especially if you happen to be located close to the server). But they're clunky enough that they can't succeed in the market.
> Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.
The edge cases are what take the time when learning though. Like, yes, you probably do need to be able to read HTML-like syntax without getting confused. But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.
> The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers.
Most apps full stop fail to achieve good performance numbers. It always takes effort. I suspect the average React app probably is slower, partly because React sites are generally newer and mostly because React lowers the bar for developer quality needed to get anything to work at all, but that doesn't mean there's a problem with the tool.
> you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.
It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase. It continued to work, and be fast - I think maybe one time in a couple of years we got alerted that we'd done something that messed up the code splitting and we fixed it. Maybe it is complexity, but it's not complexity that imposes any real overhead in actual day-to-day development.
If you're making something users don't have much choice about using - either an internal business app (the article has a box about those), or a professional tool that adds major capabilities - then you can get away with it, just as you can get away with quite bad UI in general. But if you're making something that has to appeal to users, perceptible and even imperceptible latency when they click drives them away. I'm not claiming it's rational, but developers "fixate" on it because it matters to users; I wish I could just keep writing Wicket, but I can't argue with the numbers or even just my own experience of what using these UIs feels like.
> they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.
Why though? Like, there might be specific things React does wrong (and I know that Rails is very productive for some people, much as I hate it), but there's nothing fundamental about using an SPA framework rather than a server-side framework that should make it less productive. If I want a form with 2 dropdowns and 3 text fields, that's the same question in either context, and should take the same amount of code to answer.
> There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple.
Fair enough - you made it sound like there was a lot of client-server state that was relevant. If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users, you have state on the client in an unmanaged way and get horrible glitches when the server and client disagree (e.g. client is on one tab of the form but server thinks it's on another tab), or you have state on the client in a managed way and use an SPA framework (or something indistinguishable from one).
> Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible.
No, but I've used similar systems. Yes you can make them. Yes they feel fast enough, if you haven't used the alternative (especially if you happen to be located close to the server). But they're clunky enough that they can't succeed in the market.
> Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.
The edge cases are what take the time when learning though. Like, yes, you probably do need to be able to read HTML-like syntax without getting confused. But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.
> The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers.
Most apps full stop fail to achieve good performance numbers. It always takes effort. I suspect the average React app probably is slower, partly because React sites are generally newer and mostly because React lowers the bar for developer quality needed to get anything to work at all, but that doesn't mean there's a problem with the tool.
> you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.
It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase. It continued to work, and be fast - I think maybe one time in a couple of years we got alerted that we'd done something that messed up the code splitting and we fixed it. Maybe it is complexity, but it's not complexity that imposes any real overhead in actual day-to-day development.
> but developers "fixate" on it because it matters to users
Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). Don't get me wrong, I pay for superhuman because it feels like a native app and gets many things right. I would not pay for hey.com. But hey.com is actually relatively successful out there despite its sometimes-perceptible latency. Oh, and superhuman has perceptible latency too. Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML. The delta between those two is pretty small now-a-days, and typically not perceivable.
> If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users
I mean, we do. Our forms are pretty sophisticated. Things add/remove show/hide, and they update live as others make changes. The state just doesn't need to be on the client. You say maybe we're a unicorn, I say maybe people should consider whether or not they are a unicorn too, and maybe those unicorns are just horses developers think are unicorns. They may just be a lot more common than you (and others) think. We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.
> But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.
I'm not sure how to say this... but literally none of this is typically significant and certainly not any more significant than it is in React. In React you still need to know the tags and the attributes. Escaping rules? Yea, you need to know those too -- just the JavaScript ones. Self-closing tags? Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances. I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.
> I suspect the average React app probably is slower, partly because React sites are generally newer...
This isn't why. It's because it requires a significant amount of JavaScript to load and evaluate before you see anything. That amount can get larger with time.
> It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase...
Right. That stuff is O(1)-ish, and maybe it's stabilized some, but having gone through the various transitions, I can say it's not free. Nothing is though, upgrading Rails took us a couple hours this time around because of a breaking change for our 30 apps. React comes with, as a baseline, significant complexity that is O(n): Client/server separation (APIs or phantom-APIs like Next.JS has), state entangled with presentation (See the whole smart vs dumb components for an attempt to address this), massive asynchronous concerns that cannot be fully abstracted away (suspense and the like), and probably more.
Folks can't see it until they step away from it and look back. I've done that for the last 3 years. Unless a person has done it, I wouldn't expect my arguments to land. Folks see things or they don't. Again, I'm only here to say: there's something to see that you may not see yet. I'm sorry I don't have anything more convincing.
Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). Don't get me wrong, I pay for superhuman because it feels like a native app and gets many things right. I would not pay for hey.com. But hey.com is actually relatively successful out there despite its sometimes-perceptible latency. Oh, and superhuman has perceptible latency too. Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML. The delta between those two is pretty small now-a-days, and typically not perceivable.
> If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users
I mean, we do. Our forms are pretty sophisticated. Things add/remove show/hide, and they update live as others make changes. The state just doesn't need to be on the client. You say maybe we're a unicorn, I say maybe people should consider whether or not they are a unicorn too, and maybe those unicorns are just horses developers think are unicorns. They may just be a lot more common than you (and others) think. We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.
> But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.
I'm not sure how to say this... but literally none of this is typically significant and certainly not any more significant than it is in React. In React you still need to know the tags and the attributes. Escaping rules? Yea, you need to know those too -- just the JavaScript ones. Self-closing tags? Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances. I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.
> I suspect the average React app probably is slower, partly because React sites are generally newer...
This isn't why. It's because it requires a significant amount of JavaScript to load and evaluate before you see anything. That amount can get larger with time.
> It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase...
Right. That stuff is O(1)-ish, and maybe it's stabilized some, but having gone through the various transitions, I can say it's not free. Nothing is though, upgrading Rails took us a couple hours this time around because of a breaking change for our 30 apps. React comes with, as a baseline, significant complexity that is O(n): Client/server separation (APIs or phantom-APIs like Next.JS has), state entangled with presentation (See the whole smart vs dumb components for an attempt to address this), massive asynchronous concerns that cannot be fully abstracted away (suspense and the like), and probably more.
Folks can't see it until they step away from it and look back. I've done that for the last 3 years. Unless a person has done it, I wouldn't expect my arguments to land. Folks see things or they don't. Again, I'm only here to say: there's something to see that you may not see yet. I'm sorry I don't have anything more convincing.
> If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.).
> We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.
Disagree, I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed. I used to be similarly sceptical about a lot of design work - I felt like designers were just messing with the visuals for no reason - but once I'd seen the before-and-after with a good designer I realised how much difference it makes.
> Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML.
Sure. So e.g. one thing that shocked me is how important it is to have a loading state for your form submit buttons, even though it only shows for a couple of hundred milliseconds and you'd think it wouldn't matter. But it does, and that's the sort of thing that React-based UIs tend to nudge you towards doing by default, whereas with server-side rendering often it's a bit more of an extra step.
(A server-side rendering framework will probably have a nice loading state for basic happy path form submit buttons where they've put time and effort into polishing. But it will be ad-hoc rather than idiomatic, because that kind of detailed client-side state is fundamentally cutting against the grain of a server-side framework. Once you go slightly off the beaten path, into image buttons or custom button components or what have you, it becomes harder and harder).
> Escaping rules? Yea, you need to know those too -- just the JavaScript ones.
You always need to know the JavaScript ones. So the choice is between learning the JavaScript ones or learning the JavaScript ones plus some other ones as well.
> Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances.
Then you've got another language with its own syntax that you're learning. Writing everything in the same language really does help (admittedly I don't know how many other people stay away from JSX and do everything programmatically, but doing React and never writing HTML is a genuine option, easier than doing e.g. Rails and never writing JavaScript IME).
> I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.
Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that, but my position is that learning just enough to get by is just fine, and putting more time into studying the intricacies of HTML does not generally have a good return these days. To the extent that React (or Rails, or anything) allows you to dodge learning those details, I consider that a point in its favour rather than against.
> it requires a significant amount of JavaScript to load and evaluate before you see anything.
It doesn't though. Like, I don't know how much effort it took to get the right build config etc. to make it work in my case, but it absolutely can be very fast. I'm happy to believe it's easy to make a React site that's slow, but it certainly doesn't require any superhuman effort to make one that's fast. I genuinely don't know what you have to do differently, because it didn't feel like I was doing anything special.
(At a guess I'd say committing full-throatedly to React and doing everything their way, rather than trying to half-ass things with useEffect etc. - just because that's the main thing we possibly did differently from "usual", and because most of the people who have a bad time with React seem to be the people who don't want to dive all the way in - but that really is just a guess)
> We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.
Disagree, I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed. I used to be similarly sceptical about a lot of design work - I felt like designers were just messing with the visuals for no reason - but once I'd seen the before-and-after with a good designer I realised how much difference it makes.
> Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML.
Sure. So e.g. one thing that shocked me is how important it is to have a loading state for your form submit buttons, even though it only shows for a couple of hundred milliseconds and you'd think it wouldn't matter. But it does, and that's the sort of thing that React-based UIs tend to nudge you towards doing by default, whereas with server-side rendering often it's a bit more of an extra step.
(A server-side rendering framework will probably have a nice loading state for basic happy path form submit buttons where they've put time and effort into polishing. But it will be ad-hoc rather than idiomatic, because that kind of detailed client-side state is fundamentally cutting against the grain of a server-side framework. Once you go slightly off the beaten path, into image buttons or custom button components or what have you, it becomes harder and harder).
> Escaping rules? Yea, you need to know those too -- just the JavaScript ones.
You always need to know the JavaScript ones. So the choice is between learning the JavaScript ones or learning the JavaScript ones plus some other ones as well.
> Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances.
Then you've got another language with its own syntax that you're learning. Writing everything in the same language really does help (admittedly I don't know how many other people stay away from JSX and do everything programmatically, but doing React and never writing HTML is a genuine option, easier than doing e.g. Rails and never writing JavaScript IME).
> I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.
Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that, but my position is that learning just enough to get by is just fine, and putting more time into studying the intricacies of HTML does not generally have a good return these days. To the extent that React (or Rails, or anything) allows you to dodge learning those details, I consider that a point in its favour rather than against.
> it requires a significant amount of JavaScript to load and evaluate before you see anything.
It doesn't though. Like, I don't know how much effort it took to get the right build config etc. to make it work in my case, but it absolutely can be very fast. I'm happy to believe it's easy to make a React site that's slow, but it certainly doesn't require any superhuman effort to make one that's fast. I genuinely don't know what you have to do differently, because it didn't feel like I was doing anything special.
(At a guess I'd say committing full-throatedly to React and doing everything their way, rather than trying to half-ass things with useEffect etc. - just because that's the main thing we possibly did differently from "usual", and because most of the people who have a bad time with React seem to be the people who don't want to dive all the way in - but that really is just a guess)
> I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed.
I agree with this, but probably wouldn't about specific numbers or use cases. By the way, one of the forms on our app round trips in 75ms when selecting a radio button that controls which set of fields is visible below it. On the "Slow 4G" throttling setting in Chrome, the time increases to 620ms or so, which is noticeable enough for the interaction to not feel good. Our particular forms-over-data application is not typically used on mobile (there's too much data to enter), so this isn't an issue for us. It's all contextual. If it were an issue, we'd either use an SPA-like library for our forms, or we would send all the HTML to the client and use JavaScript rules to control visibility. It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.
> A server-side rendering framework will probably have a nice loading state... Once you go slightly off the beaten path... it becomes harder and harder
Indeed, this is effectively built in to Turbo. There's nothing special about it, you add CSS rules (turbo adds and removes classes). That'd apply to image buttons or anything else you want to throw at it. You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.
If a person started their career doing React and is still doing React, that person would have certain beliefs about things that wouldn't be true. I get the impression that most people I'm engaging with here haven't actually done what we're doing but they are somehow convinced it cannot work or that our use case (line of business forms over data) is so special that it can't possibly apply to anyone else.
> Then you've got another language with its own syntax that you're learning
Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.
> Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that...
Got it. It was somewhat flippant, I admit that. They probably know the first thing, but the concerns you're raising about tags and escaping and that sort of thing honestly somewhat reinforce my flippant assertion. If those are the things we are concerned about our developers having to know then I wouldn't want them anywhere near anything our users would touch. I think we may be used to working with different calibers of developers. I get that they're all over the map now, so this is just a another contextual difference most likely.
> ...studying the intricacies of HTML...
It's not sanskrit. I'm rather confounded by the FUD around HTML here.
> It doesn't though.
Ok. I've done it, so I know exactly what it takes, at least in the 4 or 5 different apps I built with various versions of React and friends. I also know that aside from the fastest machines on the fastest networks, there's not much you can do aside from server rendering to address the first paint issue/LCP issue. But yes, once you have the initial JS bundle, the rest of the site is generally faster. By the way, one of our 30 or so web apps we have composed into a single application with nginx/SSI still uses React. LCP is 1.2s on my M4 Max and on a page with slightly more data that doesn't have React, the LCP is 0.7s. Yes, the bundle is optimized. These aren't awful numbers at all, but I'm on the fastest machine there is pretty much. There's no loading shimmer stuff like AirBNB does. Speaking of user experience, that stuff is absolute garbage and I can't wait until folks realize it. Of course, they'd have to embrace server-side rendering though... :)
Just to be reiterate: I think there are plenty of good use cases for React like libraries/frameworks. I just think there are fewer than people think.
I agree with this, but probably wouldn't about specific numbers or use cases. By the way, one of the forms on our app round trips in 75ms when selecting a radio button that controls which set of fields is visible below it. On the "Slow 4G" throttling setting in Chrome, the time increases to 620ms or so, which is noticeable enough for the interaction to not feel good. Our particular forms-over-data application is not typically used on mobile (there's too much data to enter), so this isn't an issue for us. It's all contextual. If it were an issue, we'd either use an SPA-like library for our forms, or we would send all the HTML to the client and use JavaScript rules to control visibility. It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.
> A server-side rendering framework will probably have a nice loading state... Once you go slightly off the beaten path... it becomes harder and harder
Indeed, this is effectively built in to Turbo. There's nothing special about it, you add CSS rules (turbo adds and removes classes). That'd apply to image buttons or anything else you want to throw at it. You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.
If a person started their career doing React and is still doing React, that person would have certain beliefs about things that wouldn't be true. I get the impression that most people I'm engaging with here haven't actually done what we're doing but they are somehow convinced it cannot work or that our use case (line of business forms over data) is so special that it can't possibly apply to anyone else.
> Then you've got another language with its own syntax that you're learning
Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.
> Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that...
Got it. It was somewhat flippant, I admit that. They probably know the first thing, but the concerns you're raising about tags and escaping and that sort of thing honestly somewhat reinforce my flippant assertion. If those are the things we are concerned about our developers having to know then I wouldn't want them anywhere near anything our users would touch. I think we may be used to working with different calibers of developers. I get that they're all over the map now, so this is just a another contextual difference most likely.
> ...studying the intricacies of HTML...
It's not sanskrit. I'm rather confounded by the FUD around HTML here.
> It doesn't though.
Ok. I've done it, so I know exactly what it takes, at least in the 4 or 5 different apps I built with various versions of React and friends. I also know that aside from the fastest machines on the fastest networks, there's not much you can do aside from server rendering to address the first paint issue/LCP issue. But yes, once you have the initial JS bundle, the rest of the site is generally faster. By the way, one of our 30 or so web apps we have composed into a single application with nginx/SSI still uses React. LCP is 1.2s on my M4 Max and on a page with slightly more data that doesn't have React, the LCP is 0.7s. Yes, the bundle is optimized. These aren't awful numbers at all, but I'm on the fastest machine there is pretty much. There's no loading shimmer stuff like AirBNB does. Speaking of user experience, that stuff is absolute garbage and I can't wait until folks realize it. Of course, they'd have to embrace server-side rendering though... :)
Just to be reiterate: I think there are plenty of good use cases for React like libraries/frameworks. I just think there are fewer than people think.
> It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.
Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.
And if you flip the question, I just haven't seen the compelling case for server side rendering. If you have a specific case where something else does something you can't do with React, or does something a lot better than React, then of course do that something else, and if that something else happens to use server-side rendering then maybe it will be a tolerable tradeoff. But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them (which is not to say that we wouldn't have e.g. a Ruby based convention-over-configuration framework - but I think it would have a state model closer to React's).
> You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.
It's personal experience, but perhaps outdated, and I never was hugely into Rails specifically. The last time I checked in was several years into wailing and gnashing teeth about people fleeing to React, but only really offering a smattering of ad-hoc fixes to specific pain points. Maybe they've found themselves a good unified state abstraction now, but I think it would be a real struggle especially for a framework that isn't really component-oriented in the way I see it (and indeed prides itself on embracing HTTP and having routes corresponding to pages).
> Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.
I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless. Learning new things that expand the way you think is worthwhile. Learning new tools that you can apply generally is too. Learning yet another slightly different templating syntax or curly brace programming language usually isn't. And some tools have enough depth to them that you can spend years and still learn new, useful things. I don't know that React is one of them - I don't know it as well as I'd like - but these days I generally find it more rewarding to learn a deeper corner of something that I can use a lot, than a new standalone thing that doesn't have any general lessons to impart.
Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.
And if you flip the question, I just haven't seen the compelling case for server side rendering. If you have a specific case where something else does something you can't do with React, or does something a lot better than React, then of course do that something else, and if that something else happens to use server-side rendering then maybe it will be a tolerable tradeoff. But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them (which is not to say that we wouldn't have e.g. a Ruby based convention-over-configuration framework - but I think it would have a state model closer to React's).
> You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.
It's personal experience, but perhaps outdated, and I never was hugely into Rails specifically. The last time I checked in was several years into wailing and gnashing teeth about people fleeing to React, but only really offering a smattering of ad-hoc fixes to specific pain points. Maybe they've found themselves a good unified state abstraction now, but I think it would be a real struggle especially for a framework that isn't really component-oriented in the way I see it (and indeed prides itself on embracing HTTP and having routes corresponding to pages).
> Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.
I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless. Learning new things that expand the way you think is worthwhile. Learning new tools that you can apply generally is too. Learning yet another slightly different templating syntax or curly brace programming language usually isn't. And some tools have enough depth to them that you can spend years and still learn new, useful things. I don't know that React is one of them - I don't know it as well as I'd like - but these days I generally find it more rewarding to learn a deeper corner of something that I can use a lot, than a new standalone thing that doesn't have any general lessons to impart.
> Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.
Yes, in that case, i.e., if it were a problem we had. It's NOT a problem we have though. That's my point. Not currently. Not in our context.
> But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them
Not exactly React, but there was ActiveX, Flash, and Java Applets. Thick clients came first. It wasn't until IE6 where there some AJAX was viable. React came later to address additional shortcomings: procedurally updating the state of the document via jquery got complicated, and large organizations with poor development practices (e.g., facebook) struggled to maintain control of their application. They came up with React to help with this, and it did, but it brought its own host of problems. Declarative UI was what we always had with server rendering. They just allowed it to update. Btw, this isn't a new idea. We had something like this with ASP.NET as well, but that included the server.
Meanwhile, people like Chris McCord had already built a syncing library for Rails to solve these problems and, being fed up with the performance at that point, went to Elixir where he eventually built Phoenix LiveView. By then, React already had significant market share. Turbo's previous incarnation came out before then and its current one came out around that time or slightly after. Combined with Ruby's performance improvements over time, it was quite viable for many apps.
Also, note what's happening in React -- it's moving towards more server rendering. People realized they lost something by doing client only and they're trying to get back to it. Remix is an ode to the simplicity of old (which is really the simplicity of now, but they don't want to give up their React Components). I can't blame them in a way, React is a lot of fun to write a lot of the times.
> Maybe they've found themselves a good unified state abstraction now...
We've always had the database. That's insufficient for highly interactive applications where you need client-side state, which is likely what you mean by "unified". So yes, if you need "unified" state, and specifically the ability to change your UI based on changes to that state, React is great, or any of the other libs. The author was specifically concerned about React's current state (e.g. legacy IE6 support) and I'm specifically concerned about people reaching for React when they don't need it. That's because I've done it, I've seen people do it, and I see people continuing to preach the React orthodoxy which will lead to more people doing it. This thread is full of it.
Whether or not a person recognizes it, HTMX, Turbo, LiveView and its kind have greatly narrowed that gap. They've made server rendering just as capable at highly-interactive UIs in many more cases than many people think.
> I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless.
Sure, I can relate to this. But this is different than spreading FUD about having to learn a new language. That's easy. That's the easiest thing we have to do. I'm not suggesting to do it flippantly. I'm suggesting that sometimes it's worth it. When it's worth it, you do it and it's not a big deal.
Yes, in that case, i.e., if it were a problem we had. It's NOT a problem we have though. That's my point. Not currently. Not in our context.
> But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them
Not exactly React, but there was ActiveX, Flash, and Java Applets. Thick clients came first. It wasn't until IE6 where there some AJAX was viable. React came later to address additional shortcomings: procedurally updating the state of the document via jquery got complicated, and large organizations with poor development practices (e.g., facebook) struggled to maintain control of their application. They came up with React to help with this, and it did, but it brought its own host of problems. Declarative UI was what we always had with server rendering. They just allowed it to update. Btw, this isn't a new idea. We had something like this with ASP.NET as well, but that included the server.
Meanwhile, people like Chris McCord had already built a syncing library for Rails to solve these problems and, being fed up with the performance at that point, went to Elixir where he eventually built Phoenix LiveView. By then, React already had significant market share. Turbo's previous incarnation came out before then and its current one came out around that time or slightly after. Combined with Ruby's performance improvements over time, it was quite viable for many apps.
Also, note what's happening in React -- it's moving towards more server rendering. People realized they lost something by doing client only and they're trying to get back to it. Remix is an ode to the simplicity of old (which is really the simplicity of now, but they don't want to give up their React Components). I can't blame them in a way, React is a lot of fun to write a lot of the times.
> Maybe they've found themselves a good unified state abstraction now...
We've always had the database. That's insufficient for highly interactive applications where you need client-side state, which is likely what you mean by "unified". So yes, if you need "unified" state, and specifically the ability to change your UI based on changes to that state, React is great, or any of the other libs. The author was specifically concerned about React's current state (e.g. legacy IE6 support) and I'm specifically concerned about people reaching for React when they don't need it. That's because I've done it, I've seen people do it, and I see people continuing to preach the React orthodoxy which will lead to more people doing it. This thread is full of it.
Whether or not a person recognizes it, HTMX, Turbo, LiveView and its kind have greatly narrowed that gap. They've made server rendering just as capable at highly-interactive UIs in many more cases than many people think.
> I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless.
Sure, I can relate to this. But this is different than spreading FUD about having to learn a new language. That's easy. That's the easiest thing we have to do. I'm not suggesting to do it flippantly. I'm suggesting that sometimes it's worth it. When it's worth it, you do it and it's not a big deal.
Not really surprising that a rails shop is going to have a easier time with rails than react.
Not a Rails shop. We did React and Node almost exclusively for 6 or more years. My first React project started in 2014 or so. I mentioned this in several comments. We had done Rails in the distant past, but using Rails was actually a risk for us because there were things we knew how to do with React from recent experience we would have to learn for Rails server rendering.
Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay.
I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about.
It's a tome, a full tome, without a clear position.
Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs.
The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?"
The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world.
In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping.
So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.
I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I have NO IDEA what he thinks is better, or even if he is able to disambiguate the React architecture from the React library/stack, or which one he is talking about.
It's a tome, a full tome, without a clear position.
Mine is this: a truly state based rendering and eventing engine for frontends is a dream, a beautiful dream, not unlike the beautiful dream of a purely functional language based on the lambda (or rho?) calculus. The dream giveth and it taketh away, and it is always a fundamentalist dream; where that fundamentalism hits the cracks of reality is where engineers have to make tradeoffs.
The React architecture stack (well, the stack without prop drilling) stays somewhat beautiful as a dream in my opinion, which is to say it provides guide- and guard-rails to stay relatively productive delivering mid size applications across millions of devices without a ton of moments where I'm like "what the fuck is the rule of hooks, and how did I break it here?"
The react library stack, and by extension the node stack: sucks balls, full stop. I'm happy to get some other framework which has write/compile-time type safety, modularity and an eventing/rendering system that abstracts away most of my concerns for delivering over the web and is lighter weight, has less dependencies, etc. However, if the author wants me to change my ill-begotten ways, it would probably be more effective to explain how it is that each of the items in his list: "Preact, Stencil, Svelte, Lit, FAST, Qwik, or any of a dozen faster, smaller, reactive client-side systems" provide a better world.
In this area, I believe I'm a journeyman, reading a senior / master engineer's writing -- fine. But he is not informing me at all. I don't want to go learn the recommended 18 (12 unnamed) smaller client-side systems that apparently require less mental bookkeeping of me. I'm not even sure what that means -- I code tsx in vim, and do not feel like I have to do a lot of bookkeeping.
So, back to you -- what's your recommendation? I'm genuinely curious what you think would be better. Or the author, if he wants to butt in here. I just don't understand what you (or the author) thinks should be done. The forms processing and server rendering (say with Perl 5 and tcl were two early langauges for me) were not that great.
Same here. I’ve been through old and new frameworks on both client and server end, since before javascript was even on the map, from cgi, php, aspnet, django, angular, vue, lit, jquery, you name it.
Basically, I know how to build a server side rendered application, I still reach for React, I know it sucks in so many ways, accessibility, performance, complexity, and so on. I just don’t know what to pick instead. It’s the first time a framework allows seamless refactoring into composable components. Powerful, terse and type safe templating language. Clear separation between state and presentation. The developer experience is just easier, even accounting for the additional rpc needed between client and server and the hook footguns.
Do I wish there was a better way to do server side rendering. Of course. For server side rendering to take off, the story for how to gradually add interaction need to be better. Not everything is static text. The moment you need something interactive, even the most fundamental thing: date picker, form validation, expand/collpase, selection, reordering, lazy loading... sprinkling in a bit of js in a server side language become an unmanageable mess. Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.
Basically, I know how to build a server side rendered application, I still reach for React, I know it sucks in so many ways, accessibility, performance, complexity, and so on. I just don’t know what to pick instead. It’s the first time a framework allows seamless refactoring into composable components. Powerful, terse and type safe templating language. Clear separation between state and presentation. The developer experience is just easier, even accounting for the additional rpc needed between client and server and the hook footguns.
Do I wish there was a better way to do server side rendering. Of course. For server side rendering to take off, the story for how to gradually add interaction need to be better. Not everything is static text. The moment you need something interactive, even the most fundamental thing: date picker, form validation, expand/collpase, selection, reordering, lazy loading... sprinkling in a bit of js in a server side language become an unmanageable mess. Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.
I hear you. I reached for React for 6 year or so. I built the first application for the client I've been working for for the last 4 years with React. We built the next 20+ w/ server rendered Rails. The interactivity was the same. It's forms-over-data, but the forms have a relatively unique collaborative nature -- you and others can be editing them simultaneously and you'll see each other's field changes in (relatively) real time. The forms can also be massive and have fully dynamic sections. We did it with React (using react-query) and then did it again with Rails, turbo, and stimulus.
The JavaScript code that manages the collaborative form I mentioned is around 300 lines. Every new form we build is just Rails partials with helpers. No APIs, all server-rendered. It works very well. It loads faster than the React version and it has observably less maintenance cost.
> For server side rendering to take off...
> date picker
A reasonable one is built into most browsers now. You don't tend to anything more unless you need something specialized, and then there are libraries you can use (or you could reach for vue/preact/etc w/ the so called "islands" technique)
> form validation
On the server with Turbo/LiveWire/HTMX
> expand/collpase
This can be done with just CSS and a hidden checkmark. The JavaScript version is lines of code.
> selection
Not sure what this means
> reordering
There are libraries for this. By the way, I built a Trello plugin that effectively re-implements Trello within Trello including drag-and-drop reordering and I used Preact and one of the React DND style libraries (don't recall which now). There was nothing easy about it, but it was likely easier for my specific use case to use those technologies. That's one feature in most apps though (for us it was basically the whole thing), so if I needed it in this app, even if I reached for React/Preact, it would be isolated to that one feature. I'd try very hard to avoid it though.
> lazy loading
Turbo/HTMX make this trivial. Note that we use SSI (server-side-include) to compose web applications. This is all done on the server. Our apps are fast enough that we don't need lazy loading to maintain a very low response time even when hitting multiple servers in a request.
> Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.
So have I. Then I did it with React for over 6 years (including the transition to and from Redux and to hooks). I championed React and CSS-in-JS at my agency. Now I've done it with server-rendering again and different front end libraries (turbo/stimulus) for 3 years most recently. The difference is night and day. I have 15 other devs on my team that would tell you which stack they are observably more productive with. I'm just some guy on the internet, so take everything I say with a grain of salt, but I am uniquely positioned to be able to speak on this with practical experience on all 3 topics in this discussion (how server rendering was, how React is, and how server rendering is now).
Honestly, much of it comes down to what we let our "designers" force us into. If it's just the type of things that you described, it's server rendering all day. If it's random/unnecessary interaction/fluff/flare, the appropriate countermeasure is saying "no". Again, if it's Miro, Linear, Superhuman, etc, then sure -- reach for a full-fledged SPA framework/library.
The JavaScript code that manages the collaborative form I mentioned is around 300 lines. Every new form we build is just Rails partials with helpers. No APIs, all server-rendered. It works very well. It loads faster than the React version and it has observably less maintenance cost.
> For server side rendering to take off...
> date picker
A reasonable one is built into most browsers now. You don't tend to anything more unless you need something specialized, and then there are libraries you can use (or you could reach for vue/preact/etc w/ the so called "islands" technique)
> form validation
On the server with Turbo/LiveWire/HTMX
> expand/collpase
This can be done with just CSS and a hidden checkmark. The JavaScript version is lines of code.
> selection
Not sure what this means
> reordering
There are libraries for this. By the way, I built a Trello plugin that effectively re-implements Trello within Trello including drag-and-drop reordering and I used Preact and one of the React DND style libraries (don't recall which now). There was nothing easy about it, but it was likely easier for my specific use case to use those technologies. That's one feature in most apps though (for us it was basically the whole thing), so if I needed it in this app, even if I reached for React/Preact, it would be isolated to that one feature. I'd try very hard to avoid it though.
> lazy loading
Turbo/HTMX make this trivial. Note that we use SSI (server-side-include) to compose web applications. This is all done on the server. Our apps are fast enough that we don't need lazy loading to maintain a very low response time even when hitting multiple servers in a request.
> Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.
So have I. Then I did it with React for over 6 years (including the transition to and from Redux and to hooks). I championed React and CSS-in-JS at my agency. Now I've done it with server-rendering again and different front end libraries (turbo/stimulus) for 3 years most recently. The difference is night and day. I have 15 other devs on my team that would tell you which stack they are observably more productive with. I'm just some guy on the internet, so take everything I say with a grain of salt, but I am uniquely positioned to be able to speak on this with practical experience on all 3 topics in this discussion (how server rendering was, how React is, and how server rendering is now).
Honestly, much of it comes down to what we let our "designers" force us into. If it's just the type of things that you described, it's server rendering all day. If it's random/unnecessary interaction/fluff/flare, the appropriate countermeasure is saying "no". Again, if it's Miro, Linear, Superhuman, etc, then sure -- reach for a full-fledged SPA framework/library.
I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives.
And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer when React came out and I remember how it took the web community by storm, because it was an obvious step forward.
When the alternative exists, it will be as purely obvious.
And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer when React came out and I remember how it took the web community by storm, because it was an obvious step forward.
When the alternative exists, it will be as purely obvious.
To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back.
I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience doing the exact thing you are doing say there’s another way.
The really tricky part here is that that “other way” in this case looks similar to the “old way” and thus is easy to dismiss. It also doesn’t come with any of the dopamine inducing things like hot reloading and really cool tech like virtual dom diffing, etc. in other words, it doesn’t speak to the parts of us that are drawn to the “cool” factor. It’s simple, it’s basic, it’s sometimes tedious, but it’s productive — in the long run.
I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience doing the exact thing you are doing say there’s another way.
The really tricky part here is that that “other way” in this case looks similar to the “old way” and thus is easy to dismiss. It also doesn’t come with any of the dopamine inducing things like hot reloading and really cool tech like virtual dom diffing, etc. in other words, it doesn’t speak to the parts of us that are drawn to the “cool” factor. It’s simple, it’s basic, it’s sometimes tedious, but it’s productive — in the long run.
I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React answered my three basic concerns very clearly, in an obvious way:
1. Component based architecture
2. The ability to express view as a pure function of state
3. The ability to express HTML and code together in a neat and ergonomic way
This is what I mean by obvious -- all experienced frontend engineers I knew at the time immediately got it, they got that React nailed these three things, and why they were important. Surprisingly, even new frameworks don't always lead with these three principles, which makes me less likely to believe that they resolve the particular concerns that I find of most importance.
1. Component based architecture
2. The ability to express view as a pure function of state
3. The ability to express HTML and code together in a neat and ergonomic way
This is what I mean by obvious -- all experienced frontend engineers I knew at the time immediately got it, they got that React nailed these three things, and why they were important. Surprisingly, even new frameworks don't always lead with these three principles, which makes me less likely to believe that they resolve the particular concerns that I find of most importance.
Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention.
And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption wasn't worth it.
Instead, we opted for helpers and view partials. The limited behavior we needed on the client would be in a separate Stimulus controller. The helper would typically reference it. Then, the declaration in the view would look more or less like a React component invocation, albeit with a totally different syntax.
There may very well be room for improvement here, but it certainly works "well enough". As I've mentioned, the main thing that is different now is that we can render updates to views on the server. This allows us to have "The ability to express view as a pure function of state" on the server and not have to be concerned about everything else that comes with owning and operating a React implementation.
I think React really helped move things forward and I don't regret my time using it. I may even use it again if I worked on an application where it was warranted.
I wish I could spend time with every commenter on here showing them our code, working with them on it, and helping them see the way that we do it so that my words don't just sound crazy or anathema. Unfortunately, that just doesn't work out in practice. I appreciate the discussion all the same.
And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption wasn't worth it.
Instead, we opted for helpers and view partials. The limited behavior we needed on the client would be in a separate Stimulus controller. The helper would typically reference it. Then, the declaration in the view would look more or less like a React component invocation, albeit with a totally different syntax.
There may very well be room for improvement here, but it certainly works "well enough". As I've mentioned, the main thing that is different now is that we can render updates to views on the server. This allows us to have "The ability to express view as a pure function of state" on the server and not have to be concerned about everything else that comes with owning and operating a React implementation.
I think React really helped move things forward and I don't regret my time using it. I may even use it again if I worked on an application where it was warranted.
I wish I could spend time with every commenter on here showing them our code, working with them on it, and helping them see the way that we do it so that my words don't just sound crazy or anathema. Unfortunately, that just doesn't work out in practice. I appreciate the discussion all the same.
I'm definitely a fan of LiveView and Turbo. I think they present reasonable choices for applications that are more complicated than a static site and less complicated than a full application. I would like to see their interop story with React improve, however, since I think a lot of impetus towards React comes from the fact that the core business product, which has high application/interactivity requirements, is (understandably) in React, so the cost of build is significantly lower staying within the ecosystem.
This is actually something I think a lot about, because in my company I am the TL of all the setting pages. We don't have high interactivity requirements, and it's reasonable to explore a different path. But the core product is in React, and there's basically no justification to rebuild it in something else just to build out settings pages.
This is actually something I think a lot about, because in my company I am the TL of all the setting pages. We don't have high interactivity requirements, and it's reasonable to explore a different path. But the core product is in React, and there's basically no justification to rebuild it in something else just to build out settings pages.
Indeed. I think an important concern is what constitutes a "full application". I think that's where the community (I've even seen this at my own agency) has lost the plot a bit.
> I am the TL of all the setting pages
Ok, now I'm intrigued. If you're interested, I'd love to hear more about this. As someone who has (aside from a 2 year stint at Microsoft) only worked on relatively small teams (15 max) I'd love to hear more about what it's like to work on a team that's responsible for the settings pages. If you're interested, I'd be happy to connect for a chat. I just added my contact info to my profile here. If not, no worries! Cheers.
> I am the TL of all the setting pages
Ok, now I'm intrigued. If you're interested, I'd love to hear more about this. As someone who has (aside from a 2 year stint at Microsoft) only worked on relatively small teams (15 max) I'd love to hear more about what it's like to work on a team that's responsible for the settings pages. If you're interested, I'd be happy to connect for a chat. I just added my contact info to my profile here. If not, no worries! Cheers.
Meh, indeed :) Thank you for your response, it's a fair question and critique.
It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much. You wouldn't have a tome, you'd have an anthology. You'd have to consider what is being built and by whom at the very least.
It becomes "self-evident" when you have enough knowledge and experience to make the selection and you successfully de-bias yourself from the "shiny" or the "common" (Which React was and is now respectively).
So, what would I recommend? Aside from the pat, "it depends" answer, I would recommend starting with a server-rendering based framework. I prefer Rails, personally, because Ruby works well for me and my team, but many others would do just fine.
Then, fight all superfluous interactivity for interactivity's sake in your applications. Stick to server rendering and form submissions until you need something more elaborate. Then, look for something you can use to augment behavior. I use Turbo/Stimulus, with which we are able to do a lot with very little. Others like HTMX. If one really needed the interactivity and declarative nature of something like React, then the list that the author mentioned would be good to explore. Most folks don't, and I think that's the main point that's lost on many.
Oh, and if you're building Google Maps, Miro, Linear or the like then disregard the above suggestions, they don't apply. Etc. (again, it depends)
As an aside, I was historically a huge React fan. I used it for quite a while. I'm still a fan of the declarative nature and one-way data flow. It's super powerful stuff. We actually get something somewhat similar with Turbo and the much more sophisticated Phoenix LiveView (can't recommend this one personally, haven't used it in anger). Procedural-based UI code for complex, highly interactive applications is a fool's errand in my opinion. For the basics though? Totally fine.
It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much. You wouldn't have a tome, you'd have an anthology. You'd have to consider what is being built and by whom at the very least.
It becomes "self-evident" when you have enough knowledge and experience to make the selection and you successfully de-bias yourself from the "shiny" or the "common" (Which React was and is now respectively).
So, what would I recommend? Aside from the pat, "it depends" answer, I would recommend starting with a server-rendering based framework. I prefer Rails, personally, because Ruby works well for me and my team, but many others would do just fine.
Then, fight all superfluous interactivity for interactivity's sake in your applications. Stick to server rendering and form submissions until you need something more elaborate. Then, look for something you can use to augment behavior. I use Turbo/Stimulus, with which we are able to do a lot with very little. Others like HTMX. If one really needed the interactivity and declarative nature of something like React, then the list that the author mentioned would be good to explore. Most folks don't, and I think that's the main point that's lost on many.
Oh, and if you're building Google Maps, Miro, Linear or the like then disregard the above suggestions, they don't apply. Etc. (again, it depends)
As an aside, I was historically a huge React fan. I used it for quite a while. I'm still a fan of the declarative nature and one-way data flow. It's super powerful stuff. We actually get something somewhat similar with Turbo and the much more sophisticated Phoenix LiveView (can't recommend this one personally, haven't used it in anger). Procedural-based UI code for complex, highly interactive applications is a fool's errand in my opinion. For the basics though? Totally fine.
Appreciate these thoughts back - Every maybe eight to ten years I pick up a server-side rendering framework. Last one was go templates based, (significant impedance mismatch between go and html/json as you might expect), before that was rails (2010-era: too much magic, pre-declarative UI era), before that was tcl/aolserver. I thought tcl on aolserver did a great job, and of course HTML5 browsers are vastly more capable than IE4 was. It probably still is pretty nice, I imagine.
I think as a practical matter, when I've picked a language that has good synchronicity and impedance matching with the needs of the web, (arbitrary JSON and text processing and injection, along with keeping some sort of structured idea of the DOM), I'm usually at typescript, which I...hate...but I hate it less than writing type structs in go or, dealing with erlang, or, etc. etc.
Once I'm at typescript, I'm using react as a path of least resistance. I'll check out turbo/stimulus though, thanks for the reference. It looks promising, and a little more bare to the wire which I appreciate.
I think as a practical matter, when I've picked a language that has good synchronicity and impedance matching with the needs of the web, (arbitrary JSON and text processing and injection, along with keeping some sort of structured idea of the DOM), I'm usually at typescript, which I...hate...but I hate it less than writing type structs in go or, dealing with erlang, or, etc. etc.
Once I'm at typescript, I'm using react as a path of least resistance. I'll check out turbo/stimulus though, thanks for the reference. It looks promising, and a little more bare to the wire which I appreciate.
So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.
Don't get me wrong, I would much prefer coding in a single language for both backend and frontend, and I would not choose JS/TS for that. But your choice is that, only a decent choice. Just like react is. There are so many ways to do web development, and neither of these are fundamentally bad.
Specific applications of these architecture/designs on the other hand can be catastrophic in both cases, and I'm sure most of us has been burnt by these (e.g. for SSR, I have seen code that sent back HTML segments that reused IDs. With dynamic JS it was a pain to hunt down these errors. But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs).
Don't get me wrong, I would much prefer coding in a single language for both backend and frontend, and I would not choose JS/TS for that. But your choice is that, only a decent choice. Just like react is. There are so many ways to do web development, and neither of these are fundamentally bad.
Specific applications of these architecture/designs on the other hand can be catastrophic in both cases, and I'm sure most of us has been burnt by these (e.g. for SSR, I have seen code that sent back HTML segments that reused IDs. With dynamic JS it was a pain to hunt down these errors. But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs).
> So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.
"Now" being what specifically? The technologies I mentioned allow everything to happen on the server. We've got a relatively complex set of applications: 30 deployed apps, composition using SSI (server-side include), collaborative form entry for complex form including sections that appear/disappear, etc, near-real-time comments, etc. We have on the order of 100s of lines of JavaScript and I don't think there is a single JSON API (so no DTOs).
> But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs
This may be part of your problem. The people returning the HTML are front end devs. Rails and the like are front end frameworks. The server is just the server of the front end. This notion that "front end" is just React/HMTL/CSS is a new thing that can be problematic as you describe. It's all front end stuff, always will be. You can tell because of what's happening with React with server-rendered components, NextJS trying to blur the line, etc.
I'm suggesting that if your perspective includes this kind of dichotomy and you see different teams of developers working on client-side than on server-side, you have to first address that as a problem.
"Now" being what specifically? The technologies I mentioned allow everything to happen on the server. We've got a relatively complex set of applications: 30 deployed apps, composition using SSI (server-side include), collaborative form entry for complex form including sections that appear/disappear, etc, near-real-time comments, etc. We have on the order of 100s of lines of JavaScript and I don't think there is a single JSON API (so no DTOs).
> But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs
This may be part of your problem. The people returning the HTML are front end devs. Rails and the like are front end frameworks. The server is just the server of the front end. This notion that "front end" is just React/HMTL/CSS is a new thing that can be problematic as you describe. It's all front end stuff, always will be. You can tell because of what's happening with React with server-rendered components, NextJS trying to blur the line, etc.
I'm suggesting that if your perspective includes this kind of dichotomy and you see different teams of developers working on client-side than on server-side, you have to first address that as a problem.
Then every significant (you can get away a lot with very tiny js and/or css, like menus) user interaction will necessarily cause a server round-trip, which is definitely perceptible by humans, no matter how fast your internet is - so it's a bit dishonest to claim that React is "slow".
As I said, this is definitely a viable approach, but so is react. Both would fit like 80% of all websites just fine, given that they are developed by decent developers.
As I said, this is definitely a viable approach, but so is react. Both would fit like 80% of all websites just fine, given that they are developed by decent developers.
Human perceptibility is only relevant in certain contexts. Are you in one? Ok, maybe you need client side interactivity. This is what I mean by "highly interactive" applications like Linear, Miro, Superhuman, etc. Having to wait for a server round trip in those wouldn't be good and I would build one of those using an SPA framework/library. This isn't in question.
A forms over data application can be built with React. That's "valid", but what is the cost? The latency in showing/hiding things can be seen with slower internet connections, but so what. What is the cost of that? Have you ever used an air travel booking site? Many of those interactions are painfully slow but you still booked your travel, right? Now take those slow interactions and make them so they are actually just on the edge of human perceptibility (which is easy with server rendering) and you've got a perfectly great experience for your users. If your users are captive (it's their work application, or they need to book travel, etc) then you have even more (but we wouldn't need it) leeway.
If you're a shopping site where revenue is tied latency, maybe it's necessary? But have you used Amazon? There's all sorts of server loading there and they do pretty well.
I'm not claiming that React is "slow". It's slowER on time-to-interactive on average. It can be slower to develop applications. It is certainly more costly from a maintenance perspective due to the unstable nature of JavaScript dependencies.
I'm not going to be able to convince you of any of this. I'm only here holding a sign saying that things aren't as straightforward as they seem. There are costs and costs and costs to this stuff that many see as a normal day in the office.
I'm just saying there's more productivity beyond the horizon, and you're not going to find it by embracing and extending complexity. React is complexity. All the things that come with it to compensate for its complexity are more complexity.
Teams go faster permanently by embracing simplicity. Using React for a forms over data application is the opposite of that. You can do it. You can get your first version out "quick" but over time, that complexity will rear its head and you will slow down.
Have you ever been on a team that wasn't as fast as it was on the first day of a project?
A forms over data application can be built with React. That's "valid", but what is the cost? The latency in showing/hiding things can be seen with slower internet connections, but so what. What is the cost of that? Have you ever used an air travel booking site? Many of those interactions are painfully slow but you still booked your travel, right? Now take those slow interactions and make them so they are actually just on the edge of human perceptibility (which is easy with server rendering) and you've got a perfectly great experience for your users. If your users are captive (it's their work application, or they need to book travel, etc) then you have even more (but we wouldn't need it) leeway.
If you're a shopping site where revenue is tied latency, maybe it's necessary? But have you used Amazon? There's all sorts of server loading there and they do pretty well.
I'm not claiming that React is "slow". It's slowER on time-to-interactive on average. It can be slower to develop applications. It is certainly more costly from a maintenance perspective due to the unstable nature of JavaScript dependencies.
I'm not going to be able to convince you of any of this. I'm only here holding a sign saying that things aren't as straightforward as they seem. There are costs and costs and costs to this stuff that many see as a normal day in the office.
I'm just saying there's more productivity beyond the horizon, and you're not going to find it by embracing and extending complexity. React is complexity. All the things that come with it to compensate for its complexity are more complexity.
Teams go faster permanently by embracing simplicity. Using React for a forms over data application is the opposite of that. You can do it. You can get your first version out "quick" but over time, that complexity will rear its head and you will slow down.
Have you ever been on a team that wasn't as fast as it was on the first day of a project?
> But front end performance issues are almost never the most pressing issue to deal with.
Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks.
This is literally why I cancelled Spotify, because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.
Maybe not to you, but it's by far and away the biggest complaint with any website or app that uses React/Angular under the hood in my experience. On any computer older than a few years, the sheer amount of JavaScript being demanded to be run creates serious system bottlenecks.
This is literally why I cancelled Spotify, because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.
Is it? On Hacker News it probably is, and I agree that it can drive engineers nuts to know that apps are more bloated than they have to be, but I think we’re a relatively small percentage of the population. Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.
> Among my less technically/inclined friends and family I haven’t heard one complaint about, say, Spotify being slow, and certainly never any complaints about its size.
They don't say "modern software is slow", they say "my computer is slow, I need to buy a new one" and they do.
Let's be honest: for what the vast majority of people do on their computer, there is absolutely no need for a Macbook M3. The only reason is that the websites are developed by people who buy (or get from their company) a Macbook M3 and therefore don't see how much their website sucks on a reasonable machine.
I can track it very well on my father's homepage which has been the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load. On an M3 it takes 2s. This homepage is still loading exactly the same kind of information than 25 years ago, yet it is almost unbearable on a 4 years old desktop computer. Does my father say that this webpage is slow? No, because all software goes like this. My father says that his computer is now old and considers buying a new one.
They don't say "modern software is slow", they say "my computer is slow, I need to buy a new one" and they do.
Let's be honest: for what the vast majority of people do on their computer, there is absolutely no need for a Macbook M3. The only reason is that the websites are developed by people who buy (or get from their company) a Macbook M3 and therefore don't see how much their website sucks on a reasonable machine.
I can track it very well on my father's homepage which has been the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load. On an M3 it takes 2s. This homepage is still loading exactly the same kind of information than 25 years ago, yet it is almost unbearable on a 4 years old desktop computer. Does my father say that this webpage is slow? No, because all software goes like this. My father says that his computer is now old and considers buying a new one.
> the same for 25 years. He has a 4 years old desktop mac and the webpage takes more than 20s to load
How long did it take to load 20 years ago, on a 20 year old PC/Mac ? - seems like a very big page?
How long did it take to load 20 years ago, on a 20 year old PC/Mac ? - seems like a very big page?
A few seconds. It's a news webpage, that has mostly text, links and images.
And of course now it loads a ton of useless widgets, probably much bigger images (sometimes they load a video to serve the same purpose, just because they can), and a whole lot more code. And that's with uBlock origins; if I disable it it's a lot worse.
Objectively, in 25 years they have been paying people to make it an order of magnitude worse. And it's not only them: the vast majority of websites have followed that trend.
And of course now it loads a ton of useless widgets, probably much bigger images (sometimes they load a video to serve the same purpose, just because they can), and a whole lot more code. And that's with uBlock origins; if I disable it it's a lot worse.
Objectively, in 25 years they have been paying people to make it an order of magnitude worse. And it's not only them: the vast majority of websites have followed that trend.
There is supporting data that webpages have become bigger faster than the bandwidth even increased. This is like, very bad. https://www.nngroup.com/articles/the-need-for-speed/
People just stopped complaining and search for workarounds on themselves or just suffer silently.
They don't say "I'm sick of React websites," they just say "Wow websites are getting slower and slower." or they complain about specific tabs or just the browser in general sucking up tons of RAM and CPU.
I’m also aware they won’t make the direct references and I’m willing to bet the OP is too.
There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too slow.
Whet I often hear instead to be honest is people widely seem surprised when they have 200 tabs open in Chrome and everything still feels fast to them
That’s not to say performance isn’t important, it really is, in fact I’m the performance czar where I work, I spend along time on optimizations and performance.
However the acceptable performance threshold is dependent on the activity more than anything I’ve found. That’s why it’s such a big deal in e-commerce but people don’t seem to care as much for longer lived apps, otherwise Jira might actually be snappy
Now of course there is a threshold regardless of app where it will things negatively, losing customers etc. and thus it shouldn’t be ignore either
There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too slow.
Whet I often hear instead to be honest is people widely seem surprised when they have 200 tabs open in Chrome and everything still feels fast to them
That’s not to say performance isn’t important, it really is, in fact I’m the performance czar where I work, I spend along time on optimizations and performance.
However the acceptable performance threshold is dependent on the activity more than anything I’ve found. That’s why it’s such a big deal in e-commerce but people don’t seem to care as much for longer lived apps, otherwise Jira might actually be snappy
Now of course there is a threshold regardless of app where it will things negatively, losing customers etc. and thus it shouldn’t be ignore either
Then you are in a bubble. I was recently asked by my elderly parents why they are paying for 5g internet when the internet resources they use are so slow, slower than what they remember from 1997.
They ask me to call our ISP because it makes no sense that the sites they have used for decades feel so slow
All I could say was that there was nothing I could do.
They ask me to call our ISP because it makes no sense that the sites they have used for decades feel so slow
All I could say was that there was nothing I could do.
Every time I use Facebook (which isn't many but still) I am re-shocked at how fucking SLOW it is. How many times I end up refreshing the page because some damn thing didn't connect quick enough, or maybe too quick and it wasn't ready, I'm not sure.
YouTube is also great for this, like, 1/50 navigation clicks just results in a blank page with no error message. Ctrl-R to the rescue.
Or the number of times Reddit's infinite scroll just... dies. Somewhere in the background, I don't know where.
Like I can't think of any of these major platform websites where shit isn't just constantly tripping over it's own dick and breaking in often humorous but also just ridiculous ways.
YouTube is also great for this, like, 1/50 navigation clicks just results in a blank page with no error message. Ctrl-R to the rescue.
Or the number of times Reddit's infinite scroll just... dies. Somewhere in the background, I don't know where.
Like I can't think of any of these major platform websites where shit isn't just constantly tripping over it's own dick and breaking in often humorous but also just ridiculous ways.
Insulated market forces allow certain platforms to operate like this with very few overall repercussions.
They also don’t represent the overall web. I think it would be more far to take a sum of websites used, as opposed to number of users.
They also don’t represent the overall web. I think it would be more far to take a sum of websites used, as opposed to number of users.
That is a bit of an uncommon situation. Given the prevalence of things like 5G internet is typical in more rural or underdeveloped areas, the vast majority of the population of which don’t live.
It’s a valid concern (as I think performance always is to be clear) but the majority are not on higher latency / limited bandwidth connections like 5G internet service as their primary ISP delivery tech.
Vast majority are in cable or fiber at this point, given urban saturation
It’s a valid concern (as I think performance always is to be clear) but the majority are not on higher latency / limited bandwidth connections like 5G internet service as their primary ISP delivery tech.
Vast majority are in cable or fiber at this point, given urban saturation
> because it's fucking absurd to me that I need a (then anyway) 700 MB app to stream music.
You only know that factoid because you're an engineer and you looked it up. Users have absolutely no clue, and literally do not care.
You only know that factoid because you're an engineer and you looked it up. Users have absolutely no clue, and literally do not care.
> Users have absolutely no clue, and literally do not care
When their smartphone is 3 years old and has no more storage space, they say "the smartphone is old, I need a new one".
Because they don't know that this is a problem of the software industry being extremely bad doesn't mean that it has no impact on them.
When their smartphone is 3 years old and has no more storage space, they say "the smartphone is old, I need a new one".
Because they don't know that this is a problem of the software industry being extremely bad doesn't mean that it has no impact on them.
Phones are literally sold at different prices when they have more storage. People are familiar with being unable to install more apps or take more pictures. Happens all the time.
Get out of your bubble.
Get out of your bubble.
I hate what "modern" web development has done to my UI experience.
Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text.
AirCanada and WestJet are two other websites that became awful to use after adopting React-ey style UI's.
Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text.
AirCanada and WestJet are two other websites that became awful to use after adopting React-ey style UI's.
There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.
Vast majority of the comments on this story complaining about React are actually complaints about some bad UI library or a poorly designed and architected website that happens to use React.
I might not be able to tell if it's using React specifically, but I can tell it's using a React-like framework trivially because it feels like the entire website is covered in glue
No. You are just dealing with bad code. There are highly performant web apps written in React. It's all about craftsmanship. React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection. Or architectural decisions like splitting your UI into components correctly. It's up to the individual developers to use them. Bad developers write bad code in any framework.
But one thing I've noticed is that because frontend code runs on users' computers, fewer businesses and engineers have the incentive to really optimize that performance. If one writes bad backend code, it shows up as increased AWS bill; if one writes bad frontend code, well the cost is diffuse and many don't notice it.
But one thing I've noticed is that because frontend code runs on users' computers, fewer businesses and engineers have the incentive to really optimize that performance. If one writes bad backend code, it shows up as increased AWS bill; if one writes bad frontend code, well the cost is diffuse and many don't notice it.
> No. You are just dealing with bad code. There are highly performant web apps written in React.
cool maybe I'll see one one day
> React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection
but do people use these outside of demos
I have an high end CPU with 32GB of RAM and almost every single website I use gives me a worse experience than I got 20 years ago
> if one writes bad frontend code, well the cost is diffuse and many don't notice it.
exactly, and that's why we are where we are today - surrounded on all sides by websites covered in glue, because bad experience has been completely normalised, all for what? Some abstract notion of developer convenience that results in almost every case in a significantly worse experience by almost any metric.
cool maybe I'll see one one day
> React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection
but do people use these outside of demos
I have an high end CPU with 32GB of RAM and almost every single website I use gives me a worse experience than I got 20 years ago
> if one writes bad frontend code, well the cost is diffuse and many don't notice it.
exactly, and that's why we are where we are today - surrounded on all sides by websites covered in glue, because bad experience has been completely normalised, all for what? Some abstract notion of developer convenience that results in almost every case in a significantly worse experience by almost any metric.
> hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.
This is funny to me, because I would think that for hundreds of milliseconds, anything user-facing is impacted. It's on the order of the human reaction time (~200ms). That's noticeable delay.
I do not work in frontend, so perhaps I am misguided. But I have had bad user experience using apps with even 100ms delay that require a lot of input (for example using excel or something in a streaming VM).
This is funny to me, because I would think that for hundreds of milliseconds, anything user-facing is impacted. It's on the order of the human reaction time (~200ms). That's noticeable delay.
I do not work in frontend, so perhaps I am misguided. But I have had bad user experience using apps with even 100ms delay that require a lot of input (for example using excel or something in a streaming VM).
You are not misguided. Physiology is mostly intangible but consistent. Many of the comments here willingly ignore that “yes but my use case is different and my users are patient”. Their brain will still disconnect quickly and be frustrated.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progress was ever made, to the best of my knowledge.
This was an e-commerce site, more or less. As per the author's reasoning, it absolutely should not have been an SPA.
Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progress was ever made, to the best of my knowledge.
This was an e-commerce site, more or less. As per the author's reasoning, it absolutely should not have been an SPA.
E-commerce sites are a pretty good fit for SPAs. Sounds like a bad rewrite, nothing more, nothing less.
Why do you think that?
The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.
The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.
[deleted]
To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be).
Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.
Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.
(Sorry, somewhat copying this, since I responded to a similar point elsewhere.)
This is not practical advice for the vast majority of software engineering teams.
Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
This is not practical advice for the vast majority of software engineering teams.
Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it.
To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.
To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.
> Vanilla HTML, CSS, and JS
This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components?
Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.
This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components?
Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.
I didn’t say don’t use libraries at all. There’s a wide spectrum between rolling your own everything and putting a massive abstraction layer framework between you and the platform.
This is a really good article that puts very clearly some of the WTF moments I've had since having to take over a React project. However, if the title is "If not React, then what?", then the author should've answered that question.
I did find some recommendations for other reactive front-ends buried in the article, but I didn't see anything that set them apart aside from the fact that they are smaller projects. Now, if I want to follow the article's advice and get off of React I have a ton of research to do, research that the article's title didn't hint that I'd have to get going on.
I did find some recommendations for other reactive front-ends buried in the article, but I didn't see anything that set them apart aside from the fact that they are smaller projects. Now, if I want to follow the article's advice and get off of React I have a ton of research to do, research that the article's title didn't hint that I'd have to get going on.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds)
This is merely just to show something
From what I have seen, its quite easy to have performance issues with React
Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds)
This is merely just to show something
From what I have seen, its quite easy to have performance issues with React
So easy in fact that even the company that makes React can’t use it in a way that makes their site fast.
That doesn't say much about React, though. Indeed, you can open the network panel and watch requests go by over the seconds that it takes to open, suggesting that the issue likely resides on the backend.
So the company that invented it does not know how to properly use it?
Or are you implying that React does not fit FB use case?
Or are you implying that React does not fit FB use case?
He's literally saying the front end technology doesn't matter at all in this.
Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?
Are you just going to defend React to the bitter end? Or do you just enjoy imaginary binary choices?
I think I was not clear in my question:
I don't defend React. My question was almost the opposite and I was trying to ask:
So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?
I don't defend React. My question was almost the opposite and I was trying to ask:
So if even Facebook has a problem with using React then who has a better examplea about why and how to use it?
Like I said, React has nothing to do with the slowness issues of messenger.com.
but i think the reason for +1s, +2s feeling comes not from the client side aka react, render is fast, but they do make two requests to backend which takes ~230ms (for me in EU) and one request of ~130ms every other click on already visited chat/group chat.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one.
This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.
Modern web applications sometimes feel incredibly shitty to use. Gmail, YouTube, YouTube Music, Reddit, Twitter -- these are all bloated, hulking, beastly things.
I'm really hoping Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.
Heavy software that users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.
We need an engineering culture of excellence in these domains. Channel the Steve Jobs energy to say this isn't good enough.
This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.
Modern web applications sometimes feel incredibly shitty to use. Gmail, YouTube, YouTube Music, Reddit, Twitter -- these are all bloated, hulking, beastly things.
I'm really hoping Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.
Heavy software that users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.
We need an engineering culture of excellence in these domains. Channel the Steve Jobs energy to say this isn't good enough.
Why would you think rust will make the web sing? Their HTML documentation generator uses 571+ dependencies. So, hello more bloat! If the core rust team can't avoid it why would you think any other rust project would?
Why would an HTML generator need to slim down on dependencies? It's designed to run in CI, not respond in real time to user requests. It very infrequently runs and generates production artifacts with humans out of the loop.
This is a bad argument against Rust in the frontend.
Web frontend development is very nascent in Rust, but there's already cool stuff taking shape:
- https://www.egui.rs/
- https://leptos.dev/
This is a bad argument against Rust in the frontend.
Web frontend development is very nascent in Rust, but there's already cool stuff taking shape:
- https://www.egui.rs/
- https://leptos.dev/
You’re both right. It’s not as important that a documentation generator be blazing fast, but it’s a bad sign. If the core team finds themselves using 571 dependencies for something as simple as a documentation generator, how many thousands of dependencies will the average small business, trying to deliver value to customers quickly, end up using to create a line-of-business web app?
> This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.
And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.
And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.
> Heavy software users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.
I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that.
This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should
I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that.
This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should
[deleted]
> Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.
Colour me doubtful. As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. And no one is going to transfer the DOM into WASM and break every JavaScript app out there.
Colour me doubtful. As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. And no one is going to transfer the DOM into WASM and break every JavaScript app out there.
I urge you to read Alex's Reckoning series.
> performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds.
> it doesn’t create issues visible to my users
What do your users look like? What kind of devices are they on? Is it mostly mobile or desktop? Are they mostly accessing your service on cellular networks or not? Based on that, what does your INP look like? IMO you'll see the impact of React's legacy synthetic event system by looking at your INP because it's reinventing in userland what the platform already does well. This impact on INP is amplified on mobile and moreso on low-end mobile. See CRUX data visualised by desktop or mobile below:
https://infrequently.org/2022/12/performance-baseline-2023/#...
> Finally, the author doesn’t actually give a prescription as to what to use instead of React.
I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. The TLDR is there isn't a one-size-fits-all.
> performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds.
> it doesn’t create issues visible to my users
What do your users look like? What kind of devices are they on? Is it mostly mobile or desktop? Are they mostly accessing your service on cellular networks or not? Based on that, what does your INP look like? IMO you'll see the impact of React's legacy synthetic event system by looking at your INP because it's reinventing in userland what the platform already does well. This impact on INP is amplified on mobile and moreso on low-end mobile. See CRUX data visualised by desktop or mobile below:
https://infrequently.org/2022/12/performance-baseline-2023/#...
> Finally, the author doesn’t actually give a prescription as to what to use instead of React.
I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. The TLDR is there isn't a one-size-fits-all.
Curious, is this the series https://infrequently.org/2024/08/the-landscape/ ?
> I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section.
I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more.
> The TLDR is there isn't a one-size-fits-all.
That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion:
> Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs.
Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.
I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more.
> The TLDR is there isn't a one-size-fits-all.
That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion:
> Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs.
Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.
> That's what I mean - the author gives no prescription.
Are you expecting a prescription? If so, what could that look like? Specific technologies? When specific technologies are appropriate?
> Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF.
I don't quite understand this. A bakeoff is meant to give you space to figure out what technologies are appropriate for the service you're building for your users and taking into consideration what your developers like. It's a collection of proof-of-concepts so it's a quick and lean way to get data on what's more likely to succeed for you. I can accept that the technology doesn't make a product, so focusing PMF is important, but you also don't want to pick something complex that you can't afford to manage as you scale.
The worst thing I see happening is you reach PMF and need to continuing scaling, but you hit a high complexity wall that you can't move past till you manage it. All that unnecessary complexity you took on and didn't invest your already limited resources is now tech debt that's oppressing your forward momentum. Bakeoffs can steer you towards the simplest tool you need to deliver your product so that it can stay out of your way so you can focus on iterating and developing your product.
> The rest of us will use React, which is roughly 80% as good as the optimal solution.
How are you measuring this? A lot of the evidence for using a technology and running with it without managing the complexity turns out badly (see The Reckoning series by Alex). And React is a high complexity tool that requires a lot of continued management investment.
The thing that appeals to me about doing bakeoffs to find the simplest thing for my product is not that it'll be the most optimal; it'll be the cheapest to maintain. The less complexity you have, the less you have to invest in managing it.
> I just don't think many of us are Google or Facebook.
I agree. That's why I think it's best to pick the simplest tools we can afford to manage so we can get on with building our products. Facebook or Bluesky or Airbnb can afford to build their products many times from scratch and they can pay to maintain whatever complexity they take on.
Are you expecting a prescription? If so, what could that look like? Specific technologies? When specific technologies are appropriate?
> Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF.
I don't quite understand this. A bakeoff is meant to give you space to figure out what technologies are appropriate for the service you're building for your users and taking into consideration what your developers like. It's a collection of proof-of-concepts so it's a quick and lean way to get data on what's more likely to succeed for you. I can accept that the technology doesn't make a product, so focusing PMF is important, but you also don't want to pick something complex that you can't afford to manage as you scale.
The worst thing I see happening is you reach PMF and need to continuing scaling, but you hit a high complexity wall that you can't move past till you manage it. All that unnecessary complexity you took on and didn't invest your already limited resources is now tech debt that's oppressing your forward momentum. Bakeoffs can steer you towards the simplest tool you need to deliver your product so that it can stay out of your way so you can focus on iterating and developing your product.
> The rest of us will use React, which is roughly 80% as good as the optimal solution.
How are you measuring this? A lot of the evidence for using a technology and running with it without managing the complexity turns out badly (see The Reckoning series by Alex). And React is a high complexity tool that requires a lot of continued management investment.
The thing that appeals to me about doing bakeoffs to find the simplest thing for my product is not that it'll be the most optimal; it'll be the cheapest to maintain. The less complexity you have, the less you have to invest in managing it.
> I just don't think many of us are Google or Facebook.
I agree. That's why I think it's best to pick the simplest tools we can afford to manage so we can get on with building our products. Facebook or Bluesky or Airbnb can afford to build their products many times from scratch and they can pay to maintain whatever complexity they take on.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
This is not my experience on real react sites. Loading the pages on mobile (say 4G) takes seconds to load with a partially rendered page which is slowly constructed. Loading the equivalent pages in HTML rendered server side would reliably be under 100ms (excluding assets). This is somewhat disguised by better connections and large images taking up, but all that js and json does have a cost.
You're probably trying to talk about the overhead of the framework, but what is the true overhead of a framework which encourages you to introduce bloat and create a separate component file and sometimes a separate network connection for every single component on your web page?
Here is a real case study with comparison of approaches from this author: https://infrequently.org/2024/08/object-lesson/
>The second reason the author says is that it’s based on a legacy eventing system which supports IE.
There are lots of horrible bits of react which are based on solving problems which aren't really a problem on the web any more - from manipulating the dom (pretty easy without react) to dealing with IE polyfills, and lots of bits that you really don't need the client to concern itself with (i.e. routing code). You may not care about that code but you are importing it and forcing your users to download it. It all adds to overhead.
There are also a ton of other points in the article which you've elided, which go into the multiple failings of React as a tool, and primary among them is that it encourages you to use react and only react, the ultimate in lock-in.
> Finally, the author doesn’t actually give a prescription as to what to use instead of React.
You want them to choose one framework instead of react, they're explicitly rejecting that choice and saying you don't have to become a follower of react or any other religion, instead they're advocating choosing tools based on the evidence they have presented, so they are IMO presenting a clear choice:
Server side rendering with a bit of js as required to load dynamic data
React or similar frameworks which try to push everything to the client
This is not my experience on real react sites. Loading the pages on mobile (say 4G) takes seconds to load with a partially rendered page which is slowly constructed. Loading the equivalent pages in HTML rendered server side would reliably be under 100ms (excluding assets). This is somewhat disguised by better connections and large images taking up, but all that js and json does have a cost.
You're probably trying to talk about the overhead of the framework, but what is the true overhead of a framework which encourages you to introduce bloat and create a separate component file and sometimes a separate network connection for every single component on your web page?
Here is a real case study with comparison of approaches from this author: https://infrequently.org/2024/08/object-lesson/
>The second reason the author says is that it’s based on a legacy eventing system which supports IE.
There are lots of horrible bits of react which are based on solving problems which aren't really a problem on the web any more - from manipulating the dom (pretty easy without react) to dealing with IE polyfills, and lots of bits that you really don't need the client to concern itself with (i.e. routing code). You may not care about that code but you are importing it and forcing your users to download it. It all adds to overhead.
There are also a ton of other points in the article which you've elided, which go into the multiple failings of React as a tool, and primary among them is that it encourages you to use react and only react, the ultimate in lock-in.
> Finally, the author doesn’t actually give a prescription as to what to use instead of React.
You want them to choose one framework instead of react, they're explicitly rejecting that choice and saying you don't have to become a follower of react or any other religion, instead they're advocating choosing tools based on the evidence they have presented, so they are IMO presenting a clear choice:
Server side rendering with a bit of js as required to load dynamic data
React or similar frameworks which try to push everything to the client
They’re not problems most people have because they shouldn’t be using React or maybe even a SPA-type site in the first place! I think that’s one of the big points regardless. Just using react and it’s bloat to be hip and it not actually doing anything better or more performant for the use case of a shopping site. It’s not a CAD app or web office suite.
> But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.
I'm guessing you're one of those developers who never browses the web on anything but the latest Macbook Pro and iPhone. I implore you to restrict yourself to some lower end devices for a few weeks and let us know if you still feel the same way.
I'm guessing you're one of those developers who never browses the web on anything but the latest Macbook Pro and iPhone. I implore you to restrict yourself to some lower end devices for a few weeks and let us know if you still feel the same way.
I generally agree with you, but I have a budget cell phone (~$100) and I can run StackBlitz on it without it even blinking. I think budget cell phones have gotten a lot better than most people think.
There really are only a handful of things you could do that should passably take "hundreds of milliseconds" and loading a web page is not among them. Neither is displaying a few hundred thousand things on a screen, least of all what are essentially rects in 2D.
The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.
The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.
sure if you have the access directly to drawing those rects in 2D, but if you are using a library to do drawing of the rects you may have a small tradeoff of time (obviously not 100s of milliseconds) and if you are using a library that abstracts away writing to the DOM for you and then the browser takes the DOM and essentially figures out how to draw a hundred thousand things on the screen you might get in the hundred milliseconds area - depending on a whole bunch of things that are varying from time to time.
The only reason that 100s of milliseconds might sound fine is because there are multiple layers of abstraction between levels, but as you can see from all the other responses here the 100s of milliseconds evidently does not sound fine.
The only reason that 100s of milliseconds might sound fine is because there are multiple layers of abstraction between levels, but as you can see from all the other responses here the 100s of milliseconds evidently does not sound fine.
> But front end performance issues are almost never the most pressing issue
Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D
Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D
I've spent plenty of time optimizing performance. It almost always comes down to a backend issue, unless the frontend is doing something profoundly stupid, like making multiple API requests in serial when they could be batched or parallelized.
Yes because loading 500 different css and js files is not a problem for performance.
They literally just said "unless the frontend is doing something profoundly stupid".
That's the norm in the React world nowadays. You should take a look at https://infrequently.org/2024/08/object-lesson/
This article is better, but has very little to do with React. The major issues I see are 1) loading a 2.5 MB AWS library (not React), 2) not doing SSR (not React) and 3) not tree shaking (not React). I agree these are all problems. But shouting to the skies about React is not going to solve them.
'React' is really just a stand-in for the excesses of client-rendered apps. Do you really think Alex Russell, after writing all these blog posts about the general problem, thinks that React specifically is to blame? Of course not. He is picking it as an example that often causes higher complexity.
I think his definition of profoundly stupid probably differs from other people's.
In 2024. React is probably the worst choice you could make when creating a new web application.
For static web page, it would be tough to beat html/css. But if you are building a web application of some complexity, it would be tough to beat React.
You can totally shoot yourself in the foot with any language or framework. And you can most certainly do that with React as well. As we so often see.
You can totally shoot yourself in the foot with any language or framework. And you can most certainly do that with React as well. As we so often see.
...and the best would be?
Yeah, poor performance is possible in any system using any tech. Being able to diagnose it and fix it is what matters.
I've never had a performance issue I couldn't fix in React.
I've never had a performance issue I couldn't fix in React.
I think the question that we are discussing here is:
What amount of performance issues you will not need to fix if you were not using React to begin with?
What amount of performance issues you will not need to fix if you were not using React to begin with?
>React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend.
Respectfully, I disagree on all of these points.
Respectfully, I disagree on all of these points.
Care to elaborate?
Other commenters have elaborated as well, but to summmarize: hundreds of Ms on a dev machine a) does matter and b) is likely much much more in less than ideal computing environments, I disagree that the backend usually is where more time is spent (at least in maaaaany apps I have worked on) And re: specialized domains, I think most users of most software appreciate speed even if it isn’t a stated objective
I've been building sites since the 2000s and I'll let you know why React or jQuery "won."
It's because when you write code using these libraries, your code looks nice.
I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.)
React will be unseated like jQuery got unseated when someone makes something that looks nicer. Every time you write a library (or even API at work), make sure to look at your code samples and you better be 100% be able to say "this is pretty."
It's because when you write code using these libraries, your code looks nice.
I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.)
React will be unseated like jQuery got unseated when someone makes something that looks nicer. Every time you write a library (or even API at work), make sure to look at your code samples and you better be 100% be able to say "this is pretty."
I call that "developer happiness". It's extremely subjective but yeah, writing and then maintaining React code makes me the most happy in the best case scenarios, makes me feel like I can do more with less, it's easy for me to read and design. I feel like I have more friction with other JS tools.
Just in case you're unaware of it and wish to read similar content, there's a term/thing floating around for some time now, called "Developer Experience" (often abbreviated as "DX") that seems to cover this, and more.
React code looks good for clicker example, when building real application I think it's much harder to read than vanilla JS, especially when hooks and all the dependency arrays flying around, constantly worried about how many times will things fire and super easy to make mistakes no matter the skill level.
This is the biggest detraction of react, it’s very hard to debug
A more generous way to say this is that the code is more readable, which is in fact important in a growing codebase.
plenty of react code looks nice but is still unreadable
The code samples in Hackers Delight are awfully pretty, but by no means readable.
Pretty definitely does not mean readable.
Pretty definitely does not mean readable.
To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such).
That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.
That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.
I’m going to be the devil’s advocate because I’m from the team "no SPA at all unless you have a real need like real time" but to me, Angular is the less worse when it comes to writing SPAs in teams.
Clumsy and hard to learn ? Sure. The code looking less cool than other frameworks ? Of course. Unbearably slow compiler ? Check.
But at least you got a full fledged, batteries included framework, with a powerful DI system and an established architecture to follow. Not the funniest framework but it works.
The only powerful thing but also big flaw with angular is that they deliberately expose a lot of the framework internals with a very neutral documentation that never explains that you shouldn’t touch this or this in most cases. It allows very nice and clean extensions of the framework but, oh my, if you inherit a codebase from a "smart guy" who knows the framework inside and out and "did better" than the boring angular architecture, then good luck.
I know this can happen in any codebase and I’ve seen it everywhere but Angular exposes so much things that you can make horrible things.
But in a team who have a boring CRM or SaaS front end it’s a pretty good framework to use. Except if you can do everything server side.
Clumsy and hard to learn ? Sure. The code looking less cool than other frameworks ? Of course. Unbearably slow compiler ? Check.
But at least you got a full fledged, batteries included framework, with a powerful DI system and an established architecture to follow. Not the funniest framework but it works.
The only powerful thing but also big flaw with angular is that they deliberately expose a lot of the framework internals with a very neutral documentation that never explains that you shouldn’t touch this or this in most cases. It allows very nice and clean extensions of the framework but, oh my, if you inherit a codebase from a "smart guy" who knows the framework inside and out and "did better" than the boring angular architecture, then good luck.
I know this can happen in any codebase and I’ve seen it everywhere but Angular exposes so much things that you can make horrible things.
But in a team who have a boring CRM or SaaS front end it’s a pretty good framework to use. Except if you can do everything server side.
> an established architecture to follow. Not the funniest framework but it works.
yeah, that's worthy, especially in teams, it avoids friction most of the time
yeah, that's worthy, especially in teams, it avoids friction most of the time
React does very little. You still need other libs to go with it before you can compare the set of them to Angular.
I stopped following the angular world long ago, how much is included in it ? (on my way to read their docs but I'm still open to a short summary :)
Routing, form handling, dependency injection, testing, services, http requests processing, localization etc etc …
In fact the "write a component" part is the center of React but only one of the features of Angular. In my experience, the big advantage of Angular is that you rarely need anything else and so it’s totally possible and reasonable to write a full fledged application without any other dependency than Angular itself. In $prev_job, we had nothing else in package.json than angular, some internal libs and the internal design system (which were exposed as angular providers) and some wysiwyg editor like quill.
It’s far from the funniest framework, but for writing boring things in team setting, it’s actually pretty good.
In fact having worked on the oldest AngularJS framework, it’s very interesting how it made a full 180 from "magic everywhere" to a boring "enterprise" framework.
I would never make a side project in angular because it can be pretty boilerplatey but in a team of 3 or more devs in a multi months dev project that I’ll have to maintain for years, that’d be my choice.
Except if I can reasonably do it without an SPA beforehand but that’s a totally inaudible proposition in corporate world anyway.
In fact the "write a component" part is the center of React but only one of the features of Angular. In my experience, the big advantage of Angular is that you rarely need anything else and so it’s totally possible and reasonable to write a full fledged application without any other dependency than Angular itself. In $prev_job, we had nothing else in package.json than angular, some internal libs and the internal design system (which were exposed as angular providers) and some wysiwyg editor like quill.
It’s far from the funniest framework, but for writing boring things in team setting, it’s actually pretty good.
In fact having worked on the oldest AngularJS framework, it’s very interesting how it made a full 180 from "magic everywhere" to a boring "enterprise" framework.
I would never make a side project in angular because it can be pretty boilerplatey but in a team of 3 or more devs in a multi months dev project that I’ll have to maintain for years, that’d be my choice.
Except if I can reasonably do it without an SPA beforehand but that’s a totally inaudible proposition in corporate world anyway.
I was going to write a counter argument that codebases using earlier versions of React did not look nice, and that they only started to look nice when React moved to Hooks and functional components.
But I realized that actually supports your argument. React with Hooks and functional components unseated old school React.
But I realized that actually supports your argument. React with Hooks and functional components unseated old school React.
> they only started to look nice when React moved to Hooks and functional components
Is this a widely held opinion? Call me crazy, but I really liked class components. It was nice to see the lifecycle stages in the actual method names, and encapsulate the behavior inside of a method block. To me that was really nice to read.
With hooks, everything is inside a function without clear delineation. The lifecycle stages are put anywhere in there with (to me) strange looking calls to useEffect and such.
Before, I used to love whipping up a quick UI in React, but since hooks I loathe doing that. I really don't want to upgrade my existing apps to newer versions. And for potential future project I'm looking for an alternative.
Perhaps I don't like it so much because I'm primarily a back and systems engineer, and only do small frontends on the side.
Is this a widely held opinion? Call me crazy, but I really liked class components. It was nice to see the lifecycle stages in the actual method names, and encapsulate the behavior inside of a method block. To me that was really nice to read.
With hooks, everything is inside a function without clear delineation. The lifecycle stages are put anywhere in there with (to me) strange looking calls to useEffect and such.
Before, I used to love whipping up a quick UI in React, but since hooks I loathe doing that. I really don't want to upgrade my existing apps to newer versions. And for potential future project I'm looking for an alternative.
Perhaps I don't like it so much because I'm primarily a back and systems engineer, and only do small frontends on the side.
Hooks are awful. They’re a faux-functional interface, accessing implicit local state, with so much magic going on behind the scenes that it’s obscene. At least in class component days it was obvious which components were stateful. Now you’ve got to remember which magic hook incantation is causing your “functional” component to improperly cache state and why. I cannot for the life of me see it as an improvement in any way other than “it looks nicer,” which aligns with the top-level parent’s point.
Anyway I think react in general is kind of terrible. I’ve worked at three places whereFE teams made a react codebase that wound up being so scary and difficult to work in that essentially no one would touch it, until it eventually got rewritten. Two of those just rewrote it in react again, hoping that whatever faddish state library would save them from themselves. At the third, they rewrote it in svelte, which went much better. At least for me as someone who only writes FE code when I have to, svelte is much more comprehensible and sensible.
Anyway I think react in general is kind of terrible. I’ve worked at three places whereFE teams made a react codebase that wound up being so scary and difficult to work in that essentially no one would touch it, until it eventually got rewritten. Two of those just rewrote it in react again, hoping that whatever faddish state library would save them from themselves. At the third, they rewrote it in svelte, which went much better. At least for me as someone who only writes FE code when I have to, svelte is much more comprehensible and sensible.
> React will be unseated like jQuery got unseated when someone makes something that looks nicer.
The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want.
No more JavaScript limitations.
The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want.
No more JavaScript limitations.
>No more JavaScript limitations.
But you accept a whole host of other limitations with WASM. It's a trade-off. You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? Okay, so use canvas instead and do all UI inside WASM? That seems like reinventing the wheel that is Javascript + DOM. WASM has plenty of uses, but replacing Javascript probably isn't where it shines. Javascript is still great for front-end tasks, WASM is good for lots of other things that aren't user-interface related, like running ffmpeg inside the browser. I'm doing this on a project and the front-end was easy to create a drag-and-drop file upload in javascript (React) and handle all user interface stuff like progress bars, etc. ffmpeg runs as WASM code doing whatever the Javascript tells it to do. I can't imagine also writing a front-end in Rust or something else that's supposed to run inside a web browser in WASM just because of vague "JavaScript limitations", when Javascript is really a good solution for front-end UI inside a web browser.
But you accept a whole host of other limitations with WASM. It's a trade-off. You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? Okay, so use canvas instead and do all UI inside WASM? That seems like reinventing the wheel that is Javascript + DOM. WASM has plenty of uses, but replacing Javascript probably isn't where it shines. Javascript is still great for front-end tasks, WASM is good for lots of other things that aren't user-interface related, like running ffmpeg inside the browser. I'm doing this on a project and the front-end was easy to create a drag-and-drop file upload in javascript (React) and handle all user interface stuff like progress bars, etc. ffmpeg runs as WASM code doing whatever the Javascript tells it to do. I can't imagine also writing a front-end in Rust or something else that's supposed to run inside a web browser in WASM just because of vague "JavaScript limitations", when Javascript is really a good solution for front-end UI inside a web browser.
> You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen?
You can access the DOM through JavaScript glue. These Rust WASM frameworks do that:
- Leptos: https://www.leptos.dev/
- Sycamore: https://sycamore.dev/
- Yew: https://yew.rs/
- Dioxus: https://dioxuslabs.com/
Eventually you won't need the glue.
> Okay, so use canvas instead and do all UI inside WASM?
You can do that too. That's what this VB6 clone written in C# and compiled to WebAssembly does:
- https://bandysc.github.io/AvaloniaVisualBasic6/
- https://github.com/BAndysc/AvaloniaVisualBasic6
> vague "JavaScript limitations"
It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
- https://nuenki.app/blog/bloom_filters_optimisation
- https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...
- https://www.amazon.science/blog/how-prime-video-updates-its-...
- https://web.dev/case-studies/google-sheets-wasmgc
That's a kick to the groin that's tough to walk off.
You can access the DOM through JavaScript glue. These Rust WASM frameworks do that:
- Leptos: https://www.leptos.dev/
- Sycamore: https://sycamore.dev/
- Yew: https://yew.rs/
- Dioxus: https://dioxuslabs.com/
Eventually you won't need the glue.
> Okay, so use canvas instead and do all UI inside WASM?
You can do that too. That's what this VB6 clone written in C# and compiled to WebAssembly does:
- https://bandysc.github.io/AvaloniaVisualBasic6/
- https://github.com/BAndysc/AvaloniaVisualBasic6
> vague "JavaScript limitations"
It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
- https://nuenki.app/blog/bloom_filters_optimisation
- https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...
- https://www.amazon.science/blog/how-prime-video-updates-its-...
- https://web.dev/case-studies/google-sheets-wasmgc
That's a kick to the groin that's tough to walk off.
>It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
That's great that WebAssembly outperforms Javascript. But only in processing power - and not all programming tasks require the most bleeding-edge performance. User interfaces do not require the speed of WASM. They require being easy to develop, and Javascript is almost always the right solution for UI. None of the WASM frameworks you mentioned are used very much, there's simply not the ecosystem for them that there is for Javascript for user interfaces.
And this is what they mean when they say "use the right tool for the job". I'm not going to use ffmpeg ported to Javascript, because that would be slow - of course I'm going to use ffmpeg in WASM to transcode video in the browser. And I'm not going to replace React with something in WebAssembly no matter what language, because it's just far easier to write the UI in React. Or even jQuery, or even just plain old vanilla Javascript.
Javascript is a very easy language to work with, in spite of what the people that don't really understand Javascript think about it. The only reason to do UI in WASM is that you don't understand Javascript or you have an irrational hate for it, or "because reasons". But sure, do whatever you want to do, I'm in no way saying you can't. Just don't expect that WASM will be replacing Javascript in any real way, anytime soon.
That's great that WebAssembly outperforms Javascript. But only in processing power - and not all programming tasks require the most bleeding-edge performance. User interfaces do not require the speed of WASM. They require being easy to develop, and Javascript is almost always the right solution for UI. None of the WASM frameworks you mentioned are used very much, there's simply not the ecosystem for them that there is for Javascript for user interfaces.
And this is what they mean when they say "use the right tool for the job". I'm not going to use ffmpeg ported to Javascript, because that would be slow - of course I'm going to use ffmpeg in WASM to transcode video in the browser. And I'm not going to replace React with something in WebAssembly no matter what language, because it's just far easier to write the UI in React. Or even jQuery, or even just plain old vanilla Javascript.
Javascript is a very easy language to work with, in spite of what the people that don't really understand Javascript think about it. The only reason to do UI in WASM is that you don't understand Javascript or you have an irrational hate for it, or "because reasons". But sure, do whatever you want to do, I'm in no way saying you can't. Just don't expect that WASM will be replacing Javascript in any real way, anytime soon.
> But only in processing power
Only in processing power?
So you mean JavaScript is less efficient than WebAssembly, which means every time a piece of JavaScript runs on the billions of systems running its suboptimal runtime there is higher power usage, which means there is a greater demand on energy supply, which means there are greater carbon emissions, which means more global warming, which means we're closer to a climate change catastrophe than ever before.
So not only is JavaScript slow it's also an ecological disaster.
You've convinced me. Brendan Eich has a lot to answer for.
Only in processing power?
So you mean JavaScript is less efficient than WebAssembly, which means every time a piece of JavaScript runs on the billions of systems running its suboptimal runtime there is higher power usage, which means there is a greater demand on energy supply, which means there are greater carbon emissions, which means more global warming, which means we're closer to a climate change catastrophe than ever before.
So not only is JavaScript slow it's also an ecological disaster.
You've convinced me. Brendan Eich has a lot to answer for.
Wow. I've never seen anyone make a sky-is-falling argument about Javascript to this level before. Bravo? /s? Either way it's an impressive reach.
If you're a large hosting provider like a Google or a Microsoft or an Amazon or a CloudFlare, you want to be eco. You want to be eco for PR reasons, for financial reasons, and for practical engineering reasons.
Slow scripting languages don't make you eco.
You have to think bigger.
Slow scripting languages don't make you eco.
You have to think bigger.
Yes, let's save the electrons so we can mine bitcoin with them. /s
oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s
You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just looney tunes crazy. Sorry, it just is.
oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s
You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just looney tunes crazy. Sorry, it just is.
Sure, I wrote nice code in Go, the language I want, and compiled to wasm. The most simple apps were 2MB+ of wasm compressed, browsers won’t even reliably cache blobs that large, got evicted all the time. And 100KB of react is bloated? Lol wtf.
Don’t tell me “whatever language you want” means “whatever language named Rust you want”, thank you.
Don’t tell me “whatever language you want” means “whatever language named Rust you want”, thank you.
Ah, so you want to use TinyGo. Makes smaller binaries:
https://tinygo.org/
https://tinygo.org/
No, none of my Go wasm projects worked with TinyGo (maybe reflection support is better now, but I’m not going to start a new project in it just to find out midway that it’s yet another disappointment). TinyGo is not the language I want, but rather, an unclear subset of the language I want.
Interesting take. On the other side, many library developers drop TypeScript[1] because it requires a build step and might be tricky to deliver to library users.
I wonder how much would WebAssembly suffer from this and compatibility issues. I hope browsers to improve WASM ecosystem so that it can be used more widely and without the need to ship the whole runtime with your website.
[1]: https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
I wonder how much would WebAssembly suffer from this and compatibility issues. I hope browsers to improve WASM ecosystem so that it can be used more widely and without the need to ship the whole runtime with your website.
[1]: https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
> The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want.
OK and then how do I do my form UI on that codebase?
When at all possible I write stuff in Scala, using Scala.js when it needs to run in the browser. But I still use React for the UI part.
OK and then how do I do my form UI on that codebase?
When at all possible I write stuff in Scala, using Scala.js when it needs to run in the browser. But I still use React for the UI part.
I would completely agree and this is a large part of why I like Astro for static sites
I wouldn't call it a win. Web UIs plateaued about 10-15 years ago. It was never the state of the art in what is possible with user interfaces; it always was a huge compromise between having something that feels vaguely responsive shoehorned into a platform (browsers) not really designed for being a platform for implementing UIs. Mediocrity is the norm on the web. And react is just the gold standard for shoveling that shit out. It's not good, or great, or nice, etc. It's just that the rest is just more of the same level of mediocrity.
My feeling is that the core issues were never really addressed. Javascript was utter shit 25 years ago and it still is. CSS was an inflexible complex mess. And it still is. And the browser's DOM tree was more or less an accident that resulted from a brief industry wide obsession with things like XML. Hacking UI frameworks on top of that is basically what most frameworks do. But it's just not a very good basis for any of that. Design by committee stuff. All of it. The worst is that there's a lot of good UI out there on other platforms.
The web was awkward and painful 25 years ago and it has gotten a bit better but actually not a whole lot. There's nothing pretty about it. Or state of the art (not even close). It's just a lot of mediocrity and a culture of people confusing this mediocrity with "apparently this is how it's done" and not even questioning it anymore. It was easier to do some things with Flash twenty years ago than it is with web technologies today. People have stopped bothering to attempt to even do a lot of these things. Just not worth the pain. And mediocre is good enough. Slap a drop shadow on it and call it a day. Maybe a cheesy css transition here and there.
I love brutalist websites like HN calling bullshit on this crap. Dang and his friends don't even attempt to dress it up. It's orange! Forever! Enjoy. It looked dated ten years ago, the same it does now. But it's also a major news website running circles around most of its competition. At best they might weak 1 CSS color around Christmas or so from orange to red. That's about the extent of "web design" that happens on this website. It doesn't need it. It would be just window dressing.
My feeling is that the core issues were never really addressed. Javascript was utter shit 25 years ago and it still is. CSS was an inflexible complex mess. And it still is. And the browser's DOM tree was more or less an accident that resulted from a brief industry wide obsession with things like XML. Hacking UI frameworks on top of that is basically what most frameworks do. But it's just not a very good basis for any of that. Design by committee stuff. All of it. The worst is that there's a lot of good UI out there on other platforms.
The web was awkward and painful 25 years ago and it has gotten a bit better but actually not a whole lot. There's nothing pretty about it. Or state of the art (not even close). It's just a lot of mediocrity and a culture of people confusing this mediocrity with "apparently this is how it's done" and not even questioning it anymore. It was easier to do some things with Flash twenty years ago than it is with web technologies today. People have stopped bothering to attempt to even do a lot of these things. Just not worth the pain. And mediocre is good enough. Slap a drop shadow on it and call it a day. Maybe a cheesy css transition here and there.
I love brutalist websites like HN calling bullshit on this crap. Dang and his friends don't even attempt to dress it up. It's orange! Forever! Enjoy. It looked dated ten years ago, the same it does now. But it's also a major news website running circles around most of its competition. At best they might weak 1 CSS color around Christmas or so from orange to red. That's about the extent of "web design" that happens on this website. It doesn't need it. It would be just window dressing.
I agree on all your points. The basic web technologies are still primitive, and therein lies the problem.
All these arguments about frameworks and libraries would be moot if the web technologies were properly designed, so i believe that is where we should focus our energies.
Why is it that after several decades HTML, CSS and JS are still so primitive?
All these arguments about frameworks and libraries would be moot if the web technologies were properly designed, so i believe that is where we should focus our energies.
Why is it that after several decades HTML, CSS and JS are still so primitive?
I actually think the more powerful factor was that React and jQuery before it were easy to pick up and start integrating without a lot of fuss. You don't need to build a dedicated website, you can just start incorporating these libraries into your existing stuff. Compare to Angular which basically demanded a rewrite to start using it.
For similar reasons, I thought Vue.js would win over React, but it's starting to seem I was wrong.
For similar reasons, I thought Vue.js would win over React, but it's starting to seem I was wrong.
i am skeptical. there is way more than nice looking code to make a framework popular. in my opinion if nice looking code were to matter then aurelia would be a lot more popular: https://github.com/stickfigure/blog/wiki/Opinionated-Compari...
Same reason Python is eating the world. It’s technically one of the worst runtimes. Slow and difficult to distribute. Nobody cares, because code ends up short and pretty.
If this was true we’d have Ruby everywhere.
> It's because when you write code using these libraries, your code looks nice.
When you use an operating system, you don't see the millions of lines of code that go into scheduling/kernel, drivers, etc.
When you use an operating system, you don't see the millions of lines of code that go into scheduling/kernel, drivers, etc.
A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses.
Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing.
I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra
Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing.
I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra
I think most responses to his posts are missing that this is the most important part:
> In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.
> In less vulgar terms, the struggle is to convince managers and tech leads that they need to start with user needs. Or as Public Digital puts it, "design for user needs, not organisational convenience"
This is the most important thing. The entire article series is making this point in great detail, and also being very angry at orgs (especially public services!) that don't get this.
I think this message does get a bit buried under invective against React. Surprise surprise, if you do start with user needs, then sometimes that does lead to you building a React-based SPA. I think from Alex's perspective working with organisations, looking at it from the other direction: for any given React SPA, it is unlikely that React was chosen because of user needs.
> In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.
> In less vulgar terms, the struggle is to convince managers and tech leads that they need to start with user needs. Or as Public Digital puts it, "design for user needs, not organisational convenience"
This is the most important thing. The entire article series is making this point in great detail, and also being very angry at orgs (especially public services!) that don't get this.
I think this message does get a bit buried under invective against React. Surprise surprise, if you do start with user needs, then sometimes that does lead to you building a React-based SPA. I think from Alex's perspective working with organisations, looking at it from the other direction: for any given React SPA, it is unlikely that React was chosen because of user needs.
The problem is that this fundamental claim undermines the entirety of the argument. You can build a good web experience in React if you care about the user experience.
I don't find the argument to be undermined by this. From my perspective, his strong statements against React read as deliberately lacking in nuance just like the conventional wisdom of "just use React and don't think too hard about it". It's a deliberate overvorrection away from the status quo. There can be room for nuance once the default assumption has been shaken.
I get why people are offended or find it unhelpful. If you read through his Reckoning series, I hope you'll understand some of the righteous anger he has for organisations that fail to serve the user, even when public service is their explicit purpose.
Blaming it on React may not be the most effective strategy. Who knows. But I still find value in the message.
I get why people are offended or find it unhelpful. If you read through his Reckoning series, I hope you'll understand some of the righteous anger he has for organisations that fail to serve the user, even when public service is their explicit purpose.
Blaming it on React may not be the most effective strategy. Who knows. But I still find value in the message.
If you try something for a decade and it doesn't work, maybe a change in style is necessary! An article exceeding 20 pages doesn't sound like the best persuasion strategy.
I’m not a front end engineer and I read most of this, at first for sheer morbid curiosity about the drama, then I kept reading because it looked like deep knowledge and detailed exposition of a complex subject, then I kept reading because I was wondering who listens to a guy like this and why?
In my experience, regardless of your skill at communication, coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare. If you need to communicate a subtle point or detailed argument, then you’ve already lost. This is because for any technical decision the opposite argument from FUD is easier to make and easier to digest, regardless of whether the FUD advice is to stay/defect on the tech stack or the design decision or whatever. IOW the winning strategy is basically to always go 2nd after what TFA calls the “thoughtful engineer” burns out the audience by being rational and thorough. Even more bluntly.. most people are just showing up to work and have no interest (and much less passion) for craftsmanship.
I wish it was different, since I believe in architecture / design. But, there’s a good chance no one cares about your detailed analysis at all and you’re much better off producing more shallow demos/diagrams/decks regardless of whether your audience is engineers or management.
In my experience, regardless of your skill at communication, coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare. If you need to communicate a subtle point or detailed argument, then you’ve already lost. This is because for any technical decision the opposite argument from FUD is easier to make and easier to digest, regardless of whether the FUD advice is to stay/defect on the tech stack or the design decision or whatever. IOW the winning strategy is basically to always go 2nd after what TFA calls the “thoughtful engineer” burns out the audience by being rational and thorough. Even more bluntly.. most people are just showing up to work and have no interest (and much less passion) for craftsmanship.
I wish it was different, since I believe in architecture / design. But, there’s a good chance no one cares about your detailed analysis at all and you’re much better off producing more shallow demos/diagrams/decks regardless of whether your audience is engineers or management.
This is a very underrated comment.
My only quibble is that it’s certainly possible to choose React (or any popular solution to a problem) without considering other options too much, and still care about craft.
My only quibble is that it’s certainly possible to choose React (or any popular solution to a problem) without considering other options too much, and still care about craft.
> coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare
I agree! In general, people are resistant to change, period. Some are particularly wary of facts and logic (see: politics). Successfully getting points across, even when one "is right," often requires a lot of strategizing and non-technical effort.
Whole books have been written on this subject [1]. For those attempting to navigate the challenge, just remember that it's all too easy to burn out in the office while "chasing your ideals.". Doing this while keeping your sanity is an art :-).
--
1: https://pragprog.com/titles/trevan/driving-technical-change/
I agree! In general, people are resistant to change, period. Some are particularly wary of facts and logic (see: politics). Successfully getting points across, even when one "is right," often requires a lot of strategizing and non-technical effort.
Whole books have been written on this subject [1]. For those attempting to navigate the challenge, just remember that it's all too easy to burn out in the office while "chasing your ideals.". Doing this while keeping your sanity is an art :-).
--
1: https://pragprog.com/titles/trevan/driving-technical-change/
Good point, but you should take a look at a post where he does exactly this: https://infrequently.org/2024/08/object-lesson/
I doubt it's a matter of style. There's a lot of tribalism and irrational opinions around React.
> A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses.
The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function: see his entire work on web components.
> I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research
He's not the only one speaking about web performance, or doing research. He's not Casaandra. At best, he's a false prophet.
His series on web performance gaps is good, though.
The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function: see his entire work on web components.
> I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research
He's not the only one speaking about web performance, or doing research. He's not Casaandra. At best, he's a false prophet.
His series on web performance gaps is good, though.
> and tech requires Javascript to even barely function: see his entire work on web components.
I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished downloading, and as it finishes, it progressively enhances the content of the page. Web components is a part of that story.
Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished downloading, and as it finishes, it progressively enhances the content of the page. Web components is a part of that story.
Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
> the whole premise builds atop of how the web and the browser works
Of course not. They need Javascript to participate in forms (though a button on WCs still can't work as a submit button), they need JS to handle global styles, they need JS to handle ARIA (there are at least two different proposals for this), they need JS to fix text selection etc. etc.
Nothing in web components two dozen specs builds on top of basic browser functionality.
> Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
That's bot what I wrote. I'm calling Alex Russel's hypocrisy. He's ranting against web frameworks while he's spent the past decade creating tech that needs more and more JS for basic functionality (and more JS to fix issues previous designs and patches) and is literally advised to be used as only through libraries and frameworks
Of course not. They need Javascript to participate in forms (though a button on WCs still can't work as a submit button), they need JS to handle global styles, they need JS to handle ARIA (there are at least two different proposals for this), they need JS to fix text selection etc. etc.
Nothing in web components two dozen specs builds on top of basic browser functionality.
> Why do you want web components to work without JS? Do you also put the same constraints on frameworks?
That's bot what I wrote. I'm calling Alex Russel's hypocrisy. He's ranting against web frameworks while he's spent the past decade creating tech that needs more and more JS for basic functionality (and more JS to fix issues previous designs and patches) and is literally advised to be used as only through libraries and frameworks
Yes, I think you’re right. I overwhelmingly agree with his articles, but when I share the content with my colleagues it gets at best a careless shrug, but most often what amounts to “but [technology referenced] is good because it’s popular.” React is one of those problematic choices companies continue to make.
I happen to agree with most of what he said, but man, that tone was insufferable ...
(non-wrapping extra long lines have not helped but maybe that's on my user agent)
My rules of thumb:
* informational website / blog - static frontend (Django! :heart:)
* some interactivity - htmx
* a lot of interactivity (app that happens to libe in the browser) - spa (React and weep)
For a very strong assertion he makes (even if you need spa, react is obsolete), he dismisses finding a good alternative as an exercise to the reader. The ones listed offhandedly in a side note look all the same (as react) to me.
(non-wrapping extra long lines have not helped but maybe that's on my user agent)
My rules of thumb:
* informational website / blog - static frontend (Django! :heart:)
* some interactivity - htmx
* a lot of interactivity (app that happens to libe in the browser) - spa (React and weep)
For a very strong assertion he makes (even if you need spa, react is obsolete), he dismisses finding a good alternative as an exercise to the reader. The ones listed offhandedly in a side note look all the same (as react) to me.
Or maybe he's just complaining about things that most people don't care about. Because they're not relevant for the day to day jobs
For me, when he said this:
"In short, nobody should start a new project in the 2020s based on React. Full stop."
He lost me. My React web app of medium complexity is statically exported and gets cached by the user's browser. All the data it needs for the main page is fetched by a single graphql call. The UI code renders in less than 10ms even on old machines. Network and the backend are the primary bottlenecks for me.
Could I redesign and rearchitect it such that the frontend is very slow to render even on modern machines? Yes, quite easily. And I suspect, many people complaining about React's performance are doing just that.
"In short, nobody should start a new project in the 2020s based on React. Full stop."
He lost me. My React web app of medium complexity is statically exported and gets cached by the user's browser. All the data it needs for the main page is fetched by a single graphql call. The UI code renders in less than 10ms even on old machines. Network and the backend are the primary bottlenecks for me.
Could I redesign and rearchitect it such that the frontend is very slow to render even on modern machines? Yes, quite easily. And I suspect, many people complaining about React's performance are doing just that.
Maybe because they start with this tldr:
> In short, nobody should start a new project in the 2020s based on React. Full stop.
Good arguments here but the dogma doesn't help.
> In short, nobody should start a new project in the 2020s based on React. Full stop.
Good arguments here but the dogma doesn't help.
Sometimes you have to fight fire with fire. The fact that some people reach for React before even considering what they are building requires some corrective polemics.
I disagree. The author can make the "perfect argument" but it won't matter if the individuals who need convincing bounce before the first section.
4ntiq(2)
The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish
People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to manage O(n^2) UI state transitions via recursive mutating callbacks. Simple things like "have a the list of photos shown always kept in sync with a label showning count of photos" was incredibly error prone, and the complexity of implementation went up quadratically with the complexity of your app (due to the n^2 state transitions you needed to worry about!)
Today React is not the only one to do this O(^2) to O(n) complexity reduction, but it was the first to go mainstream, and very much deserves its success in spite of its various shortcomings
People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to manage O(n^2) UI state transitions via recursive mutating callbacks. Simple things like "have a the list of photos shown always kept in sync with a label showning count of photos" was incredibly error prone, and the complexity of implementation went up quadratically with the complexity of your app (due to the n^2 state transitions you needed to worry about!)
Today React is not the only one to do this O(^2) to O(n) complexity reduction, but it was the first to go mainstream, and very much deserves its success in spite of its various shortcomings
You're completely right, but I think it's worth adding that the O(n^2) to O(n) change isn't specific to React or UI. That same improvement is often seen when migrating other code from a mutating style to a pure-functional style.
"A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture because of performance concerns. In practice, the baseline performance is often faster than they expect, and it can be made much, much faster using strategies like memoisation and fine-grained reactivity.
"A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture because of performance concerns. In practice, the baseline performance is often faster than they expect, and it can be made much, much faster using strategies like memoisation and fine-grained reactivity.
> "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture because of performance concerns. In practice, the baseline performance is often faster than they expect, and it can be made much, much faster using strategies like memoisation and fine-grained reactivity.
But before React came along, you just couldn't do this without major UX breaking bugs, because of how the DOM worked.
Say you have a form that you want to change depending on the state of the app. If the user is typing in a form field while an update to the app state comes, and a pure function that transforms (app state -> DOM/HTML output) resets the form (meaning removing the old out of state DOM and replacing it with the new DOM), the user loses focus on the form. So you have to add some kind of logic where the app remembers what form input the user was focused on, where in the field the focus was, etc. The more complex your app is, the more complex the DOM reset logic became, and you cannot abstract your way out of it with pure functions, because the DOM that relies on mutation slowly creeps into your pure functions anyway.
React changed this, because it gives you a pure function interface, but resets the DOM using mutation functions i.e. native DOM methods, surgically. This is achieved with the VDOM (Virtual DOM), by diffing VDOM states and then reflecting that to the actual DOM. This means when the DOM resets, there's no problem with elements getting removed and added back in, and the focus states etc. don't get thrown away with the DOM. Before React, nothing like this existed.
But before React came along, you just couldn't do this without major UX breaking bugs, because of how the DOM worked.
Say you have a form that you want to change depending on the state of the app. If the user is typing in a form field while an update to the app state comes, and a pure function that transforms (app state -> DOM/HTML output) resets the form (meaning removing the old out of state DOM and replacing it with the new DOM), the user loses focus on the form. So you have to add some kind of logic where the app remembers what form input the user was focused on, where in the field the focus was, etc. The more complex your app is, the more complex the DOM reset logic became, and you cannot abstract your way out of it with pure functions, because the DOM that relies on mutation slowly creeps into your pure functions anyway.
React changed this, because it gives you a pure function interface, but resets the DOM using mutation functions i.e. native DOM methods, surgically. This is achieved with the VDOM (Virtual DOM), by diffing VDOM states and then reflecting that to the actual DOM. This means when the DOM resets, there's no problem with elements getting removed and added back in, and the focus states etc. don't get thrown away with the DOM. Before React, nothing like this existed.
> If the user is typing in a form field while an update to the app state comes
Could you give a practical example of what you mean here? I can't quite wrap my head around what kind of interaction you're describing.
Do you mean some kind of scenario like a shared document with multiple people editing it? This is a very niche case.
> This means when the DOM resets, there's no problem with elements getting removed and added back in,
Could you give a practical example of this? I've been building web apps for a long time and I don't know what "when the dom resets" means.
Could you give a practical example of what you mean here? I can't quite wrap my head around what kind of interaction you're describing.
Do you mean some kind of scenario like a shared document with multiple people editing it? This is a very niche case.
> This means when the DOM resets, there's no problem with elements getting removed and added back in,
Could you give a practical example of this? I've been building web apps for a long time and I don't know what "when the dom resets" means.
The problem described by antris is that, if a developer were to naively tear down and rebuild the entire DOM tree on each state change, the browser would discard some important state which belongs to the old DOM nodes. This state includes the text selection, keyboard focus, mouse capture, scroll position, and the progress of CSS transitions and animations.
React solves this problem by building a virtual DOM, and then conservatively updating the actual DOM (sometimes just mutating individual HTML attributes!) so that this state is preserved.
React solves this problem by building a virtual DOM, and then conservatively updating the actual DOM (sometimes just mutating individual HTML attributes!) so that this state is preserved.
React doesn't have this "pure function" feature what-so-ever. hooks are magic stateful functions, not pure functions. They behave differently the second time called and therefore have all kinds of side-effects and restrictions on when, where, and how they can be used.
Accumulative recursive functions also behave differently the second time they are called...
Hooks are a declarative DSL for accumulator arguments to the recursive function (the component).
If you would rather rewrite the render loop in continuation passing style, and have a 46 line recursive call expression which conditionally changes like 15 immutable parameters to set up the next render iteration for your component, I'd like to see the code when you are done.
Hooks are a declarative DSL for accumulator arguments to the recursive function (the component).
If you would rather rewrite the render loop in continuation passing style, and have a 46 line recursive call expression which conditionally changes like 15 immutable parameters to set up the next render iteration for your component, I'd like to see the code when you are done.
We've been doing the O(n) thing forever with PHP and CGI since 1995, the issue is that it required constant whole-page reloads and was a poor experience that got worse the more interactive your webapps got. React let you do the same thing but made it fast(ish) with local updates
We actually see similar innovations on the FP side as well, with persistent data structures that allow structural sharing so your "copy and update" operations can be fast enough to be usable (even if still not nearly as fast as in-place mutation)
We actually see similar innovations on the FP side as well, with persistent data structures that allow structural sharing so your "copy and update" operations can be fast enough to be usable (even if still not nearly as fast as in-place mutation)
React isn’t that special. You can do a react-like design in many frameworks, and in fact you can even do it with vanilla web components. The code ends up a bit more verbose and ugly, but it still has that o(n) core design. To give an idea, here’s a video I made where I port react’s tic tac toe example to vanilla web code.
https://youtu.be/bhvNvQA2oqA?si=bJYZYAU8uueb-6ST
And here’s a more advanced example that preserves input field focus and uses a context: https://github.com/jsebrech/vanilla-context-and-reducer
https://youtu.be/bhvNvQA2oqA?si=bJYZYAU8uueb-6ST
And here’s a more advanced example that preserves input field focus and uses a context: https://github.com/jsebrech/vanilla-context-and-reducer
I never want to go back to a non-declarative rendering framework.
Does anyone remember a blog post from maybe 2016-ish which described the process of "building your own" react-like rendering loop? I remember it being a fantastic explanation of what the virtual dom is and does, and why the "UI is a function of state" paradigm is great. I remember it having a live example to the right side, with prose and code on the left. I can't for the life of me find it now :(
Does anyone remember a blog post from maybe 2016-ish which described the process of "building your own" react-like rendering loop? I remember it being a fantastic explanation of what the virtual dom is and does, and why the "UI is a function of state" paradigm is great. I remember it having a live example to the right side, with prose and code on the left. I can't for the life of me find it now :(
To be fair it predates 2016 when the term “immediate mode ui” was “invented”. uis as a function of state were and still are the norm on game development. React introduced this concept on top of “retained mode ui” which is the dom. Never want to go back too despite people spreading so much hate which is not in the library itself I think but on the ecosystem. Maybe react become synonymous of too many companion libraries/bloated frameworks?
Sadly not. I did find this article too while searching for what I remember. It is a close match in so many ways, but also not quite.
I remember the article very much taking the approach that you've never heard of React before, and walking through a series of problems and discoveries like "oh, what if we just render the state to the DOM every frame? let's see how that works".
Almost like a "you could have invented React" kind of vibe. I think there was a button-counter demo app.
I remember the article very much taking the approach that you've never heard of React before, and walking through a series of problems and discoveries like "oh, what if we just render the state to the DOM every frame? let's see how that works".
Almost like a "you could have invented React" kind of vibe. I think there was a button-counter demo app.
Not a live preview and not a button-counter demo at the end, but the overall structure and the whole O(n) vs O(n^2) argumentation was in this blog post from a now defunct domain. Maybe this is what you were looking for:
https://web.archive.org/web/20150414080539/http://hackflow.c...
https://web.archive.org/web/20150414080539/http://hackflow.c...
This definitely looks different, and I don't recall seeing this before. But this is a great post! It communicates some of the very important ideas in a straightforward way. Thanks!
Are you maybe thinking of this classic post?
- https://archive.jlongster.com/Removing-User-Interface-Comple...
- https://archive.jlongster.com/Removing-User-Interface-Comple...
Another one that seems so close that it makes me think I imagined the one I'm looking for, and this is actually what I read. Thanks for trying - it's not causing me to say eureka! but it is close.
How are you getting to O(n)? Is that in terms of the logic you need to read and keep in your mind? Or is it the actual computational complexity?
Am curious on the O(n) calculation as well haha — I get what OP is saying, but would love to know if there's some deeper technical details here.
The basic idea is if you have n ways your page can display, with the old PHP/CGI whole page refresh model you needed to write n endpoints, but every interaction required a slow and disruptive whole page refresh
With pre-react single page apps, if you had O(n) ways your webpage could display, you needed to write code to account for n^2 ways that each of those n states could transition into another one of those n states
With react, you write code to render n pages, and get the fine grained interactivity for free with good (enough) performance. It basically removed a tradeoff/dilemma that had been facing web developers since time immemorial, so no surprise it was a big hit
With pre-react single page apps, if you had O(n) ways your webpage could display, you needed to write code to account for n^2 ways that each of those n states could transition into another one of those n states
With react, you write code to render n pages, and get the fine grained interactivity for free with good (enough) performance. It basically removed a tradeoff/dilemma that had been facing web developers since time immemorial, so no surprise it was a big hit
This. I still have nightmares sometimes.
If you don't use a framework you will probably end up building one, and it's not going to be as good as the existing options.
If you don't use a framework you will probably end up building one, and it's not going to be as good as the existing options.
I don't know if I'm convinced. I have several react projects stuck in dependency hell. If I upgrade from build in node 18+ (from 16) I start getting errors. If I try to upgrade react then 1 of the 3 external widgets I'm using barfs out. If I do manage to get upgrade I get complaints about all the best practices from react 16 that have been deprecated. If I'd written my own all of these issue would disappear because I wouldn't have made breaking changes to my own framework.
Note: you might say node 16 is old and I agree. I'd much rather be on 22. But since I can't get out of this dependency hell without days or weeks of work the projects have been stuck for years.
Note: you might say node 16 is old and I agree. I'd much rather be on 22. But since I can't get out of this dependency hell without days or weeks of work the projects have been stuck for years.
Then do it.. you are free to experience it. Especially if it’s just you on the team you might be totally fine.
I will just say that any project that lasts that long will require maintenance work now and then. The issues you describe seem quite minor and are probably relatively easy to patch up. React provides code mods that do a lot of the heavy lifting, your external widgets have updates, or alternatives.
I would also add that you don’t have to use dependencies with react. It’s always good to be mindful of dependencies and limit them.
It’s the same thing, you choose dependencies to save you time, or you do it yourself.
My main point is that with your own framework you will also run into limitations, causing big rewrites taking days/weeks/months, and/or lots of upfront cost..
I will just say that any project that lasts that long will require maintenance work now and then. The issues you describe seem quite minor and are probably relatively easy to patch up. React provides code mods that do a lot of the heavy lifting, your external widgets have updates, or alternatives.
I would also add that you don’t have to use dependencies with react. It’s always good to be mindful of dependencies and limit them.
It’s the same thing, you choose dependencies to save you time, or you do it yourself.
My main point is that with your own framework you will also run into limitations, causing big rewrites taking days/weeks/months, and/or lots of upfront cost..
You should check out htmx. It goes really well with ScalaTags :-)
ScalaRx and Scalatags actually works a lot like React.js, in user-facing experience even if not in implementation. Unfortunately I was just a college kid and couldn't push it the same way the pros at Facebook could push react!
I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
Amen. I adopted react for the first time in around 2014. It’s now “boring” and various predictable groups of people are desperate to replace it with /something/, while I’m getting on with my job of delivering software using a nice set of reasonably standardized tools, not having problems hiring, and just generally enjoying life.
Long may the reign of typescript, nodejs and react continue.
Long may the reign of typescript, nodejs and react continue.
My god.. A sensible take?
Maybe it’s time I learn it…
Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before I want to even look at it (I’m not a frontend person, it’s all academic to me.)
Is there a consensus on any of it yet? How to do routing, state, builds, etc? Or is there still as many combinations of components as there are tutorials?
Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before I want to even look at it (I’m not a frontend person, it’s all academic to me.)
Is there a consensus on any of it yet? How to do routing, state, builds, etc? Or is there still as many combinations of components as there are tutorials?
IME there is a general consensus:
Routing: react router (not very good imo but widely accepted and good enough)
state: No libraries. Just use “useState” and if necessary “useReducer”
Builds: vite
Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql
Routing: react router (not very good imo but widely accepted and good enough)
state: No libraries. Just use “useState” and if necessary “useReducer”
Builds: vite
Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql
> Routing: react router (not very good imo but widely accepted and good enough)
Unnecessarily complicated and confusing, with odd choices in the most recent version (that IIRC are not backwards compatible). I went with wouter after searching around.
> state: No libraries. Just use “useState” and if necessary “useReducer”
useState is the same thing as the old setState, and useReducer not much different - they're not sufficient for building an app because you just revert back to the original state antipattern, prop drilling.
Unnecessarily complicated and confusing, with odd choices in the most recent version (that IIRC are not backwards compatible). I went with wouter after searching around.
> state: No libraries. Just use “useState” and if necessary “useReducer”
useState is the same thing as the old setState, and useReducer not much different - they're not sufficient for building an app because you just revert back to the original state antipattern, prop drilling.
I don’t see how prop drilling is an anti pattern. Passing data around via props is a feature of the library, it’s totally fine if you need to pass a lot of props.
If you really have too many props or need to widely disperse the same prop you can refactor using higher order components or use a context. A separate state management library isn’t necessary unless you are building something with a ton of complex UI state like a photo editor or a music production workbench.
If you really have too many props or need to widely disperse the same prop you can refactor using higher order components or use a context. A separate state management library isn’t necessary unless you are building something with a ton of complex UI state like a photo editor or a music production workbench.
Prop drilling refers to depth, not width - you had to add the props to every intermediate component between where the state is stored and where it's used. Some of us tried to come up with nested usage patterns so at least the intermediate components didn't need to know about the structure and it wouldn't be a pain when moving things around, but it still wasn't very good.
> with odd choices in the most recent version (that IIRC are not backwards compatible)
This exact sentence could have been said about react router 8 years ago when I last looked at react, lol. And IIRC it was react router that turned me off the most, as every react tutorial that stressed working permalinks/URLs (which I believe to be essential) was teaching me react-router, but with sample code that was incompatible with the latest version. Because documentation and tutorials would last like a month tops before they were all horribly broken and out of date. Sounds like this hasn’t changed much.
This exact sentence could have been said about react router 8 years ago when I last looked at react, lol. And IIRC it was react router that turned me off the most, as every react tutorial that stressed working permalinks/URLs (which I believe to be essential) was teaching me react-router, but with sample code that was incompatible with the latest version. Because documentation and tutorials would last like a month tops before they were all horribly broken and out of date. Sounds like this hasn’t changed much.
I'd throw in the occasional context provider store. However, the point absolutely stands that most likely don't need a state library in React anymore unless you're learning it to maintain an older codebase.
The best way to learn a library is to learn it by itself without bringing in other things. I encourage you to learn React without any router, redux, or any alphabet soup indeed. Don't even need a build step, since JSX is optional.
You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.
I'm having trouble forgiving Vue for the backwards compatibility issues and short support period from Vue 2.x => Vue 3.x. I'm now faced with unnecessary cost to upgrade line of business apps built with Vue that in full maintenance mode but now have critical security vulnerabilities popping up in scanners with no way to fix them other than large scale code migration. I saw they are now dropping support for Vue 2 even in the DevTools, so even migration is going to be harder, if we can't easily introspect the pages we are migrating.
I'm suspecting they are going to drop backwards compatibility again in the near future by deprecating support for the options API - leaving me with another headache.
I'm suspecting they are going to drop backwards compatibility again in the near future by deprecating support for the options API - leaving me with another headache.
What I like about React is that generally speaking, it has rock solid backwards compatibility support (class components are still supported for example), presumably due to Meta using it at scale such that they cannot scrap everything immediately. Vue, being not used in any large company, does not have the same sense of responsibility to preserve backwards compatibility, it seems. This has its pros and cons though but for many people, backwards compatibility is a big deal.
That's actually fair and my one gripe with Vue, and I just spent the past week and a half porting over my old project that I wanted to resurrect. If they screw with my vue3 using composition API then I'll dust off my pitchfork.
Week and a half… sounds nice :,)
Has gitlab finished upgrading yet? Last time I checked they spent 2+ years and that’s with codemod tools and super smart engineers.
At work, I spent a month upgrading one project to work with the compatibility build and we’ve been slowly migrating for the past 18 months. After the end of this year, we should be out of the woods for that project but then we have 3 more so…
Luckily, Evan has said that he has zero interest in fracturing the community again and I believe him. The new architecture of Vue 3 also makes it very easy to adopt almost any new paradigm into Vue as evidenced by the numerous demos Evan has made to compare Vue to other JS frameworks like Svelte and Solid.
Has gitlab finished upgrading yet? Last time I checked they spent 2+ years and that’s with codemod tools and super smart engineers.
At work, I spent a month upgrading one project to work with the compatibility build and we’ve been slowly migrating for the past 18 months. After the end of this year, we should be out of the woods for that project but then we have 3 more so…
Luckily, Evan has said that he has zero interest in fracturing the community again and I believe him. The new architecture of Vue 3 also makes it very easy to adopt almost any new paradigm into Vue as evidenced by the numerous demos Evan has made to compare Vue to other JS frameworks like Svelte and Solid.
Have you tried Vue Compat?
But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem?
And perhaps most important of all: it's the tool we know.
And perhaps most important of all: it's the tool we know.
I only responded because they said they're using vanilla React which for some reason in my head instantly translated to "old version of React before it started sucking", and replied accordingly.
>But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem?
Yeah fair enough.
>But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem?
Yeah fair enough.
By vanilla React I meant that I don't use the new Next.js / SSR stuff and instead build a JS file.
what do you use for routing? I built Routerino for just exactly this purpose, to use with vanilla React. maybe it'll be useful for you!
https://www.npmjs.com/package/routerino
https://www.npmjs.com/package/routerino
I actually use the history API. I've been thinking about modernizing by replacing it with React Router. I'll check out Routerino also.
React router is a nightmare.
Lots of massive paradigm shifts with little backwards compatibility.
I’ve gone through like 3-5 times where there is some massive changes between versions.
Right now they are pushing some new routing mechanisms…
Lots of massive paradigm shifts with little backwards compatibility.
I’ve gone through like 3-5 times where there is some massive changes between versions.
Right now they are pushing some new routing mechanisms…
Yeah I only realized that later :P
Because it’s not and people hate these sites…I’m sorry…”apps” you make.
Right, and people would obviously love those same apps if they were written with Vue instead. Of course.
I think that user prefers just HTML.
They’ll love something that loads fast and feels fast even if they’re on a cellular connection at the gas station. Such as me trying to load a gas station app to pay at the pump in a rural area and waiting forever for each step due to the size.
Aren't you brave, presumptuously insulting random people on the internet like that behind a fake name?
I'd say some SWEs hate the sites. The majority of laypeople don't care at all.
I started with Vue and switched to React, because of better library and TypeScript support. Every other framework pales in comparison to React due to its ecosystem, and I'm not gonna spend time building new packages to bridge that gap when I have my own work I need to get done, so I'll just use React and npm install what I need.
What gap needed bridging for you?
Back when I switched, I was looking for a good drag and drop library as well as a node based diagramming library. React Flow for the latter is best in class, and it's simply unavailable for other frameworks.
I think i'm passed splitting html, js and css into separate files.
Having logic, presentation and styling all in one spot addressable via js and jsx feels so much more ergonomic for apps of reasonable complexity.
I will say though that solidjs seems like an improvement on react though.
I will say though that solidjs seems like an improvement on react though.
To me, the best part of react/jsx is that if you know HTML, and you know JavaScript, you can easily write JSX. I'm primarily a backend engineer, but I grokked JSX pretty much instantly. Anything in scope in JS is available in the JSX.
Vue templates are, well, yet another funny little template language. The hello world example already seems way too magical. Just let me use the language I already know.
Vue templates are, well, yet another funny little template language. The hello world example already seems way too magical. Just let me use the language I already know.
Fun fact, you can use JSX with Vue and get the benefit of its built-in reactivity framework. I've done this for small prototypes and it's quite nice. My favourite part was that without .vue files, I could compile the whole app using esbuild instead of fiddling with webpack (yes yes I will try Vite one day).
Java is still getting great support and great new features every release while maintaining backward compat
Java is way way better than React (hooks) in this regard. Boring tech is good, but React is the opposite of boring tech, it innovates new way to write software, but ends up in disaster.
[deleted]
Have you heard of HTML, CSS and forms? They are even more boring, more mature, more stable, often faster, have a huge community, massive resources and ecosystem. React is even built on one of these technologies!
Which one of these technologies is React built on top of?
HTML, specifically react-dom. It’s built with JavaScript
Back in 2013 there was a nifty little library that everyone, absolutely everyone ended up using called https://vanilla-js.com. They even had a size calculator depending on the features, amounting to zero bytes every time (25 bytes gzipped).
> React developers are web developers.
This has felt increasingly untrue recently. I hope I'm just experiencing the peak of the bell curve but I've been bumping into more and more devs who only have experience in SPA React and associated styling frameworks. Ask them to actually style something and they flake out.
I was used to some tribalism in backends (everyone thinks theirs in the best and equally hates PHP devs and Wordpress) but can all publish a static page if asked.
It's a self fulfilling issue. Mid-managers want React because Facebook and pre-juniors train to meet job postings. Not enough question it.
This has felt increasingly untrue recently. I hope I'm just experiencing the peak of the bell curve but I've been bumping into more and more devs who only have experience in SPA React and associated styling frameworks. Ask them to actually style something and they flake out.
I was used to some tribalism in backends (everyone thinks theirs in the best and equally hates PHP devs and Wordpress) but can all publish a static page if asked.
It's a self fulfilling issue. Mid-managers want React because Facebook and pre-juniors train to meet job postings. Not enough question it.
It's not recent. We've had memes for years about React devs using divs with click events instead of using links.
No, but five, ten years ago that wasn't the average "junior web dev" outlook. There was diversity in experience and education.
Big money FAANG posts have really distilled the market down.
Maybe I'm just an oldfart. When I started a quarter of a century ago, people were crowing about Frontpage experience. I'm fairly sure I'd boasted about Macromedia Dreamweaver 3 expertise. And there was an explosion of technologies being thrown around between different devs. But now you don't get to discriminate against bad technology if the market demands it.
Big money FAANG posts have really distilled the market down.
Maybe I'm just an oldfart. When I started a quarter of a century ago, people were crowing about Frontpage experience. I'm fairly sure I'd boasted about Macromedia Dreamweaver 3 expertise. And there was an explosion of technologies being thrown around between different devs. But now you don't get to discriminate against bad technology if the market demands it.
What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically?
It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind.
Or maybe I'm hooked into a router and I need to pass some additional state, or control a transition direction, or maybe I want a navigation to happen after some async action completes, etc...
Also, not all clicks are navigation actions.
BTW, I'm not a react guy, just vanilla web components here, but genuinely curious why you see clickable divs as a bad thing?
It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind.
Or maybe I'm hooked into a router and I need to pass some additional state, or control a transition direction, or maybe I want a navigation to happen after some async action completes, etc...
Also, not all clicks are navigation actions.
BTW, I'm not a react guy, just vanilla web components here, but genuinely curious why you see clickable divs as a bad thing?
* Accessibility tools may not be able to detect that it's an interactive element unless you go out of your way to mark it up as such
* It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked
* We already have a tag for a clickable element that is not a link: <button>
* It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked
* We already have a tag for a clickable element that is not a link: <button>
Good points, but I think you and the others who responded to my question are thinking about "web pages" vs what I generally create, which are responsive mobile PWAs for internal line of business apps.
> Accessibility tools
Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.
> It often ... breaks middle-clicking
Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.
> We already have a tag for a clickable element that is not a link: <button>
Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.
I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.
All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.
> Accessibility tools
Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.
> It often ... breaks middle-clicking
Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.
> We already have a tag for a clickable element that is not a link: <button>
Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.
I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.
All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.
Do you religiously check that you haven't broken ctl-click, middle click or "right click/open in new tab"? I come across a site - sorry I meant "app" - almost every day that breaks this.
Just use <a> and you don't have to.
Just use <a> and you don't have to.
> Non deep-linked sub-nav (tabs, etc...)
Smells like a mistake. Or a button.
> Also, not all clicks are navigation actions.
There are other interactive elements like buttons.
href="?tab=tabName"
href="?state=stateId"
href={condition ? "/direction/a" : "/direction/b"}
Smells like a mistake. Or a button.
> Also, not all clicks are navigation actions.
There are other interactive elements like buttons.
There's nothing wrong with clickable divs. The problem is using them in place of links.
If you're linking to something, then just use a link. So people get their accessibility/screenreader support, and you can still use JS to accomplish whatever other auxillary behavior you want.
If you're linking to something, then just use a link. So people get their accessibility/screenreader support, and you can still use JS to accomplish whatever other auxillary behavior you want.
Having seen some large react codebases I’d agree wholeheartedly with this article.
React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have.
It means downloading MBs of javascript just to render a simple page.
It encourages multiple loads of massive json payloads for bits of the page which are then translated into html; this is a huge complexity and network tax for no gain.
It encourages constant re-rendering of page components.
It encourages mixing code and layout, making it incredibly easy for junior developers to make a terrible mess.
It encourages splitting web pages into thousands of components with poorly defined boundaries and putting lots of logic on the front end - this is disastrous for productivity and clarity when the project is of any size.
It has a bunch of legacy bits (double rendering, useEffect, useMemo, shadow dom etc) which just aren’t required and are often solutions to problems react itself created.
As to a prescription for what to use instead of react - anything else which is not ‘modern javascript’ would be a good place to start. Start with server side rendering and stateless web pages, add interactivity and dynamic loading as required.
React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have.
It means downloading MBs of javascript just to render a simple page.
It encourages multiple loads of massive json payloads for bits of the page which are then translated into html; this is a huge complexity and network tax for no gain.
It encourages constant re-rendering of page components.
It encourages mixing code and layout, making it incredibly easy for junior developers to make a terrible mess.
It encourages splitting web pages into thousands of components with poorly defined boundaries and putting lots of logic on the front end - this is disastrous for productivity and clarity when the project is of any size.
It has a bunch of legacy bits (double rendering, useEffect, useMemo, shadow dom etc) which just aren’t required and are often solutions to problems react itself created.
As to a prescription for what to use instead of react - anything else which is not ‘modern javascript’ would be a good place to start. Start with server side rendering and stateless web pages, add interactivity and dynamic loading as required.
React was never intended to solve browser inconsistencies. Of course it developed hand-in-hand with the tools that solved those (transpilers, polyfills, bundlers), but that was not the main reason it was invented or became popular.
The original motivation was to describe UI as a function of state. It sounds trivial, because it is when server rendering, but once you start sprinkling enough interactivity it can get messy. It's of course not the solution to everything, but above a certain level of complexity I really think you should let someone else handle the problem of syncing state with UI, and JS on its own will never do that for you.
The original motivation was to describe UI as a function of state. It sounds trivial, because it is when server rendering, but once you start sprinkling enough interactivity it can get messy. It's of course not the solution to everything, but above a certain level of complexity I really think you should let someone else handle the problem of syncing state with UI, and JS on its own will never do that for you.
Yes that’s a good point sorry I just gave one e.g. from the article of IE event handling.
Re the original purpose of react being syncing state, I’m really not sure this small problem is actually worth the trade-offs of massive complexity and lock-in, nor that react is a good solution for it (double renders, persistent rendering bugs, use state, hooks etc).
It’s not something important to lots of apps and there are loads of other options from simple polling to web sockets to reloads, this can be done in a far simpler way without react. Also the use cases where this is central are really quite small.
Re the original purpose of react being syncing state, I’m really not sure this small problem is actually worth the trade-offs of massive complexity and lock-in, nor that react is a good solution for it (double renders, persistent rendering bugs, use state, hooks etc).
It’s not something important to lots of apps and there are loads of other options from simple polling to web sockets to reloads, this can be done in a far simpler way without react. Also the use cases where this is central are really quite small.
> It means downloading MBs of javascript just to render a simple page.
React + react-dom minified gzipped is around 60kB. Yes, this is a lot; but no, this is not MBs of javascript. If your (simple) pages download MBs of javascript, that means you have added lots of other stuff on top of react.
While I completely agree that react is unnecessary for simple sites, react itself is not guilty of megabyte-size javascript bundles.
React + react-dom minified gzipped is around 60kB. Yes, this is a lot; but no, this is not MBs of javascript. If your (simple) pages download MBs of javascript, that means you have added lots of other stuff on top of react.
While I completely agree that react is unnecessary for simple sites, react itself is not guilty of megabyte-size javascript bundles.
You’re writing your entire website in react then downloading it to the client every time. This means the weight is react plus hundreds or thousands of dependencies (which this is ecosystem seems to actively encourage) plus all your app logic. MBs is not uncommon for larger websites.
Wasn’t expressing UIs declaratively the original purpose of react? “The V in the MVC”. IMO it helped advancing the industry with declarative uis and Jsx
I never liked React. I'm primarily a backend developer, and preferred server generated HTML with a sprinkling of Javascript. It may sound ridiculous to some, but I miss the JQuery days. For newer projects I'm looking at Elixir / Phoenix / LiveView and HTMX.
Look at Imba. If you are strong enough to avoid cargo culting and try things which aren't popular, they are some of the best ways to build frontend apps out there: https://imba.io/
Thanks. It looks interesting and I will check it out.
No need to miss jquery days. If you want jquery you can use it now. I know at least some companies use it even for greenfield projects.
Hasn't JS caught up with jQuery mostly?
* x-platform (that was a big thing in jQuery in the beginning): solved in JS
* DOM selection (not as elegant w/o some aliassing, but still): solved in JS
* making XHR: solved in JS
* building plugins: solved in JS
* method().chaining().style().of().programming(): not in JS
That's mostly I think.
* x-platform (that was a big thing in jQuery in the beginning): solved in JS
* DOM selection (not as elegant w/o some aliassing, but still): solved in JS
* making XHR: solved in JS
* building plugins: solved in JS
* method().chaining().style().of().programming(): not in JS
That's mostly I think.
I'm fine with using it for personal projects. For anything with a larger team, they'd probably look at me like I was crazy if I suggest anything that didn't involve React, at least in these parts.
> The choice isn’t between JavaScript frameworks, it’s whether SPA-oriented tools should be entertained at all. For most sites, the answer is a clearly “no”.
“Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA.
Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by the various Product teams.
These products benefit from being an SPA. Preload and fetch is such an incredible paradigm for speed and interactivity that every company I’ve worked for has appreciated. Company employees are not trying to run their work browsers without JS nor do they even have to particularly worry about mobile support. It’s a very predictable environment: office, work laptop, internet that can support video calls, and a modern browser. That’s the operational stack that many businesses require.
> The predictable consequence are NPM-algamated bundles full of redundancies like core-js, lodash, underscore, polyfills for browsers that no longer exist, userland ECC libraries, moment.js, and a hundred other horrors.
People really love to hate on npm without trying to understand the reason why it exists in its current form: https://bower.sh/my-love-letter-to-front-end-web-development
As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. Next.js is a react framework and as a React expert it’s something I have zero interest in using.
I could keep going but these arguments have been argued and counter-argued before. For a different spin on the success of react: https://bower.sh/react-is-bad-because-its-great
“Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA.
Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by the various Product teams.
These products benefit from being an SPA. Preload and fetch is such an incredible paradigm for speed and interactivity that every company I’ve worked for has appreciated. Company employees are not trying to run their work browsers without JS nor do they even have to particularly worry about mobile support. It’s a very predictable environment: office, work laptop, internet that can support video calls, and a modern browser. That’s the operational stack that many businesses require.
> The predictable consequence are NPM-algamated bundles full of redundancies like core-js, lodash, underscore, polyfills for browsers that no longer exist, userland ECC libraries, moment.js, and a hundred other horrors.
People really love to hate on npm without trying to understand the reason why it exists in its current form: https://bower.sh/my-love-letter-to-front-end-web-development
As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want. Next.js is a react framework and as a React expert it’s something I have zero interest in using.
I could keep going but these arguments have been argued and counter-argued before. For a different spin on the success of react: https://bower.sh/react-is-bad-because-its-great
> As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want.
React isn't a library, it's a framework. A narrowly focused framework perhaps, but a framework nonetheless: it has to control the event loop and you have to follow its special rules (hooks), you can't just call into it like vanilla code.
React isn't a library, it's a framework. A narrowly focused framework perhaps, but a framework nonetheless: it has to control the event loop and you have to follow its special rules (hooks), you can't just call into it like vanilla code.
I agree with most of what you said. As a minor nit, my understanding is that you call into a library, whereas a framework calls into you. Since React typically does most of the calling into my components I think it’s fair enough to call it a framework.
That’s a nice description but it is not perfect. React does one thing well: view = func(state)
It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.
It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.
But most people don't use it for the only thing it does well and pick appropriate approaches for the other parts; they use it for everything and this has transpired into the reinventing of browser mechanisms like CSS in user land. This is the real problem. Not the tool "React" (or others like it) but the cult that vehemently denies their bets were wrong and doesn't take responsibility for the real damage it's caused.
It seems you only want to call MVC frameworks frameworks? But there's millions of other types of frameworks for thousands of purposes. Framework is a generic term (for which the definition is usually the calls into you/you call into it thing). What it does and whether it's a framework is two completely orthogonal things.
> It seems you only want to call MVC frameworks frameworks?
No, I'm illustrating the limited scope of React. I wouldn't call a chunk of code that handles the V in MVC a framework.
> for which the definition is usually the calls into you/you call into it thing
Again there's nuance here:
All react does is render/diff/patch your dom, everything else is up to the end-developer. Would you call `express` a framework? Again this is semantics but look at all the react frameworks that exist on top of react, why do those exist?
No, I'm illustrating the limited scope of React. I wouldn't call a chunk of code that handles the V in MVC a framework.
> for which the definition is usually the calls into you/you call into it thing
Again there's nuance here:
import { useEffect, useState } from "react";
import { createRoot } from 'react-dom/client';
document.body.innerHTML = '<div id="app"></div>';
const root = createRoot(document.getElementById('app'));
root.render(<App />);
function App() {
const counter = useState(0);
useEffect(() => { console.log('effect') }, []);
return <h1>hello world: {counter}</h1>
}
All react does is render/diff/patch your dom, everything else is up to the end-developer. Would you call `express` a framework? Again this is semantics but look at all the react frameworks that exist on top of react, why do those exist?
> I'm "calling into" react (3) times here, while react is calling "into me" (1) time.
It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.
> Are we saying any external source code that accepts a function as a parameter is considered a framework?
Code that accepts a function for narrowly scoped use where the control flow is still under your control (e.g. map/reduce/filter libraries) is probably not a framework. But external code where you register a callback that gets called some time later, not under your control, is pretty much the definition of a framework.
It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.
> Are we saying any external source code that accepts a function as a parameter is considered a framework?
Code that accepts a function for narrowly scoped use where the control flow is still under your control (e.g. map/reduce/filter libraries) is probably not a framework. But external code where you register a callback that gets called some time later, not under your control, is pretty much the definition of a framework.
> It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point.
If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").
If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").
> If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").
As I understand it both the useState and useEffect create points where their code will be suspended and resumed as a coroutine, even if everything only gets run once? But yeah, the more important point is that in the general case React will run it multiple times in ways that are not really under the user's control (at least not without understanding the internal details of React quite deeply).
As I understand it both the useState and useEffect create points where their code will be suspended and resumed as a coroutine, even if everything only gets run once? But yeah, the more important point is that in the general case React will run it multiple times in ways that are not really under the user's control (at least not without understanding the internal details of React quite deeply).
Nope:
The first run through, useState() returns the default value and your code runs to completion. When the update function is called, that entire React function is run again, but this time useState() returns the new value instead of the default value.
Likewise useEffect(), your React function runs all the way through and the callback passed to it is run afterwards at various times depending on the dependencies array. First run is immediately after, on component mount, then every time the dependencies change (if dependencies are specified), or every rerender (if null/undefined instead of an empty array).
The first run through, useState() returns the default value and your code runs to completion. When the update function is called, that entire React function is run again, but this time useState() returns the new value instead of the default value.
Likewise useEffect(), your React function runs all the way through and the callback passed to it is run afterwards at various times depending on the dependencies array. First run is immediately after, on component mount, then every time the dependencies change (if dependencies are specified), or every rerender (if null/undefined instead of an empty array).
> The first run through, useState() returns the default value and your code runs to completion.
Your function was still sliced into the part before and the continuation (Dispatch) after though, right? The React runtime calls that continuation immediately with the default value, so you don't notice the suspension, but control flow wise it's still React calling your code twice rather than once.
Your function was still sliced into the part before and the continuation (Dispatch) after though, right? The React runtime calls that continuation immediately with the default value, so you don't notice the suspension, but control flow wise it's still React calling your code twice rather than once.
Nope, it's a normal function that updates some variables in the React module then returns two values. There's a little bit of magic going on, with how it knows which component it's in, but that's happening outside of the individual hooks.
I didn't say it does? I am just spliting hairs over the definition of framework.
I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward:
• A large portion of the cost of maintaining a code repository goes toward maintaining the build.
• Multiple builds per repo create significant costs.
• Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused.
• If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build.
• SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.
• A large portion of the cost of maintaining a code repository goes toward maintaining the build.
• Multiple builds per repo create significant costs.
• Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused.
• If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build.
• SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.
I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case.
The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively reduces the complexity and cost of creating and maintaining a build.
Most of us aren't working on anything that requires the entirety of every page and the entire navigation model to be implemented on the client.
The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively reduces the complexity and cost of creating and maintaining a build.
Most of us aren't working on anything that requires the entirety of every page and the entire navigation model to be implemented on the client.
So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with.
What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.
What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.
Another thing is that almost every complaint I see about React (except bundle size maybe, but who cares?) exists in the APP context.
If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS.
As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS.
As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
> is just a nice templating lib
Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client?
> experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS
I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?
Are these templates only used on the server-side to generate the HTML upfront? Or is it being generated on the client?
> experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS
I don't believe this can quantified. How are you measuring DX improvements? Are you also able to continue to measure these improvements as your application/codebase scales?
It's certainly possible to generate the HTML up-front. Tooling like Next.js even sets things up so it's easier to render the HTML for the first page load on the server than to push it to the client.
I have a website. It's not great, it doesn't get much traffic, but it's mine :). If you disable JS, it works: links are links, HTML is loaded for each page view. If you enable JS, it still works: links will trigger a re-render, the address bar updates, all the nice "website" stuff.
If I write enough (and people read enough) then enabling JS also brings performance benefits: yes, you have to load ~100kB of JS. But each page load is 4kB smaller because it doesn't contain any boilerplate.
Obviously I could generate the HTML any way I choose, but doing it in React is nice and composable.
I have a website. It's not great, it doesn't get much traffic, but it's mine :). If you disable JS, it works: links are links, HTML is loaded for each page view. If you enable JS, it still works: links will trigger a re-render, the address bar updates, all the nice "website" stuff.
If I write enough (and people read enough) then enabling JS also brings performance benefits: yes, you have to load ~100kB of JS. But each page load is 4kB smaller because it doesn't contain any boilerplate.
Obviously I could generate the HTML any way I choose, but doing it in React is nice and composable.
If you really want to, you can have a react app that is just static templates with no interactivity with a simple Node server that just called renderToString and all of a sudden react is just a backend templating framework. If you want to get really fancy you can then re-render specific components on the client side without re-rendering the entire page. You don't need NextJS to do this either, its very simple and straightforward and lets you use an entirely frontend toolchain to do everything.
Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization of static assets etc. The fact is the "islands of interactivity" model still requires two builds.
> Building a web application with a UI in a professional context without a frontend build is borderline malpractice.
I sincerely disagree. I am not about to add node to a project that gets by fine with Django + HTMX.
I'm tempted to say that adding hundreds of perishable npm packages to a project is a better heuristic for 'malpractice'.
I sincerely disagree. I am not about to add node to a project that gets by fine with Django + HTMX.
I'm tempted to say that adding hundreds of perishable npm packages to a project is a better heuristic for 'malpractice'.
Very funny that you think a build with an entire CMS involved is somehow "simpler". You apparently have a lot of patience for Django's static asset management pipeline, but I do not.
> I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler
Modern CSS is amazing. Why on earth would anyone use SCSS? It pays to look at what Vanilla can do these days.
> Even a "thin" layer of JS on top requires some degree of dependency management
Use modules and import away. If it is truly a thing layer, there's no need for further optimisation until far along in the product.
Modern CSS is amazing. Why on earth would anyone use SCSS? It pays to look at what Vanilla can do these days.
> Even a "thin" layer of JS on top requires some degree of dependency management
Use modules and import away. If it is truly a thing layer, there's no need for further optimisation until far along in the product.
Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them. But most importantly, many of dependencies one might want to use also make use of SCSS/SASS downstream. If you're happy to build everything from scratch and eschew any dependencies that require a build system, then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component in some frontend library somewhere.
> Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them
You say it like more those features are desirable.
> then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component
Sure. I wasted more time getting an assortment of pre-built components to behave than I did building the basics from scratch. And then comes a breaking change. And then that component library uses styled components and doesn't run properly on the server. Why do people do this to themselves?
You say it like more those features are desirable.
> then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component
Sure. I wasted more time getting an assortment of pre-built components to behave than I did building the basics from scratch. And then comes a breaking change. And then that component library uses styled components and doesn't run properly on the server. Why do people do this to themselves?
> Building a web application with a UI in a professional context without a frontend build is borderline malpractice.
Why do you think that? What problem is a build tool solving for you that without it you think you're being irresponsible for not doing it by hand?
Why do you think that? What problem is a build tool solving for you that without it you think you're being irresponsible for not doing it by hand?
Nowhere in my comment did I say abandon a build step?
I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them.
I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long before I ever worked on an SPA, it’s hardly a good reason to move your entire UI and routing to the client-side.
I’m saying—if you do not have high interactivity requirements, which I would claim is most things on the web—you will encounter a lot less overall complexity shipping mostly server-rendered pages with isolated, self contained JS bundles where you need them.
I was using multi-entrypoint build steps outputting separate per-page or per-feature CSS and JS bundles long before I ever worked on an SPA, it’s hardly a good reason to move your entire UI and routing to the client-side.
What's rendering the pages on the server? Because if its not javascript, and you still have a frontend build, you have a repository with two separate builds, and builds are expensive to maintain. If your containerizing, you need two different containers, each with a dependency management system, a runtime, probably a separate workflow for development and production.
There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.
There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.
Do you know, that some of the most used features of SASS/SCSS are now in vanilla CSS?
> Building a web application with a UI in a professional context without a frontend build is borderline malpractice.
This is outdated nonsense for most sites.
This is outdated nonsense for most sites.
What does "most sites" even mean? I do this professionally, and I assume that most of the people replying here do as well. The article we're discussing is written by a professional for an audience of professionals. The number of sites I've had to build that were entirely static with no interactivity I can count on one hand.
You don't need a heavy frontend build for interactivity. All you really need nowadays is asset fingerprinting.
> Any web application with a UI _requires_ a frontend build for CSS/JS.
Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step.
- http/2 makes bundling a questionable choice
- polyfills are pretty much no longer a thing
- CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.)
- es6 modules work
This has been a big talking point in the Rails community lately — one of the big selling points of Rails 8 was the fact that you can, by default, ship a whole webapp without a build step, and that this is considered the "happy path".
Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step.
- http/2 makes bundling a questionable choice
- polyfills are pretty much no longer a thing
- CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.)
- es6 modules work
This has been a big talking point in the Rails community lately — one of the big selling points of Rails 8 was the fact that you can, by default, ship a whole webapp without a build step, and that this is considered the "happy path".
In web application terms, the "build" is everything that needs to happen to get your application running into production. That means a runtime and dependencies. Speaking of dependencies, does your perfect frontend simply not have any of them? Is every tool you will need to use perfectly packaged with vanilla CSS and ES6 modules? Browser support for import maps is around, but its nothing I would build a production application on. And god help if you if you work in a context that requires support for older browsers.
Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.
Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.
I mean, people ARE doing it, and like I said it's mature enough to be the default way to build Rails apps. There's tradeoffs, no doubt, but this is absolutely a valid, productive way to write (certain types of) web apps.
[deleted]
I write web apps with UI using ES6 native modules and https://stimulus.hotwired.dev. It's very simple, and life is good. No-build is the way.
WOW this is a long article! Still waiting for the substance though...
The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient.
Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.
The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient.
Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.
Cannot agree more! Mastering React is ridiculously hard for what it is. There are so many “buts,” “it depends,” and subtle differences to navigate, like useEffect vs. useLayoutEffect. But don't forget useEffect is an evil in the first place and so on, and so on.
It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it. They’re even building their own compiler. A compiler. For something that’s supposed to represent the V in MVC.
As a SPA framework, it’s questionable. But using React to build server-side apps? That’s beyond absurd for me, it’s like Electron for the backend, only worse. And yet, the industry loves to pretend otherwise, so here we are.
It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it. They’re even building their own compiler. A compiler. For something that’s supposed to represent the V in MVC.
As a SPA framework, it’s questionable. But using React to build server-side apps? That’s beyond absurd for me, it’s like Electron for the backend, only worse. And yet, the industry loves to pretend otherwise, so here we are.
React is a guided missile foot gun. You can figure out how to have it hit something else, but even when you aren’t pointing it at your foot, it’s probably going to hit your foot. You can have that feeling of wonder as the rocket sails off into the distance, and then just as you get customers, it comes back over the horizon and hits your foot. Experienced physicists and rocket scientists can override the guidance mechanism and have a much better chance of not hitting a foot, but who has time for that. Most people just like that it has a big red button labeled “Shoot” that’s easy to press.
You shouldn't write a single useEffect in the first year or two of your career in React.
Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs?
Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your first year of full-time job.
Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs?
Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your first year of full-time job.
That’s true. Just to note, I never claimed otherwise. See, useEffect is an evil remark. This is more based on my experience working with an average React codebase.
As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?”
I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encouraged as a catch-all solution. There’s still a lot of inertia from the old componentDidThis/componentDidThat paradigm, with useEffect being its direct replacement.
I feel it is only a recent tendency to finally abandon the overuse of effect hooks.
Just open an average Stack Overflow React question, and you’ll see how many useEffects are crammed in there.
As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?”
I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encouraged as a catch-all solution. There’s still a lot of inertia from the old componentDidThis/componentDidThat paradigm, with useEffect being its direct replacement.
I feel it is only a recent tendency to finally abandon the overuse of effect hooks.
Just open an average Stack Overflow React question, and you’ll see how many useEffects are crammed in there.
How do you fetch and persist server side data without useEffect? (Assuming vanilla react)
That’s probably the main real-world use case for useEffect. Dedicated third-party libraries like React Query obviously use useEffect under the hood as well
Yeah that's what I thought -- all the React codebases that I've worked in are riddled with `useEffect` for this reason primarily.
I'm jealous, then. I've seen all kinds of deranged Rube Goldberg machines built using useEffect
[deleted]
> Sorry to be the bearer of bad news, but the JS-free web isn't coming back.
It has never went anywhere? All it takes is a user brave enough to disable it or to use a web browser that doesn't use it or has issues with it. But for some reason many web devs actively ignore that.
It has never went anywhere? All it takes is a user brave enough to disable it or to use a web browser that doesn't use it or has issues with it. But for some reason many web devs actively ignore that.
> though once you master it, it can be pretty efficient.
Would it be fair to say in which case that React shouldn't be a tool teams reach for unless they have people who have mastery of it or can pay for it?
> user won't be able to tell the difference.
I think the user can:
https://infrequently.org/2024/08/object-lesson/
Would it be fair to say in which case that React shouldn't be a tool teams reach for unless they have people who have mastery of it or can pay for it?
> user won't be able to tell the difference.
I think the user can:
https://infrequently.org/2024/08/object-lesson/
React is really easy to learn. Stupidly easy.
It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was.
The core of React though is really simple and no amount of attempts at complexification can destroy that.
It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was.
The core of React though is really simple and no amount of attempts at complexification can destroy that.
Hello world might be simple, but you don’t have to build very much before you start to run into problems with the simple “props down, events up” and you start needing to learn about contexts, hooks in general and so on.
Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limitations of JavaScript, but it is essentially a kludge.
Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limitations of JavaScript, but it is essentially a kludge.
As someone who developed in Adobe Flex back in the day I find React so straightforward that as long as you keep an iota of discipline then even events, contexts and hooks feel "easy" compared to every other attempt at large Rich Internet Application approaches I've seen.
Just like in Flex the difficulty (and don't get en wrong often extreme awful difficulty) comes when someone fights against the system and can cause a cascade of terribleness. There were always telltale red flags when looking at Flex code when someone tried to circumvent the component lifecycle and the same smell can be spotted in React code.
Just like in Flex the difficulty (and don't get en wrong often extreme awful difficulty) comes when someone fights against the system and can cause a cascade of terribleness. There were always telltale red flags when looking at Flex code when someone tried to circumvent the component lifecycle and the same smell can be spotted in React code.
What do you find hard to learn about react? I think a lot of tutorials are really bad, might be the problem.
Not GP. Started using React at work around 2017. The hooks API is just awful. Those complaints are extremely well-trodden ground at this point so I won't rehash. I'm using Lit.js for personal stuff instead these days. Shadow DOM isn't perfect but web components with Lit has been pretty low-surprise so far, which I can't say for Hooks React.
> The hooks API is just awful
Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.
Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.
This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.
>you get weird stateful functions
This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.
This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.
Again, you can still use class components today, feel free and have fun.
The question in this thread is "What do you find hard to learn about react". The question is not "are you allowed to not learn about react".
Unsure what your point is. I know that; the codebase I work on professionally has both. This thread is discussing the quality of the hooks API.
How do you write a singleton service that can feed state back into the component that calls it when that state changes?
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
In class components you just could await the result and perform a set state, and that would be it. Easy as pie.
But now in function components when everything is called all the time without your control you have to use escape hatches like use effect just to work around react.
Hooks let you wrap all sorts of logic (and other hooks) and return values that rerender the callsite component when changed. Just keep adding on to my hook example and you get more and more code that you need to repeat in every class component that uses it.
Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.
Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.
It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.
Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.
Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.
It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.
You can just use a service instead, expose public methods and hide private while keep expending and refactoring the internal logic. The same way it’s been done for decades. The only problem is the one that react created for itself in function components which is when to refresh the render from the state.
1. Nobody said that classes are bad. Yes you can encapsulate logic and state in a singleton, that's not the issue, the issue is how you then "apply" it. There was a fantastic diagram that (most likely) Dan Abramov posted on Twitter a while ago (before it became the olympic pool of diarrhea that it is today) that was demonstrating the superiority of hooks in a beautiful and obvious way but I cannot find it anymore... :/
2. Sorry but if you keep using "weird", "hard" and "complicated" adjectives to define something that is quite honestly not so hard to grasp you make it hard to not go with "skill issues".
2. Sorry but if you keep using "weird", "hard" and "complicated" adjectives to define something that is quite honestly not so hard to grasp you make it hard to not go with "skill issues".
Nobody is saying that officially, but for the past 7-8 years the react documentation pretty much ignore class components. Today you have no way of knowing how to create a large class based react application because the ecosystem has moved on, it’s not the best practice.
I’m using weird and hard in a relative and not absolute way. Weird because functions can’t have state, and for years we’ve been taught to keep functions small and predictable. Hard because there are much simpler ways to write stateful code other than hooks. The problem with react is that instead of creating a powerful state library, powerful ui library, and creating a bridge between them, they chose to subjugate the state library to the UI library’s limitations.
I’m using weird and hard in a relative and not absolute way. Weird because functions can’t have state, and for years we’ve been taught to keep functions small and predictable. Hard because there are much simpler ways to write stateful code other than hooks. The problem with react is that instead of creating a powerful state library, powerful ui library, and creating a bridge between them, they chose to subjugate the state library to the UI library’s limitations.
Not parent, but I'll answer anyway: React was much much easier to learn back when Class Components were the thing. Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.
> Nowadays there is layers upon layers of magic like Functional Components with State from Hooks.
1. you can still write class based components if you want, but if you are in a team everyone will hate you for that because... 2. the preferred and vastly more flexible and powerful way is functional components. That's it, there isn't any other way or any other mystical layer of magic.
What everybody in this umpteenth omfg-react-is-satan thread is that implementing complex things with simple things is a fucking pipe dream. Fucking deal with it.
1. you can still write class based components if you want, but if you are in a team everyone will hate you for that because... 2. the preferred and vastly more flexible and powerful way is functional components. That's it, there isn't any other way or any other mystical layer of magic.
What everybody in this umpteenth omfg-react-is-satan thread is that implementing complex things with simple things is a fucking pipe dream. Fucking deal with it.
I didn't talk about any pipe dream, I named a very specific way of how those things were done before - in React! - and how it used to be simple and now it's not.
"Fucking deal with it?" What are you, a cultist? I answered a question here, fuck off.
"Fucking deal with it?" What are you, a cultist? I answered a question here, fuck off.
If you need all this complexity to implement a setTimeout or setInterval in a React component I don't think you can really blame the tutorials.
https://overreacted.io/making-setinterval-declarative-with-r...
https://overreacted.io/making-setinterval-declarative-with-r...
As someone who's been doing React since the beginning, I would agree that it's hard starting out.
However, I think any new paradigm is difficult starting out. Recently I've been learning OO for work and I've been finding it stupidly hard and entirely unintuitive.
However, I think any new paradigm is difficult starting out. Recently I've been learning OO for work and I've been finding it stupidly hard and entirely unintuitive.
I’ve found Vue easier to learn because it bundles things and lets you learn visual components before fully exploring the reactive model. So while the modularity of React is preferable to a seasoned developer, it does no good to a newcomer.
I have no doubt React is easy if you've been there from the beginning. But if you learned it last year like me, you got to find out the hard way that things are done slightly differently in each version, introducing breaking changes which invalidate the vast majority of the documentation you can find (which you need because the official docs is absolute crap for beginners, as it assumes you already know React's paradigms).
what do you mean by learning OO here? javascript is OO too, so you have already been doing OO, as far as i understand it and what you are learning is something different. and now i am curious what that is.
Between modern frameworks and that MS born monstrosity Typescript, I thought this was the JS-free web. I would love to see the back of it.
Web Dev seems to be ignoring the last 10-15 years of new native browser technologies and getting really stagnant with proprietary bloat as a result.
It's a really good time to start from scratch and see what we can do with WebGL/WebGPU/Shaders, WASM(C, C++, Rust Etc) and Web Audio, as well as the new features of Vanilla JS
The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag?
Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.
Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.
But anchors and hyperlinks mean I make a new HTTP request to download the full page content, and make the browser re-draw only the parts that changed[1].
On the other hand, with something like react-router you can now just download the full page content[2] but without <head> [3], and then make the browser re-draw only the parts that changed.
Only half-joking though. People can build things whatever way they like, and these frameworks can have good trade-offs. But sometimes the justifications devs give[4] just sound like they're reluctant to say "because I already know it, so I'm more efficient with it" or something like that.
[1]: "Paint holding".
[2]: Code splitting.
[3]: These savings are probably offset by the library's 19kB, anyway. Or with that small icon that was inlined as base64.
[4]: Which they don't need to give to anyone, unless it's for a situation like an employer asking for it.
On the other hand, with something like react-router you can now just download the full page content[2] but without <head> [3], and then make the browser re-draw only the parts that changed.
Only half-joking though. People can build things whatever way they like, and these frameworks can have good trade-offs. But sometimes the justifications devs give[4] just sound like they're reluctant to say "because I already know it, so I'm more efficient with it" or something like that.
[1]: "Paint holding".
[2]: Code splitting.
[3]: These savings are probably offset by the library's 19kB, anyway. Or with that small icon that was inlined as base64.
[4]: Which they don't need to give to anyone, unless it's for a situation like an employer asking for it.
The entire disappearance of semantic HTML tags has been sad to see. It's just all <divs> inside of <divs> inside of <divs> these days.
To be honest, as someone who like semantic HTML, it's a pain to search for an appropriate tag and then try to figure out how to undo all its quirks and re-style it.
Semantic HTML was always a wrong half-solution to the problem. A website is always going to need custom semantics, the random grab-bag of whatever ideas people had back in 1993 is not a good set to base anything on.
You're right that there's certainly bad HTML produced by React apps out there. But there's good HTML, too!
As far as I can tell, React let's you write HTML in both the right and wrong ways, like all frameworks (including plain JS).
Maybe it seems like React is worse in terms of HTML because of how popular it is? There are more users of it, so more potential examples of bad HTML?
As far as I can tell, React let's you write HTML in both the right and wrong ways, like all frameworks (including plain JS).
Maybe it seems like React is worse in terms of HTML because of how popular it is? There are more users of it, so more potential examples of bad HTML?
> There are more users of it, so more potential examples of bad HTML?
I think you have hit the nail on the head.
I think you have hit the nail on the head.
There are some good use cases for this, for example soundcloud uses this to prevent reloading the page (and thus stopping the music when you click a link)
Fun fact, soundcloud uses links.
React can use links and still be dynamic. The problem is without it, you break the browser history, you break long press menu on mobile, you lose the link preview in the status bar.
React can use links and still be dynamic. The problem is without it, you break the browser history, you break long press menu on mobile, you lose the link preview in the status bar.
damn that's true. Soundcloud history sucks. It's unfortunate that there isn't a solution to this in the web standard.
You can build a good website in React and you can build a bad website in React. It's easier to build a bad website in React than it is to build a bad website with just plain HTML/CSS.
> It's easier to build a bad website in React than it is to build a bad website with just plain HTML/CSS.
I think many people would argue that it is easier to build a good web app in React than plain HTML/CSS/JS.
I think many people would argue that it is easier to build a good web app in React than plain HTML/CSS/JS.
Sure, but most people think they’re building a webapp when they’re really building a website.
No arguments there. Nothing worse than one-page website that seems to be a overly complicated SPA instead!
Great, another misinformed rant about React; meanwhile React developers get stuff done without inventing yet another template language.
Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.
Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.
Why do you think bad developers or teams without sufficient budget may produce bad experiences when using React? What should those teams be caring about that React doesn't solve for them?
Interactive UI development just isn't easy nor simple regardless of the platform and framework.
A tool like React can shrink the space you need to be vigilant about to ensure performance (not just speed but also UX), but you still need vigilance and attention to detail to make sure you're not making mistakes like running something on every re-render that you meant to do just once.
And it has its own idiosyncrasies that you need to be vigilant about. Like if you write a hook `const x = useMyHook({ optionA, optionB })` then you need to handle the cases (either at the call site or inside the hook) where the options object is new one every render and when optionA or optionB are non-primitives that change every render.
A tool like React can shrink the space you need to be vigilant about to ensure performance (not just speed but also UX), but you still need vigilance and attention to detail to make sure you're not making mistakes like running something on every re-render that you meant to do just once.
And it has its own idiosyncrasies that you need to be vigilant about. Like if you write a hook `const x = useMyHook({ optionA, optionB })` then you need to handle the cases (either at the call site or inside the hook) where the options object is new one every render and when optionA or optionB are non-primitives that change every render.
COBOL developers also get stuff done
Yes, but is COBOL increasing in popularity with devs year after year?
not anymore. React, I have the impression as a long time developer, might have peaked too
> It's the rewarding side of real engineering, trying out new materials under well-understood constraints to improve user outcomes.
Good thing we’re mostly keeping the attitude to hobby projects.
Can’t imagine hundreds of artisans™ bikeshedding over what the hell this even means.
And I can’t read with a straight face an article talking about complexity of React while suggesting Vue (sic!) as an alternative. Lol!
Good thing we’re mostly keeping the attitude to hobby projects.
Can’t imagine hundreds of artisans™ bikeshedding over what the hell this even means.
And I can’t read with a straight face an article talking about complexity of React while suggesting Vue (sic!) as an alternative. Lol!
what is wrong with vuejs?
Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton)
A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things like filtering or updating lists, you use the lightweight library for smooth, efficient updates. You get the best of both worlds—a super-fast initial experience and the ability to add dynamic features without the React baggage (and often-neglected backend).
A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things like filtering or updating lists, you use the lightweight library for smooth, efficient updates. You get the best of both worlds—a super-fast initial experience and the ability to add dynamic features without the React baggage (and often-neglected backend).
I've been using Inertia.js with laravel and Vue and its been great, no need to write an API layer. You get the simplicity of writing server rendered with the interactivity of an SPA
Same. Using it at work (although with React/Rails) and it works great. Best of both worlds with minimal drawbacks.
I've generally agreed with this but found the UI (ie. HTML) story on the backend is utter shite. Namely it's usually been handled by templates which inevitably lead to ridiculously inconsistent UIs with so much redundancy. In contrast something like JSX is really good and makes building small components for reuse natural.
Fortunately there has been some change in this area. FastHTML is a batteries-included library for Python and there are numerous standalone HTML generation libraries that can be used with other frameworks like Django, e.g. htpy, htmy etc.
I've been using alpine on a static site and it's really quite impressive just how much of "the stuff you probably want js for" it covers. So much so that you can pretty much say "if you can't do it in alpine, maybe we shouldn't do it at all".
Fortunately there has been some change in this area. FastHTML is a batteries-included library for Python and there are numerous standalone HTML generation libraries that can be used with other frameworks like Django, e.g. htpy, htmy etc.
I've been using alpine on a static site and it's really quite impressive just how much of "the stuff you probably want js for" it covers. So much so that you can pretty much say "if you can't do it in alpine, maybe we shouldn't do it at all".
I am using Laravel Blade components which are effectively just fully server rendered templates in component style, so you get the benefit of that mental model.
Then you can just add Alpine as necessary.
Then you can just add Alpine as necessary.
I think React is fine, especially when using it mainly for rendering, keeping async stuff out of the components as much as possible.
The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc.
Imagine being able to do this without importing any 3rd party code:
I’m not aware of any initiatives like this currently. WebComponents could also benefit, as building a DOM tree within a class extending HTMLElement is still cumbersome: the WebComponents API doesn't really add anything to simplify DOM handling, which is why libraries like Lit exist.
--
1: Inspired by https://github.com/developit/htm
The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc.
Imagine being able to do this without importing any 3rd party code:
const content = html`<h1 id=hello>Hello world!</h1>`; // New API: html Tagged templates [1].
console.log(content);
// Outputs: { type: 'h1', props: { id: 'hello' }, children: ['Hello world!'] }
document.querySelector("#container").patch(content); // New API: HTMLElement.patch.
I’m not aware of any initiatives like this currently. WebComponents could also benefit, as building a DOM tree within a class extending HTMLElement is still cumbersome: the WebComponents API doesn't really add anything to simplify DOM handling, which is why libraries like Lit exist.
--
1: Inspired by https://github.com/developit/htm
Apart from running screaming in the opposite direction from tagged templates for security reasons, I think a more suitable approach (that fits current ECMAScript naming conventions / namespacing) might just be something like:
Worth noting too: you could cheat in the html function above and have it directly return content.childNodes, thus reducing the differences between the two examples to simply "patch" vs "replaceChildren".
In your example, are you envisioning that HTMLElement.patch() is doing something different than Element.replaceChildren() or Element.replaceWith()? That'd be one area that wouldn't be addressed with this.
Having it first-party would be lovely but it's already pretty doable.
const content = document.createTemplate(`tagged string`).content
function html(markup) {
const templateNode = document.createElement(markup)
templateNode.innerHTML = markup
return templateNode.content
}
import html from "MyModule"
const content = html`<h1 id=hello>Hello world!</h1>`; // No New API Needed
document.querySelector("#container").replaceChildren(content.childNodes)
Worth noting too: you could cheat in the html function above and have it directly return content.childNodes, thus reducing the differences between the two examples to simply "patch" vs "replaceChildren".
In your example, are you envisioning that HTMLElement.patch() is doing something different than Element.replaceChildren() or Element.replaceWith()? That'd be one area that wouldn't be addressed with this.
Having it first-party would be lovely but it's already pretty doable.
All of what I'm talking about is doable through libraries today (or you can write it yourself). But making things available through DOM APIs create a new baseline where the very same tools are made available for anyone, no matter the framework (think: document.querySelector APIs).
Regarding patch, morphdom explains very well the difference between replacing and patching the DOM [1]:
> Replacing an entire DOM tree is fast but loses internal state (e.g., scroll positions, input carets, CSS transitions). Instead, we aim to transform the existing DOM tree to match the new one, minimizing changes and preserving state.
Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
---
1: https://github.com/patrick-steele-idem/morphdom
Regarding patch, morphdom explains very well the difference between replacing and patching the DOM [1]:
> Replacing an entire DOM tree is fast but loses internal state (e.g., scroll positions, input carets, CSS transitions). Instead, we aim to transform the existing DOM tree to match the new one, minimizing changes and preserving state.
Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
---
1: https://github.com/patrick-steele-idem/morphdom
I agree on the point of first-party, as I already wrote.
I suspect there would be a lot of edge case footguns in trying to write something like patch() that tries to crawl the content as a diff and make only the minimal changes. Things like events being bound incorrectly to elements, what to do when the structures of the old and new don't match in some breaking way, etc.
Not saying it can't be done but I suspect it's more complexity than we think of typically when using a term like patch. Some of those items (such as transitions) can be pretty straightforward to deal with already.
> Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
Performance and the DOM (especially as typically deployed in an SPA / the "modern" web) don't really go together already, so I'm not convinced that's a particularly compelling argument. Making it first-party on its own is already that compelling argument IMO.
I suspect there would be a lot of edge case footguns in trying to write something like patch() that tries to crawl the content as a diff and make only the minimal changes. Things like events being bound incorrectly to elements, what to do when the structures of the old and new don't match in some breaking way, etc.
Not saying it can't be done but I suspect it's more complexity than we think of typically when using a term like patch. Some of those items (such as transitions) can be pretty straightforward to deal with already.
> Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.
Performance and the DOM (especially as typically deployed in an SPA / the "modern" web) don't really go together already, so I'm not convinced that's a particularly compelling argument. Making it first-party on its own is already that compelling argument IMO.
What security reasons? Tagged template libraries like lit-html are extremely safe.
There is a proposal for JavaScript-based HTML templates: https://github.com/WICG/webcomponents/issues/1069
Thanks for sharing, I wasn't aware of this one. I hope they succeed!
... also TFA conflates web application architecture with frontend frameworks, creating a false dichotomy. For instance, I’m building a site that serves static HTML but still benefits greatly from Preact for the dynamic parts.
The critique seems focused on SPA architectures heavily based on React, as seen in frameworks like Next.js and Remix. To be clear, I also lean away from that style of web application architecture, but I’m not sure this 20-page article effectively makes the case for simpler alternatives.
The critique seems focused on SPA architectures heavily based on React, as seen in frameworks like Next.js and Remix. To be clear, I also lean away from that style of web application architecture, but I’m not sure this 20-page article effectively makes the case for simpler alternatives.
I thought Next.js and Remix were SSR-based frameworks, both created as alternatives to building a SPA.
After the initial "SPA fever" died down, these frameworks cropped up to address the shortcomings of SPAs such as a lack of SEO-compatibility.
After the initial "SPA fever" died down, these frameworks cropped up to address the shortcomings of SPAs such as a lack of SEO-compatibility.
Next.js and similar tools redefine server-side rendering (SSR) to mean generating HTML on the server using the same code that runs on the frontend, requiring server-side JavaScript and what they call "hydrating" on the client. Next.js and friends are very much SPA frameworks, they just try to address the shortcomings of SPA architecture and in the process introduce a lot of complicated layers.
Since the term SSR has been... "repurposed" now, what I was talking about a simpler CGI-style approach—no JavaScript, no async complications like Suspense. Rendering React components server-side often requires special tricks, especially when components interact with DOM APIs or make HTTP calls.
As an example, Templ has a detailed guide on using React in a traditional architecture without server-side rendering React components [1].
---
1: https://templ.guide/syntax-and-usage/using-react-with-templ/
Since the term SSR has been... "repurposed" now, what I was talking about a simpler CGI-style approach—no JavaScript, no async complications like Suspense. Rendering React components server-side often requires special tricks, especially when components interact with DOM APIs or make HTTP calls.
As an example, Templ has a detailed guide on using React in a traditional architecture without server-side rendering React components [1].
---
1: https://templ.guide/syntax-and-usage/using-react-with-templ/
what you described is lit-html, which might find its way to the browser:
https://github.com/WICG/webcomponents/issues/1069
https://github.com/WICG/webcomponents/issues/1069
I'm not a web dev at all, but when I need some web UI ClojureScript/Reagent works pretty well. I get all the pretty React components while being able to avoid JavaScript and JSX entirely (all XML-style DSLs that have closing tags I find incredibly verbose and ugly).
People don’t understand the beauty of closure!
If Java is your cup of tea, you might want to try Flavour. I did and now it's the only frontend framework I use. https://flavour.sourceforge.io/
It lets you write your frontend and backend code in the same language, even sharing models and validation logic so refactorings work full stack.
You get strong typing and a rich SPA framework that includes routing, templates, and easy server calls.
There's a book ( https://frequal.com/Flavour/book.html ) and a Java SwingSet-like app with live demos and source code called Tea Sampler ( https://frequal.com/tea-sampler/ ).
It lets you write your frontend and backend code in the same language, even sharing models and validation logic so refactorings work full stack.
You get strong typing and a rich SPA framework that includes routing, templates, and easy server calls.
There's a book ( https://frequal.com/Flavour/book.html ) and a Java SwingSet-like app with live demos and source code called Tea Sampler ( https://frequal.com/tea-sampler/ ).
How do you think it compares to Vaadin?
> Frameworkism isn't delivering.
It isn't? I find React to be great to work with.
It isn't? I find React to be great to work with.
Yes, you the developer. I think that’s his point. The performance if react sites is another thing and that’s what the user cares about. It also doesn’t work on mobile. React native was worshipped and now is thrown out.
Is it even working for the developer though? Last I checked the server-side rendering performance for react based frameworks was somewhere like 200 pages per second? Is that something to be proud of as a developer?
React is absolutely performant. A developer who makes a slow React site would make a slow site with something else.
They're a wide chasm between what one can make and what is led to making. React can lead to fast, responsive websites, though you'd be fighting against a current pulling you out to a bloated, buggy mess. There's a unique stench that comes from many react sites where everything is a skeleton screen, everything loads slowly, history rewriting is busted, there's no hotlinking, and scrolling is glitchy. Peek under the hood, it's almost always react. Facebook.com quality is the outlier, not the likely outcome.
Tell that to all the former PHP developers. Where are these performant React sites? The largest and best tech companies out there certainly can’t do it.
The same former PHP developers responsible for all those slow WordPress sites?
The ones who made react.
Uh... I'm pretty sure Compass.com is running on Next.js...
React is far from performant for SSR, and it simply can’t be, as it wasn’t designed with backend needs in mind. The fact that it works at all is more of a happy accident or side effect. Current approaches are more like workarounds than proper solutions for making it function effectively on servers.
Most importantly, it’s also not particularly performant on the client side in real-world scenarios.
For evidence, here’s a guy testing major websites using his awesome react-scan tool: https://x.com/aidenybai/status/1861442057598062653
Most importantly, it’s also not particularly performant on the client side in real-world scenarios.
For evidence, here’s a guy testing major websites using his awesome react-scan tool: https://x.com/aidenybai/status/1861442057598062653
If React is so great how come Amazon isn't using it in their store?
I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.
I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.
Do not base your company’s tech decisions on FAANG companies unless your company is a FAANG company. Your challenges are likely very different from theirs
Everyone using React is basing their work on Facebook’s challenge!
You're missing the point of my comment.
Someone is contesting that "frameworkism isn't delivering" when we have objective data to prove that it is in fact not delivering.
The Amazon store is just a good example because there's a lot of data about it, not because it's FAANG.
Someone is contesting that "frameworkism isn't delivering" when we have objective data to prove that it is in fact not delivering.
The Amazon store is just a good example because there's a lot of data about it, not because it's FAANG.
What I read from what you said is “Chevy trucks are good? Oh yeah, if trucks are good, why does the post office use non-Chevy, non-truck, fleet cars?”
Please help me understand where I misunderstand
Please help me understand where I misunderstand
"Trucks are bad for X"
"No, trucks are good for X"
"Look at this use case (Amazon) with tons of objective data that shows that trucks are bad for X"
"No, trucks are good for X"
"Look at this use case (Amazon) with tons of objective data that shows that trucks are bad for X"
"Look at this use case (Amazon) with tons of objective data that shows that trucks [do not fit Amazon's use case for X]"
It seems that you're arguing that the performance requirements of Amazon are different from other sites (in e-commerce or not). Is this it?
Are you arguing that web devs should ignore CWV for e-commerce sites?
Are you arguing that web devs should ignore CWV for e-commerce sites?
You just picked Amazon arbitrarily because it supports your argument, but there are many more counter examples where react is used, so what's your point?
And who where it’s faster and more performant? Not Pinterest. Not Airbnb. Not X. Not the Amazon competitors he showed. Not even the flipping creators (Facebook) of the framework. You all keep blaming the specific companies for their sites but can’t ever seem to show us an actual performant and good example of react usage.
I used Amazon because there's a significant amount of data to indicate React is a bad fit for e-commerce (as the OP article points out).
React is in use in many heavily used frontends at Amazon, maybe not the retail site
But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site
But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site
My constant problem with React-based tools is that they don't support deep links properly. You want to right-click on a product description to open it in a different tab to check later, and you can't.
Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.
Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.
I'm not sure how much experience you have with react, but it doesn't need to "support" links, they function exactly the same as with vanilla js, there's nothing about react that prevents their use. Using JavaScript for links is entirely a developer decision.
Sure is odd that a good number of react-and-friends websites can’t manage to support it all then.
Just like how routing and history is “solved” but I encounter websites every other day that completely break my browser history.
Just like how routing and history is “solved” but I encounter websites every other day that completely break my browser history.
> Sure is odd that a good number of react-and-friends websites can’t manage to support it all then.
I don't think that's true. More likely, you use react websites all the time and don't even think about it because the links work as you expect.
I don't think that's true. More likely, you use react websites all the time and don't even think about it because the links work as you expect.
I'm familiar with React. And no, links in React often don't work without extra attention.
It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details.
Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details.
Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
> And no, links in React often don't work without extra attention
Links work fine, out of the box, react treats them the same way vanilla js does. JavaScript onClick events aren't links, and that's true whether you're using react or vanilla js.
> It's way too easy to put some state information into the context and then have your pages depend on it.
What do you mean it's too easy? If someone makes poor engineering choices because that's the "easy" thing to do, that's their fault, the tool didn't make them do that.
> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
This is true of JavaScript in general, it has nothing to do with react. In order for links to work, the server has to render pages that correspond to the link, whether that means encoding state in the url or pulling it from a session, this is required whether you're using react or literally anything else.
Links work fine, out of the box, react treats them the same way vanilla js does. JavaScript onClick events aren't links, and that's true whether you're using react or vanilla js.
> It's way too easy to put some state information into the context and then have your pages depend on it.
What do you mean it's too easy? If someone makes poor engineering choices because that's the "easy" thing to do, that's their fault, the tool didn't make them do that.
> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.
This is true of JavaScript in general, it has nothing to do with react. In order for links to work, the server has to render pages that correspond to the link, whether that means encoding state in the url or pulling it from a session, this is required whether you're using react or literally anything else.
> I'm familiar with React. And no, links in React often don't work without extra attention.
^ These two statements are at odds with each other.
React will return a pure browser link that behaves exactly as a browser link:
So, the problem isn't React. The problem is people overriding default browser behaviour for their widgets. It was a problem before React, and it will be a problem long after React.
For example, here's Google's premier site about web technologies: https://web.dev/articles Check out the pagination links at the bottom. There's no React on the page
^ These two statements are at odds with each other.
React will return a pure browser link that behaves exactly as a browser link:
function Comp() { return <a href="some-link">text</a>; }
So, the problem isn't React. The problem is people overriding default browser behaviour for their widgets. It was a problem before React, and it will be a problem long after React.
For example, here's Google's premier site about web technologies: https://web.dev/articles Check out the pagination links at the bottom. There's no React on the page
> React will return a pure browser link that behaves exactly as a browser link
No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through.
Yes, you don't _have_ to do it this way.
No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through.
Yes, you don't _have_ to do it this way.
> No it doesn't (in practice).
Yes , yes it does, in practice.
> React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself,
"Taken over by Router", "handled by SPA itself" .... "React is to blame"
> Yes, you don't _have_ to do it this way.
Yes, you don't have to it this way, and this isn't React-specific. See Google's web.dev site built with web components
Yes , yes it does, in practice.
> React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself,
"Taken over by Router", "handled by SPA itself" .... "React is to blame"
> Yes, you don't _have_ to do it this way.
Yes, you don't have to it this way, and this isn't React-specific. See Google's web.dev site built with web components
> My constant problem with React-based tools is that they don't support deep links properly.
I worry that most people complaining here about React, including the OP, do not actually understand the very basics of React. Here someone is complaining about how React somehow messes with deep links. Without understanding that React does nothing to links. Nothing.
I worry that most people complaining here about React, including the OP, do not actually understand the very basics of React. Here someone is complaining about how React somehow messes with deep links. Without understanding that React does nothing to links. Nothing.
> maybe not the retail site
I'm discussing the retail site specifically because that's where CWV matter.
If a company has internal tools that take seconds to load it doesn't really matter. Captive users don't have much of a choice.
I'm discussing the retail site specifically because that's where CWV matter.
If a company has internal tools that take seconds to load it doesn't really matter. Captive users don't have much of a choice.
It's in use in customer facing apps, Prime Video is built with React
Most of their app is a mismatch of web views and native with spinners galore. It doesn’t seem like performance is a high priority for them anymore.
E-commerce is fundamentally small data once the user lands on a product page, so every subsequent link and click should be instant.
E-commerce is fundamentally small data once the user lands on a product page, so every subsequent link and click should be instant.
Because Amazon Store is and aleays was an armpit of webdesign? It's the worst designed e-commerce site and decades of tinkering only brought it half way towards basic level of decency that was obvious to a beginner web developer making their own first e-commerce site from scratch in PHP 20 years ago?
You’re blurring architecture with UI.
The Amazon site is pretty ugly, yes, but it’s functional and fast.
The Amazon site is pretty ugly, yes, but it’s functional and fast.
I honestly think this conversation gets overly complex because we fail to define the kind of websites we are talking about. These are my definitions, so I'll just share them upfront:
- a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket
- a web application -- which has high interactivity requirements. Things like Gmail, Linear, Google Calendar, and an enormous amount of SaaS apps fit in this bucket of things.
React is better at anything else at making the second. React developers happily pay the weird tradeoffs that come with it in order to efficiently develop the second.
React is pretty reasonably good at making the first, but the negative costs are more obvious.
As someone who has worked on one of the most consumed React apps in the world (Discord), I think the concerns with React are overstated. People want a good product, they don't care about the framework and it's costs. React is one of the most efficient (in terms of developer productivity) ways to get there.
I'm not a React loyalist; I would love to see someone dethrone React. My ears are always to the ground for new developments in technology. In my opinion it hasn't happened yet, but I would be surprised if it never happens.
- a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket
- a web application -- which has high interactivity requirements. Things like Gmail, Linear, Google Calendar, and an enormous amount of SaaS apps fit in this bucket of things.
React is better at anything else at making the second. React developers happily pay the weird tradeoffs that come with it in order to efficiently develop the second.
React is pretty reasonably good at making the first, but the negative costs are more obvious.
As someone who has worked on one of the most consumed React apps in the world (Discord), I think the concerns with React are overstated. People want a good product, they don't care about the framework and it's costs. React is one of the most efficient (in terms of developer productivity) ways to get there.
I'm not a React loyalist; I would love to see someone dethrone React. My ears are always to the ground for new developments in technology. In my opinion it hasn't happened yet, but I would be surprised if it never happens.
> a web site [...] a web application
But is that not the crux of the article? So much of the web is the former but is built and distributed as if it's the latter, with all the end-user downsides that entails.
But is that not the crux of the article? So much of the web is the former but is built and distributed as if it's the latter, with all the end-user downsides that entails.
Honestly, that wasn't clear to me from the article, and judging by the comments section to this post, I don't think I'm alone. That's part of why I advocate for defining these terms up front, because one person is talking about whether or not Linear should be in React, another person is talking about whether or not Linear's docs should be in React.
> React is better at anything else at making [a web application]
Mithril.js beats it in my opinion.
I’m sure many developers would argue in favor of other libraries over React.
React is simply the most popular.
Mithril.js beats it in my opinion.
I’m sure many developers would argue in favor of other libraries over React.
React is simply the most popular.
Being the most popular comes with big benefits. There are far more articles about how to support issues that you run into, and many more libraries available for your use. While other libraries maybe "better"in some cases, giving up the support of the large community is a big cost.
No argument there. But “better at” implies something inherent to React’s design rather than to its community.
I'm glad you like it, but https://mithril.js.org/simple-application.html is some "uh-huh, thanks but no"
Care to be specific? Is it the documentation you don’t like? Is it the example application’s design you don’t like? Or is it something about Mithril itself?
Two things, in descending order of rage-close-tab for me: that m(.., [m(), m()]) is deeply unserious, and .then((result) => User.list = result) just seems oppressively singleton (although I'm open to that being a tutorialism but why even show users antipatterns if that's not how it's going to work for real?)
I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find gainful employment when they have to go to their next job that also uses Mithril. But I hope I never ever have to work in an organization which thinks a shitload of m() functions is easier to read than JSX
I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find gainful employment when they have to go to their next job that also uses Mithril. But I hope I never ever have to work in an organization which thinks a shitload of m() functions is easier to read than JSX
Yes, that whole page you cited is simply tutorialism.
And Mithril supports jsx. (Not to mention the advantages gained by avoiding JSX in favor of hyperscript)
Might be best to actually use it in a small (or large) application of your own design rather than judging prematurely.
(I’m not suggesting large orgs use Mithril, as other commenter mentioned, community in some situations is more important than the tooling. But “building a web app” does not necessarily imply “employing a team of local developers to build a web app asap for less than x usd”.)
And Mithril supports jsx. (Not to mention the advantages gained by avoiding JSX in favor of hyperscript)
Might be best to actually use it in a small (or large) application of your own design rather than judging prematurely.
(I’m not suggesting large orgs use Mithril, as other commenter mentioned, community in some situations is more important than the tooling. But “building a web app” does not necessarily imply “employing a team of local developers to build a web app asap for less than x usd”.)
JSX vs hyperscript is a religious issue. You can use JSX with Mithril if you prefer (after all the m() thing is what JSX compiles to).
He spent a chunk of the article defining exactly those terms.
I know we're not supposed to accuse people of not rtfa but sometimes it's a struggle.
I know we're not supposed to accuse people of not rtfa but sometimes it's a struggle.
Said this somewhere else, but: honestly, that wasn't clear to me from the article, and judging by the comments section to this post, I don't think I'm alone. That's part of why I advocate for defining these terms up front, because one person is talking about whether or not Linear should be in React, another person is talking about whether or not Linear's docs should be in React.
I don't appreciate the rudeness. I wasn't rude to you or the author, don't see any reason for you to be rude to me.
I don't appreciate the rudeness. I wasn't rude to you or the author, don't see any reason for you to be rude to me.
I apologise for my rudeness.
> and an enormous amount of SaaS apps fit in this bucket of things.
Let’s not get ahead of ourselves. An enormous amount of SaaS’s _wish_ they were a web app. A good chunk of them would probably have a net-better UX by dispensing of this delusion.
Let’s not get ahead of ourselves. An enormous amount of SaaS’s _wish_ they were a web app. A good chunk of them would probably have a net-better UX by dispensing of this delusion.
Turbo morphing. It’s part of Hotwire.
Re-Render the full page server side, app takes response, applies only the changes needed. Preserves scrolling state, etc.
Super simple pattern for building dynamic sites.
https://turbo.hotwired.dev/handbook/page_refreshes#morphing
Re-Render the full page server side, app takes response, applies only the changes needed. Preserves scrolling state, etc.
Super simple pattern for building dynamic sites.
https://turbo.hotwired.dev/handbook/page_refreshes#morphing
This is the way.
It achieves 95% of the effect, and you maintain one implementation, not two.
It achieves 95% of the effect, and you maintain one implementation, not two.
I love react and don’t feel the pain that people talk about.
Yes it’s hard to learn the mental model but worth the effort.
My one tip to make your life with react easier …. don’t use state except within a component, instead send document events …… makes react 10X easier.
Having said the above I don’t do any SSR and not a fan of it.
Yes it’s hard to learn the mental model but worth the effort.
My one tip to make your life with react easier …. don’t use state except within a component, instead send document events …… makes react 10X easier.
Having said the above I don’t do any SSR and not a fan of it.
I still think you can build good tools using just html, css and pure js if you have the right knowledge. For example, this social network was built without any frameworks and has the performance it has https://chat-to.dev
It sounds like the author is complaining more about SPAs than the React itself.
Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
Nobody needs an SPA, it’s a stylistic choice, not a need.
Ugh, that's just the fundamentalistic, non-engineering approach that we need less of.
Everything is a trade-off, and SPAs offer a trade-off that is right for some cases and wrong for others.
Everything is a trade-off, and SPAs offer a trade-off that is right for some cases and wrong for others.
I disagree that SPAs are the only solution to some problems. This is an orthodoxy which people buy into but there are always a few different approaches possible. What do SPAs actually offer which is unique?
There are multiple possible solutions to most problems, including gmail or google maps for example. Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs (the followers of which I’d argue are far more fundamentalist in insisting you can only use SPAs).
There are multiple possible solutions to most problems, including gmail or google maps for example. Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs (the followers of which I’d argue are far more fundamentalist in insisting you can only use SPAs).
> I disagree that SPAs are the only solution to some problems.
I disagree with that too. Did I ever say otherwise?
I do believe, however, that there are problems for which a SPA offers the best trade-off. Not the only solution, but the best trade-off.
> This is an orthodoxy which people buy into but there are always a few different approaches possible.
Like the orthodoxy that "nobody needs an SPA"?
> What do SPAs actually offer which is unique?
Interactivity. Good luck keeping your focus or scroll position while reloading a page. If done carefully, performance can also be on that list, though I agree it is often not done carefully.
> Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs
Agreed. Though you can load both code and data dynamically from a SPA, if you need.
Perhaps our definitions of a "SPA" differ? SPA is when you don't do reloads, hence "single page". But there are many ways to do that, some of them involving React.
I disagree with that too. Did I ever say otherwise?
I do believe, however, that there are problems for which a SPA offers the best trade-off. Not the only solution, but the best trade-off.
> This is an orthodoxy which people buy into but there are always a few different approaches possible.
Like the orthodoxy that "nobody needs an SPA"?
> What do SPAs actually offer which is unique?
Interactivity. Good luck keeping your focus or scroll position while reloading a page. If done carefully, performance can also be on that list, though I agree it is often not done carefully.
> Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs
Agreed. Though you can load both code and data dynamically from a SPA, if you need.
Perhaps our definitions of a "SPA" differ? SPA is when you don't do reloads, hence "single page". But there are many ways to do that, some of them involving React.
I think we mostly agree, I meant people choose it - they don’t need to do things that way.
I disagree a bit with the article's implication that putting more code on the client leads to a loss of control. With web programming, there is no way to have full control. Even if you avoid JavaScript on the client and concentrate all the code on the server, the server output still has to be rendered by the browser, and you don't control that. You have no control over what browser is being used, what settings have been applied to the browser, the level of resources available on the client machine, what other programs are running, and so on.
I've come to the realization that unless you're OK with some very clunky front-end, there's just no way to avoid quite a bit of JavaScript on the client. Once you need to write a non-trivial UI heavy web app, you quickly realize that avoiding JavaScript on the client is a non-starter, as cool as that would have been.
The issues involve a lack of standardized sophistication of the web technologies, like HTML controls being clunky, very unsophisticated and hard to configure/style properly, CSS not being properly composable, HTML forms not implementing the full set of HTTP verbs, etc... To me these are fundamental problems with the web architecture that need solving.
Revamping the web architecture to properly support a sophisticated negotiation of control between the developer, the browser, and the end-user would greatly reduce, if not almost eliminate, all the thorny problems that declarative UI frameworks and libraries bring into focus.
I've come to the realization that unless you're OK with some very clunky front-end, there's just no way to avoid quite a bit of JavaScript on the client. Once you need to write a non-trivial UI heavy web app, you quickly realize that avoiding JavaScript on the client is a non-starter, as cool as that would have been.
The issues involve a lack of standardized sophistication of the web technologies, like HTML controls being clunky, very unsophisticated and hard to configure/style properly, CSS not being properly composable, HTML forms not implementing the full set of HTTP verbs, etc... To me these are fundamental problems with the web architecture that need solving.
Revamping the web architecture to properly support a sophisticated negotiation of control between the developer, the browser, and the end-user would greatly reduce, if not almost eliminate, all the thorny problems that declarative UI frameworks and libraries bring into focus.
W3C and WHATWG need to take a long hard look at what functionality is common to most frameworks that's missing from the default HTML/CSS spec and add it. It's literally their job and the existence of such a mass amount of frameworks that implement mostly the same things in slightly different ways means they're not doing it well.
There's bloat and then there's sending the exact same thing over the network quadrillions of times at every page load because it's not standard and everyone needs it.
There's bloat and then there's sending the exact same thing over the network quadrillions of times at every page load because it's not standard and everyone needs it.
The people who don't think React (or Vue) is important are the same ones who have never worked on a large project with lots of screen updates and state changes that absolutely cannot be avoided. React is still #1 in popularity, and the most crucial tool for almost any web developer (aside from using TypeScript, instead of plain JS which is also critical for large projects)
React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.
React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.
> React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.
The options you present are: "either use a JS framework or don't use JavaScript at all". That's a false dichotomy. I've built plenty of interactive apps with JavaScript without using frameworks.
The options you present are: "either use a JS framework or don't use JavaScript at all". That's a false dichotomy. I've built plenty of interactive apps with JavaScript without using frameworks.
> I've built plenty of interactive apps with JavaScript without using frameworks
And once you reach sufficient project complexity, you will end up with just another homegrown framework, with all the lessons learned by mature frameworks, left to be fixed over the next 5 years.
And once you reach sufficient project complexity, you will end up with just another homegrown framework, with all the lessons learned by mature frameworks, left to be fixed over the next 5 years.
Oh yeah? And when will that happen? Because people have been throwing this argument at me since at least 2014. I still haven't slipped on a banana peel and accidentally fallen on a homegrown framework. You don't just create a framework by accident.
I don't have any context, but I do have trouble imagining that any of your projects have scale/complexity above brochure-ware if you haven't run into this.
If you have trouble imagining, here's one such project: https://github.com/baobabKoodaa/ouija
I have a lot of "framework free" single-developer projects as well (such as https://bongo.to ), but that isn't really what I think we are talking about here. Single developer projects can do whatever they want, it isn't a problem. The problem comes when you have to work with distributed teams, juniors, etc. One way or another a large team still has to come to agreements about how to do things, and without an external reference it will have to be made up in an ad-hoc manner instead. This often leads to issues, many of us have noticed.
The goalposts just keep moving...
The claim upthread was that you couldn't make a web app at all without a framework ("or it would just be a document"). I said yes you can and the goalposts shifted to: sure, but only "brochure-ware" (referring to simple unambitious projects). I show an ambitious interactive project made without a framework and now the goalposts are moving to: sure, but large distributed teams couldn't work like this? You know, this solo project is more ambitious than 99% of the projects I work on at my actual work. You know, projects that have 10, 40, or 100 devs working on it.
The claim upthread was that you couldn't make a web app at all without a framework ("or it would just be a document"). I said yes you can and the goalposts shifted to: sure, but only "brochure-ware" (referring to simple unambitious projects). I show an ambitious interactive project made without a framework and now the goalposts are moving to: sure, but large distributed teams couldn't work like this? You know, this solo project is more ambitious than 99% of the projects I work on at my actual work. You know, projects that have 10, 40, or 100 devs working on it.
I absoluetly agree with your sentiment, and furthermore in projects as large and mature as mine, with 500K LOC (about maybe 30% in TypeScript) lots of times I simply cannot remember enough about my code to effectively refactor it from memory without type safety (to check me) and IDE refactoring to DO the refactoring.
I mean if I need to change a variable name in a class or something, unless it's a perfectly unique name (easily searchable), it would take me hours to do in JS what I can do in 4 seconds with TypeScript.
I mean if I need to change a variable name in a class or something, unless it's a perfectly unique name (easily searchable), it would take me hours to do in JS what I can do in 4 seconds with TypeScript.
Even if you know of massive projects in JS, the problem isn't that they cannot exist, it's that maintaining them takes 100x the manpower it would in TypeScript.
Jesus Christ, a 1300 line single file codebase.
Not a single file codebase
Sorry:
a codebase with a 1300 line file.
a codebase with a 1300 line file.
> Not a single file codebase.
Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here.
And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's first ever coding project.
Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here.
And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's first ever coding project.
> App.js is all the code there is
No, it's not. Chatbot.js is 3400 LOC.
There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"?
Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts.
> tiny toy project
Huh? 99% of web development is about rendering text and images. This project is moving your mouse inside a web browser & provides a plausible chat experience without a language model. That's more ambitious than just about any actual work project I've seen.
No, it's not. Chatbot.js is 3400 LOC.
There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"?
Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts.
> tiny toy project
Huh? 99% of web development is about rendering text and images. This project is moving your mouse inside a web browser & provides a plausible chat experience without a language model. That's more ambitious than just about any actual work project I've seen.
Even considering chatbot.js, it's still a small enough toy project to just barely get by without type safety. I don't consider a project "large" until it's in the 30K to 50K LOC at least, where it becomes impossible to literally remember where each use of any given variable is. Type Safety catches most typos at build time, and also allows ease of refactoring. Only these small projects can get by without type safety, but EVEN the small projects DO benefit from catching errors at build time. It's just a self-foot-shoot to find bugs at runtime instead of build time.
The question in this thread is not TypeScript vs JavaScript. It's framework vs no-framework. Specifically, is it possible - possible at all - to create an interactive web app without frameworks - one that isn't "just a document" or "brochure-ware". I've demonstrated pretty clearly that yes it is possible. You people just keep shifting the goalposts further and further... Now it doesn't count unless it's 50K LoC? As if unnecessary complexity was some kind of inherent good.
For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion.
Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if they have a high IQ and decades of experience.
Sure you can develop very large projects in JS, as long as you don't mind being 1% as efficient, and having 100x more bugs. In JS, refactoring a huge project is the biggest nightmare in the world and really no human is capable of doing a great job of it in a reasonable time, even if they have a high IQ and decades of experience.
I don't share your opinion but I'm too tired to go into another JS vs TS debate
Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.
Awfully funny considering our major security issues in code these days are from a type safe language.
Yeah because any systems or OS programming is done in type-safe languages. lol. And BTW correlation is not causation.
That was kind of my point. You speak to type safety and all the issues not having is that would be prevented but memory safety is yet another one and is a huge issue with common platforms TODAY. So, obviously your pet issue isn’t the only one out there and there are trade offs made.
Here's how your "point" landed, according to everyone but you:
Me: "Seat belts are important."
You: "Awfully funny considering our major car accidents these days are mostly all ones with seat belts."
You're implying a nonsensical causation that's purely a correlation.
Me: "Seat belts are important."
You: "Awfully funny considering our major car accidents these days are mostly all ones with seat belts."
You're implying a nonsensical causation that's purely a correlation.
My point was how our most serious issues are with memory management that exists in popular type-strict languages and so type safety is not up there in importance compared to the biggest causes.
That's exactly backwards. Without the type-safety in those memory-unsafe languages (like C++) there would be 100x more buffer overruns and other memory issues and security holes. Having the type-safety in place is literally the main thing that makes memory-unsafe languages viable.
"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"
I literally said the exact opposite. I don't care what language you use as long as it's type-safe.
Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.
Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.
First it was "10+ years experience", which would qualify me, but now you shifted the goalposts again to "decades" experience. Lol. I guess you can keep pretending that everybody who matters agrees with you when you just count everybody who disagrees as someone who doesn't matter
I originally typed "seasoned developer" and then I edited it to say decades. Neither one of us has perfect definition of "seasoned developer" in terms of precise years, and it doesn't even matter.
But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.
But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.
> And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you.
You don't believe what exactly? Don't believe I have 10+ yrs of experience? You can see that my GitHub account has activity from the past 10 years, so... you don't believe I prefer dynamic typed languages like Python? You think I actually prefer static typing and I'm lying about that? Like what?
Oh, and it just so happens that Python was the most popular language in the 2024 StackOverflow survey: https://survey.stackoverflow.co/2024/technology#2-programmin...
I guess literally none of those people were "seasoned developers" either, and none of them had ever worked in a "scaled" and "large" project, like you mr big man.
You don't believe what exactly? Don't believe I have 10+ yrs of experience? You can see that my GitHub account has activity from the past 10 years, so... you don't believe I prefer dynamic typed languages like Python? You think I actually prefer static typing and I'm lying about that? Like what?
Oh, and it just so happens that Python was the most popular language in the 2024 StackOverflow survey: https://survey.stackoverflow.co/2024/technology#2-programmin...
I guess literally none of those people were "seasoned developers" either, and none of them had ever worked in a "scaled" and "large" project, like you mr big man.
Sorry, I'm just not buying any of that.
I'm a seasoned developer. Your opinion is just your opinion, not a fact.
Have you heard of Python by any chance? Pretty much the entire field of data science is built on top of a dynamically typed language. Plenty more seasoned developers working in that field.
Have you heard of Python by any chance? Pretty much the entire field of data science is built on top of a dynamically typed language. Plenty more seasoned developers working in that field.
Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason.
If Python was just fine without type-safety that's how everyone would have kept it.
If Python was just fine without type-safety that's how everyone would have kept it.
> Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason.
This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, because Python is not a type-safe language even for those developers who are using "every type-safety feature available to them". You claimed earlier that "Any language that lacks type-safety is completely inappropriate for large-scale projects" even though you seem to be aware of the fact that "seasoned developers" are using Python for "large-scale projects". So, again, you're just lying.
This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, because Python is not a type-safe language even for those developers who are using "every type-safety feature available to them". You claimed earlier that "Any language that lacks type-safety is completely inappropriate for large-scale projects" even though you seem to be aware of the fact that "seasoned developers" are using Python for "large-scale projects". So, again, you're just lying.
Also, we're talking about the web here. How many type-safe supersets of JavaScript are there? When you say "I don't care what language you use as long as it's type-safe", you're pretending as if there's more viable options than just TypeScript.
There is a choice on the server side too, to go with type-safe languages or non-type-safe ones. When I'm stating something as true and general as the importance of type-safety I speak as broadly as possible, because I'm indeed NOT talking about just TS when I say "type safety", I mean it everywhere computer code exists. All untyped languages are garbage.
Generalizing much? React is as popular as it is because of inertia.
React holds an important space but its hardly the only tool that can succeed in a "large project with lots of screen updates and state changes". That's ridiculous.
React holds an important space but its hardly the only tool that can succeed in a "large project with lots of screen updates and state changes". That's ridiculous.
The reason I said "(or Vue)" was specifically to say that there are other leading frameworks. I didn't say "or Angluar" because in my opinion it's a race between React and Vue at this point. But if you think there's a third contender, let me know. I'm always looking to learn.
My main point was to compare "frameworks" v.s. "no frameworks", rather than to say that React is best, but if you want my opinion then yes I do say React is indeed the best, and I admit it's an opinion not a fact. lol.
My main point was to compare "frameworks" v.s. "no frameworks", rather than to say that React is best, but if you want my opinion then yes I do say React is indeed the best, and I admit it's an opinion not a fact. lol.
Have you ever worked on a project that used Rails, Laravel, Django or Spring? Without being a SPA? For many (most) websites, I find that these are far superior to client side heavy SPAs with json apis (react, vue etc).
Most of the apps I've worked on were very business oriented, and about people getting work done, rather than "website" type stuff that's mostly static. So for example, being able to refresh a part of the screen with new information from the server, is critical. Doing page reloads would destroy the experience. I have 35yrs exp so yes I've used most of what you mentioned.
You’re just proving the point. This stuff was easy when it was called Ajax. You don’t need React for that simple thing lmao.
I just use the 'fetch' command to get data from the server. That's basically like Ajax. Where React comes into play of course is taking care of all the page updates, which would be a nightmare for any large app, unless you have a framework being used.
Angluar -> I'm using this from now on
In case I was unclear, I consider Angular dead and obsolete.
> In case I was unclear, I consider Angular dead and obsolete.
maybe you would expand on this? I have no intention to challenge you, just genuinely curios if and why I should consider vue over agnular for new project (I use angular already).
maybe you would expand on this? I have no intention to challenge you, just genuinely curios if and why I should consider vue over agnular for new project (I use angular already).
Maybe Angular is still used a lot, in legacy projects. I just mean for starting a new project, imo most people will choose React or Vue in 2024, right? I never used Angular myself, but have used both React and Vue a lot.
If you’ve never used it don’t declare it dead. Angular is updated regularly every 6 months. While react is busy thinking how to create more SSR apis, the angular team keeps improving developer experience.
IMO right now it’s easier to start an angular project with much less foot guns than react.
IMO right now it’s easier to start an angular project with much less foot guns than react.
I call plenty of things dead without ever having used them. FORTRAN for example.
What I mean by dead is it's a VERY unlikely choice for any new app. People will choose React or Vue most of the time. You don't see Angular used hardly ever for a new project.
BTW: Vite is the new best way to manage the build pipeline, and makes React super easy to start using.
What I mean by dead is it's a VERY unlikely choice for any new app. People will choose React or Vue most of the time. You don't see Angular used hardly ever for a new project.
BTW: Vite is the new best way to manage the build pipeline, and makes React super easy to start using.
I’ve never used a drill press; does that make them dead?
Fortran certainly has its issues with portability and feature development, but it is by no means dead.
Fortran certainly has its issues with portability and feature development, but it is by no means dead.
As I already pointed out, my use of "dead" doesn't mean "no longer in use". It means no longer being selected by choice for a new project.
And your drill press example is agreeing with me, which is that, as I also already said myself, no one needs to have ever used something to be able to declare it dead, nor did I declare something dead because I don't personally use it. That's absurd.
And your drill press example is agreeing with me, which is that, as I also already said myself, no one needs to have ever used something to be able to declare it dead, nor did I declare something dead because I don't personally use it. That's absurd.
I don't have strong insights about current agnular popularity. I think at least teams/companies which built strong expertise in angular will continue using it for new projects unless there is some big reason not to.
SO trends show that angular is more popular, while vue is loosing share (not necessary absolute number): https://trends.stackoverflow.co/?tags=angular,vue.js,reactjs
SO trends show that angular is more popular, while vue is loosing share (not necessary absolute number): https://trends.stackoverflow.co/?tags=angular,vue.js,reactjs
Thanks for sharing that graph. It does show React as the leader, the the others in distant 2nd/3rd place.
However I think the "drop off" in the chart for React is misleading/incorrect, and likely indicates just a slowing down of the economy and/or people moving to LLMs for their searches and abandoning StackOverflow completely, as I have.
For the past year I haven't yet found a question that an LLM couldn't answer better than S.O. could, although ironically most of the LLM learning did come from S.O.
Anyway, yeah shops will stick to their legacy code forever unless something forces change, because retooling is super expensive in money and time, not to mention replacing all your developers with different ones!
However I think the "drop off" in the chart for React is misleading/incorrect, and likely indicates just a slowing down of the economy and/or people moving to LLMs for their searches and abandoning StackOverflow completely, as I have.
For the past year I haven't yet found a question that an LLM couldn't answer better than S.O. could, although ironically most of the LLM learning did come from S.O.
Anyway, yeah shops will stick to their legacy code forever unless something forces change, because retooling is super expensive in money and time, not to mention replacing all your developers with different ones!
Same, anGLuar sounds, for a french speaker, like https://en.wiktionary.org/wiki/engluer
1. to birdlime
2. (reflexive) to get bogged down
1. to birdlime
2. (reflexive) to get bogged down
In case I was unclear, I consider French dead and obsolete.
WordPress relies on server-generated HTML and its admin interface is a fairly complex "app", especially once you factor in the plugin ecosystem. According to [1], it's used on 43.7% of all public websites.
[1] https://w3techs.com/technologies/details/cm-wordpress
[1] https://w3techs.com/technologies/details/cm-wordpress
It’s been a while since I worked with WordPress, but isn’t their Gutenberg editor (which is the heart of their CMS) built on React? So while React may not be used on the user facing side, it is still powering the content side of WordPress and in a way, powering all of those sites.
If every user input causes a page refresh, that's not an "app" that's a "website". If you don't have any executable code (i.e. Javascript), but just form submits, yeah I agree that's what most of the web is, and as you pointed out most of the web is websites not web apps.
Have you explored cross-document view transitions? Would you classify something that uses those as an app or a site?
https://developer.chrome.com/docs/web-platform/view-transiti...
https://developer.chrome.com/docs/web-platform/view-transiti...
I'm not saying my own definition of "app" is the only correct definition, but in my opinion only if I do a click and something on the SAME page changes, then it's an app. Transitioning to different pages isn't an app, imo.
With this browser feature a navigation to a new page can look like only part of the page changes - without needing any JavaScript.
> can look like
Yeah, but it ain't. lol.
Yeah, but it ain't. lol.
It's easy for developers to forget who the "app" is actually for.
Users don't care how it was implemented or how nice the code looks, they just want it to work.
Users don't care how it was implemented or how nice the code looks, they just want it to work.
Right. That's precisely why full page reloads/updates every time some action is done (mouse click for example) would be completely unacceptable for most apps I've worked on. I've worked mostly on apps not websites.
The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue.
By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?
I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.
SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.
By your measure though, it sounds as though you'd be fine if these page loads in the javascriptless world were done in iframes, since then only some portion of the site is being reloaded?
I'm using that to illustrate the argument is absurd and the basis on which it is made seems also absurd.
SPAs are heavy and frequently written poorly, often eschewing the principles of loading only the bare minimum for a kitchen-sink approach. If you view the web as having only those two options to accomplish "real work" then yeah, you're gonna thing that SPAs are the only way. It's not reality though.
Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.
I think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity.
Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.
Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.
> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed
In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.
It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem.
It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs already.
That's actually rather new so we shall see how frontend practice reacts. I've only seen a few instances of it out in the wild so far.
Ha and jquery was pretty high too. How is that an argument?
I'll happily ditch React once something better emerges. I've been doing web development since 1998, so I'm used to change.
You can't be more wrong. You're saying that only logic performed on the client side can be considered an application? State can be stored in the server. Screen changes can be done by loading html, it doesn't need a framework. React is far from crucial for web development, but people haven't learned anything else the last decade. Most front end developers these days don't even know what a template engine is, and some don't even know how to create a website without a backend rest api that spews json data.
I wasn't comparing SSR to non-SSR (Server Side Rendering). As long as you can refresh portions of a webpage (or states of GUI elements), after a user action (button click or whatever), that's fine.
However the reason my Dialog Boxes open in a millisecond, and close in a millisecond too, is because I choose to render them locally. I'm not against SSR tho, as a viable concept. That's a different complex discussion where there are trade-offs to consider.
However the reason my Dialog Boxes open in a millisecond, and close in a millisecond too, is because I choose to render them locally. I'm not against SSR tho, as a viable concept. That's a different complex discussion where there are trade-offs to consider.
Popularity is not an argument for merit. Diabetes and heart disease are popular. Taylor Swift is popular. It doesn't follow that I should desire these things.
If appeals to the status quo were reasonable arguments, there would be no room to improve on what is.
https://en.wikipedia.org/wiki/Argumentum_ad_populum
If appeals to the status quo were reasonable arguments, there would be no room to improve on what is.
https://en.wikipedia.org/wiki/Argumentum_ad_populum
Popular is not a synonym for "common", like you're implying it is. They're different things. Popular means desired.
The more popular a piece of software is, the more likely it is to have had the bugs worked out of it, the more people there are reporting issues, the more answers there are on StackOverflow, the more likely AI/LLMs are to be able to answer questions, the more secure it's likely to be, the more stuff interoperates with it, etc. Popularity alone isn't a good reason to select something, but it's a good data point, with which so judge viability.
The more popular a piece of software is, the more likely it is to have had the bugs worked out of it, the more people there are reporting issues, the more answers there are on StackOverflow, the more likely AI/LLMs are to be able to answer questions, the more secure it's likely to be, the more stuff interoperates with it, etc. Popularity alone isn't a good reason to select something, but it's a good data point, with which so judge viability.
I think almost any technology gets to the "this is stupid" point. Not it "was" stupid, but it is. We understand something so well, we know that despite being useful it is fundamentally flawed. This is not usually verbal knowing, but initially more from an intuition and understanding a pattern. I have used react, it was certainly a better choice than the alternatives. I like it. But it is now "stupid", at least for me. And why? Because my whole web paradigm has been changed by "mobile first". What is mobile, and here I am talking iPhone and "good" Android? It is a good processor with tiny screen and really good graphics processor. You can run pretty good games on many/most phones. So why not use that 3D technology instead of html, css? Or at least in addition to. If you play around for react-three/{fiber,drei} for a little bit it feels like you have burst out of a straitjacket.
I once was told to make a product "cool" and after struggling to understand what "cool" even meant, I came to an idea. Things are cool if they make it so you never see the world the same way again. react-three/{drei,fiber} and threejs are cool. [For example https://r3f.docs.pmnd.rs/getting-started/examples]
I once was told to make a product "cool" and after struggling to understand what "cool" even meant, I came to an idea. Things are cool if they make it so you never see the world the same way again. react-three/{drei,fiber} and threejs are cool. [For example https://r3f.docs.pmnd.rs/getting-started/examples]
These are cool demos, I agree, and they definitely show a glimpse of what the future of the web could look like. Right now though, pretty much all of them take ages to load, then spin my fans up as they run at low fps. And this is on a dev laptop, can't imagine what they're like on mobile or an older device.
My iPhone 12 just crash the page while loading
This keeps coming up here:
"It isn't React, just those specific implementations"
Perhaps it is React, JS ecosystems and overbloated frameworks generally. These tools provide abundant footguns.
"It isn't React, just those specific implementations"
Perhaps it is React, JS ecosystems and overbloated frameworks generally. These tools provide abundant footguns.
I'm trying to build server rendered websites, but I find React (or other SPA-API systems) hard to resist:
- Form is hard. Doing it in backend make it even harder when the form is complicated. For example, a form with tab needs JS to operate and you need to signal the JS which tab the error is.
- If you're using backend form framework, you don't have control over the HTML unless you learn the hook points of it (do you add attribute in code, or in template? Where is the default template to override?) Compared to frontend framework where you can paste the CSS framework's example HTML.
- I wanted to build a new user wizard, which should be easy with a frontend framework as you can easily store incomplete state in memory. If not using JavaScript one would have to store the state in the untyped session variables, add hooks cluttering the HTML template, etc.
- Progressive enhancement is easier when you have to write the code only once. If there's a table and you want to refresh without refreshing the page, in React you just call the data fetcher again. In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint. If you're using jQuery you might as well write the table loop twice in the backend template engine and in jQuery.
- I haven't see any good backend framework (be it Django, Laravel, Symfony, Gin) that has similar server-rendered frontend component like React. Many frameworks believed that logic should be precomputed in the view layer and the template engine should not be turing-complete.
I was thinking about moving to SSR-rendered SPA, but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code.
- Form is hard. Doing it in backend make it even harder when the form is complicated. For example, a form with tab needs JS to operate and you need to signal the JS which tab the error is.
- If you're using backend form framework, you don't have control over the HTML unless you learn the hook points of it (do you add attribute in code, or in template? Where is the default template to override?) Compared to frontend framework where you can paste the CSS framework's example HTML.
- I wanted to build a new user wizard, which should be easy with a frontend framework as you can easily store incomplete state in memory. If not using JavaScript one would have to store the state in the untyped session variables, add hooks cluttering the HTML template, etc.
- Progressive enhancement is easier when you have to write the code only once. If there's a table and you want to refresh without refreshing the page, in React you just call the data fetcher again. In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint. If you're using jQuery you might as well write the table loop twice in the backend template engine and in jQuery.
- I haven't see any good backend framework (be it Django, Laravel, Symfony, Gin) that has similar server-rendered frontend component like React. Many frameworks believed that logic should be precomputed in the view layer and the template engine should not be turing-complete.
I was thinking about moving to SSR-rendered SPA, but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code.
> a form with tab needs JS to operate
Yes, this use case is better solved client-side but even in an SSR app you can always use rich widgets/web components in React, Preact, Vue, Svelte, etc.
> I wanted to build a new user wizard
Use some JS component(s) or web component(s) as I pointed out earlier.
> In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint
See fragments:
https://htmx.org/essays/template-fragments/
> I haven't see any good backend framework that has similar server-rendered frontend component like React
Plenty of backend solutions give you SSR components that are composable and where you can colocate template with backend logic. See Razor pages in dotnet or Astro.
> but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code
I'm 99% certain SvelteKit and Remix allow you to do this.
Yes, this use case is better solved client-side but even in an SSR app you can always use rich widgets/web components in React, Preact, Vue, Svelte, etc.
> I wanted to build a new user wizard
Use some JS component(s) or web component(s) as I pointed out earlier.
> In HTMX your backend needs to have a "full render" endpoint and a "table only" render endpoint
See fragments:
https://htmx.org/essays/template-fragments/
> I haven't see any good backend framework that has similar server-rendered frontend component like React
Plenty of backend solutions give you SSR components that are composable and where you can colocate template with backend logic. See Razor pages in dotnet or Astro.
> but I know of no Next.js-style library for any frontend framework that actually allow form submission without JavaScript AND progressive enhancement with JavaScript using the same code
I'm 99% certain SvelteKit and Remix allow you to do this.
I've spent years slowly migrating a personal project from PHP to Scala/React, and I'm devastated if React is out-of-date already. The web tech treadmill is relentless!
Seems the author recommended HTMX as an alternative in a couple of scenarios including my own use case (https://caption.me).
I checked out HTMX. The canonical example on the homepage (https://htmx.org/) was a button where a click calls the server and the response contains HTML to replace the outerHTML of the button.
I must be missing something here. Is HTMX really suggesting muddying the back-end code with front end code? So, any changes to front- or back-end would have to be carefully managed to avoid breaking the other side?
Feels like PHP all over again!
Seems the author recommended HTMX as an alternative in a couple of scenarios including my own use case (https://caption.me).
I checked out HTMX. The canonical example on the homepage (https://htmx.org/) was a button where a click calls the server and the response contains HTML to replace the outerHTML of the button.
I must be missing something here. Is HTMX really suggesting muddying the back-end code with front end code? So, any changes to front- or back-end would have to be carefully managed to avoid breaking the other side?
Feels like PHP all over again!
yes, htmx is very much suggesting returning HTML rather than JSON from the server, and collapsing a layer of complexity in the process. this has turned out very well for some applications, dramatically lowering complexity:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify the application. You don't worry about "breaking the other side" because there is no other side: everything is hypermedia, in the original mode of the web
I don't think PHP has much to do with htmx: you can use PHP if you'd like on the server side, but you can use whatever server side technology you'd like to produce HTML. People are using Go, Java, Kotlin, Scala, Rust, Python, Lisp, etc. with it and it works fine. It's a generalization of hypermedia controls[1] (anchors and forms) and, like anchors and forms, has no opinion on what the server side looks like.
One piece of good news regarding htmx is that the API is not going to change dramatically in perpetuity, so there is no treadmill to keep up with.
[1] - https://dl.acm.org/doi/pdf/10.1145/3648188.3675127
https://htmx.org/essays/a-real-world-react-to-htmx-port/
looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify the application. You don't worry about "breaking the other side" because there is no other side: everything is hypermedia, in the original mode of the web
I don't think PHP has much to do with htmx: you can use PHP if you'd like on the server side, but you can use whatever server side technology you'd like to produce HTML. People are using Go, Java, Kotlin, Scala, Rust, Python, Lisp, etc. with it and it works fine. It's a generalization of hypermedia controls[1] (anchors and forms) and, like anchors and forms, has no opinion on what the server side looks like.
One piece of good news regarding htmx is that the API is not going to change dramatically in perpetuity, so there is no treadmill to keep up with.
[1] - https://dl.acm.org/doi/pdf/10.1145/3648188.3675127
As I understand it, HTMX front-end components aren't re-usable in the same way as ReactJS components.
HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end.
The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easily on the client side. That would affect the scalability and maintainability.
I'm not getting a sense of why HTMX would be better than a pure client/server approach. I have no attachment to "hypermedia," or any other concepts penned in the 1960s!
HTMX components are 1:1 coupled with back-end code. So if I try to build a complex UI with nested structures, I'm going to have to build a parallel structure in back end.
The back end will have to manage all state, so there will be round trips for everything and things in server side memory that could be managed easily on the client side. That would affect the scalability and maintainability.
I'm not getting a sense of why HTMX would be better than a pure client/server approach. I have no attachment to "hypermedia," or any other concepts penned in the 1960s!
I don't know what you mean by reusable: you can reuse anything you create on the server side via various techniques (e.g. template inclusion, or using something like JSX for SSR, etc.)
A complex UI with nested structures covers a lot of area: the DOM is fundamentally a complex UI with nested structures. I'd need more specific examples to say anything intelligent about it.
htmx certainly doesn't necessitate round-trips for everything. HTML itself doesn't (see detail elements and HTML5 form validations) and client-side scripting is perfectly compatible with htmx:
https://hypermedia.systems/client-side-scripting/
htmx is better than a pure client/server approach in some cases because it relies on the already-built hypermedia client, the browser. This can, in some cases, dramatically simplify & improve applications:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
(67% reduction in LoC, 96% reduction in dependencies, halved memory usage, 50% decrease in first load time)
Looking at your application, it appears to be amenable to the hypermedia approach, but I didn't do a deep dive on it. OTOH of course, if you are happy with the current approach I don't see any reason to move to hypermedia for its own sake.
A complex UI with nested structures covers a lot of area: the DOM is fundamentally a complex UI with nested structures. I'd need more specific examples to say anything intelligent about it.
htmx certainly doesn't necessitate round-trips for everything. HTML itself doesn't (see detail elements and HTML5 form validations) and client-side scripting is perfectly compatible with htmx:
https://hypermedia.systems/client-side-scripting/
htmx is better than a pure client/server approach in some cases because it relies on the already-built hypermedia client, the browser. This can, in some cases, dramatically simplify & improve applications:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
(67% reduction in LoC, 96% reduction in dependencies, halved memory usage, 50% decrease in first load time)
Looking at your application, it appears to be amenable to the hypermedia approach, but I didn't do a deep dive on it. OTOH of course, if you are happy with the current approach I don't see any reason to move to hypermedia for its own sake.
Interesting. Thanks for the details, and for the link to the React->htmx migration.
React is not even a framework, really. It is a great starting point for simpler sites. Honestly still one of the best solutions out there.
Why wouldn't simple HTML be a great starting point for simpler sites? What's it missing that React solves, in your opinion?
How do you define a framework if React is not one?
It is one of more clear examples of a framework:
- calls your code
- heavily affects how the code is written
- requires significant build configuration (could even be argued it is something more than a framework, but definitely not a library)
It is one of more clear examples of a framework:
- calls your code
- heavily affects how the code is written
- requires significant build configuration (could even be argued it is something more than a framework, but definitely not a library)
A framework is declarative. You declare what you want. Generally in a configuration file and you get an app.
A library does not impose any configuration. I don’t see any required configuration with React. You can use it wherever you want in your code as an addition.
My piece on that: https://datacadamia.com/code/design/library_vs_framework
A library does not impose any configuration. I don’t see any required configuration with React. You can use it wherever you want in your code as an addition.
My piece on that: https://datacadamia.com/code/design/library_vs_framework
Genuinely curious if you could point to some examples of actual "frameworks" by your definition then. Because from your description, Rails, Django, Laravel, Phoenix, Vue.js, and basically every other "framework" I've encountered aren't actually frameworks.
Completely agree. People regularly conflate react core libraries with stuff like next
So glad I work in an ecosystem that doesn't even support SSR.
I'm also glad that the local-first movement got some traction.
I'm also glad that the local-first movement got some traction.
"design for user needs, not organisational convenience"
If I've ever come close to something like a natural law in software development, it's Conway's law. Therefore, this strikes me as saying: Design your airplane according to what the pilot needs, not aerodynamics or gravity.
If I've ever come close to something like a natural law in software development, it's Conway's law. Therefore, this strikes me as saying: Design your airplane according to what the pilot needs, not aerodynamics or gravity.
My answer:
Something not JS, or even TS. So it has to compile to JS or WASM or both.
Rust is cool. Dioxus looks really promising. https://dioxuslabs.com/
Elm is great. Actually quite mature in my experience. (Sure there are talks about the development model and release cadence, but still...)
Same $LANG as on the backend, as many langs compile to JS and/or WASM nowadays. But then how do you feed the browser a DOM? You still need something: HTMX, or... React?
And if you squint your eyes, isn't Elm also doing the DOM-feeding in a React-like manner? (I dont know for Dioxus).
Possibly the idea of React is really good, just Elm has implemented nicer? (and provides a good story for how to structure the rest of the application: state-mgmt, API calling, etc.
Something not JS, or even TS. So it has to compile to JS or WASM or both.
Rust is cool. Dioxus looks really promising. https://dioxuslabs.com/
Elm is great. Actually quite mature in my experience. (Sure there are talks about the development model and release cadence, but still...)
Same $LANG as on the backend, as many langs compile to JS and/or WASM nowadays. But then how do you feed the browser a DOM? You still need something: HTMX, or... React?
And if you squint your eyes, isn't Elm also doing the DOM-feeding in a React-like manner? (I dont know for Dioxus).
Possibly the idea of React is really good, just Elm has implemented nicer? (and provides a good story for how to structure the rest of the application: state-mgmt, API calling, etc.
> Rust is cool. Dioxus looks really promising.
And Leptos: https://www.leptos.dev/
And Sycamore: https://sycamore.dev/
And Yew: https://yew.rs/
And Leptos: https://www.leptos.dev/
And Sycamore: https://sycamore.dev/
And Yew: https://yew.rs/
My preferred Technology for non-SSG Web Apps is Blazor + Vue [1]. Where Blazor's Enhanced Navigation still gives you SPA-like navigation without any heavy client state, no client-side routing, no client build tools, no large download bundles in SPAs, etc.
Blazor static rendering provides a great UX for rendering static content, Streaming Rendering is great for pages that needing to dynamically update and any pages requiring client interactivity I just progressively enhance Blazor's static content with Vue - avoiding any npm node_modules dependencies or client build tools.
[1] https://servicestack.net/posts/net8-best-blazor
Blazor static rendering provides a great UX for rendering static content, Streaming Rendering is great for pages that needing to dynamically update and any pages requiring client interactivity I just progressively enhance Blazor's static content with Vue - avoiding any npm node_modules dependencies or client build tools.
[1] https://servicestack.net/posts/net8-best-blazor
The overall landscape for developing applications is a mess but this article does not help much with clearing it up.
One reason for the mess seems to me is the coexistence of many paradigms for achieving similar functionality (for example you can draw many different boundaries between client and server).
Combine this with the many distinct use cases (form factors, application types etc.) and the various non-interoperable platforms and you have a serious combinatorial optimization problem.
Depending on what one wants to do there might be a sweet spot of the 80%/20% type. Alpine.js seems to one such, which if it was developed many years ago it may have saved a lot of wasted complexity.
One reason for the mess seems to me is the coexistence of many paradigms for achieving similar functionality (for example you can draw many different boundaries between client and server).
Combine this with the many distinct use cases (form factors, application types etc.) and the various non-interoperable platforms and you have a serious combinatorial optimization problem.
Depending on what one wants to do there might be a sweet spot of the 80%/20% type. Alpine.js seems to one such, which if it was developed many years ago it may have saved a lot of wasted complexity.
React does have a bunch of legacy baggage holding it back, definitely from a performance angle. But I think a major part of the issue is just the fact that React _is_ so popular, with that comes the inevitability that the majority of people using it aren’t all that experienced. It’s relatively easy to build a React app that performs pretty well if you prioritise performance, though not as easy as something say Svelte or Solid, but getting performance to be prioritised and rewarded is the real battle —- as mentioned in the article itself.
I created a serverless platform and some generic Web Components which let me build highly maintainable applications (which update in realtime) very quickly. It's more
versatile than just CRUD as it supports complex views and serverless querying capabilities including fast search with indexing.
Unfortunately, it seems essentially impossible to get get traction in my country so I'm unsure what to do with it. I use it for my own projects. See https://saasufy.com/
Unfortunately, it seems essentially impossible to get get traction in my country so I'm unsure what to do with it. I use it for my own projects. See https://saasufy.com/
> Frameworkism isn't delivering.
Correct. The reason is not the frameworks but the languages. What is needed is a much more high-level and feature-powerful language.
Just look at react. Passing down dependencies/values is a pain. So what did react do? It introduced contexts. Similar, other react addons try to solve this problem. But they all sacrifice type-safety in the process.
They simply cannot solve this problem; only a better language can. Typescript maybe could, but they restrict themselves to not generate code (or at least very limited, I think for enums they do it).
Without a change here, nothing can ever improve.
Correct. The reason is not the frameworks but the languages. What is needed is a much more high-level and feature-powerful language.
Just look at react. Passing down dependencies/values is a pain. So what did react do? It introduced contexts. Similar, other react addons try to solve this problem. But they all sacrifice type-safety in the process.
They simply cannot solve this problem; only a better language can. Typescript maybe could, but they restrict themselves to not generate code (or at least very limited, I think for enums they do it).
Without a change here, nothing can ever improve.
This is straight up not true. React state management is very flexible and requires you to think about what your problem is and the nature of state.
There is absolutely nothing preventing you from keeping those safety - I’m not sure what you mean by that.
The typescript type system is very advanced, maybe even too advanced! I disagree that more sophisticated languages are required.
There is absolutely nothing preventing you from keeping those safety - I’m not sure what you mean by that.
The typescript type system is very advanced, maybe even too advanced! I disagree that more sophisticated languages are required.
See what Peter Kelly wrote. For example.
The React team should have done their own language, rather than making it a framework/library. Then they could ensure the absence of side effects in rendering code, and had a better way of detecting updates. The knowledge about how to do this was already out there for many years before they started: https://en.wikipedia.org/wiki/Functional_reactive_programmin...
Yes, but if they did their own language it would have almost certainly died in obscurity.
React won because it solved a real pain point for a group of people, using the techniques they were already using... but better!
Having built large apps in angular, handlebars, and jquery... it was (and still is) a godsend for building highly interactive, stateful web applications.
I am deeply skeptical of some of the stuff that people are doing now wrt. putting backend logic into React components, but the fundamentals of React are still very reasonable to me.
React won because it solved a real pain point for a group of people, using the techniques they were already using... but better!
Having built large apps in angular, handlebars, and jquery... it was (and still is) a godsend for building highly interactive, stateful web applications.
I am deeply skeptical of some of the stuff that people are doing now wrt. putting backend logic into React components, but the fundamentals of React are still very reasonable to me.
Isn’t that ReScript?
https://rescript-lang.org/
https://rescript-lang.org/
That's exactly my point.
This new language.
Do you mean something that compiles down to JS like Typescript, Coffescript & Dart?
Or a language that compiles to WASM like C, C++ or Rust?
Doesn't matter, as long as the language directly supports the required features.
Don’t use state, except within a component.
I build all my react this way.
No prop drilling, no Redux, no context, no mobx no state.
If you need to communicate between components then send a document event.
Your react application will be dramatically more simple without state.
I build all my react this way.
No prop drilling, no Redux, no context, no mobx no state.
If you need to communicate between components then send a document event.
Your react application will be dramatically more simple without state.
In reality these few ms more do not hurt these companies. it is sad but true.
I think react native is always a better choice than tools like cordova while the best choice is native development. every time i use a cordova app it is painful and you just know something is off. react-native apps are a lot nearer to native experience. you can differ them if your really trying to though. but if your just want a good native ios and android app react-native is a good choice. and you can slowly learn native development from there and shift to native if you like.
I think react native is always a better choice than tools like cordova while the best choice is native development. every time i use a cordova app it is painful and you just know something is off. react-native apps are a lot nearer to native experience. you can differ them if your really trying to though. but if your just want a good native ios and android app react-native is a good choice. and you can slowly learn native development from there and shift to native if you like.
One of the under appreciated reason why spa took off is it exploits the lower cdn cost.
Things that generate html on the server side need to pay for the higher bandwidth costs that are hard to cache well.
In the other hand with spa, a well configured cdn can have a short ttl on index.html and cache the unique per deployment js bundles forever.
The only server bandwidth cost is the actual api data
Things that generate html on the server side need to pay for the higher bandwidth costs that are hard to cache well.
In the other hand with spa, a well configured cdn can have a short ttl on index.html and cache the unique per deployment js bundles forever.
The only server bandwidth cost is the actual api data
I don't think so. You can still generate a significant amount of your static HTML at build before pushing that to a CDN, and load dynamic content using JS; JAM Stack.
Once you get to the examples of different types of webpages, the author basically admits React (and SPAs in general) is likely appropriate for a bunch of application types. At that point the argument seems to boil down to "use a CMS and a simple frontend if user sessions are simple enough".
If not react(ive, of some flavor), which is appropriate for some things, then hypermedia, which is appropriate for a different but overlapping set of things:
https://htmx.org/essays/when-to-use-hypermedia/
https://htmx.org/essays/when-to-use-hypermedia/
React is not reactive. That's why it re-renders the whole vdom when you store state at root.
Surprised nobody has mentioned Electric Clojure yet, with client and serverside blocks nested in _one file_.
My answer to this is https://gridwhale.com.
GridWhale runs your code entirely on the server and then remotes the UI to the browser via a platform layer.
The advantage is that you can program a web app as if it were an old-style GUI app on a PC: your program has full and direct control over the UI. For example, imagine you need to disable a button due to permissions. In GridWhale, you just check the permissions and set .disabled = true on the control. This automatically propagates the setting to the UI. And because the .disabled property is on the server, it stays disabled even if you hack the client.
In contrast, with React or any framework-based UI, you need to write code in two places: on the server (at the API level) and on the client to show the proper UI. And if you're not careful, these two can get out of sync.
Of course, GridWhale is just a different trade-off. It works great for traditional business apps, but would not be appropriate for low-latency video games (at least not yet).
GridWhale runs your code entirely on the server and then remotes the UI to the browser via a platform layer.
The advantage is that you can program a web app as if it were an old-style GUI app on a PC: your program has full and direct control over the UI. For example, imagine you need to disable a button due to permissions. In GridWhale, you just check the permissions and set .disabled = true on the control. This automatically propagates the setting to the UI. And because the .disabled property is on the server, it stays disabled even if you hack the client.
In contrast, with React or any framework-based UI, you need to write code in two places: on the server (at the API level) and on the client to show the proper UI. And if you're not careful, these two can get out of sync.
Of course, GridWhale is just a different trade-off. It works great for traditional business apps, but would not be appropriate for low-latency video games (at least not yet).
> Frameworkism isn't delivering. The answer isn't a different tool, it's the courage to do engineering.
While frameworkism has bad sides, React (hooks) is bad in very unique and particular ways, sometimes switching a different tool is the answer.
While frameworkism has bad sides, React (hooks) is bad in very unique and particular ways, sometimes switching a different tool is the answer.
Most webapps would be dramatically improved if the developers were banned from using any JavaScript on the client side in the first version, and allowed only to apply progressive enhancements from there.
I wonder if the author would be interested in writing 'React the good parts' - i think some things are still good even if the whole is bad.
> if not React, then what?
TinyJS?! http://github.com/victorqribeiro/tinyjs
TinyJS?! http://github.com/victorqribeiro/tinyjs
I'm not a front-end developer by any stretch (though I did do web apps in the beginning), and I have to say, using GenAI and describing a web app to Claude or ChatGPT gets amazing results.
I'm inclined to think this is one of the areas that GenAI can massively reduce cost. Claude will even iterate wireframes (in React).
As for performance, that's not going to ever be a framework problem. That's a deployment and scaling and architecture problem.
I'm inclined to think this is one of the areas that GenAI can massively reduce cost. Claude will even iterate wireframes (in React).
As for performance, that's not going to ever be a framework problem. That's a deployment and scaling and architecture problem.
It's the JavaScript, stupid. The world needs to move on already from this horrible thing into which we've invested gazillions of development hours and unfathomable amount of money. It's a non-deterministic crap that should have been replaced so freaking long time ago that we're now paying the price for being lazy and sticking with a bad thing instead of moving forward.
Here's proof that you don't need a big fat framework: Take a look at this SPA app: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
It is well architected, yet only uses a 500-line component lib and a 500-line router.
It is well architected, yet only uses a 500-line component lib and a 500-line router.
writing your own goddamn javascript and not being a failure nobody wants in this industry
the irony is that the website javascript/css is broken atm
Well, LiveView is great
Everytime I see a question like this, the answer is mobx.
React also gives you React Native, that's why.
Creating an interactive UI with rapid development is a fundamentally difficult problem. Its no wonder that people spend billions on creating UI (collectively) and I haven't any good ones yet (performant, interactive, efficient).
Why not just drop the requirement altogether? All I want is an internet of links, images and texts? Whats so wrong with Facebook that looks like this website? Just a bunch of links and texts.
I don't give a shit if the button is a square or round. Why do you get to decide what is "best" for me anyway? Let the web be the web and the user decide how to present them.
Why not just drop the requirement altogether? All I want is an internet of links, images and texts? Whats so wrong with Facebook that looks like this website? Just a bunch of links and texts.
I don't give a shit if the button is a square or round. Why do you get to decide what is "best" for me anyway? Let the web be the web and the user decide how to present them.
“Think, do, observe” — that’s over?
I hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’re using it wrong; You’re a not as smart as me; I drew you as the Soyjak and me as the Chad. Please won’t somebody tell me that I’m cutting edge?!
I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!”
JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since.
Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test!
It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read.
There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement.
It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.
I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!”
JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since.
Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test!
It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read.
There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement.
It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.
I generally agree (that the React isn't the main culprit), but what does Tailwind have to do with templating? It's still just CSS classes, but with specific names. Also, I bet you could have strongly typed class name strings using TypeScript's template literal type somehow.
The gist is something like a new cohort of front-end developers and some begrudging back-end folks who never actually learned how anything worked are now trying to inscribe their influence as the new smart people with tools like Tailwind and HTMX.
Wanting to prove yourself isn’t a problem. It’s actually a sign that a developer is starting to form their own opinions. But it becomes toxic when the primary motivation comes from a desire to appear smart instead of actually solving a problem.
You’re absolutely right about typed classes and that’s how React Native does it. Writing and debugging CSS is hard for many of the same reasons that string-based templates exhibit. IMO the developers who push Tailwind are looking through the wrong end of the telescope. CSS is challenging because it’s a combination of declarative aesthetic UI and imperative state management. Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system. Modern CSS is pretty great and learning how it works pays endless dividends.
Wanting to prove yourself isn’t a problem. It’s actually a sign that a developer is starting to form their own opinions. But it becomes toxic when the primary motivation comes from a desire to appear smart instead of actually solving a problem.
You’re absolutely right about typed classes and that’s how React Native does it. Writing and debugging CSS is hard for many of the same reasons that string-based templates exhibit. IMO the developers who push Tailwind are looking through the wrong end of the telescope. CSS is challenging because it’s a combination of declarative aesthetic UI and imperative state management. Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system. Modern CSS is pretty great and learning how it works pays endless dividends.
> Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system.
I think you maybe don't understand what Tailwind actually does. The only abstraction is its "language" that is used to generate the list of class names you can then use to style elements, but that's not really an abstraction, because in the end it's not that different from using something like BEM and then having to remember project-specific classes. But with Tailwind, it's not specific to a single project. And you always have to understand CSS and how it works anyway.
I think you maybe don't understand what Tailwind actually does. The only abstraction is its "language" that is used to generate the list of class names you can then use to style elements, but that's not really an abstraction, because in the end it's not that different from using something like BEM and then having to remember project-specific classes. But with Tailwind, it's not specific to a single project. And you always have to understand CSS and how it works anyway.
> Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists
I couldn't agree more with this. Components and TSX are a much nicer way to build UI trees, even on the backend.
I couldn't agree more with this. Components and TSX are a much nicer way to build UI trees, even on the backend.
If not React, then Elm!
There's a lot to like about Elm, but the tradeoff is that the BDFL (Evan) has essentially abandoned public work on it [0, 1], and the community seems to be shrinking [2].
I personally wouldn't choose it for new projects, and I consider it essentially a brilliant research language (it's inspired a LOT of other UI work).
0: https://elmcraft.org/lore/elm-core-development/
1: https://podcasts.apple.com/us/podcast/elm-the-future-of-open...
2: https://reasonableapproximation.net/2024/11/02/elm-community...
I personally wouldn't choose it for new projects, and I consider it essentially a brilliant research language (it's inspired a LOT of other UI work).
0: https://elmcraft.org/lore/elm-core-development/
1: https://podcasts.apple.com/us/podcast/elm-the-future-of-open...
2: https://reasonableapproximation.net/2024/11/02/elm-community...
If I needed to build a Single Page Application, personally, Elm is the only tech I would use.
Rails? SSR?
solidJS?
then anything else?
React is not slow. React is not "big". React is not the reason your website is slow.
Any engineer who thinks that its React that is causing the slow renders and replacing it with X is deluded. Yes, there are ways to make slow React web apps. But there are also ways to make fast React web apps. It just requires effort and a little bit of foresight.
Any engineer who thinks that its React that is causing the slow renders and replacing it with X is deluded. Yes, there are ways to make slow React web apps. But there are also ways to make fast React web apps. It just requires effort and a little bit of foresight.
In my travels I have found React to be, generally, a poor choice for most applications - particularly in projects that have contributions from many developers with varying levels of experience.
While it _can_ be super fast, in practice, it requires quite advanced knowledge of React-isms to get it there. Those React-isms require more code with increasing complexity, combine that with contributions from developers that have varying levels of experience and you end up with spaghetti code.
Consequently, I have yet to walk into a new role where the React code isn't a dumpster fire.
In a way, React feels very much like writing raw C - it has a lot of power to be fast but most developers aren't as smart as you (joking, sarcasm) so unless you're the only contributor; you're better off using a higher level language with fewer footguns.
Modern Angular, for instance, is amazingly ergonomic and the opinionated approach makes it difficult to drag the project too far down the unmaintainable rabbit hole. The compiler handles optimizations for you so you don't need to worry about render cycles or how a functional component loops around - making it friendly (in theory) to developers with varying levels of experience.
These ergonomics fall apart when developers try to make Angular projects "React-y" with tools like ngrx but for me; the biggest downside is that you have no control over the tooling (test runner, TypeScript version, bundler, etc). That is the only reason I avoid it in personal projects.
Svelte and Vue on the other hand suffer from similar problems in that they are fantastically ergonomic, but use custom file formats with bespoke compilers that are difficult to integrate with other established tools (TypeScript, linting, formatting, testing).
One thing that saddens me is that toolmakers (specifically TypeScript) sleep on opportunities to have much better front end frameworks because they don't provide the capability to extend the LSP and transpiler.
For instance the inclusion of Rust-like compiler macros in TypeScript could enable projects like Vue, Svelte and Angular to integrate directly into the language without the need for bespoke compilers and adapters to connect to tooling.
That way, much like how TypeScript has a built in compiler for JSX, Vue could integrate their template compiler within TypeScript rather than using external tooling that targets .vue files - example:
So ultimately, while React isn't really a great choice for web applications, it's attained a jquery-like status where it's not really good but the alternatives are worse so you kinda have to use it.
While it _can_ be super fast, in practice, it requires quite advanced knowledge of React-isms to get it there. Those React-isms require more code with increasing complexity, combine that with contributions from developers that have varying levels of experience and you end up with spaghetti code.
Consequently, I have yet to walk into a new role where the React code isn't a dumpster fire.
In a way, React feels very much like writing raw C - it has a lot of power to be fast but most developers aren't as smart as you (joking, sarcasm) so unless you're the only contributor; you're better off using a higher level language with fewer footguns.
Modern Angular, for instance, is amazingly ergonomic and the opinionated approach makes it difficult to drag the project too far down the unmaintainable rabbit hole. The compiler handles optimizations for you so you don't need to worry about render cycles or how a functional component loops around - making it friendly (in theory) to developers with varying levels of experience.
These ergonomics fall apart when developers try to make Angular projects "React-y" with tools like ngrx but for me; the biggest downside is that you have no control over the tooling (test runner, TypeScript version, bundler, etc). That is the only reason I avoid it in personal projects.
Svelte and Vue on the other hand suffer from similar problems in that they are fantastically ergonomic, but use custom file formats with bespoke compilers that are difficult to integrate with other established tools (TypeScript, linting, formatting, testing).
One thing that saddens me is that toolmakers (specifically TypeScript) sleep on opportunities to have much better front end frameworks because they don't provide the capability to extend the LSP and transpiler.
For instance the inclusion of Rust-like compiler macros in TypeScript could enable projects like Vue, Svelte and Angular to integrate directly into the language without the need for bespoke compilers and adapters to connect to tooling.
That way, much like how TypeScript has a built in compiler for JSX, Vue could integrate their template compiler within TypeScript rather than using external tooling that targets .vue files - example:
export const HelloComponent = {
tag: 'app-hello',
template: vue!(<div>Hello {{name}})</div>),
data: () => ({
name: "World"
})
}
class AppComponent {
static tag = 'app-component'
static template = angular!(<div>Hello {{ name }}</div>)
#[model]
name = 'world'
}
So ultimately, while React isn't really a great choice for web applications, it's attained a jquery-like status where it's not really good but the alternatives are worse so you kinda have to use it.
ah yes, the guy that does the 'real' engineering,
and then I'm hired to rewrite that 'engineering' to a normal modern framework
*Blazor enters the chat*
I read through this to hopefully save all of you the clickbait and mid-way through nonsensical philosophical diatribe. It's a bit ranty and devoid of technically-caloric content.
The author is advocating for use of plain HTML/SSR patterns and avoiding SPAs and complicated frameworks/libraries ala Angular/React/etc. It's an old thought that lines up with the "you don't need JS" crowd.
Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
You can read it that way if you ignore the rest of the article, I guess. They simply are saying many (most?) sites do not need to be SPAs and the baggage that entails with load times and latency. Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.
In most cases later frameworks are slow and bulky. I certainly hate using sites like X or Target on mobile. Random delayed loading of things, loss of scrolling position when going back, things just not loading the first time it delayed reactions. It sucks.
In most cases later frameworks are slow and bulky. I certainly hate using sites like X or Target on mobile. Random delayed loading of things, loss of scrolling position when going back, things just not loading the first time it delayed reactions. It sucks.
Nah, the rest of the article is not insightful either.
eg React Native is dismissed in 5 sentences, with no real solution at all given to the basic problem of wanting to have a website and mobile apps without writing your app 3 times. Let alone a website + mobile apps + windows + mac clients. The suggested solutions do not address this need -- eg there's some Apache crap that no one I've heard of uses (it's renamed Adobe Phonegap crap that Adobe bailed on and tossed over to Apache); some random link to a 5 year old google i/o presentation; etc.
As far as I know, there's basically 3 toolkits that offer this: React + derivates; Rails with Hotwire; and Flutter, which means trusting Google (fools only), and which has recently deprioritized desktop... so that's a rock solid foundation to pour millions of dollars of eng time into. And I guess Xamarin, if anyone is using that.
eg React Native is dismissed in 5 sentences, with no real solution at all given to the basic problem of wanting to have a website and mobile apps without writing your app 3 times. Let alone a website + mobile apps + windows + mac clients. The suggested solutions do not address this need -- eg there's some Apache crap that no one I've heard of uses (it's renamed Adobe Phonegap crap that Adobe bailed on and tossed over to Apache); some random link to a 5 year old google i/o presentation; etc.
As far as I know, there's basically 3 toolkits that offer this: React + derivates; Rails with Hotwire; and Flutter, which means trusting Google (fools only), and which has recently deprioritized desktop... so that's a rock solid foundation to pour millions of dollars of eng time into. And I guess Xamarin, if anyone is using that.
I think sadly to that point there’s no solution given because there isn’t one. And the ones that promise it (RN) still has you doing tons of platform specific code and in some cases supporting even more platforms than just going native.
I've been at orgs that wrote 3x apps and at orgs that shipped via RN. RN was a significantly superior choice ime. While yes, it wasn't 100% write once, it was pretty good and also avoided some of the ugly single-platform-only bugs I experienced at choice one, eg in core data libs (subtly different validations on data), that made the write 3 apps strategy be more like 4x work.
As for the article, honesty probably would have just had the author write something like: "RN: an unfortunate but maybe your best choice in these circumstances" instead of pretending there's serious alternatives eg the Apache garbage dump.
As for the article, honesty probably would have just had the author write something like: "RN: an unfortunate but maybe your best choice in these circumstances" instead of pretending there's serious alternatives eg the Apache garbage dump.
> Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.
This is how you end up with an amalgam of legacy crap that no one wants to touch. I can’t read guarantee you that outside of big tech and a couple of unicorns started by experienced devs this will NEVER work reliably.
This is how you end up with an amalgam of legacy crap that no one wants to touch. I can’t read guarantee you that outside of big tech and a couple of unicorns started by experienced devs this will NEVER work reliably.
React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have.
The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks.
Before anyone mentions Custom Elements and Web Components, I must say I tried it. Gave it a lot of effort to be a solution but it is not!
The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks.
Before anyone mentions Custom Elements and Web Components, I must say I tried it. Gave it a lot of effort to be a solution but it is not!
"React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have."
That's covered in this section: https://infrequently.org/2024/11/if-not-react-then-what/#%22...
"The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks."
That's covered here: https://infrequently.org/2024/11/if-not-react-then-what/#%22...
That's covered in this section: https://infrequently.org/2024/11/if-not-react-then-what/#%22...
"The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks."
That's covered here: https://infrequently.org/2024/11/if-not-react-then-what/#%22...
I think people prefer ecosystem with many resourceful components
https://github.com/brillout/awesome-react-components
This point is not directly covered in the article.
https://github.com/brillout/awesome-react-components
This point is not directly covered in the article.
Heartily concur. It's a classic of an essay written by one of those tortured souls who cannot understand why everyone so blithely moves past the incisive, obvious, truths they share.
With a topping of how this is all just solved by "giving a toss about the user", followed by a cloying apology for being vulgar
I'm not in web and am amenable to a good web dev hot take but this simply isn't worth the time, it's an array of generic wisdom delivered as if it's specific, written with the effort of someone who is proud of themselves when you disagree.
With a topping of how this is all just solved by "giving a toss about the user", followed by a cloying apology for being vulgar
I'm not in web and am amenable to a good web dev hot take but this simply isn't worth the time, it's an array of generic wisdom delivered as if it's specific, written with the effort of someone who is proud of themselves when you disagree.
I mean the graph in the article of Amazon vs Target vs Wayfair is pretty damning. And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.
Yep! Made me remember my bad target experiences as well. Love how that’s all ignored by some.
> And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.
I was not able to notice any difference between them
I was not able to notice any difference between them
Were you using a ~$2000 laptop on a broadband connection?
Out of curiosity I checked on iPhone 14/4g and 2018 Intel MBP.
I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?
I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?
Alex's position is that the average consumer is on a cheap Android phone, which has severe CPU weaknesses compared to any iPhone from the last ~five years: https://infrequently.org/2024/01/performance-inequality-gap-...
Software engineers tend not to experience the web on the same class of device as most of their users.
Software engineers tend not to experience the web on the same class of device as most of their users.
But is the average Target shopper on a cheap Android phone accessing over non-broadband? Wayfair?
It's a fair point to note devs and users might have different devices, but in some cases they don't and the decision to use React might be well-founded with that fact.
It's a fair point to note devs and users might have different devices, but in some cases they don't and the decision to use React might be well-founded with that fact.
Do you not care about most of your potential customers, or do you only cater to high net worth people? If so, then sure, substandard devices and connections can be ignored. If you’re Target, on the other hand, you probably shouldn’t ignore them.
I find it extremely odd that this was even a question on this site. Do you think the problem you’re solving should impact your tech stack at all, or is your tech stack more important than the problem?
I find it extremely odd that this was even a question on this site. Do you think the problem you’re solving should impact your tech stack at all, or is your tech stack more important than the problem?
You're making the same mistake as the author. I get unnecessarily aggro too, but a plain reading of their comment isn't "they only cater to high net worth people" or they're advocating for such. Its "hey we're talking about 3G connections at this point, which are mostly shut down, and we don't cover developing markets"
Note most of this is nonsensical too.
His primary thing is "you don't need client side code because JS = (HTML + CSS) * x, where X >= 1"
We can start sneering about not caring about users there, too, having a one time client side download of that magnitude can certainly be much better on the poors than 10 page loads with SSR.
Note most of this is nonsensical too.
His primary thing is "you don't need client side code because JS = (HTML + CSS) * x, where X >= 1"
We can start sneering about not caring about users there, too, having a one time client side download of that magnitude can certainly be much better on the poors than 10 page loads with SSR.
I keep hearing the "SPA is actually lightweight" argument but it's never materialized for me, the fastest sites are SSRs that are mostly static. The saving from HTML vs JSON just isn't that much over the wire and mobile CPUs and memory are a bottleneck.
I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.
I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.
> "SPA is actually lightweight"
With utmost respect, that's not what I'm saying :)
I hold no hot take position on anything web dev, or any firm declarative position.
What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.
This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.
With utmost respect, that's not what I'm saying :)
I hold no hot take position on anything web dev, or any firm declarative position.
What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.
This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.
And it doesn’t even have to be that. Just someone at the wrong end from a cell phone tower or in a clogged one from a sports event or something.
o7 thanks, people like this who do not work in contexts with problems that React solves yet insist React is not solving problems are profoundly boring.
I spent a lot of time working on react applications of one kind or another and I think most businesses don’t have “problems that React solves” for their frontends. Somewhere that’s actually an application might, but most line of business applications would be better as something like Rails views rather than React
> I think most businesses don’t have “problems that React solves” for their frontends.
that is neither here nor there. you are replying to an article whose thrust is that react ought never be used.
> Somewhere that’s actually an application might
might, lol? wait are you the author?
> most line of business applications would be better as something like Rails views rather than React
why?
that is neither here nor there. you are replying to an article whose thrust is that react ought never be used.
> Somewhere that’s actually an application might
might, lol? wait are you the author?
> most line of business applications would be better as something like Rails views rather than React
why?
Because, for most business applications I've worked on, React just complicates the frontend code compared to serving up simple HTML views and for no real benefit aside from "using React"
No need for personal attacks.
And there's also the other side: people who insist in overusing React. Perhaps that's what the author refers to.
I for one have see HTMX eat React for breakfast in a few of my clients during consulting.
And there's also the other side: people who insist in overusing React. Perhaps that's what the author refers to.
I for one have see HTMX eat React for breakfast in a few of my clients during consulting.
Really? HTMX for me brings spaghetti code on the server side. Fine for small projects but not so for large ones. I would prefer the clear separation between frontend and backend beyond small scale projects.
React does not create a clear separation. Anyone who claims that hasn’t worked on any react bigger than a todo list.
If you struggle with backend code then you’re just not a good backend developer. Maybe just stick to HTML/CSS.
If you struggle with backend code then you’re just not a good backend developer. Maybe just stick to HTML/CSS.
> I for one have see HTMX eat React for breakfast in a few of my clients during consulting.
What about the rest of them?
What about the rest of them?
[deleted]
[deleted]
[deleted]
Aeolun(1)
What a load of dung.
[deleted]
The only sure cure for the JavaScript blues is WebAssembly.
Use something like Leptos and be happy:
https://www.leptos.dev/
Use something like Leptos and be happy:
https://www.leptos.dev/
Leptos is even worse than React in memory consumption and startup metrics.
https://krausest.github.io/js-framework-benchmark/current.ht...
https://krausest.github.io/js-framework-benchmark/current.ht...
But faster overall, one code base front and back, and it will only improve as new WebAssembly features roll out (js-string-builtins, Memory64, eventually component model DOM access).
And any high performance functions you need on the front end will be higher performance than JavaScript. Like bloom filters for example: https://nuenki.app/blog/bloom_filters_optimisation
And any high performance functions you need on the front end will be higher performance than JavaScript. Like bloom filters for example: https://nuenki.app/blog/bloom_filters_optimisation
> But faster overall
Only in further updates to the DOM. There are very few use cases where you need to continually update thousands of DOM elements.
For most use cases, start up time and memory usage are really the most important metric.
Only in further updates to the DOM. There are very few use cases where you need to continually update thousands of DOM elements.
For most use cases, start up time and memory usage are really the most important metric.
WebAssembly can't do anything without Javascript. You're still using the same annoying Web APIs with another layer of indirection between. Plus, now you're using the slow Rust compiler so your iteration times are going to suffer. We already have type-safety in Typescript. We don't have to care about lifetimes, either.
> WebAssembly can't do anything without Javascript.
But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.
But it's JavaScript glue code generated by Rust's wasm-bindgen that you don't need to care about. And eventually the glue code will be unnecessary with wasm component model DOM access.
Agree that WASM cannot yet directly manipulate the DOM. But are build times in JS/TS framework world any slower than Rust compile times? I'm not convinced on this point.
As a disclaimer, I still prefer vanilla JS and progressive enhancement.
As a disclaimer, I still prefer vanilla JS and progressive enhancement.
TS is very fast with esbuild and the likes, it's basically just stripping off the type annotations. Your setup may vary, of course.
The other point isn't so much that there's a wrapper around the DOM, but that the DOM API itself is bad and slow. There's only so much pain a better language can take away here, and Rust isn't even a better language for that domain.
The other point isn't so much that there's a wrapper around the DOM, but that the DOM API itself is bad and slow. There's only so much pain a better language can take away here, and Rust isn't even a better language for that domain.
One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend.
The second reason the author says is that it’s based on a legacy eventing system which supports IE. The author goes on for quite a while to say how bad this is, but I question the assumption it’s predicated on: the legacy eventing system never bothers me, and it doesn’t create issues visible to my users. As far as it seems to me, this argument is akin to saying that React hasn’t bothered refactoring an old part of the code base. Yes, that’s not great, but it hardly strikes me as a reason to drop a framework entirely.
Finally, the author doesn’t actually give a prescription as to what to use instead of React. This is, personally, where the argument really falls apart. React does make a set of tradeoffs, I don’t deny that, but most alternatives I’ve seen make a worse set of tradeoffs that shift more work onto the engineer. Of course, since the author doesn’t actually highlight any alternative, we can’t have a discussion about what you’re trading away, but I suspect that the author makes no proposal because he knows that any alternative would immediately be shot down as obviously worse than React.