6 ms·

Building a robust frontend using progressive enhancement

244 points by artbristol 2y ago

hnarayanan 2y ago
This is very good advice.
bigfatkitten 2y ago
> If you use a JavaScript framework you should: > > be able to justify with evidence, how using JavaScript would benefit users Steady on, guys.
- joseferben 2y ago
  for real, do you want swarms of developers to lose their jobs because software complexity collapsed?
  - mrthrowaway999 2y ago
    If we want full employment, we should mandate people use spoons instead of shovels.
    - joseferben 2y ago
      https://en.wikipedia.org/wiki/Perverse_incentive https://en.wikipedia.org/wiki/Perverse_incentive
- j45 2y ago
  Use? I look at all the time to keep it running.
pensatoio 2y ago
I wish the whole internet followed this advice.
- fouronnes3 2y ago
  We could shutdown a few dozen powerplants easy.
  - mfenniak 2y ago
    Great idea, more capacity for LLMs! /s
  - EasyMark 2y ago
    Wait until you hear about the next big thing, AI compute centers, and those plant shutdowns will be a drop in the ocean…
truculent 2y ago
Good advice, but > - 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
- ljm 2y ago
  You kind of get it out of the box with plain old HTML though. Once you get into SPA territory you’re reinventing a lot of wheels to get back to parity, or replacing native functionality with JS alternatives. 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.
  - bufferoverflow 2y ago
    You can easily store intermediate state in sessionStorage or localStorage and prevent all the unneeded requests to the server just for moving between steps.
  - truculent 2y ago
    Yes, hence why it’s good advice.
- edelbitter 2y ago
  How could you possibly make them true, if you are told to respect even deliberately disabled features? If the user does not permit retroactively messing with their navigation history, then you are left with only one option: get the history right, at the time it is written.
- earnesti 2y ago
  > These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother 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.
wg0 2y ago
When even governments knows the web better than the tech industry by and large itself. 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.
- mentalgear 2y ago
  Despise React's unnecessary complexity and non-standard-compliant non-separation-of-concerns squeeze-it-all-in-js approach as well. 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.
  - mhoad 2y ago
    Lit is also totally web standards compliant to be fair.
    - deleted 2y ago
      [deleted]
  - wg0 2y ago
    React in the hook's era has gotten overly complex. The cods is unreadable and hard to reason about. Check any longer/complicated component as an example riddled with hooks. 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?
    - shadowgovt 2y ago
      Mostly for reactive rendering in response to incoming small data packets (or user supplied changes) mutating state. I have not seen an example of how to do that using vanilla HTML and CSS without some JavaScript support. Maybe it exists and I haven't come across it.
  - 2y ago
mentalgear 2y ago
This advise may have been correct for old-school SPAs, but most if not all points should be fixed in the current generation. E.g. first page load is static or SSR, and then the page is hydrated as a accessible SPA including url manipulation. Also automatic a no-js fallbacks are provided with many.
- wild_egg 2y ago
  Having to deploy a dedicated server unit to render your frontend is a lot of additional complexity for zero benefit when you still require an API server to actually drive everything. 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
- mrthrowaway999 2y ago
  Why bring in all that extra complexity in the first place, even if it works? 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).
- pylua 2y ago
  Yeah— I was thinking the article was not being fair. That said, try using a website across a wide variety of browsers and os and you will get a wide variety of interpretations. Since it’s a government website that is not acceptable.
- deleted 2y ago
  [deleted]
simmerup 2y ago
User first programming rather than work inflating bloated frameworks mainly used to justify further dev work. Which one do engineers choose
- bigfatkitten 2y ago
  The one they can put in their promo packet, obviously.
- andrepd 2y ago
  I think SWE must be the only (allegedly) engineering discipline where developer convenience is overtly prioritised above product quality or user experience. 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.
  - endemic 2y ago
    The funny thing is that DX for JS apps is usually _worse_: 2x the code just so we don’t have a page transition.
    - simmerup 2y ago
      And also screw up the browsers back functionality in the process
projectileboy 2y ago
OMG it feels so good to not be the lone voice in the woods. I would say about 3/4 of my frustrations as a user are from sites that should have simply been built with HTML + CSS and minimal Javascript. The front end community most days feels like a jobs program.
- pjmlp 2y ago
  Same here as developer, I only put up with SPAs at work, because job title isn't doing fronted stuff. However on side projects it is pretty much vanilla.js without any kind of SPA related stuff.
