Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.

A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.

As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.

Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.

A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge.

It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard form" with a multiple sub-forms to get through the full "form" process), not just accept a "finished" or "complete" submission. If a sub-form needs a change the backend, the backend's storage, and the frontend all need to change. The backend and frontend have to agree on validation logic for each small piece of the form. The backend and the frontend need to both validate every small piece of the form, and maybe can't share that validation logic (depending on what language the backend is written in), especially if one of the goals is to do as much of the frontend validation as possible with Browser native validation tools (`<input required` and `<input type="email"` and so forth) so that you get the most benefits of progressive enhancement.

The original ways of making websites were "full stack" and from a full stack perspective it shouldn't seem that hard to have a coordinated frontend and backend, especially when a progressive enhancement approach likely means a smaller more agile frontend, but current siloed world where frontend and backend are different teams with different goals and alignment makes that seem like way too much work.

They don’t know how to compose and style elements without someone providing them with a prebuilt library of $framework components.

This was the jQuery way. It was called Graceful Degradation.

The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.

I think the problem is hearing just one side.

Someone is saying that they delivered a very reasonable solution that's simpler than most would come up. Person taking over was not happy.

Do we know if the code being handed over was high quality? Were they reacting to the fact that it was "not React"? Maybe they have a template they enforce in the company about how apps are built?

We don't know.

It probably has to do with what technology people are used to. There has been a couple of generations of web developers who have only known javascript and its ecosystem for building webapps, and so anything other than pure javascript solution looks foreign.

As an application becomes more stateful it gets harder to keep that state aligned across the frontend and backend, especially if they're in different languages.

As a web dev a lot of this is simply ongoing maintenance of a largely unknown quantity. Most web devs know React and use it extensively; Astro is something they'll have to learn on the job or hire for specifically.

It's akin to writing a backend in Haskell. Chances are you could write something performant that leverages FP in a way that serves as a magic bullet for your domain. But now everyone after you needs to learn Haskell and how to model all future problems in a way that conforms with it - or rewrite things again.

By this point people don't appear to have any real clue how to write HTML anymore. Writing semantic HTML isn't significantly harder than say writing Markdown. You copy some HTMl skeleton and you literally just stack your elements into the body. I managed to do that as a 13 year old on MySpace without any deep instruction. Sure you have to close elements as well so the syntax is slightly harder than markdown, but that allows you to differenciate between for example <article>, <section> and <aside>.

I am convinced the one single thing that made HTML unusable over the time was that people wanted or needed a way to re-use parts of the page across multiple pages, like headers, navigational elements and footers.

This meant people used frames, PHP, templating engines or any other new technology mainly for the purpose of creating shared elements, simply because HTML failed (and to this day: fails) to offer a way to include one HTML file in another without having it suck (like frames definitely did, since the browser treated each subpart of the page like its own entity including caching).

Simpler doesn't mean easier. Consider a chef who at their previous job started using a wood-burning stove. This is an objectively simpler tool than a gas or electric stove, yet it would be very difficult (even impossible, depending on local architecture and regulations) for a new kitchen to add one.

I suspect they are both more familiar with client-side rendering, and also thinking of things being able to share components, reuse existing libraries, and so on. So re-implementing everything with vanilla HTML and forms feels like reinventing the wheel to a team used to an SPA component library, it's not that it's intrinsically harder, it's that they don't have the existing building blocks they'd normally reach for.

Modern frameworks such as Astro allow for a similar development experience (and can optionally use JS, React and other client-side libraries) while still being able to generate a static site if desired.

I think server-side rendering and static site generation are less familiar to many web devs who came up in the React/Vue/Svelte era. The patterns and mental model are just different. In an ideal world we combine both: fast static HTML that works everywhere, with progressive enhancement for interactivity. Astro does this well; Next.js supports it too, though the SSR parts have a learning curve.

Because before there was AI Slop, there was React.

