Steady on, guys.
This way, the biggest downsides (moving between pages & requiring an internet connection) are eliminated.
But if your app requires an internet connection and multiple pages, it's better to let the browser handle navigation in a fault-tolerant way.
SPA's are one thing, the complexity to create it is another.
After almost 6 years away I came back around 2015 when I realised a web server would be useful for whatever I was doing. I was shocked to find the world had forgotten about so much regarding HTML and CSS. We used to build multiple stylesheets for our sites. That was forgotten. We used to make stuff work without JS first, then add JS as a nice-to-have afterwards. That was forgotten. I saw web devs just doing all their form validation in js and the server doing none. Shockingly, this is still common today. I'm not aware of a common pattern where you get the server to do validation and just display it in js. Everyone seems to either duplicate or not even do it on the server at all!
When I saw this I was no longer impressed by what people were doing on the web because it wasn't the web I knew, it was just "applications" built in JS. Trying to argue for "web first" was a losing battle.
Started with html 3.2/xhtml and css as a kid. Some years later got a job and did Django + jQuery, but found myself drawn into infra. A year ago I worked alongside a web dev team and decided to peek into their work--nothing made sense anymore. The amount of complexity was staggering. It seemed like they spent most of their time managing that complexity, eg. reducing build times, solving dependency problems, solving weird TS issues, handling errors in different components, etc.
In the Django+jQuery days, the emphasis was still always on what user got to see and use.
Reducing server workload is useful
> - users of assistive technology would be unaware of changes in context, for example when moving to a new page
> - it would fail to handle focus when moving between pages
> - the user would be unable to navigate using the back or forward buttons in their browser
> - users would be unable to recover from an error, for example if there is an interruption to their network connection
These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother
Consider multi-page forms: how many SPAs just store all of that in memory and then make one request at the end? Without JS, the BE would be saving the state for each step so you could come back to the form later or refresh without losing anything.
Yes you can, but then it is way more difficult, and the fact that most don't even bother means that it is not exactly trivial to implement. Why to force that garbage when basic HTML basic web sites work just fine out of the box.
Maybe we should prioritize the simplest possible solution rather than what’s trendy today.
Just because the rest of the industry has been high on JS doesn’t mean everyone has.
https://www.gov.uk/service-manual/technology/designing-for-d...
The non-flippant answer that is related to the flippant answer: because there are dozens of distros and within those distros about a dozen browsers if you factor in all of the Mozilla forks. They could probably choose a blessed one, but any individual blessed one turns out to have an incredibly small user base (Even Ubuntu, to the extent that numbers can be generated as a secondary signal, looks to be about 1% desktop OS share).
But what users like and what developers like (and can quickly develop) are often very different things.
Here on HN we often see the schism between speaking "as a developer" and "as a user".
As a user I hate a lot of the shit we gleefully enthuse about here. As a coder it's super cool.
When you build programs that run on _your_ computers, you have to pay for that. Or at least have to deal with the finance folks asking why your cloud spend increased 5%.
But if you run your software on other people's devices, like frontend devs do, there's barely any cost to that. Any negative signals need to trickle in through user reports, support tickets, and maybe Twitter posts. There's a ton of selection going on there so you're likely not getting the full picture.
Ie. It's all about incentives
The web is replacing traditional thick clients, which also assumed a fairly stable network connection and platform specification.
Government systems need to work with the lowest denominator - even if it's not that common. Tech startups only need 1 client to exist at the start (and can mostly trust that their requirements will become commonplace as they scale).
In fact, I think that people dislike this approach because they are frontend developers, as otherwise there would be very little frontend to develop.
A business probably thinks that it doesn't need 100% accessibility. A nicer site may be thought to get more users/customers, even if the site doesn't work for many (or maybe devs just want to fit in with the other cool devs making cool dev sites)
2. Tools. React+JavaScript is the industry monoculture. If they're all you know (and for a significant number of frontend devs this is unfortunately true) then you're invariably going to build something complex because its in the nature of your chosen tools.
3. Career anxiety. Building something simple using simple tools isn't sufficiently hardcore and braggable to get that juicy comp increase at the next performance review, never mind a promotion or hopping to that next job.
a. I once worked on a project where the webapp frontend went through a time-consuming, mid-project framework swapout because the "senior full-stack developer/architect" decided it needed server-side rendering for SEO purposes. Never mind that it was a niche industrial app that required a login to use and simply wasn't visible to search engines.
b. I remember being advised to stay quiet when I asked why a different web developer, upon being asked to build a simple static website, had nevertheless built it in React.
Secondly it's less "boring" for developers and arguably less work.
Thirdly you have a large amount of only-frontend (often only-React) devs know who won't think of alternatives.
Humphrey: But what happens to us?
Bernard: Well, much less work.
Humphrey: Yes! Much. Less. Work. So little that fullstack engineers might almost be able to do it on their own!
There were will always be a group of devs that don’t like it because it isn’t the same web as in their heyday, and they all will eagerly pile on anything remotely JS-critical is posted on HN.
There is a selection bias to the comments that does not accurately reflect the industry opinion.
"Companies" don't really know anything. The decisions get made by people, with all the flaws that people have. I have seen many developers make decisions that are detrimental to the company.
I do agree that there is a section of HN that will pile on these kind of topics, and I have flagged dozens of low-effort swiped against JS over the years that add nothing.
But two things can be true at the same time:
1. there is an unpleasant section of HN that will rant about all things JS, and
2. SPAs (or our current approach to them) bring a lot of downsides and are often not worth it.
Are entirely compatible.
Please don't make this an Us vs. Them thing.
[0]: http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....
> If you do choose to use client-side JavaScript frameworks, be aware that although they can be helpful when building a service with a complex user interface, they can introduce problems.
> Using a client-side JavaScript framework can:
> - increase the overall size of your code base and push processing to the client-side, causing performance issues for users with a slower network connection or lower powered device
> - create a reliance on third-party code that your developers do not have control over, requiring you to make major changes to your service in order to stay up to date with changes in the framework
> - make it difficult to find people with the skills required to maintain the code, if the framework’s loses popularity over time
> If you use a JavaScript framework you should:
> - be able to justify with evidence, how using JavaScript would benefit users
> - be aware of any negative impacts and be able to mitigate them
> - consider whether the benefits of using it outweigh the potential problems
> - only use the framework for parts of the user interface that cannot be built using HTML and CSS alone
> - design each part of the user interface as a separate component
> Having separate components means that if the JavaScript fails to load, it will only be that single component that fails. The rest of the page will load as normal.
If you doubt this, think how many times you've seen a framework advertised due to its ease of use for developers vs due to e.g. performance in low bandwidth.
On another note a lot of the UK Gov Web services runs on Ruby Rails.
> You should consider
Is Gov UK's way of allowing people internally to point to it and say 'Well, did you consider it?'.
UK Digital don't have any direct power to force change - they have to use sensible advice and internal process to encourage better design.
Limiting complexity to where it's *really* needed is the hidden magic of a great leader in my opinion. A great engineer knows how to wall that complexity off from the rest of the system as well because complexity spreads like cancer through a codebase.
I've never been a TD but I can imagine your pain.
It might be worth asking why that is.
I used to write a ton of SSR'ed pages back when that was really the only option we had (before people introduced jQuery and AJAX), then I wrote SPAs (mostly Angular & React), then again SSR'ed websites (Java/Spring/JSP with a ton of more-or-less vanilla JavaScript) and now I've been on a Vue-based stack (w/ Astro/Vite for SSR) for a number of years. And these were all applications with dozens of teams working on them in parallel and a corresponding number of components & LoC.
Personally, I wouldn't want to go back to traditional SSR stacks (Spring/JSP, vanilla PHP, or Python w/ Django or Flask) ever. People often vastly underestimate the complexity of good UIs. They might start simple ("could be a simple SSR site", as you say) and, before long, the wheels come off the bus and they look at a big unmaintainable ball of vanilla JS on top of HTML templates that are directly coupled to the database schema, with global CSS styles permeating (infecting) the entire code base.
In my experience, there is a certain amount complexity that is inherent to a good UI. It doesn't matter whether you use classic SSR, or modern frontend frameworks like Angular/React/Vue/Svelte/SolidJS, or new kids on the block like HTMX/Turbo/… — that complexity will still be there. However, with modern frameworks you've at least got a chance to tame that beast.
More specifically, what modern frontend frameworks give us is: 1) Modularization into components, 2) scoping of styles, 3) type-safety, 4) unit-testability of components, 5) component-local state management (≠ insanities like Redux), 6) clear separation between view/UI logic and business logic.
If you can replicate these features using a bespoke version of JSP or HTMX or whatever, great! But if you can't, I'd personally rather pick a well-established frontend framework like React or Vue. Yes, your developers might still mess that up and produce shitty code, but the chances of them messing up in a classic SSR stack (without the aforementioned features) are so much greater.
A hill I will die on: the users NEVER asked for them. The UI community likes to pretend otherwise, but the users never asked for SPAs. What users want is the simplest, clearest and fastest possible experience, that changes only gradually and only when necessary. SPAs often stumble on simple and clear, and straight up explode on fast.
You can build a SPA SSR as well.
But I'm not really sure how we're going to handle that or who we'll hire for it, because I fear we'll end up with another react-soup. My current strategy is to make a MVP in my spare time to show it can be done and that it'll be quite nice.
I really wish something like HTMX is built into the browser or part of HTML5 spec.
Else you will have exactly this problem
Probably 80% of websites could do with a good designer that knows how to get their designs from concept to CSS and a good backend engineer that know how to output decent markup.
You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire.
The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..."
The good way to do it: "Our users often share links within the application with each other to navigate and the new single page app you demoed doesn't allow that."
Or: "While the page load times look great on the metrics in your power point, as everything is lazy loaded it takes 10 seconds for the page to actual become usable, the old site loaded in under a second why are we regressing the user experience here?"
Or the evergreen: "What does that buy us?"
However on side projects it is pretty much vanilla.js without any kind of SPA related stuff.
I’m sure, and it will be hard to convince me otherwise, that it’s NOT a client model (thin client, thick client, mixed approaches) that is a source of your frustrations, but the amount of bullshit that “frontend developers” tend to serve to everyone including themselves and at the same time leave ends loose by e.g. never checking for errors or assuming incorrect lifetimes or phases of page loading.
If you just write a regular non-wEbApp app with js as a scripting lang and dom as a poor man’s ui lib, it works like any other ui app. All problems arise from trying to jump over the head to render empty frames 200ms faster out of total 12 seconds of loading.
My “stack” is mithril.js, bootstrap.css and just js runtime for “state”, for those curious. Yes, I manage “state” by storing it in js objects and transform it via assignment operators (shocking I know).
It is partially the fault of developers because they do their best to make this field what Alan Kay calls "pop culture and not really a field". I spent recently a lot of time questioning certain tools we use that I consider useless for us, but it's "standard" because someone else uses it and it spreads around because again you don't want to be left behind in your CV. For a lot of people the most important is to check all the tech boxes (spa, docker, kubernetes, cloud), but that the actual product is poor is less relevant. The outcomes are poor because a lot of this stuff is actually really hard, but if you take that approach it will take you forever to really master all the details of your craft. So instead you make it barely work on the happiest path and you've shipped your app as a full stack developer.
I don't know the solution, but articles like these are a good start.
So, I see those website below as examples and ask myself: What's wrong with those:
Both are SPAs. Fast, small, working very well.
Ok, they need JS to work. But honestly, how many people are not using JS because they can't (as opposed to because they don't want to). And how many have so low end devices that running the JS is a problem? People watching videos all day on their smartphones. So, the days where processing JS for creating the DOM is a problem are over. Esp. if using fast frameworks like Solid, Preact, Vue or Svelte.
Of course there're website that load 20 MB JS of analytics and spyware. Those are slow not because they're SPAs but because they do all this additional (of course unwanted) stuff. Also accessibility issues are not caused by using SPAs or not. Svelte even has accessibility warnings built-in.
Think cascading requests, you need to render a list of user saved posts, you fetch the list, then you fetch details for each item, then you render them (n+1 problem). In a simple SSR app even if you do some inefficient backend queries, the overhead is trivial compared to the equivalent SPA logic. This is just an example, but I think in general is way easier to screw up an SPA than it is to screw up an SSR site.
If the website is simple then definitely no SPA is needed, either htmx or alpinejs or vanilla can get the job done.
Having a single source of truth by push things down into the backend is a godsend in terms of limiting complexity.
Don’t forget about the other “invisible” requirements with a JS solution — more tests, more code, longer builds, more 3rd party libraries.
JavaScript has appeared in 1995, it's now technically impossible to use a browser that doesn't support JS, because it will fail to load the website due to its old SSL/TLS stack, worrying about JS support is just insane.
Not using JavaScript doesn't give you accessibility by default, see: <a href="/121/"><img src="abcd.jpeg"></a>
The whole article feels like it was written my someone stuck in the early 2000s, you can make a well designed and accessible SPA. Using stone age technology should not be the goal, accessibility should be the goal.
The tax section of the gov.uk domain follows these guidelines and it's a mess, other pages can also be very difficult to use.
Providing good UX with HTML/CSS/Progressive enhancement usually means less-than-ideal DX. And good DX with JS frameworks tends to end up with less-than-ideal UX.
Poor DX usually results in slower development, thus devs are usually incentivized to prefer DX over UX.
The holy grail of good UX/DX requires exceptional developers whatever path you choose.
I despise React, ended up with Svelte+Typescript and now I realise that could do it all mostly with HTMX + templating with bit of alpine.js if at all.
Svelte(kit) is still the most W3C compliant of the major frameworks out there. Also, it's not even a runtime-framework but a compiler, meaning you're left with nothing but the necessary HTML, JS & CSS just relevant for your page.
Comparatively, Svelte has a much simpler mental model and at the end, leaves nothing but basic plain old javascript.
But I tend to question these days that do we need this much Javascript?
I'd argue that it's way easier to master the internals of a library than a whole bespoke compiler.
Have your API server render the HTML itself and your entire stack becomes radically simpler. Iteration speed goes through the roof.
If you're not building Google Sheets, skipping the entire SPA universe provides massive benefits with no notable downsides. The same UX can be provided either way but often with improved performance which actually means a better UX
Unless there's a good reason to, like long-lived sessions or a complex, updating UI, then I can't think of a reason to send a truckload of js to the user that eats through their CPU like a baby eats through a tub of icecream.
Not everyone in the world is sporting the newest MacBook and iPhone. Hell, I'm using a pixel 8 and some sites or components take _seconds_ to load (eg. Twitter search drop-down).
That said, however, there is a list of four inaccessibilities in the article, and I was thinking that spas have work around for these.
In the US, tech you can deploy varies significantly agency to agency. In my case they were using a dated PHP CMS and we’d have to go through significant efforts and sign offs to get our own simple RDBMs in place on their services. Deploying to cloud infrastructure also was filled with red tape, especially for small applications. Internally they had little experience so forget just spinning up and hosting some AWS service. Then there’s costs, it’s not that such services might be too costly so to speak but money has color in the government and money to build the application is often a different color, maybe entirely different group, than those who will maintain it. So deployment/transfer for handoff is pretty much a nightmare, yet agencies often want (for good reason I’d say) full ownership of the application and surrounding infrastructure.
Stakeholders pop up from the agency your working with and any sort of collaborations between other agencies they’re trying to leverage, then if you have your own organization you end up with a superset of “idea makers” from a couple agencies and your own coming up with “wouldn’t it be nice” features from what otherwise should be a simple application.
Ultimately for deployment to arbitrary infrastructure and maintenance, SPAs simplify a lot if you absolutely need dynamic content and absolutely struggle to get real server side service infrastructure (eg most government organizations from my experience). So you pack as much complexity as you can into JS because it can somewhat take it, and you rely on user browsers to pickup the slack. This only goes so far of course, as there’s only so much you can do in an SPA that actually runs on a lot of devices but needs some real application functionality, so think small desktop applications, wizards, small computational models (a lot of what I do), etc.
So SPAs are the land I’ve been pushing in this space, no matter how much I loathe them in general, they’re one of the best fits for the constraints in these environments (which is why they get them a lot).
So now we have two extra buttons on the form.
And perhaps the extensive user testing that gov.uk do would discover that for most people this added UI complexity makes the form less usable than keeping it as simple as possible.
But, when you were writing one you do take on all of those responsibilities as the author. You are substituting the browser's standard behaviors with behaviors of your own choice.
Pet peeve: when did “to error” become a verb?
Otherwise, I wish the rest of the web were designed this way.
I don't know why many HN users don't like SPAs but I don't know any sites where I have a problem with it from a user perspective. IMHO there are far more badly designed sites. From a developer side it is a completely different story, due to the added complexity and I get it if someone doesn't want to build an SPA/PWA.
However, I would take any SPA any day, compared to what the German government offers...