- stavros 2y ago
  You aren't alone, I'm a technical director and even I can't win this battle. We have a ton of complexity on what could be a simple SSR site, but frontend devs don't like writing anything but SPAs, so it's hard to change.
  - haliskerbas 2y ago
    Hope next.js 14 isn’t the framework behind the “simple SSR site”
    - stavros 2y ago
      It's Django. Next.js fails the "simple" part.
  - dazzawazza 2y ago
    My constant battle in the last 15 years (of 30 years of development) has been the unending torrent of completely unneccesary complexity that teams inflict on themselves. I feel it's often just to pad their CVs or because the current *perfectly usable* stack is boring. 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.
randomifcpfan 2y ago
“You should consider using this in your requirements” implies that this is not a hard rule, it’s just an ignorable suggestion. It would be interesting to audit gov.uk web pages over time to see whether this advice is being followed.
- etothepii 2y ago
  Don't forget the rules of British English that make it very clear that the grammatical construction: "you should consider" means "you must in all circumstances save for the immediate alternate outcome being a genocide."
  - randomifcpfan 2y ago
    Thanks for explaining! That’s quite different from the US English (and RFC English) meaning of “should”.
    - etothepii 2y ago
      This translation guide is usually helpful. https://polish2english.files.wordpress.com/2011/11/55551980-anglo-eu-translation-guide1.pdf https://polish2english.files.wordpress.com/2011/11/55551980-... I'm afraid I don't know what RFC English is and neither does Google.
      - valley_guy_12 2y ago
        Huh, for me the very first non-ad result for googleing RFC English is https://en.wikipedia.org/wiki/Request_for_Comments https://en.wikipedia.org/wiki/Request_for_Comments, which is the correct citation.
        etothepii 2y ago
        For me it was to do with Rugby Football.
    - layer8 2y ago
jt2190 2y ago
Even the article notes that mindless server-side is not good software engineering. (Note the use of the phrase "can cause problems" instead of "does cause problems".): > 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.
lousken 2y ago
hopefully developers will start paying attention some day, if i see a webpage that renders blank with js off, i leave
- layer8 2y ago
  I do the same for sentences starting in lower case and missing punctuation.
twooclock 2y ago
This is what I try to follow - serving html with prefetch data from the server, what could be done on client I do on client to minimize server round trips, minimum css (responsive layout) and vanilla js. Separate web pages as needed. Somehow that sounds weird and oldfashioned with my colleagues since I'm using only html, css and vanilla js? I don't miss a thing...
globular-toast 2y ago
I started web stuff in the 90s as a child. I didn't know what CSS or JS were, except the latter you could copy/paste some magic scripts to make things flash and suchlike. Later I built dynamic sites with PHP for local businesses. I learnt JS and CSS at this point (to some extent as least). Then I decided to quit web development because I couldn't stand spending so much time things to work with the shittiest browser available (IE6). 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.
- mrthrowaway999 2y ago
  Similar experience. 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.
- Gooblebrai 2y ago
  I'd argue that doing client validation saves your server from superfluous requests just to validate that your username input has less than 16 characters. Of course, you later still do it in the server again because you can't never trust the clients Reducing server workload is useful
noop2714 2y ago
What’s old is new again. Maybe we should prioritize the simplest possible solution rather than what’s trendy today.
- pjmlp 2y ago
  Just watched the recent DHH keynote at Rails World, I might not do Rails, but fully on-board with his point of view with where modern Web has gone.
- devoidskeleton 2y ago
  Following trends is why 99.9% of developers are useless and should never hold an engineering title.
- TimReynolds 2y ago
  Not really. The UK government has never supported the use of JavaScript in its web services and has heavily invested in design systems which use html and css with accessibility at their core. Just because the rest of the industry has been high on JS doesn’t mean everyone has.
pjmlp 2y ago
Great that government organisations are putting a break into the insanity of SPA frameworks for static content.
Elfener 2y ago
A lot of (younger?) people seem to think that you need JS when just a regular html form would do.
- Already__Taken 2y ago
  ah ageism. If younger guys think that it's the old lot writing shit docs/blogs giving them the idea.
