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.
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.
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).
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.
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.
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
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.
> 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.
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.
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.
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).
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?
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.
Nobody got fired for building an app in React? When something is an accepted as an industry standard, it's safe to make a decision that goes with the flow. Also, nobody is doing devrel for html/css/vanilla js - if you search how to do things you will find nearly only exclusively framework related content.
There's no cost to building slow, fragile, and inefficient websites.
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.
Because the trend is also towards doing more over the web.
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).
My gut is that the government wants services that work for 100% of people. In terms of purely costs, people who can't use a site may need to be serviced anyway by more expensive means (e.g., voter registration by mail).
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)
1. Complexity. Devs like complexity like cats like catnip.
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.
UIs in general are pretty hard unless you have a set of primitives that do everything you want. HTML + CSS used to be lacking (and still are in some respects). A thin layer of vanilla js on top of them has a tendency to turn into a mess of spaghetti as more and more features are added. So, you organize it into a framework. But a framework needs to be able to assert control over anything that would affect how it renders, which is pretty much everything a browser might do, leading to an SPA.
I think it’s a nice idea, but given the bean-counting-efficiency-experts that run the company, this will never fly “build for the 90-95%” is what I constantly heard from bosses before I left frontend and went to backend, and eventually leaving the cloud industry all together. I can see it working for government sites though because profit isn’t the sole purpose of the website, it’s more there to serve the public as a whole.
Firstly it's what looks good in demos, both internally to management and when trying to sell things to consumers. Government services have users without a choice and usually that they have to provide it has been decided top down.
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.
Because most websites today are more than just informational. Some web apps facilitate complex user interactions which typically require a lot of state which are the raison d'etre of web frameworks.
Because the ux and dx are better once you reach a certain amount of complexity. Companies know what is best for their business.
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.
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...
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.
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.
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!
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.
“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.
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."
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.
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.
It seems that the pendulum of public opinion is swinging back towards simple, mostly HTML-based solutions, with the rise of intermediate solutions like htmx.
I don’t make sites like gov.uk or any random-user facing sites, but they are fast, frustrationless and “frontend”. I use them myself. Coming from desktop UIs (from most of them, and they are like 100x superior), writing 1.0 websites is a sort of bdsm to me. I actually avoided web programming before 2.0 became a thing.
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'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.
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.
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.
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.
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.
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.
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.
I suspect when you specify “100% availability to the public” then even the most React-ionary devs will soon realize they will have to go down this alley since they have to handle browsers with javascript turned off.
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.
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.
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
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).
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.
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).
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.
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.
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.
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...
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.
bigfatkitten|1 year ago
Steady on, guys.
joseferben|1 year ago
j45|1 year ago
WA|1 year ago
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|1 year ago
j45|1 year ago
SPA's are one thing, the complexity to create it is another.
layer8|1 year ago
globular-toast|1 year ago
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|1 year ago
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|1 year ago
Reducing server workload is useful
truculent|1 year ago
> - 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|1 year ago
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.
earnesti|1 year ago
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.
c0wb0yc0d3r|1 year ago
edelbitter|1 year ago
pensatoio|1 year ago
fouronnes3|1 year ago
noop2714|1 year ago
Maybe we should prioritize the simplest possible solution rather than what’s trendy today.
devoidskeleton|1 year ago
TimReynolds|1 year ago
Just because the rest of the industry has been high on JS doesn’t mean everyone has.
pjmlp|1 year ago
amelius|1 year ago
https://www.gov.uk/service-manual/technology/designing-for-d...
shadowgovt|1 year ago
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|1 year ago
layer8|1 year ago
ksynwa|1 year ago
entuno|1 year ago
But what users like and what developers like (and can quickly develop) are often very different things.
margarina72|1 year ago
mrthrowaway999|1 year ago
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
philipwhiuk|1 year ago
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).
stavros|1 year ago
In fact, I think that people dislike this approach because they are frontend developers, as otherwise there would be very little frontend to develop.
bogtog|1 year ago
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)
andyjohnson0|1 year ago
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.
slashdave|1 year ago
scarmig|1 year ago
EasyMark|1 year ago
dtech|1 year ago
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.
derangedHorse|1 year ago
nfw2|1 year ago
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.
twooclock|1 year ago
jt2190|1 year ago
> 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.
simmerup|1 year ago
andrepd|1 year ago
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.
bigfatkitten|1 year ago
andrepd|1 year ago
ksec|1 year ago
On another note a lot of the UK Gov Web services runs on Ruby Rails.
https://github.com/alphagov
Elfener|1 year ago
icedchai|1 year ago
Already__Taken|1 year ago
randomifcpfan|1 year ago
philipwhiuk|1 year ago
> 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.
etothepii|1 year ago
earnesti|1 year ago
projectileboy|1 year ago
stavros|1 year ago
jonathrg|1 year ago
pjmlp|1 year ago
However on side projects it is pretty much vanilla.js without any kind of SPA related stuff.
wruza|1 year ago
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).
locallost|1 year ago
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.
WuxiFingerHold|1 year ago
So, I see those website below as examples and ask myself: What's wrong with those:
https://vitepress.dev/
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|1 year ago
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.
synergy20|1 year ago
If the website is simple then definitely no SPA is needed, either htmx or alpinejs or vanilla can get the job done.
redman25|1 year ago
Having a single source of truth by push things down into the backend is a godsend in terms of limiting complexity.
endemic|1 year ago
Don’t forget about the other “invisible” requirements with a JS solution — more tests, more code, longer builds, more 3rd party libraries.
voidr|1 year ago
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.
lousken|1 year ago
layer8|1 year ago
pjmlp|1 year ago
hnarayanan|1 year ago
hakanderyal|1 year ago
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.
wg0|1 year ago
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.
EasyMark|1 year ago
mentalgear|1 year ago
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.
sscarduzio|1 year ago
layer8|1 year ago
mentalgear|1 year ago
wild_egg|1 year ago
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|1 year ago
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).
unknown|1 year ago
[deleted]
pylua|1 year ago
pylua|1 year ago
That said, however, there is a list of four inaccessibilities in the article, and I was thinking that spas have work around for these.
Frost1x|1 year ago
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).
amazingamazing|1 year ago
IshKebab|1 year ago
philgyford|1 year ago
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.
lupire|1 year ago
shadowgovt|1 year ago
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.
raddan|1 year ago
Pet peeve: when did “to error” become a verb?
Otherwise, I wish the rest of the web were designed this way.
margarina72|1 year ago
meindnoch|1 year ago
arendtio|1 year ago
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|1 year ago