[HN Gopher] Building a robust frontend using progressive enhance...
___________________________________________________________________
Building a robust frontend using progressive enhancement
Author : artbristol
Score : 221 points
Date : 2024-09-29 11:54 UTC (11 hours ago)
(HTM) web link (www.gov.uk)
(TXT) w3m dump (www.gov.uk)
| hnarayanan wrote:
| This is very good advice.
| bigfatkitten wrote:
| > If you use a JavaScript framework you should: > > be able to
| justify with evidence, how using JavaScript would benefit users
|
| Steady on, guys.
| joseferben wrote:
| for real, do you want swarms of developers to lose their jobs
| because software complexity collapsed?
| mrthrowaway999 wrote:
| If we want full employment, we should mandate people use
| spoons instead of shovels.
| joseferben wrote:
| https://en.wikipedia.org/wiki/Perverse_incentive
| j45 wrote:
| Use? I look at all the time to keep it running.
| pensatoio wrote:
| I wish the whole internet followed this advice.
| fouronnes3 wrote:
| We could shutdown a few dozen powerplants easy.
| mfenniak wrote:
| Great idea, more capacity for LLMs!
|
| /s
| EasyMark wrote:
| Wait until you hear about the next big thing, AI compute
| centers, and those plant shutdowns will be a drop in the
| ocean...
| truculent wrote:
| 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 wrote:
| 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.
| edelbitter wrote:
| 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.
| c0wb0yc0d3r wrote:
| I think that section could be more clear if something like
| "without more effort" was added.
| earnesti wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Lit is also totally web standards compliant to be fair.
| wg0 wrote:
| 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 wrote:
| 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.
| avaldez_ wrote:
| >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.
|
| I'd argue that it's way easier to master the internals of a
| library than a whole bespoke compiler.
| EasyMark wrote:
| 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.
| mentalgear wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| simmerup wrote:
| User first programming rather than work inflating bloated
| frameworks mainly used to justify further dev work. Which one do
| engineers choose
| bigfatkitten wrote:
| The one they can put in their promo packet, obviously.
| andrepd wrote:
| 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 wrote:
| 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 wrote:
| And also screw up the browsers back functionality in the
| process
| projectileboy wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Hope next.js 14 isn't the framework behind the "simple SSR
| site"
| stavros wrote:
| It's Django. Next.js fails the "simple" part.
| dazzawazza wrote:
| 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.
| stavros wrote:
| Hey, at least I managed to consolidate all our services
| into a monolith, which developers ended up really liking,
| and it works well for us.
|
| One battle at a time, I guess, but the "let's simplify the
| frontend" effort is meeting much more resistance from
| people who are interested in the frontend having a lot of
| state.
| Frost1x wrote:
| Part of the issue in the complexity battle is competition
| and levels of expectations from features. Non technical
| decision makers (and there are lots of them, I'd say most
| of them) see services from Facebook, Google, etc. and have
| the same level of feature expectations in their one off
| small app. They have no clue how much effort exists behind
| it to maintain what seems simple and now even standard
| (across large services).
|
| Ultimately they come up with ideas and write feature
| requirements (indirectly) based around this premise with
| their shoestring budget and ad hoc team. And we end up in a
| world with not so well developed applications attempting to
| create similar features to competitors in budget which
| leads to a lot of corner cutting and barely working
| implementations with no thought towards long term
| maintenance requirements. At least, this has been mostly my
| experience.
|
| There are of course those out there simply bored with life
| who want to build unnecessary complexity because they have
| to be doing _something_ (heaven forbid there be idle time
| in any work environment either from their own pressure and
| /or internal organizational pressures) and they start
| trying to be clever or skill up to some wider marketable
| skillset (e.g. react).
|
| It's really business environments that create this sort of
| complexity requirement from needless feature requests to
| wide adoption of specific trendy skills in their stack to
| make hiring easier/cheaper, etc.
| tarsinge wrote:
| Everybody is incentived to use the tools FAANG+ are using
| even if completely unnecessary, ie follow fashion.
| Developers for Resume Driven Development, and execs because
| it reassure investors and is good for marketing. The
| industry doesn't reward smart engineering choices.
| willcipriano wrote:
| > I can't win this battle
|
| You are fighting the wrong battle. You harp on the technology
| used rather than the specific functionality you desire.
|
| The bad way to do it: "You made a single page app with PHP
| and {other tech} and {database}! I hate those! Don't you read
| (reddit, twitter, hacker news)? Best practices say..."
|
| The good way to do it: "Our users often share links within
| the application with each other to navigate and the new
| single page app you demoed doesn't allow that."
|
| Or: "While the page load times look great on the metrics in
| your power point, as everything is lazy loaded it takes 10
| seconds for the page to actual become usable, the old site
| loaded in under a second why are we regressing the user
| experience here?"
|
| Or the evergreen: "What does that buy us?"
| stavros wrote:
| This is fairly basic advice, and it feels a bit insulting
| to assume I'm just hating on some tech. Obviously, if
| things were as easy as "here's the immediate and
| unambiguous problem with this approach", I would have gone
| that way.
|
| Things would be great if the risks were as simple as this.
| The actual problem is "six years later, the frontend is a
| ball of spaghetti code and it takes you two sprints to
| change a component".
|
| How many developers do you think heed those warnings?
| j45 wrote:
| Not enough. But they will scoff at other technologies old
| and new.
| willcipriano wrote:
| > heed those warnings
|
| It's not a warning. It's a functional requirement that
| you put into the ticket. The project isn't done if the
| rewritten page takes longer to load than the old one did.
| Don't ship it, don't pay bonuses based on shipping it.
| stavros wrote:
| Please read my comment more carefully, you're being
| patronizing. I can't put "I want feature development on
| this codebase to be faster than two sprints in six years"
| in the requirements.
| willcipriano wrote:
| Sounds like you should talk to the person who is actually
| in charge then.
| stavros wrote:
| I'll have a chat with the mirror.
| arp242 wrote:
| Our frontend is a bunch of barely working wonky react-soup,
| and we really need to rewrite it. It's mostly a "tables and
| forms"-type frontend with a lot of complexity in the backend:
| it's a great use case for htmx (or even vanilla/jQuery).
|
| But I'm not really sure how we're going to handle that or who
| we'll hire for it, because I fear we'll end up with another
| react-soup. My current strategy is to make a MVP in my spare
| time to show it can be done and that it'll be quite nice.
| stavros wrote:
| The main part is to avoid holding state in two places
| (frontend and backend) if you can do with holding state in
| only one (either frontend or backend).
| redman25 wrote:
| Unless you're building an app that holds data locally,
| for most web apps, you should be pushing state down into
| the backend. Fat models should be your single source of
| truth, skinny controllers, and service functions in order
| to separate data from code for testability.
|
| Avoid caching as much as possible until you absolutely
| need to. As soon as you introduce caching you now have
| multiple sources of truth instead of one.
| bdangubic wrote:
| or be stateless... ;)
| bdangubic wrote:
| after you re-write it (either immediately or with time) you
| will end up with the same thing, just a different kind of
| soup. using vanilla-whatever you will eventually notice you
| are doing "X" over and over again and then you'll start
| writing small libraries (or even worse, some internal
| "framework") which over time will get stale or will get
| bunch of features from devs that need "just that plus a few
| more things.." ad infinitum...
| arp242 wrote:
| This is simply not true, and has never been true anywhere
| I've worked. We can do everything with a much better UX
| in about 2,000 to 3,000 lines of code, instead of ~25,000
| (and almost 2,000 dependencies).
|
| It's a boring tedious "true-ism" that keeps getting
| pounded. I don't really know what else to say, but it's
| simply just not true.
| bdangubic wrote:
| What is the longest you have ever worked on a single
| piece of software? If you are in some sort of consultancy
| or jump jobs every 2-3 years it most definitely won't be
| true. You stay with a product for 5+ years it is bound to
| happen unless your dev shop is like 10 people. If you
| think this is not true AND have spent 5+ years with the
| same piece of software you are an outlier...
| j45 wrote:
| Things like Livewire, and alpine.js are showing simpler ways.
|
| You can build a SPA SSR as well.
| ksec wrote:
| And it doesn't help when the Browser, the Web Spec and front
| end dev are all aligned into making SPAs with JS.
|
| I really wish something like HTMX is built into the browser
| or part of HTML5 spec.
| imacrayon wrote:
| There's a draft proposal to get some of HTMX in the
| browser: https://github.com/alexpetros/triptych
| eddd-ddde wrote:
| Then why hire front end devs for a project that doesn't need
| one?
|
| Probably 80% of websites could do with a good designer that
| knows how to get their designs from concept to CSS and a good
| backend engineer that know how to output decent markup.
| stavros wrote:
| Because someone needs to turn the concept to browser-ready,
| responsive, cross-browser, lightweight markup, and that
| person is a developer who specializes in the frontend, ie a
| frontend developer.
| paulddraper wrote:
| An SSR site needs to have full stack devs, not front end
| devs.
|
| Else you will have exactly this problem
| stavros wrote:
| An SSR site needs a frontend dev to produce the HTML/CSS/JS
| and a backend dev to provide the template variables. You
| don't need a developer to do both when the interface is so
| small.
| paulddraper wrote:
| Nah that's crazy man
| codethief wrote:
| > could be a simple SSR site, but frontend devs don't like
| writing anything but SPAs
|
| It might be worth asking why that is.
|
| I used to write a ton of SSR'ed pages back when that was
| really the only option we had (before people introduced
| jQuery and AJAX), then I wrote SPAs (mostly Angular & React),
| then again SSR'ed websites (Java/Spring/JSP with a ton of
| more-or-less vanilla JavaScript) and now I've been on a Vue-
| based stack (w/ Astro/Vite for SSR) for a number of years.
| And these were all applications with dozens of teams working
| on them in parallel and a corresponding number of components
| & LoC.
|
| Personally, I wouldn't want to go back to traditional SSR
| stacks (Spring/JSP, vanilla PHP, or Python w/ Django or
| Flask) _ever_. People often vastly underestimate the
| complexity of good UIs. They might start simple ( "could be a
| simple SSR site", as you say) and, before long, the wheels
| come off the bus and they look at a big unmaintainable ball
| of vanilla JS on top of HTML templates that are directly
| coupled to the database schema, with global CSS styles
| permeating (infecting) the entire code base.
|
| In my experience, there is a certain amount complexity that
| is _inherent_ to a good UI. It doesn 't matter whether you
| use classic SSR, or modern frontend frameworks like
| Angular/React/Vue/Svelte/SolidJS, or new kids on the block
| like HTMX/Turbo/... -- that complexity will still be there.
| However, with modern frameworks you've at least got a chance
| to tame that beast.
|
| More specifically, what modern frontend frameworks give us
| is: 1) Modularization into components, 2) scoping of styles,
| 3) type-safety, 4) unit-testability of components, 5)
| component-local state management ([?] insanities like Redux),
| 6) clear separation between view/UI logic and business logic.
|
| If you can replicate these features using a bespoke version
| of JSP or HTMX or whatever, great! But if you can't, I'd
| personally rather pick a well-established frontend framework
| like React or Vue. Yes, your developers might still mess that
| up and produce shitty code, but the chances of them messing
| up in a classic SSR stack (without the aforementioned
| features) are _so_ much greater.
| stavros wrote:
| You're arguing against something different, though: I agree
| you shouldn't do components with CSS/jQuery, components
| should be self-contained. I'm arguing against _SPAs_ ,
| where the state of the user's browsing is replicated on the
| frontend as well, with all the complexity this entails.
|
| Isn't there a good component framework we can use, and
| that's it? I want to be able to say <carousel></carousel>
| and have it work, without having to have a whole SPA
| attached to my components library, with routing, state, and
| all the rest. Doesn't that exist?
| jonathrg wrote:
| 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.
| wruza wrote:
| 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).
| layer8 wrote:
| I started avoiding web programming after 2.0 became a thing,
| because it turned into an unmanageable time sink and
| usability nightmare, and it still is.
| wruza wrote:
| And I remember when 1.0 sites erased most of the form on an
| apparent mistake on my part and took ages to load aspx.
| There are facets in each version of web that we tend to see
| or ignore, but it's clear that the common facet is poor
| and/or overcomplicated programming, not a paradigm itself.
| randomifcpfan wrote:
| "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 wrote:
| 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 wrote:
| Thanks for explaining! That's quite different from the US
| English (and RFC English) meaning of "should".
| etothepii wrote:
| This translation guide is usually helpful.
|
| 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 wrote:
| Huh, for me the very first non-ad result for googleing
| RFC English is
| https://en.wikipedia.org/wiki/Request_for_Comments, which
| is the correct citation.
| layer8 wrote:
| To be fair, here is the RFC meaning:
| SHOULD This word, or the adjective "RECOMMENDED", mean
| that there may exist valid reasons in particular
| circumstances to ignore a particular item, but the
| full implications must be understood and carefully
| weighed before choosing a different course.
|
| It means you can't simply ignore it, and instead have to
| have compelling reasons to justify any deviation.
| valley_guy_12 wrote:
| Unfortunately, in many organizations, "the library we use
| doesn't follow this recommendation" is a valid compelling
| reason. Which means that in practice "SHOULD" effectively
| means "WOULD BE NICE IF".
| philipwhiuk wrote:
| Having
|
| > 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.
| jt2190 wrote:
| 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 wrote:
| hopefully developers will start paying attention some day, if i
| see a webpage that renders blank with js off, i leave
| layer8 wrote:
| I do the same for sentences starting in lower case and missing
| punctuation.
| twooclock wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| What's old is new again.
|
| Maybe we should prioritize the simplest possible solution rather
| than what's trendy today.
| pjmlp wrote:
| 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 wrote:
| Following trends is why 99.9% of developers are useless and
| should never hold an engineering title.
| TimReynolds wrote:
| 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 wrote:
| Great that government organisations are putting a break into the
| insanity of SPA frameworks for static content.
| Elfener wrote:
| A lot of (younger?) people seem to think that you need JS when
| just a regular html form would do.
| Already__Taken wrote:
| ah ageism. If younger guys think that it's the old lot writing
| shit docs/blogs giving them the idea.
| icedchai wrote:
| 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 wrote:
| Me too, I was devastated. The guy was a super expensive
| senior react dev. He literally went like: "Wdym multipart
| form data?"
| meindnoch wrote:
| Amen. Amen. Amen.
| earnesti wrote:
| Singe page apps suck arse. This really isn't news to anyone,
| except for those who make money by developing that garbage.
| pylua wrote:
| 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 wrote:
| > 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 wrote:
| it depends which release of the english language you are using
| ksynwa wrote:
| 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 wrote:
| Because browsers are being used as application frameworks (i.e.
| for making applications) rather than what they were designed
| for.
| dariusj18 wrote:
| The dream has long been to have code distributed to thin
| clients while allowing intensive tasks to be run on servers.
| shadowgovt wrote:
| 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 wrote:
| 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 wrote:
| 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.
| margarina72 wrote:
| 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.
| philipwhiuk wrote:
| 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).
| nfw2 wrote:
| 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.
| endemic wrote:
| JS-heavy sites are frustrating to me due to generally worse
| UX -- links can't be opened in a new tab, because they're not
| actually anchor tags. Forms can't be submitted by the
| "return" key. Navigation using back/forward buttons is
| broken. There might be a few companies who get it right, but
| most don't.
| mrthrowaway999 wrote:
| How is increased FCP, LCP, ttvc better ux and DX? We've had
| hard data that decreasing page load time make for better user
| experience[0].
|
| Please don't make this an Us vs. Them thing.
|
| [0]: http://glinden.blogspot.com/2006/11/marissa-mayer-at-
| web-20....
| shadowgovt wrote:
| Because we also have hard data that users absolutely hate a
| blank or frozen screen and "CONFIRM FORM RESUBMISSION."
| Users are allowed to hate multiple things at the same time
| and it's up to the web developers to stack rank those.
| nfw2 wrote:
| The OP was asking for an explanation why the preferences of
| the industry diverge from the preferences of this comment
| section. The question itself identifies two groups.
|
| The top comment on this page said the frontend community
| seems like a jobs program. It's interesting that you are
| only criticizing the view you disagree with as being too
| divisive.
| arp242 wrote:
| > Companies know what is best for their business.
|
| "Companies" don't really know anything. The decisions get
| made by people, with all the flaws that people have. I have
| seen many developers make decisions that are detrimental to
| the company.
|
| I do agree that there is a section of HN that will pile on
| these kind of topics, and I have flagged dozens of low-effort
| swiped against JS over the years that add nothing.
|
| But two things can be true at the same time:
|
| 1. there is an unpleasant section of HN that will rant about
| all things JS, and
|
| 2. SPAs (or our current approach to them) bring a lot of
| downsides and are often not worth it.
|
| Are entirely compatible.
| nfw2 wrote:
| I agree there are tradeoffs to SPAs, and I shouldn't have
| implied that companies are a perfect decision-making
| apparatus.
|
| That said, I think if a certain technology becomes an
| industry standard, especially one that demonstrates some
| staying power, as React has, it should not be dismissed
| out-of-hand, and most of this comments section is doing.
| arp242 wrote:
| There are probably more companies _not_ using React than
| are. Words like "industry standard" don't really mean
| much. Languages like Ruby or Go are widely used and here
| to stay, yet there are also many people who don't like it
| - and that's okay.
|
| There's a lot of self-sorting going on here; I stopped
| doing the frontend thing because I didn't like the way
| things were going and even tepid critique of this was
| (and still is) often met with completely out of
| proportion aggression, vitriol, and insults. I got more
| hate and vitriol over my "Why I'm using jQuery in 2018"
| post than the rest of my website combined. It feels like
| engaging on the Israel/Palestine debate or something.
|
| Of course every community self-sorts to a degree. That's
| okay. I would never presume to critique React on a React
| thread. But "frontend" is very broad and also includes
| non-React.
|
| Your comments here are fine, but at the same time it also
| strongly suggests that SPAs are the _only_ way to build
| good frontends and that everyone who disagrees is just
| some old coot stuck in their ways. Both of which are
| rather tiring tropes, and especially that second one is
| pretty dismissive, if not downright insulting.
|
| So I kind of gave up on this years ago. It's easy to
| reach consensus if you chase away everyone who disagrees.
| dtech wrote:
| 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.
| _dain_ wrote:
| _> Secondly it's less "boring" for developers and arguably
| less work._
|
| Humphrey: But what happens to _us_?
|
| Bernard: Well, much less work.
|
| Humphrey: Yes! Much. Less. Work. So little that fullstack
| engineers might almost be able to do it on their own!
| stavros wrote:
| Because the people who like this approach aren't frontend
| developers.
|
| 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 wrote:
| 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)
| scarmig wrote:
| 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.
| mrthrowaway999 wrote:
| 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.
|
| Ie. It's all about incentives
| andyjohnson0 wrote:
| 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.
| andyjohnson0 wrote:
| A couple of anecdotes relating to point 3 above:
|
| a. I once worked on a project where the webapp frontend went
| through a time-consuming, mid-project framework swapout
| because the "senior full-stack developer/architect" decided
| it needed server-side rendering for SEO purposes. Never mind
| that it was a niche industrial app that required a login to
| use and simply wasn't visible to search engines.
|
| b. I remember being advised to stay quiet when I asked why a
| different web developer, upon being asked to build a simple
| _static website_ , had nevertheless built it in React.
| EasyMark wrote:
| 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.
| ksec wrote:
| 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
| WA wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There are bad sever side apps and "single page apps".
| synergy20 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There is no need for JavaScript for a Tomorrow button.
| philgyford wrote:
| 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 wrote:
| 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 wrote:
| 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 PSx 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Why is Linux not in this list:
|
| https://www.gov.uk/service-manual/technology/designing-for-d...
| layer8 wrote:
| Less than 2% of users?
| shadowgovt wrote:
| 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 wrote:
| Why should it be on that list? When does a webpage work on
| macOS and Windows but not Linux?
| shadowgovt wrote:
| 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 wrote:
| Can Gov.uk become the new W3C? Pretty please?
| layer8 wrote:
| You mean the new WHATWG.
| hakanderyal wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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://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 wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-29 23:01 UTC)