- icedchai 2y ago
  I’ve run into developers that don’t understand how regular HTML forms work and think everything needs a REST call with JSON. Many of them were not young.
  - sscarduzio 2y ago
    Me too, I was devastated. The guy was a super expensive senior react dev. He literally went like: “Wdym multipart form data?”
    - icedchai 2y ago
      Sadly, we now have a whole generation of web devs that don't know anything other than SPAs.
meindnoch 2y ago
Amen. Amen. Amen.
earnesti 2y ago
Singe page apps suck arse. This really isn't news to anyone, except for those who make money by developing that garbage.
pylua 2y ago
I am definitely one that believes the fronted is way too complicated. That said, however, there is a list of four inaccessibilities in the article, and I was thinking that spas have work around for these.
raddan 2y ago
> If your JavaScript uses a syntax or calls an API that is not supported in the user’s browser, it will error … Pet peeve: when did “to error” become a verb? Otherwise, I wish the rest of the web were designed this way.
- margarina72 2y ago
  it depends which release of the english language you are using
ksynwa 2y ago
Genuine question: Judging from the comments, seems like people like this approach. So why is the general trend more towards approaches that use javascript (sometimes unnecessarily) and frameworks like React?
- slashdave 2y ago
  Because browsers are being used as application frameworks (i.e. for making applications) rather than what they were designed for.
  - dariusj18 2y ago
    The dream has long been to have code distributed to thin clients while allowing intensive tasks to be run on servers.
    - shadowgovt 2y ago
      That's one dream. There are advantages to thick clients as well... less network traffic if the device can do processing on site, A much easier to maintain and update distribution model over the traditional desktop experience for what is essentially application software, etc.
- entuno 2y ago
  As an end user, I really like the style of applications that GOV.UK write and endorses - lightweight, clean layouts, accessible, and generally work with minimal (or no) JavaScript. And I dislike most SPAs, because they usually end up breaking lots of expected browser functionally, are useless without JavaScript, and often load all kinds of heavy dependencies from various third party sites. But what users like and what developers like (and can quickly develop) are often very different things.
  - nonrandomstring 2y ago
    Ambivalence is a weird thing. People often speak in two minds. We hate AI, but we love AI. I love ice-cream and crisps. but I tell my kid not to eat that. As George Carlin said, when you're driving everybody going 5 mph slower than you is an idiot, and everybody going 5 mph faster is a maniac. 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.
ksec 2y ago
If only the rest of the UK Gov IT system is as good as their Web Design teams. Instead they pay huge sums of money to Oracle or Accenture. On another note a lot of the UK Gov Web services runs on Ruby Rails. https://github.com/alphagov https://github.com/alphagov
WA 2y ago
A good rule of thumb is: if your app can/could run offline-first like a desktop app, it's ok to make it a single-page application. They can be snappier and better than a multi-page browser app. Examples would be stuff like Photopea, Google Docs/Sheets, tldraw, etc. 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.
- synergy20 2y ago
  This is a good point. Web platform is now doing both websites and GUIs cross-platform. If you need anything offline or desktop GUI alike across multiple OSes, SPA is your friend, if you just want to build a website, SPA might not be the best fit.
- layer8 2y ago
  You have to test a lot though, especially in contexts like gov.uk, since a significant number of users is still using older phones with browsers that aren’t updated anymore (like for example iOS 15 Safari).
- j45 2y ago
  Snappier is an outdated concept. HTML has lots of tools in it now. SPA's are one thing, the complexity to create it is another.
amazingamazing 2y ago
There are bad sever side apps and “single page apps”.
synergy20 2y ago
For medium to large projects, SPA or not basically boils down to the question where you want to manage the state and logic, is it at frontend(SPA) or backend(MVC,CRUD,etc), you still have to do that somewhere with complexity. If the website is simple then definitely no SPA is needed, either htmx or alpinejs or vanilla can get the job done.
- endemic 2y ago
  > you still have to do that somewhere with complexity Don’t forget about the other “invisible” requirements with a JS solution — more tests, more code, longer builds, more 3rd party libraries.
  - synergy20 2y ago
    or you have to test Model View and Controller at the backend, the backend can be messy as well over time, not to mention it has to sync with frontend team. it depends on team experience, e.g. stronger at backend or frontend and more importantly, how they work together.
- redman25 2y ago
  Unless you're building a local first app (i.e. google sheets), the backend for most web apps is the source of truth. SPAs that lazy load tons of data on the frontend are introducing a lot of complexity trying to sync state between the frontend and backend. Having a single source of truth by push things down into the backend is a godsend in terms of limiting complexity.
