Funny enough. I’m opening this on mobile internet connection and it stuck at loading spinner. I don’t know if the problem is with my internet (probably not) or support for mobile so I can’t even read the content.
Most of my apps are now simply HTMX + Go + SQLite.
I've found it's enough for most projects.
But yes, lately I am building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage on the app without sign-up or involving a backend.
What can I do? So I was forced to switch to Flutter on Android, but I ran into another pain point: app updates sometimes spend a lot of time "under review," which is frustrating. For the same app, I maintain a web app that is very quick to update by comparison.
I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
It's still present. JSON/JS parsing still has a delay. And in either case (as the author states) not everyone is using an iPhone over 5G. Heavy React apps are a miserable experience on low end Android phones, even when the connection is fast. I've seen JS/JSON parsing times in the multiple seconds.
Read the article. Typical users had old browsers often with poor reception. One user was using a PlayStation Portable which had very limited WWW capability.
True. Crappy developers will build crappy websites irrespective of the tech.
The article is clearly aimed at non crappy developers or developers who want to do better for their users.
And it provides an anecdotal experience where an HTML first
option developed by a good developer was far superior to what a JS necessary option would have been, given the user base of this application.
It's definitely possible to make slow server-rendered website. Most of the slow client-side apps are slow because they're waiting on slow network requests.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
This is patently untrue, give a craftsman terrible tools, and they'll still produce a decent end result. That said, defaults matter, and astro is going to be significantly more friendly out-of-the-box to low-end clients
Not really, no. Astro requires you to opt a component in to client-side rendering, React (with its server components etc) require you to opt out. Defaults matter in scenarios like this and I'd bet the average developer of crappy websites would have a much faster site with Astro than React for that reason alone.
> this was a regulated monopoly, and if their customer satisfaction dropped below 96% (if I remember correctly) it could result in millions of pounds in fines.
OK, I'm still at the beginning and irrelevant to the article, but as a USA-ian, I am so jealous about that. Unheard of here.
Recently I had to migrate an old SpringBoot app that had a React front-end to a new cluster. Not wanting to mess with super-old dependencies, I opted to rewrite it on a new version of Java/SpringBoot. When it came to the frontend, I paused. I couldn't come up with a single good reason why this app needed React. I rewrote the frontend in straight HTML with a little bit of JavaScript for DOM manipulation. I literally used `var` instead of `let/const` just to drive the point home... (yes, that was overkill). But you know what I didn't need? A BUILD PROCESS! No npm deps. No vite/rsbuild/etc. It was like I had forgotten we could even DO that.
Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.
If you're a "React person", as the article puts it, friendly reminder that you can render components to HTML and serve that to the user.
I have done exactly that on a project that was under similar constraints. The UI models live in .tsx files and the browser gets pure HTML with zero JS by default.
The full context of that quote makes it clear that it's meant more as a wry joke:
> A venerable web application pattern that has had a small modern renaissance thanks to Remix, form submissions and redirects took a while to explain to my colleagues, on account of everyone being used to heavily client-side web applications.
(Although it's not really a joke, it's pretty amazing how many professional web developers these days don't know how to use forms without JavaScript.)
The opposite is why I'd never be a good web developer. I grew up messing around with PHP and if I spent the time to learn the modern stack, I'd constantly be thinking it's stupid.
I think the author is suggesting that Remix was the inspiration for the renaissance, not that it's necessarily the most popular method for doing so.
I'd be curious to see the stats on how often Next.js users lean into the server component model that makes the frontend fast. My anecdotal experience is that it's an afterthought for many. By comparison, Astro (as mentioned by the author) makes you think about this stuff upfront via opt-in rather than opt-out. It's a wonderful framework.
Maybe this is heretical in today's AI hype climate but...weirdly due to the rise of AI, then AI-slop polluting everything, a lot of old fundamentals are coming back. Clear, well-structured, descriptive content on a well-built page has a better shot of being picked up for SEO/AEO/whatever which are the same best practices from 2005. A lot of these tips and tricks and hacks just aren't going to move the needle as much anymore imo.
SEO and accessibility laws have always been the most effective way to convince someone to build clean, well-structured webpages. Guess what, both are measures of how easy it is for a machine to extract content from your pages. AI is just the latest machine that wants to slurp up your soup of tags.
I was a little confused by "doubled our users" since that's more about inbound traffic than site experience. I guess it's really shorthand for "halved form abandonment" which is still pretty great.
I think that's even more significant, since it's measuring people who cared enough to click the form in the first place, which is juicier than just page loads.
> In the most recent, contractors in another country had built a React app. The React app was online for 3 days before being pulled because of customer complaints. I took one look at it and told my boss “we can’t take ownership of this.” It was a mess of loading spinners and global javascript states. It was not accessible. Image upload was a vital part of the form, and it attempted to store images (along with all other form data) in localstorage which has a 5mb limit!
> contractors in another country
Sorry to spoil but the problem was not react. The problem was clearly this excerpt because we all know which country it was.
Idk, the general javascript spinner situation is beyond normalized at this point. I think mainly driven by React and other large/overkill JS frameworks. I avoid JS/TS heavy stuff so I don't really know but that's largely the impression I get. The whole thing reminds me of dialup era internet were we all were watching progressive JPGs load on a slow connection despite the fact I have fiber. I can't believe anyone is Ok with that UX, I don't see how any framework choice justifies introducing that type of behavior.
No we don't. There are lots of countries with software outsourcing industries, and contractors in any country can be good or bad. Would you rather have a top IIT graduate, or someone who took a year of programming classes at a community college in Fresno?
The counterargument: In Defence of the Single Page Application:
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
Funny enough. I’m opening this on mobile internet connection and it stuck at loading spinner. I don’t know if the problem is with my internet (probably not) or support for mobile so I can’t even read the content.
I think that's the joke :) all other articles load fine instantly, just this one that has a spinner
Heh it got me then :)
My guess it’s a joke.
it's a sarcasm loader
Sufficiently advanced parody is indistinguishable from reality.
All I got is a "loading" animation. Gave up after 10 seconds. So, not a counterargument, but a confirmation of the article's thesis.
It's a joke/sarcasm
lol this got me
Having been building websites since the mid 90's, I laugh at terms like "HTML-first website"
Most of my apps are now simply HTMX + Go + SQLite.
I've found it's enough for most projects.
But yes, lately I am building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage on the app without sign-up or involving a backend.
What can I do? So I was forced to switch to Flutter on Android, but I ran into another pain point: app updates sometimes spend a lot of time "under review," which is frustrating. For the same app, I maintain a web app that is very quick to update by comparison.
I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort.
I like how quickly you can update PWA app.
Empathy and respect for users is what product managers should be doing.
Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.
They don't know what a megabyte is
They feel the slowness of the page load
Not on their iPhones operating over 5G or the corporate WiFi.
It's still present. JSON/JS parsing still has a delay. And in either case (as the author states) not everyone is using an iPhone over 5G. Heavy React apps are a miserable experience on low end Android phones, even when the connection is fast. I've seen JS/JSON parsing times in the multiple seconds.
There's 5 bars 5G and there's one bar 5G anyway... Citing connection types really is completely beside the point.
You don't think there's any palpable difference as long as the connection is any good?
Read the article. Typical users had old browsers often with poor reception. One user was using a PlayStation Portable which had very limited WWW capability.
The person you are replying to is saying the PMs are using new phones on WiFi, not that the customers are.
"If our users can't afford the bits, we don't need them!"
People who built a crappy website using React are just as likely to build a crappy website using Astro, HTML-first approach or any other technology
True. Crappy developers will build crappy websites irrespective of the tech.
The article is clearly aimed at non crappy developers or developers who want to do better for their users.
And it provides an anecdotal experience where an HTML first option developed by a good developer was far superior to what a JS necessary option would have been, given the user base of this application.
At least it'll be a fast and crappy website.
It's definitely possible to make slow server-rendered website. Most of the slow client-side apps are slow because they're waiting on slow network requests.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
yeah, I love when shit loads immediately, so I'm not wasting seconds of my life just to see shit.
You can do a bad job with any tool but you cannot do a good job with any tool.
This is patently untrue, give a craftsman terrible tools, and they'll still produce a decent end result. That said, defaults matter, and astro is going to be significantly more friendly out-of-the-box to low-end clients
with this logic, why discuss any technology?
Not really, no. Astro requires you to opt a component in to client-side rendering, React (with its server components etc) require you to opt out. Defaults matter in scenarios like this and I'd bet the average developer of crappy websites would have a much faster site with Astro than React for that reason alone.
> this was a regulated monopoly, and if their customer satisfaction dropped below 96% (if I remember correctly) it could result in millions of pounds in fines.
OK, I'm still at the beginning and irrelevant to the article, but as a USA-ian, I am so jealous about that. Unheard of here.
Interesting they went with Astro.Makes sense for a form-heavy site. No JS until you need it,and it handles page transitions cleanly.
Recently I had to migrate an old SpringBoot app that had a React front-end to a new cluster. Not wanting to mess with super-old dependencies, I opted to rewrite it on a new version of Java/SpringBoot. When it came to the frontend, I paused. I couldn't come up with a single good reason why this app needed React. I rewrote the frontend in straight HTML with a little bit of JavaScript for DOM manipulation. I literally used `var` instead of `let/const` just to drive the point home... (yes, that was overkill). But you know what I didn't need? A BUILD PROCESS! No npm deps. No vite/rsbuild/etc. It was like I had forgotten we could even DO that.
Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.
If you're a "React person", as the article puts it, friendly reminder that you can render components to HTML and serve that to the user.
I have done exactly that on a project that was under similar constraints. The UI models live in .tsx files and the browser gets pure HTML with zero JS by default.
Designing for failure modes (bad network, old devices, no JS) often leads to better systems even in the happy path. This is a good case study of that.
Good post, but:
> A venerable web application pattern that has had a small modern renaissance thanks to Remix
Remix is not that popular. I don't think attributing this to remix is accurate. Next.js quite possibly.
The full context of that quote makes it clear that it's meant more as a wry joke:
> A venerable web application pattern that has had a small modern renaissance thanks to Remix, form submissions and redirects took a while to explain to my colleagues, on account of everyone being used to heavily client-side web applications.
(Although it's not really a joke, it's pretty amazing how many professional web developers these days don't know how to use forms without JavaScript.)
The opposite is why I'd never be a good web developer. I grew up messing around with PHP and if I spent the time to learn the modern stack, I'd constantly be thinking it's stupid.
I think the author is suggesting that Remix was the inspiration for the renaissance, not that it's necessarily the most popular method for doing so.
I'd be curious to see the stats on how often Next.js users lean into the server component model that makes the frontend fast. My anecdotal experience is that it's an afterthought for many. By comparison, Astro (as mentioned by the author) makes you think about this stuff upfront via opt-in rather than opt-out. It's a wonderful framework.
Opt-in = action is required to opt in = off by default.
I think Remix brought back interest in Form Actions and other meta frameworks took inspiration from that.
Maybe this is heretical in today's AI hype climate but...weirdly due to the rise of AI, then AI-slop polluting everything, a lot of old fundamentals are coming back. Clear, well-structured, descriptive content on a well-built page has a better shot of being picked up for SEO/AEO/whatever which are the same best practices from 2005. A lot of these tips and tricks and hacks just aren't going to move the needle as much anymore imo.
SEO and accessibility laws have always been the most effective way to convince someone to build clean, well-structured webpages. Guess what, both are measures of how easy it is for a machine to extract content from your pages. AI is just the latest machine that wants to slurp up your soup of tags.
I was a little confused by "doubled our users" since that's more about inbound traffic than site experience. I guess it's really shorthand for "halved form abandonment" which is still pretty great.
Users visited the site and couldn't even begin the form, nor get seen as a visitor, due to javascript metrics and rendering failing.
I think that's even more significant, since it's measuring people who cared enough to click the form in the first place, which is juicier than just page loads.
may be he meant, doubled our users who actually submitted the form
> In the most recent, contractors in another country had built a React app. The React app was online for 3 days before being pulled because of customer complaints. I took one look at it and told my boss “we can’t take ownership of this.” It was a mess of loading spinners and global javascript states. It was not accessible. Image upload was a vital part of the form, and it attempted to store images (along with all other form data) in localstorage which has a 5mb limit!
> contractors in another country
Sorry to spoil but the problem was not react. The problem was clearly this excerpt because we all know which country it was.
Idk, the general javascript spinner situation is beyond normalized at this point. I think mainly driven by React and other large/overkill JS frameworks. I avoid JS/TS heavy stuff so I don't really know but that's largely the impression I get. The whole thing reminds me of dialup era internet were we all were watching progressive JPGs load on a slow connection despite the fact I have fiber. I can't believe anyone is Ok with that UX, I don't see how any framework choice justifies introducing that type of behavior.
No we don't. There are lots of countries with software outsourcing industries, and contractors in any country can be good or bad. Would you rather have a top IIT graduate, or someone who took a year of programming classes at a community college in Fresno?
Considering the rampant fraud in a certain country's university system, give me local CC graduates.