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
* Have working back/forward buttons * Have working progress indicator as provided by the browser * Show errors to the user - even if they are ugly * Be accessible to keyboard navigation
With SPAs these are all things the developer has to get right.
So often when using a SPA I'll click a button, you get a spinner and then nothing will happen. Is it still in progress? Don't know. Eventually I'll open developer console and trace the network requests to find the JSON HTTP request that returned "ERR_BAD_EMAIL" and fix what I've entered. With a normal form submission at least the user will see the error message and can press back and then fix it.
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.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
But I 100% see where the author's coming from, considering the massive fragmentation of react codebases/patterns and decision paralysis of React development in general. I really doubt most React apps, even the more accessible ones, are testing their multi-page form wizards with JS completely turned off.
HTML-first does seem highly underutilized in the commercial web, and I learnt a lot from reading this (as a solidJS/react dev).
This is an absurd statement. Just because something is a proverb, doesn't mean it's automatically true for all cases.
A professional woodcarver armed with only a metal spoon will still make a nicer woodcarving than I can given a full wood shop. Similarly, if you only give me notepad.exe, I can still make a pretty nice website.
Does using the right tools make our lives easier? For sure. Using mildly-wrong tools (react, in this case) isn't going to hold us back very much though.
I have trouble seeing how React vs Astro is two tools of different kind entirely?
It can use other libraries with it too, or just plain HTML, but it’s not in the same space.
React can’t work on the backend by itself without Astro, Next.js, etc, or some hand-made micro-framework.
> A poor workman blames his tools
which is towards the opposite meaning
An "old school" Ruby on Rails/Symfony/Django app, with templates, usual get/post forms etc, frames you and pushes you in using the standards and relying on browser default behaviors.
In JS-heavy apps, it's as easy to code normal `button` elements as it is to code clickable `div` elements. But with the divs you just forget to handle keyboard nav, proper element roles, etc. It's easy to create fake links, not relying on `a` tags, using an internal JS router that doesn't expose URLs, doesn't handle middle click mouse, for no particular reasons.
In less JS-heavy contexts, the easiest way to do is to use proper HTML so you are less inclined to mess up.
Even on codebases that use a decent framework like Next.js that handles those for you on paper, it's often we see people not very aware of the benefits of using proper semantics and standard behaviors, and you easily end up with web apps with poor UX in the end.
Astro itself works just fine with React, and it can still be HTML-only.
But you can also render React on the server yourself using renderToString, if you don't want a framework.