IshKebab 2y ago
Ok but let's not deify gov.uk. Yes it's very good compared to most government websites but it's not the peak of web design. They are so anally averse to any form of JavaScript or interactivity that often the web pages become quite tedious to use, e.g. when picking dates for payments, they don't have a "tomorrow" button even though that's what you want 99.999% of the time because that would need the dreaded JavaScript.
- lupire 2y ago
  There is no need for JavaScript for a Tomorrow button.
- philgyford 2y ago
  Personally I'd always want "today", never "tomorrow". 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.
  - IshKebab 2y ago
    Today isn't an option for the form I'm thinking of (tax free childcare); you can't set up payments for the same day. Really you want "asap" but I was simplifying for discussion.
    - dracos 2y ago
      I agree the tax-free childcare form could certainly be improved (I've even written a script to do the three-monthly reconfirmation for me, see my latest gist, though that's policy rather than tech!), but you can set up payments for the same day, you put today's date in (that is what I do; it gives a "You've asked for a payment of £x to be made to [site] today" extra confirmation step). There's nothing in the service manual page that says they couldn't enhance this form with a button as you're suggesting, and hopefully one day they will, though you're always actually worrying it could get worse...
locallost 2y ago
It's not entirely the fault of developers that we are in this state, where they follow every "fad" (if it's a fad). People get paid better when they do modern tech, especially if they do slightly mundane work, e.g. apps that boil down to forms and CRUD, that have a lot of detail to get right, but aren't that challenging on its own (they often end up being). I remember about 10 years ago, I did a bit of Angular in some projects and there was a client that knew that and insisted I was working for them. I even heard my boss on the phone once saying "yes so and so is not the only one that does Angular". So I had it good just because I dabbled in tech that was hot at the moment. Other devs also want to be in that place so they follow the trends. 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.
andrepd 2y ago
Some different type of praise: I absolutely love the voice used throughout gov.uk (this page being no exception). The language and tone is clear, straightforward, to the point, neutral, as technical as it needs to be and no more, and stripped of unnecessary flourish, without being dry. Amazing!
arendtio 2y ago
In Germany, a government service is considered digital when there is an online form where you can enter the data. Afterward, it doesn't matter if you must print it out and send it via postal services (no kidding); all that is required is an online form. 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...
- gryzzly 2y ago
  I on the contrary applaud whoever built the new citizenship application form as HTML. It saved state money and users time. I’m quite sure it would have taken longer and worked worse if it was a SPA built by the gov. contractors.
  - arendtio 2y ago
    But what value does an HTML form alone have? Compared to the old offline version, you have more trouble authenticating before filling it out (which isn't worth anything because you have to sign it anyway...).
amelius 2y ago
Why is Linux not in this list: https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices https://www.gov.uk/service-manual/technology/designing-for-d...
- layer8 2y ago
  Less than 2% of users?
- shadowgovt 2y ago
  The flippant answer: because it's a kernel. 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).
- arp242 2y ago
  Why should it be on that list? When does a webpage work on macOS and Windows but not Linux?
shadowgovt 2y ago
They can have whatever rules they want, but for what it's worth there's nothing about SPAs that makes those four bullet points a reason not to do them. You can write an SPA that is accessibility friendly, maintains focus, and respects the back button. 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.
sscarduzio 2y ago
Can Gov.uk become the new W3C? Pretty please?
- layer8 2y ago
  You mean the new WHATWG.
hakanderyal 2y ago
In the frontend dev land, there is a constant tension between user experience(UX) and developer experience(DX). 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.
Frost1x 2y ago
I’ve helped build significant portions (nearly all, technically speaking) of a few small US government services through contracts, so I’ll share my opinion although I realize US government agencies may be a bit different than those in the UK government. 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).
voidr 2y ago
I love simple and accessible websites as much as everyone else, but I believe this leans way too much into extremity and dictates solutions instead of requirements. 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.
WuxiFingerHold 2y ago
I don't get it (really, not pretending). I know many SPAs are crap, but if SPAs were inherently crap, then all SPAs would be at least kind of crap. So, I see those website below as examples and ask myself: What's wrong with those: https://vitepress.dev/ https://vitepress.dev/ https://www.solidjs.com/ https://www.solidjs.com/ 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.
- eddd-ddde 2y ago
  It's easy to make an SPA blow out of proportions and exponentially ruin UX. 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.