> 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.

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. It feels like it's specialized for that and not trying to be a jack of all trades.

>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?

On the mobile point, there is https://github.com/instawork/hyperview

Your Go server can have endpoints that render XML instead of HTML and basically get the same server-driven experience of your HTMX site. Fully skips the need for the app review process since you're not updating the actual client app code to make UI changes.

> 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.

Pages has a 20k-100k limit on static files, but if they just guide you to R2 to offload it, which is still Cloudflare.

Did you mean the CDN? In which case, I'm not seeing that in the terms. [0] Though, I would have expected they'd have a similar thing. R2 resources don't generally count towards your cache limits.

[0] https://www.cloudflare.com/service-specific-terms-applicatio...

> 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.

Because there isn't a 30% walled garden you can create with that.

Where do you store the SQLite database files? What is your strategy for partitioning your data into SQLite files? One per user or…?

10TB is nothing these days. All Hetzner virtual servers in Europe have 20TB/month traffic included (excess less than $2/TB) and all their dedicated servers have unlimited fair use (which is probably about 200TB/month averaged over many months).

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.

Developing webapps only for iPhone was Jobs original strategy. Only changed when developers complained.

> Most of my apps are now simply HTMX + Go + SQLite.

Would like to hear about your Go stack for building htmx apps.

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.

Discussed at the time:

In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - May 2022 (32 comments)

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.

I wish I hadn't read the replies. I love being made the fool (though not to worry, I'll have plenty of other opportunities, likely today!)

I got wooshed.

Nice work!

I have to say that I hate SPAs. It is often a far worse user experience than the vanilla multi-page websites.

Like most defenses of Single Page Applications it managed to make me angry, at least at first.

lol this got me

> The improvement comes from the change design, not tech.

You could argue that the constraints of using HTML-first (as they call it) helped them stay away from the bad patterns they were using before.

But you’re right: The user change came from fixing the design, not the technology used.

This is a lot like those bad resume bullet points where someone tries to claim an increase in business was due to their code change. “Increased visitor count 100% by rewriting website to be HTML-first”. Then when you ask them about that point they concede that the entire site was redesigned to fix some design problems or add a feature and that’s what drove the visitor increase.

Of course, is just what with React is 100x harder, and when you fail the fans will blame you instead of the technology.

The standard answer to that is that some technologies make one harder than the other. That's kind of true from first principles, but it requires making the case that e.g. React is actually harder to make good than a plain HTML page.

Fun thing, TFA describes a kind of multi-page wizard style form that I haven't seen a lot anymore in the last decade or so. But when I did see it, it's always some dogshit enterprise system. Some Oracle product for expensing expenses last time.

The problem with those things always seems to be that they are slow in the middle of doing your task. Every button is seconds of waiting. Doubly annoying if you have to go back a step or two. The badly coded SPAs seem to be slow at the start. It takes a while to load, but once it's loaded its performance is usually okay.

If it makes you feel any better, the people using the fancy frameworks and whatnot usually aren't smart enough to understand them either.

I love the web. I hate what the React cretins have done to it.

Embrace Extend Extinguish is real, and the people going along with it deserve to be replaced by a LLM that lies and spits out garbage code just like they do but faster.

1. Presumably the team that made the previous app also thought they knew what they were doing. Presumably they were not hired on the assumption that they couldn't make a good app.

2. The design constraints had always existed, the previous app just failed to meet them.

just use firefox with an adblocker like adnauseam and a fairly decent chunk of the internet stops working, including chase.com and several other massive corp sites.

I can't imagine trying to use links/lynx or a browser with less market share than FF that isn't based on chromium.

And that is what pixel tracking is for. :)

I am actually impressed by the gov.uk websites. Its minimal and just about right for its purpose.

May I ask what tech is used for mobile apps? I am guessing not a full mobile app but it uses webview.

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.

+1 to the idea. Developers should have a powerful machine to develop, but a minimal machine to run and test.

