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 was going to comment on the Terence Eden excerpt quoted by the author about the woman researching housing benefits on an old PSP browser, when I noticed that you (the OP) are Terence himself. It's strikingly powerful, and a reminder of the duty we have in building our infrastructure.
> Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.
It is frightening to think of how many people are alienated from critical systems every day because of this bias reinforcing the idea that they do not exist.
I haven't heard much about in a while, but the HTML Triptych proposal [0] is still something I hope to eventually land in browsers. HTML forms speaking to REST endpoints are a good pattern. (meaning user-aiding validation is handled via the input attributes, real validation is handled on the far side of the request, and the flow is GET /form => POST /thing => GET /thing/1) It would be a great pattern with the triptych features implemented!
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.
"What, support Safari? Isn't that, like, less than 20%? And its standards support is abysmal! No, not worth my time, they can upgrade to a normal browser like everyone else."
If Rick Rubin could take a tape to his car to listen to his mixes, your product people can try their websites on £20 phones from Tesco. They can ask to sit in on user tests with minority groups. Extending your knowledge like this is trivial, but rarely done.
You're not a good and modern engineer who knows his craft if you aren't defaulting to react and tailwind.
And don't dare to contradict me, the fact that MIT-bred leetcode ninjas paid half a million per year can't produce a simple (mostly static) website on that stack it's only because of management that wants to ship the next product. /s
I am not familiar with this astro framework they used. But having built some sites using Pure HTML/JS back in the day, React, Angular, Vue, Rails ERB, Rails Hotwire, and HTMX. I think HTML first websites are absolutely the way to go. Rails Hotwire with View Components makes rails sites super fast, faster to develop and easy to re-use components. HTMX more generally, but Ive used it with Spring boot and Thymeleaf. I really don't want to go back to SPAs. Development time is less and the website performance is better, and I haven't really seen any regressions in capability. With HTMX and some url parameters, I can make a pure HTML site that seems like a Single Page Application but without the excessive loading times.
There is one hard wall that stops very old clients from connecting: Not supporting newer versions of HTTPS. That stops historical versions of Microsoft Internet Explorer from working, and I'm sure it also stops other old browsers as well.
As a teenager I remember going to a website for... a city, I think? And their 'sidebar' was a Java applet that did nothing but provide links for you to click with on-hover effects. The page used frames; the applet was in the left-side frame and the content was in the main frame on the right.
The applet took 30 seconds to load. Once it loaded, it showed five buttons to click to get to different sections of the site. When you clicked on one, instead of changing the content frame, it sent you to an entirely new frameset. This, of course, caused the sidebar to take another 30 seconds to load. Hitting the back button did the same thing.
Meanwhile, I knew someone whose friend made a little applet that he showed me; it was a Java applet that you could provide an image URL for and it would load the image and then, below the image, show a rippling effect as though you were looking at something on the shore of a rippling lake. This applet took less than a second to load and ran incredibly smoothly.
Java was a curse, not because Java was bad but because Java applets were written badly and used badly simply because they were neat.
I did some work for a company that spent nearly a grand on a Flash animation for their title page of a red bouncing ball that would bounce from right to left along the letters of the word "Yipee" (yeah totally not ripping off Yahoo! were they?) until it landed in the crook of the Y, where it would spread down the middle - the finished logo had the Y made out of blue, yellow, and red stripes.
Every single person I showed it to including my then-70-something mother said "that just looks like menstrual bleeding".
Every single person said that.
They still went with it. Conversion rate? Dunno, never got numbers high enough to test the script.
I'm not convinced from the article that HTML-first was the thing that fixed the problem. What fixed the problem was 1) the person building it knew what they were doing and 2) it had design constraints from the get-go to be user-friendly. You can do that with React. It's arguable whether it's easier or better, but you can get there regardless of the approach you use.
Most of my apps are now simply HTMX + Go + SQLite.
I've found it's enough for most projects.
One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup:
1. S3 (I wanted reliable data storage)
2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both the browser and Cloudflare for 1 year, ignore origin cache policies, ignore query strings, etc., and I simply use immutable objects that require revisioning.
3. BunnyCDN in front
Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.
And if you run only S3, the bills will be huge.
But yes, lately I’ve been building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage in 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.
Since you're using HTMX, I have to ask: do you have any tips or idioms for composing complex forms and UI without things getting out of hand? I love the approach, but I'm having a bad time figuring out where the ideal balance is between too few or too many HTMX-replaced areas in a page. Thanks.
Go is so awesome for server apps. I should have discovered it much sooner. It somehow sits in the exact optimal point having no bullshit overhead like C, yet also getting out of your way so you can focus on the business logic like Java (not Rust).
It's not great for every task - in particular the lack of abstraction-building capabilities - but it's great for business-logic-heavy server apps, probably because it's specialized for that and not trying to be a jack of all trades.
> 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.
There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.
If 2009 is too far back you can try your luck in 2012 with Firefox OS.
Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.
>One of my sites is image heavy and serves 10 TB of traffic per month
I can't imagine this kind of traffic without acting as a CDN, advertising broker, pornographer, or part of a massive ecommerce site. I have to wonder, what are you doing that generates 10TB of traffic per month?
I disagree. An HTML website which uses links, forms, buttons and inputs will by default:
* 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.
I agree. Server-rendered React can also send down 100% HTML apps.
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).
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.
I find it's way easier to build crappy React apps than an HTML-first approach.
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.
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)
but the host (the company) will need to pay the price in the form of server equipment. Not the user as is the case with client side rendering. If server side rendering becomes slow it will affect all users regardless of their hardware or connection, prompting earlier response from management and devteams.
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.
I built apps like these on GOV.UK over 10 years ago for the Ministry of Justice. We built our own form wizard library that let us validate long forms in steps and break them out into multiple pages because Ruby on Rails didn't support doing that out of the box. It was a very important principle back then that everyone should be able to make use of these digital services regardless of whatever users were using to access them.
I've always liked basic HTML pages where one can upload a document without having to restart the entire application. That's a great practice you have there with general forms. With each session ID, it can cross reference a page in a multi page application with that session ID, so that the user can maybe type it in if necessary, but it should be able to determine that with enough information, like IP address, upload date, browser, OS and so on. But the most accurate session would be within the browser so that the cookies for a single application aren't mixed up with another applicant, like a relative, who might be using the Playstation Portable.
> When we launched, the number of people completing the form doubled. The analytics people didn’t even know where these users were coming from. Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.
Yeah, reminds me of the b52 story re holes in wings on the planes that made it back from missions, leading them down the wrong path of strengthening wings. They weren't looking at the planes that never came back with holes in the fuel silages.
This is such a great story. I am glad more people are sharing stories like this. I hope my article the other day inspired more to develop lightweight websites:
Hmm I cannot load the font on Firefox 151.0.3 Arch Linux. All I see is only a title and empty paragraphs. So I end up reading the article in the source code mode and felt pretty on-brand.
Back to HN comments it looks like this wasn't actually intentional?
I've started getting traffic on my website only after I re-build it with a locally-brewed MD parsing engine that uses Astro to spit out the final version of the site.
I guess the main argument is how easy it is for an LLM to ingest the content, since I can bet all of the crawlers are llm-enabled one way or another.
Don't tell me were going to rediscover progressive enhancement all over again after more than a decade. Back when we used to actually care about the end user whether you were programming frontend or backend.
Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.
> 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.
That hit me, too, specifically thinking about my current gas/electricity provider. I have not heard one single piece of positive feedback from the public, and there's only ever problems. I feel like that's a pretty universal experience here. Even outside the scope of websites, it holds so very true.
Personal anecdote: Recently they were updating everyone to "smart meters" on the gas lines. They needed me to be home so they could enter my apartment and bleed the gas out of the line by turning on the stove prior to replacing the meter. I played phone tag with them for 6 months, setting up countless appointments, and nobody ever showed up, the meter remains un-upgraded. At the same time, I have received weekly phone calls and monthly physical letters stating that if I don't upgrade the meter, my gas will be shut off.
I just moved, so the new tenant will have to deal with it now.
The public sector, simple, no frills, accessible, no flashy graphics, websites were a massive eye-opener.
They just worked. They had a job. They did it. I wasn't going to buy more from them because of it, and they didn't care. It was great.
I've heard that recently they've dismantled the centralised team that wrote all the rules, enforced it, and started moving to decentralised hosting, but so far the whole still seems to hold to together really well. I think, I hope, they have embedded the expectation that the local council, the tax office, your visa status, etc, should just be utilitarian in nature, and work for everyone.
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.
> Javascript and modern CSS should be used to enhance the experience
When messing around with my blog's Javascript, this mantra is so thoroughly embedded into writing it, that I try to include "enhance" in function names where it makes sense. I might have to do likewise with my CSS.
My go-to for spinning up a site has been Jekyll + Bootstrap with the occasional bit of React for well over 10 years now.
While it still does the job, I'm a little curious to explore more modern options, if for nothing else to understand the choices a more junior dev would face/make today.
I'm seriously considering giving Atro a go. Is it worth it?
All the text is invisible for me in Firefox on Linux when the `--font-body` is set to `"Atkinson", sans-serif`. Setting it to `"Atkinson Hyperlegible", sans-serif` fixed it.
in the bio ... "has over twenty years of experience building highly accessible and usable web applications"
why not take the html5 standard (see https://html.spec.whatwg.org/ ) and if needed (dont think so for these use cases... "for clients ranging from energy companies to political parties") htmx or alpinejs ...
The downside mentioned by the author's replacement in the article is the unfortunate explanation for why this is rare in practice.
> "but that’s a lot more work for us."
And it's not that any individual or team is lazy. Most teams have a constant barrage of priorities to balance and are paid by companies valuing efficiency over everything. That said, I think the article makes a great case for adjusting our prioritization. Going a bit slower won't kill anyone, in fact doing so will probably save some.
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.
esm.ah let's you include "complicated" JS that isn't usually found in CDNs.
it doesn't work for everything and imo is worse for (p)react due to the lack of native JSX, but it does allow for bringing in stuff that usually takes an `npm install && npm build`
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.
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.
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.
Totally agree, gov pages should be widely accessible. Also gov services should NEVER mandate internet access. There should always be a way for tech-illiterate people to ask someone, and fill their forms
> 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.
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?
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.
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
Nice work!
> Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures.
It is frightening to think of how many people are alienated from critical systems every day because of this bias reinforcing the idea that they do not exist.
[0] https://triptychproject.org/
Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.
React is too heavy weight for a lot of things. But it's ridiculous to call it disrespectful.
And don't dare to contradict me, the fact that MIT-bred leetcode ninjas paid half a million per year can't produce a simple (mostly static) website on that stack it's only because of management that wants to ship the next product. /s
https://en.wikipedia.org/wiki/Chai
The applet took 30 seconds to load. Once it loaded, it showed five buttons to click to get to different sections of the site. When you clicked on one, instead of changing the content frame, it sent you to an entirely new frameset. This, of course, caused the sidebar to take another 30 seconds to load. Hitting the back button did the same thing.
Meanwhile, I knew someone whose friend made a little applet that he showed me; it was a Java applet that you could provide an image URL for and it would load the image and then, below the image, show a rippling effect as though you were looking at something on the shore of a rippling lake. This applet took less than a second to load and ran incredibly smoothly.
Java was a curse, not because Java was bad but because Java applets were written badly and used badly simply because they were neat.
Every single person I showed it to including my then-70-something mother said "that just looks like menstrual bleeding".
Every single person said that.
They still went with it. Conversion rate? Dunno, never got numbers high enough to test the script.
I've found it's enough for most projects.
One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup:
1. S3 (I wanted reliable data storage) 2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both the browser and Cloudflare for 1 year, ignore origin cache policies, ignore query strings, etc., and I simply use immutable objects that require revisioning. 3. BunnyCDN in front
Cloudflare will not let you run an image heavy site on its own, so I use this approach to massively cut the bills. Their policy says you cannot use it primarily for images; it must be used for HTML, CSS, JavaScript, and other site content.
And if you run only S3, the bills will be huge.
But yes, lately I’ve been building mobile apps. PWAs are limited; the OS can evict IndexedDB storage, so I cannot offer people reliable data storage in 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.
It's not great for every task - in particular the lack of abstraction-building capabilities - but it's great for business-logic-heavy server apps, probably because it's specialized for that and not trying to be a jack of all trades.
There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS.
If 2009 is too far back you can try your luck in 2012 with Firefox OS.
Joking aside, people and companies have given it a go. But a combination of bad timing and various other events never made that reality happen in our timeline.
I can't imagine this kind of traffic without acting as a CDN, advertising broker, pornographer, or part of a massive ecommerce site. I have to wonder, what are you doing that generates 10TB of traffic per month?
Would like to hear about your Go stack for building htmx apps.
* 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.
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).
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.
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.
(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)
Yeah, reminds me of the b52 story re holes in wings on the planes that made it back from missions, leading them down the wrong path of strengthening wings. They weren't looking at the planes that never came back with holes in the fuel silages.
https://inavoyage.blogspot.com/2026/06/im-building-parallel-... https://inavoyage.blogspot.com/2026/06/how-about-new-java-ba...
Back to HN comments it looks like this wasn't actually intentional?
You've only got yourself to blame, there.
I guess the main argument is how easy it is for an LLM to ingest the content, since I can bet all of the crawlers are llm-enabled one way or another.
Too much VC money and big tech influence in the JS ecosystem made the web worse in some ways.
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.
Personal anecdote: Recently they were updating everyone to "smart meters" on the gas lines. They needed me to be home so they could enter my apartment and bleed the gas out of the line by turning on the stove prior to replacing the meter. I played phone tag with them for 6 months, setting up countless appointments, and nobody ever showed up, the meter remains un-upgraded. At the same time, I have received weekly phone calls and monthly physical letters stating that if I don't upgrade the meter, my gas will be shut off. I just moved, so the new tenant will have to deal with it now.
The public sector, simple, no frills, accessible, no flashy graphics, websites were a massive eye-opener.
They just worked. They had a job. They did it. I wasn't going to buy more from them because of it, and they didn't care. It was great.
I've heard that recently they've dismantled the centralised team that wrote all the rules, enforced it, and started moving to decentralised hosting, but so far the whole still seems to hold to together really well. I think, I hope, they have embedded the expectation that the local council, the tax office, your visa status, etc, should just be utilitarian in nature, and work for everyone.
I worry how long it will last...
Is it more work?
> 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.
> 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.)
I recently had to intervene during the latest office holy war to explain that you don't need JS for file uploads.
It was eye opening.
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.
When messing around with my blog's Javascript, this mantra is so thoroughly embedded into writing it, that I try to include "enhance" in function names where it makes sense. I might have to do likewise with my CSS.
While it still does the job, I'm a little curious to explore more modern options, if for nothing else to understand the choices a more junior dev would face/make today.
I'm seriously considering giving Atro a go. Is it worth it?
P.S. your solution seems to have disabled the custom font instead of fixing it
why not take the html5 standard (see https://html.spec.whatwg.org/ ) and if needed (dont think so for these use cases... "for clients ranging from energy companies to political parties") htmx or alpinejs ...
What were some of the downsides? Illuminating the tradeoffs would elevate this post from good to great.
> "but that’s a lot more work for us."
And it's not that any individual or team is lazy. Most teams have a constant barrage of priorities to balance and are paid by companies valuing efficiency over everything. That said, I think the article makes a great case for adjusting our prioritization. Going a bit slower won't kill anyone, in fact doing so will probably save some.
Don't get me wrong, I actually have enjoyed React over these past 10 years. But, including it blindly is just silly.
it doesn't work for everything and imo is worse for (p)react due to the lack of native JSX, but it does allow for bringing in stuff that usually takes an `npm install && npm build`
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.
> 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.
Oh yeah? Which?