244 points by artbristol 2y ago

This is very good advice.

> If you use a JavaScript framework you should: > > be able to justify with evidence, how using JavaScript would benefit users Steady on, guys.

joseferben 2y ago
for real, do you want swarms of developers to lose their jobs because software complexity collapsed?
- mrthrowaway999 2y ago
  If we want full employment, we should mandate people use spoons instead of shovels.
  - joseferben 2y ago
    https://en.wikipedia.org/wiki/Perverse_incentive https://en.wikipedia.org/wiki/Perverse_incentive
j45 2y ago
Use? I look at all the time to keep it running.

pensatoio 2y ago

I wish the whole internet followed this advice.

fouronnes3 2y ago
We could shutdown a few dozen powerplants easy.
- mfenniak 2y ago
  Great idea, more capacity for LLMs! /s
- EasyMark 2y ago
  Wait until you hear about the next big thing, AI compute centers, and those plant shutdowns will be a drop in the ocean…

truculent 2y ago

Good advice, but > - 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

ljm 2y ago
You kind of get it out of the box with plain old HTML though. Once you get into SPA territory you’re reinventing a lot of wheels to get back to parity, or replacing native functionality with JS alternatives. 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.
- bufferoverflow 2y ago
  You can easily store intermediate state in sessionStorage or localStorage and prevent all the unneeded requests to the server just for moving between steps.
- truculent 2y ago
  Yes, hence why it’s good advice.
edelbitter 2y ago
How could you possibly make them true, if you are told to respect even deliberately disabled features? If the user does not permit retroactively messing with their navigation history, then you are left with only one option: get the history right, at the time it is written.
earnesti 2y ago
> These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother 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.

wg0 2y ago

When even governments knows the web better than the tech industry by and large itself. 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.

mentalgear 2y ago
Despise React's unnecessary complexity and non-standard-compliant non-separation-of-concerns squeeze-it-all-in-js approach as well. 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.
- mhoad 2y ago
  Lit is also totally web standards compliant to be fair.
  - deleted 2y ago
    [deleted]
- wg0 2y ago
  React in the hook's era has gotten overly complex. The cods is unreadable and hard to reason about. Check any longer/complicated component as an example riddled with hooks. 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?
  - shadowgovt 2y ago
    Mostly for reactive rendering in response to incoming small data packets (or user supplied changes) mutating state. I have not seen an example of how to do that using vanilla HTML and CSS without some JavaScript support. Maybe it exists and I haven't come across it.
- 2y ago

mentalgear 2y ago

This advise may have been correct for old-school SPAs, but most if not all points should be fixed in the current generation. E.g. first page load is static or SSR, and then the page is hydrated as a accessible SPA including url manipulation. Also automatic a no-js fallbacks are provided with many.

wild_egg 2y ago
Having to deploy a dedicated server unit to render your frontend is a lot of additional complexity for zero benefit when you still require an API server to actually drive everything. 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
mrthrowaway999 2y ago
Why bring in all that extra complexity in the first place, even if it works? 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).
pylua 2y ago
Yeah— I was thinking the article was not being fair. That said, try using a website across a wide variety of browsers and os and you will get a wide variety of interpretations. Since it’s a government website that is not acceptable.
deleted 2y ago
[deleted]

simmerup 2y ago

User first programming rather than work inflating bloated frameworks mainly used to justify further dev work. Which one do engineers choose

bigfatkitten 2y ago
The one they can put in their promo packet, obviously.
andrepd 2y ago
I think SWE must be the only (allegedly) engineering discipline where developer convenience is overtly prioritised above product quality or user experience. 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.
- endemic 2y ago
  The funny thing is that DX for JS apps is usually _worse_: 2x the code just so we don’t have a page transition.
  - simmerup 2y ago
    And also screw up the browsers back functionality in the process

projectileboy 2y ago

OMG it feels so good to not be the lone voice in the woods. I would say about 3/4 of my frustrations as a user are from sites that should have simply been built with HTML + CSS and minimal Javascript. The front end community most days feels like a jobs program.