> Windows 11 machine with only 4 GB of RAM using Firefox with the network throttled to 3G speeds

And their mobile device should be the cheapest Android phone from a monthly cell provider you've never heard of. This is what the real world is for a lot of people, and a huge number of developers simply don't know or care.

I still think it's worth it to provide connections over plain HTTP for this reason. It probably doesn't apply to many people, and you shouldn't allow anything really important to happen over plain HTTP (logins, payment), but normal viewing should still be possible.

Sadly, the internet as a whole seems to disagree. Even the most useful resource on the web one could use over plain HTTP, Wikipedia, only allows connections over HTTPS. I guess it kind of made sense as part of the campaign to push the internet as a whole over to HTTPS, but anyone who's connecting to any website over normal HTTP these days is doing so because they literally can't use HTTPS.

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.

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.

You can do a bad job with any tool but you cannot do a good job with any tool.

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).

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.

true, but where can I find the smallest functional react website where react is needed...?

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.

It may only be 1%, but that small fraction of users are also probably the people who sure as hell don't need even one more tiny thing going wrong in their life.

If you're using a decade old phone to sign up for a utility, you've got bigger problems in your life and no self-respecting person should be adding to them.

I first tested Astro on my site and never went back. Now every new project defaults to Astro and I have to have a reason not to use it. So far no reasons. It's simple, fast and it kinda fits my desire to keep things minimal. For example, yes, page content matters, but all but one page on my site is under 10kb, most hovering in the 3-4kb range (100% of the downloadable content)

None of the increased traffic was from AI agents. FTA: 'The results? When we launched, the number of people completing the form doubled.'

All completions were real people. It's a government website.

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.

I moved to the UK in 2016.

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...

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.)

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.

I think Remix brought back interest in Form Actions and other meta frameworks took inspiration from that.

Remix has been nonetheless influential in the space, in the same way preact and signals have been.

I would argue it's not even old people. Most people do not have any understanding of what's going on when you click a button. Website either acts as expected, or it doesn't "work"