pjmlp 2y ago
Same here as developer, I only put up with SPAs at work, because job title isn't doing fronted stuff. However on side projects it is pretty much vanilla.js without any kind of SPA related stuff.
stavros 2y ago
You aren't alone, I'm a technical director and even I can't win this battle. We have a ton of complexity on what could be a simple SSR site, but frontend devs don't like writing anything but SPAs, so it's hard to change.
- haliskerbas 2y ago
  Hope next.js 14 isn’t the framework behind the “simple SSR site”
  - stavros 2y ago
    It's Django. Next.js fails the "simple" part.
- dazzawazza 2y ago
  My constant battle in the last 15 years (of 30 years of development) has been the unending torrent of completely unneccesary complexity that teams inflict on themselves. I feel it's often just to pad their CVs or because the current *perfectly usable* stack is boring. 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.

randomifcpfan 2y ago

“You should consider using this in your requirements” implies that this is not a hard rule, it’s just an ignorable suggestion. It would be interesting to audit gov.uk web pages over time to see whether this advice is being followed.

etothepii 2y ago
Don't forget the rules of British English that make it very clear that the grammatical construction: "you should consider" means "you must in all circumstances save for the immediate alternate outcome being a genocide."
- randomifcpfan 2y ago
  Thanks for explaining! That’s quite different from the US English (and RFC English) meaning of “should”.
  - etothepii 2y ago
    This translation guide is usually helpful. https://polish2english.files.wordpress.com/2011/11/55551980-anglo-eu-translation-guide1.pdf https://polish2english.files.wordpress.com/2011/11/55551980-... I'm afraid I don't know what RFC English is and neither does Google.
    - valley_guy_12 2y ago
      Huh, for me the very first non-ad result for googleing RFC English is https://en.wikipedia.org/wiki/Request_for_Comments https://en.wikipedia.org/wiki/Request_for_Comments, which is the correct citation.
      - etothepii 2y ago
        For me it was to do with Rugby Football.
  - layer8 2y ago

jt2190 2y ago

Even the article notes that mindless server-side is not good software engineering. (Note the use of the phrase "can cause problems" instead of "does cause problems".): > 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.

lousken 2y ago

hopefully developers will start paying attention some day, if i see a webpage that renders blank with js off, i leave

layer8 2y ago
I do the same for sentences starting in lower case and missing punctuation.

twooclock 2y ago

This is what I try to follow - serving html with prefetch data from the server, what could be done on client I do on client to minimize server round trips, minimum css (responsive layout) and vanilla js. Separate web pages as needed. Somehow that sounds weird and oldfashioned with my colleagues since I'm using only html, css and vanilla js? I don't miss a thing...

globular-toast 2y ago

I started web stuff in the 90s as a child. I didn't know what CSS or JS were, except the latter you could copy/paste some magic scripts to make things flash and suchlike. Later I built dynamic sites with PHP for local businesses. I learnt JS and CSS at this point (to some extent as least). Then I decided to quit web development because I couldn't stand spending so much time things to work with the shittiest browser available (IE6). 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.

mrthrowaway999 2y ago
Similar experience. 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.
Gooblebrai 2y ago
I'd argue that doing client validation saves your server from superfluous requests just to validate that your username input has less than 16 characters. Of course, you later still do it in the server again because you can't never trust the clients Reducing server workload is useful

noop2714 2y ago

What’s old is new again. Maybe we should prioritize the simplest possible solution rather than what’s trendy today.

pjmlp 2y ago
Just watched the recent DHH keynote at Rails World, I might not do Rails, but fully on-board with his point of view with where modern Web has gone.
devoidskeleton 2y ago
Following trends is why 99.9% of developers are useless and should never hold an engineering title.
TimReynolds 2y ago
Not really. The UK government has never supported the use of JavaScript in its web services and has heavily invested in design systems which use html and css with accessibility at their core. Just because the rest of the industry has been high on JS doesn’t mean everyone has.

pjmlp 2y ago

Great that government organisations are putting a break into the insanity of SPA frameworks for static content.

Elfener 2y ago

A lot of (younger?) people seem to think that you need JS when just a regular html form would do.

Already__Taken 2y ago
ah ageism. If younger guys think that it's the old lot writing shit docs/blogs giving them the idea.
icedchai 2y ago
I’ve run into developers that don’t understand how regular HTML forms work and think everything needs a REST call with JSON. Many of them were not young.
- sscarduzio 2y ago
  Me too, I was devastated. The guy was a super expensive senior react dev. He literally went like: “Wdym multipart form data?”
  - icedchai 2y ago
    Sadly, we now have a whole generation of web devs that don't know anything other than SPAs.