If the button doesn't work, the average user is going to say "this most be broken" and then use a competitor (or contact your support). That's why it's really important to error-proof one's design (eg https://en.wikipedia.org/wiki/Poka-yoke).

So instead of the button failing because you didn't check a box, pop up with a message telling them "Please click $box before continuing". Or if you want to be fancy, feed them whatever form you're giving them piecemeal, so that they can't continue until they finish this small part (e.g., have them input a name, then the next page only has a spot for an address, then the next page only has a spot for card information, then the next only has a spot to select shipping). Simple bite sized chunks anyone (well, anyone you would ethically want to sell to) can understand.

> Old people don't have that because they

Aren't insane.

When did the industry put the onus on the user to understand how the computer works? What happened to the old days of Xerox PARC's HCI studies putting the user first? The computer is in service of the user, not the other way around!

If I need to build a mental turing machine to understand your application, it is a bad application. It is rather the engineer's job to build a mental model of the user and their needs, and if you can't do that you should not call yourself a software engineer.

> 60 year people can't user your fancy site because then don't have an internal model of how a computer works.

I think this is a bit outdated. I'll be 60 in a month, and have been practicing and writing about machine learning, for money, for a straight 10 years now; and I was a young man (and a full stack developer) during the digital revolution.

If anything, GenX had to work harder to get into these brittle emerging technologies and paradigms. There's no-one of my age group, at least that I know of, who is remotely as tech-illiterate as your comment depicts.

Truth is that it took so long for smartphones to dumb down everyone's tech acumen that those of my generation had already learned to do it the hard way.

You are just describing a broken site?

I've seen static sites with these same problems, 404 was invented decades before React...

There's a great book that explains how abstract computer systems have become from the machinery: https://dabacon.org/caelifera/2017/02/05/book-overcomplicate...

This describes all non-technical users, not just "old people."

"Old people don't have that because they didn't grow up with computers."

You know, it's time to stop this trope.

People who are 60 today were born in 1966, they probably entered the workforce in the mid 80's. They probably are not even retired yet. They know how to use computers, they own a smartphone (or if they don't, it's probably for economic reasons unrelated to their age).

As a founder and product manager, this kind of thinking is unhelpful as we design the future. In many ways it's actually ageist to imply that old people are unable to utilize everyday technology.

I was building public service websites (BBC News website) back in the early 2000's where accessibility was a real and important consideration. Technology progresses, and the bar for accessibility has moved up.

My father is about to turn 80 - he checks his heart with his Apple watch, video calls his grandson from his iPad, and asks ChatGPT questions from his iPhone and MacBook Pro. Maybe he's more unusual for 80yo's but it's time to stop this lazy trope that old people are technically illiterate.

(also, shit, I'm only 15 years away from being 60 myself :/ )

And now also a lot of young people. They grew up with iPhones and many think that "Wi-Fi" = "internet".

Keep it simple and light. HTML+CSS first, JS to expand functionality. Don't re-invent the wheel.

Giving up is a wise choice: there are so many other sites to interact with. On the other side they have only one refrigerator.

> Old people don't have that because they didn't grow up with computers.

You realize that someone who was 18 when the Mac was first released would be 60 now?

Old people. They exist.

It's not about age. It's about ability.

A lot of the people I build web pages for are poorly educated. The text we use for web is written for people with an eighth-grade education. Print material is fifth-grade.

People in the SV bubble can't imagine that there are tens of millions of people in America who cannot understand how an SPA works.

These people are invisible, even as they ladle out the food in the Google cafeteria, and polish the chrome in the Meta lobby.

Same. But I never got so lucky as to find a company where this is valued.

> Arch Linux

You've only got yourself to blame, there.

My biggest tip to reduce complexity of data validation if you are using React is to stop using React controlled components and switch to React uncontrolled components. They are an underused part of React. You usually don’t need React to handle every single keypress and every single character being entered by the user. In fact before React popularized it, it was unusual for form components to update on each key press; traditional desktop apps tend to validate when a field loses focus only, not on each key press. This has at least three benefits: (a) good for performance, (b) reduces unnecessary error UI when the user is in the middle of entering data, and (c) simplifies your own code by not having to deal with prefixes of valid input that’s not itself valid.

> Shipping tens of megabytes per web page is impolite, if not outright disrespectful to users.

You're being generous with what I would consider negligence.

"If our users can't afford the bits, we don't need them!"

They don't know what a megabyte is

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

Yes

Users visited the site and couldn't even begin the form, nor get seen as a visitor, due to javascript metrics and rendering failing.

Doubling conversions, in digital marketing-speak. Marketing firms probably give out fat bonuses for this kind of result.

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

I read the article in the source code mode and thought it was intentional until I came back to the comments

P.S. your solution seems to have disabled the custom font instead of fixing it

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`

UK government services guidance is to use progressive enhancement

https://www.gov.uk/service-manual/technology/using-progressi...

No, it's actually people. FTA: 'My client was a utility company, and they had a big problem. To apply for their services, customers could either use an old ASP form on the website...'

Ie customers of the utility company were completing the form, not random users from the internet.

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.

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.

>> There should always be a way for tech-illiterate people to ask someone, and fill their forms

Isn't that more open to fraud and abuse though by the "someone" whether that is a gov employee or otherwise.

FTA: 'To apply for their services, customers could either use an old ASP form on the website, or follow a manual process.'

It's like chai tea.

Reminds me of “pre-jit”

I’m sorry I can’t hear you over the Flash animation splash pages I was forced to sit through before being able to look up hours of operation.

I thought this article was missing a (1999) in the title.

Same, and it has certainly made me realize that I am now officially entering my "old man yelling at cloud" phase of my life, and I'm "only" 38!