meindnoch 2y ago

Amen. Amen. Amen.

earnesti 2y ago

Singe page apps suck arse. This really isn't news to anyone, except for those who make money by developing that garbage.

pylua 2y ago

I am definitely one that believes the fronted is way too complicated. That said, however, there is a list of four inaccessibilities in the article, and I was thinking that spas have work around for these.

raddan 2y ago

> If your JavaScript uses a syntax or calls an API that is not supported in the user’s browser, it will error … Pet peeve: when did “to error” become a verb? Otherwise, I wish the rest of the web were designed this way.

margarina72 2y ago
it depends which release of the english language you are using

ksynwa 2y ago

Genuine question: Judging from the comments, seems like people like this approach. So why is the general trend more towards approaches that use javascript (sometimes unnecessarily) and frameworks like React?

slashdave 2y ago
Because browsers are being used as application frameworks (i.e. for making applications) rather than what they were designed for.
- dariusj18 2y ago
  The dream has long been to have code distributed to thin clients while allowing intensive tasks to be run on servers.
  - shadowgovt 2y ago
    That's one dream. There are advantages to thick clients as well... less network traffic if the device can do processing on site, A much easier to maintain and update distribution model over the traditional desktop experience for what is essentially application software, etc.
entuno 2y ago
As an end user, I really like the style of applications that GOV.UK write and endorses - lightweight, clean layouts, accessible, and generally work with minimal (or no) JavaScript. And I dislike most SPAs, because they usually end up breaking lots of expected browser functionally, are useless without JavaScript, and often load all kinds of heavy dependencies from various third party sites. But what users like and what developers like (and can quickly develop) are often very different things.
- nonrandomstring 2y ago
  Ambivalence is a weird thing. People often speak in two minds. We hate AI, but we love AI. I love ice-cream and crisps. but I tell my kid not to eat that. As George Carlin said, when you're driving everybody going 5 mph slower than you is an idiot, and everybody going 5 mph faster is a maniac. 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.

ksec 2y ago

If only the rest of the UK Gov IT system is as good as their Web Design teams. Instead they pay huge sums of money to Oracle or Accenture. On another note a lot of the UK Gov Web services runs on Ruby Rails. https://github.com/alphagov https://github.com/alphagov

WA 2y ago

A good rule of thumb is: if your app can/could run offline-first like a desktop app, it's ok to make it a single-page application. They can be snappier and better than a multi-page browser app. Examples would be stuff like Photopea, Google Docs/Sheets, tldraw, etc. 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.

synergy20 2y ago
This is a good point. Web platform is now doing both websites and GUIs cross-platform. If you need anything offline or desktop GUI alike across multiple OSes, SPA is your friend, if you just want to build a website, SPA might not be the best fit.
layer8 2y ago
You have to test a lot though, especially in contexts like gov.uk, since a significant number of users is still using older phones with browsers that aren’t updated anymore (like for example iOS 15 Safari).
j45 2y ago
Snappier is an outdated concept. HTML has lots of tools in it now. SPA's are one thing, the complexity to create it is another.

amazingamazing 2y ago

There are bad sever side apps and “single page apps”.

synergy20 2y ago

For medium to large projects, SPA or not basically boils down to the question where you want to manage the state and logic, is it at frontend(SPA) or backend(MVC,CRUD,etc), you still have to do that somewhere with complexity. If the website is simple then definitely no SPA is needed, either htmx or alpinejs or vanilla can get the job done.

endemic 2y ago
> you still have to do that somewhere with complexity Don’t forget about the other “invisible” requirements with a JS solution — more tests, more code, longer builds, more 3rd party libraries.
- synergy20 2y ago
  or you have to test Model View and Controller at the backend, the backend can be messy as well over time, not to mention it has to sync with frontend team. it depends on team experience, e.g. stronger at backend or frontend and more importantly, how they work together.
redman25 2y ago
Unless you're building a local first app (i.e. google sheets), the backend for most web apps is the source of truth. SPAs that lazy load tons of data on the frontend are introducing a lot of complexity trying to sync state between the frontend and backend. Having a single source of truth by push things down into the backend is a godsend in terms of limiting complexity.

IshKebab 2y ago

Ok but let's not deify gov.uk. Yes it's very good compared to most government websites but it's not the peak of web design. They are so anally averse to any form of JavaScript or interactivity that often the web pages become quite tedious to use, e.g. when picking dates for payments, they don't have a "tomorrow" button even though that's what you want 99.999% of the time because that would need the dreaded JavaScript.

lupire 2y ago
There is no need for JavaScript for a Tomorrow button.
philgyford 2y ago
Personally I'd always want "today", never "tomorrow". 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.
- IshKebab 2y ago
  Today isn't an option for the form I'm thinking of (tax free childcare); you can't set up payments for the same day. Really you want "asap" but I was simplifying for discussion.
  - dracos 2y ago
    I agree the tax-free childcare form could certainly be improved (I've even written a script to do the three-monthly reconfirmation for me, see my latest gist, though that's policy rather than tech!), but you can set up payments for the same day, you put today's date in (that is what I do; it gives a "You've asked for a payment of £x to be made to [site] today" extra confirmation step). There's nothing in the service manual page that says they couldn't enhance this form with a button as you're suggesting, and hopefully one day they will, though you're always actually worrying it could get worse...

locallost 2y ago

It's not entirely the fault of developers that we are in this state, where they follow every "fad" (if it's a fad). People get paid better when they do modern tech, especially if they do slightly mundane work, e.g. apps that boil down to forms and CRUD, that have a lot of detail to get right, but aren't that challenging on its own (they often end up being). I remember about 10 years ago, I did a bit of Angular in some projects and there was a client that knew that and insisted I was working for them. I even heard my boss on the phone once saying "yes so and so is not the only one that does Angular". So I had it good just because I dabbled in tech that was hot at the moment. Other devs also want to be in that place so they follow the trends. 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.

andrepd 2y ago

Some different type of praise: I absolutely love the voice used throughout gov.uk (this page being no exception). The language and tone is clear, straightforward, to the point, neutral, as technical as it needs to be and no more, and stripped of unnecessary flourish, without being dry. Amazing!

arendtio 2y ago

In Germany, a government service is considered digital when there is an online form where you can enter the data. Afterward, it doesn't matter if you must print it out and send it via postal services (no kidding); all that is required is an online form. 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...

gryzzly 2y ago
I on the contrary applaud whoever built the new citizenship application form as HTML. It saved state money and users time. I’m quite sure it would have taken longer and worked worse if it was a SPA built by the gov. contractors.
- arendtio 2y ago
  But what value does an HTML form alone have? Compared to the old offline version, you have more trouble authenticating before filling it out (which isn't worth anything because you have to sign it anyway...).

amelius 2y ago

Why is Linux not in this list: https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices https://www.gov.uk/service-manual/technology/designing-for-d...

layer8 2y ago
Less than 2% of users?
shadowgovt 2y ago
The flippant answer: because it's a kernel. 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).
arp242 2y ago
Why should it be on that list? When does a webpage work on macOS and Windows but not Linux?

shadowgovt 2y ago

They can have whatever rules they want, but for what it's worth there's nothing about SPAs that makes those four bullet points a reason not to do them. You can write an SPA that is accessibility friendly, maintains focus, and respects the back button. 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.

sscarduzio 2y ago

Can Gov.uk become the new W3C? Pretty please?

layer8 2y ago
You mean the new WHATWG.

hakanderyal 2y ago

In the frontend dev land, there is a constant tension between user experience(UX) and developer experience(DX). 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.

Frost1x 2y ago

I’ve helped build significant portions (nearly all, technically speaking) of a few small US government services through contracts, so I’ll share my opinion although I realize US government agencies may be a bit different than those in the UK government. 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).

voidr 2y ago

I love simple and accessible websites as much as everyone else, but I believe this leans way too much into extremity and dictates solutions instead of requirements. 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.

WuxiFingerHold 2y ago

I don't get it (really, not pretending). I know many SPAs are crap, but if SPAs were inherently crap, then all SPAs would be at least kind of crap. So, I see those website below as examples and ask myself: What's wrong with those: https://vitepress.dev/ https://vitepress.dev/ https://www.solidjs.com/ https://www.solidjs.com/ 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.

eddd-ddde 2y ago
It's easy to make an SPA blow out of proportions and exponentially ruin UX. 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.