Hacker News Reader

Comment by bit_logic | Hacker News Reader

What upsets and concerns me the most is when I see poorly developed SPA on really important sites. For example, government service application websites. If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure. Especially since these services are most often used by exactly the population most impacted by bloated SPA (they tend to have slow or unreliable internet and slow computers, maybe even a cheap android phone is all they have).

Such sites should be using minimal or no JS. These aren't meant to be pretty interactive sites, they need to be solid bulletproof sites so people can get critical services. And I haven't even mentioned how SPA sites often lack any accessibility features (which is so much easier to implement if sticking to standard HTML+CSS and no/minimal JS).

View on HN

Yeah what's weird is that there's is an entire generation of developers who think of SPA as the default.

They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML.

Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML.

Rendering HTML on a server side Intel/AMD/whatever CPU is way faster than rendering it on a mobile device (and probably more efficient too).

Even if it weren't faster and more efficient, it would save battery power on the client.

And there is a ton of latency on the client side these days, ignoring network issues. There are ways of using the DOM that are expensive, and a lot of apps and frameworks seem to tickle those pathological cases. These 20-year-old browser codebases don't seem to be great workloads for even modern Android or iPhone devices.

---

edit: To be fair, I think what's driving this is that many sites have mobile apps and web apps now, and mobile apps are prioritized because they have more permissions on the device. (This is obvious when you look at what happened to Reddit, etc.)

It's indeed a more consistent architecture to do state management all on the client. Doing a mix of state on the server and state on the client is a recipe for confusion -- now you have to synchronize it.

Still there are plenty of apps that are website-only, like the government sites people are talking about. Those people appear to be copying the slow architecture of the dual mobile+web clients and getting a result that's worse.

I've always taken "server side is slower" to mean "slower to host" in context of web pages. Sure it may blow chunks to parse 10 MB of JS to click a button and leave on the client side but that's 10 MB of static JS served via dirt cheap anycast style CDN and it doesn't matter if you have 1 client or 100,000 clients you could host it on a single server's worth of CDN which doesn't have to worry about any client state ever (and for the tiny percentage of client state you do need to manage it might be hosted on a much smaller solution that handles just that logic).

I'm more of the classic take that the "problem" is performance has continued to grow meaning we get more stuff made faster but the tradeoff is it runs at the same speed. Client side or server side there is no reason the app needs 10 MB of JS logic to do its job it just made it quicker and easier to deploy to have it use 10 MB of JS logic. For some things like required government services this is a real problem but for most things this is just reality - how fast a piece of software is isn't the only benchmark software is made against, often not even in the top 3 things it's checked against.

Take away React, Vue, Angular, or similar away from most current front end developers and there is panic. When I say panic I mean full insanity panic like abandoning the profession or completely going postal.

——

A simple checklist to provide superior front end applications:

* Don’t use this. You (general hypothetical you) probably don’t realize how easily you can live without it only because you have never tried. Doing so will dramatically shrink and untangle your spaghetti code.

* Don’t use addEventListener for assigning events. That method was added around the time of ES5 to minimize disruption so that marketers could add a bunch of advertising, spyware, and metric nonsense everywhere more easily without asking permission from developers. That method complicated code management, is potentially point of memory leaks, and performs more slowly.

* Don’t use querySelectors. They are a crutch popularized by the sizzle utility of jQuery. These are super epic slow and limit the creative expression of your developers because there is so much they can’t do compared to other means of accessing the DOM.

I now add ESLint rules to my code to automate enforcement of that tiny checklist.

What do you use instead of these constructs?

Instead of this I use explicitly named variables and functions.

Instead of addEventListener I assign event handlers directly to the event property of the DOM: button.onclick = whatever. This forces simplicity and cleaner code management because only one function can be assigned to any given property.

Instead of querySelectors I use other standard DOM methods.

Other standard DOM methods like what? getElementById and getElementsByClassName?

I also want to know this.

Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml

For a practical example try this: https://github.com/prettydiff/semanticText

Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml

For a practical example try this: https://github.com/prettydiff/semanticText

I think a bit of context about `this` is important.

Using `this` in a callback -- where you expect your caller to provide your local binding -- is straight-up bad juju. Pass arguments instead.

Using `this` in an object instance to namespace is just fine. The entire point of having an object is that you get these nice encapsulated namespaces which can send messages to each other.

One suggestion, and a related ask: rather than just saying "Don't do FOO", provide alternatives as well; e.g., "Don't use `addEventListener`, use `superFooBarBazzer`".

Bonus points awarded for runnable examples. :)

Perhaps my biggest gripe about the entire Javascript ecosystem is finding libraries that provide documentation that looks like this:

    // See how easy my library is to use!
    myLibrary.doTheThing(fooBar, bazBang);

Without ever showing you what a `fooBar` or `bazBang` are, and perhaps where and/or how an enterprising developer might obtain one.

https://github.com/prettydiff/share-file-systems

40k loc. I wrote an ESLint rule to error on this in both statements and expressions.

This is a silly list. What? You really think document.getElementById is going to be faster than querySelector("#foo")? You really think there is a meaningful difference between other methods of adding event handlers, other than it being way hackier to add more than one with the other methods?

I have no idea what your objection to "this" is. Object Oriented code can be bad sometimes but so can procedural code.

This person has a weird unjustified objection to querySelector.

I remembered this same conversation from 8 months ago where I pointed out that parsing something like '#foo' is NOT slow, he argued against it, 5 people pointed out the same thing, and he was not receptive to that feedback, etc.

https://news.ycombinator.com/item?id=24054745

Performance is hard; optimizing the wrong thing is also a problem ...

I guess you ignored this from that thread: https://news.ycombinator.com/item?id=24057163

If jsPerf is down try http://jsbench.github.io/

What precisely do you think a microbenchmark taken out of context is going to prove?

That a 250,000x performance difference is a very large gap. It’s the difference between walking 1 foot or 48 miles.

Or the difference between walking 1 femtometer or a quarter of a nanometer in a day where you're planning to hike 10km. And that's assuming the relative difference holds to the same degree in a real app, which seems unlikely.

P.s. i also didn't get that level of difference when i tried to run the microbenchmark but i didn't try very hard.

Your opening sentence is weirdly derogatory...

And I think these are all pretty far from the main performance issues with common apps FWIW. These are more low level coding issues, whereas the real slowness (e.g. 10x or 100x issues) comes from architecture, dependencies, network usage, data structures, reflows, etc.

> comes from architecture, dependencies, network usage, data structures, reflows, etc.

That is tech debt and complexity. If you start from a simplicity first perspective most of what you list evaporates as a matter of habit.

I know this won't count for much, but as an amatuer programmer who has done a lot of web scraping at my job due to having a restricted corporate environment, its a breath of fresh air to work with the few websites that actually assign IDs to elements, don't autogenerate all graphic elements and feel like whoever wrote them actually cared. Especially if you are trying to parse it with something stupid like Excel VBA. Trying to reverse engineer what happens when you click a button on a site with 20 event listeners tied to "submit" is a freakish nightmare.

Thinking about it a bit more, Reddit is a really good example because it launched and got popular before the iPhone or the App Store existed (2006 or so). It was a fast and minimal site back then, similar to what Google used to be.

Either the existence of the mobile app, or the drive to get people to install it, ruined the website. It's slower and has poorer usability than 5 years ago, and also 15 years ago.

Twitter is another company that existed before the App Store and the SPA trend. I noticed they recently turned off the ability to see the 280 chars you care about without having JavaScript on :-(

It's trivial to have a no-JS fallback, and they had it, but turned it off.

Indeed about twitter, I won't follow about 95% of links there due to the issue you mention.

Imo Reddit ruined their site on purpose as that makes users go to the app instead which adblockers have a hard time blocking ads on (unless you have pi hole setup). They also added a ton of extra wasted space to make users scroll longer and thus stuff more ads in and increase user times.

This isn't an opinion, this is a proven fact given that Reddit blocks many subreddits from being accessed from the browser when using the default UI, redirecting to their app, for no reason other than moving users to the app. They do not even pretend for there to be any other reason for they have never given any explanation as to why they do this. It's some of the most user-hostile behaviour I've seen, even the usual suspects don't block basic access.

Good to hear there’s fact behind my opinion. I hadn’t researched it deep enough but just figured it out based on my own experience on their site. I don’t visit Reddit often for 2 years now unless I really need to. And when I do, I go to the old.Reddit subdomain.

Question: which subreddits does Reddit block from the browser? Genuinely curious. Are they also blocked from third party apps like Apollo?

> They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML.

> Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML.

The argument I remember from years ago used "slower" as a bad simplification. What it actually meant was, doing the rendering server-side wasted CPU the server could be using to respond to another request. Instead, just send the data and distribute some of this processing to all your users by way of client-side rendering.

Also, back then bundling was a lot rarer than it is now, so the large libraries that made of most of those 10 MB javascript files would be separate files the browser can keep cached.

I believe Svelte has the best outlook for developers wanting to build with JS as it doesn’t load an entire framework upfront (Angular/React/etc). In regards to server side languages being slow, as you pointed out, it’s really not the case; in my experience the culprit to slow applications is the database design.

I am going to :+1: the UK census site - built on code developed by the gov.UK digital service, it has been apparently bulletproof at taking 20 million plus individual households through a moderately complex survey.

sometimes it can be done right.

And it uses a framework :-)

Which framework?

If my memory serves me right, it's Python/Django. I contracted in that department a few years ago.

Edit: Just remembered it's all open source too! Look here and search for repos beginning "eq-". Survey runner is the app I believe. When I was there the plan was to use that, though perhaps they eventually wrote a fresh app. Anyway the code should all be there https://github.com/ONSdigital?q=Eq&type=&language=&sort=

That was notably one of the best web experiences I’ve used recently. Gov.uk is exceptionally good.

Wagtail

https://docs.publishing.service.gov.uk/

Looks like the core site is Rails but it seems they use a bit of everything. Preact, Go, Node, etc

Yeah I was pretty impressed with it too. One thing I liked, it does lots of error checking along the way to pick up accidental screw ups.

Eg. It says ‘what is your date of birth?’ And then on the next page it says. ‘You are X years old. Is that correct?’

Yeah, I was impressed enough to fill out the feedback form at the end. It is probably the first time I've used a feedback form for compliments in my life.

Not quite bulletproof. I found a couple of bugs while using it.

At the end, just before submission it showed the completed sections, and you could look at each section to see a tidy summary of the answers provided. Except for the section 1, where doing that jumped to the last of the section's questions instead.

I wanted to see one of the answers I had given in the section 1 to check before committing, and due to the missing summary page, tried stepping backwards and forwards through each question. All were shown, except the question I wanted to check (and had answered) was skipped.

Inspired to try things, I added a non-existent person to the household, then removed the non-existent person.

After that, when I stepped through all questions in section 1 it included the question and answer I'd been looking for, allowing me to confirm it was correct before submission.

Consider filing a bug report: https://census.gov.uk/en/web-form/

Thanks. I already did so via the feedback form at the end.

Indeed - I used this site the other day. My reaction at the time was "This is the nicest web application I've used in decades." Web design that good is so rare now, it really stands out.

gov.uk is such a glaring exception to government sites around the world I can only imagine there was some massive screw up where the developers were allowed to go off and build a fast, accessible and responsive site on their own without the requisite ten layers of committees, meetings and expensive external consultants. I hope there is a government inquiry to ensure this doesn't happen again and that taxpayers money is properly squandered on massive IT failures as per standard practice.

This gave me a good laugh, thanks for that ;)

Why do these things even need to be an SPA? What function does that serve when the standardized and infinitely more compatible form-with-a-bit-of-javascript approach works just as well if not better?

I work on one such project and it absolutely drives me nuts -- it's a rails app, but the customer front-end (which is literally just a form to fill out) is a React SPA. There is nothing there that couldn't be done with Turbolinks and some light JS for validations/popups.

How can a government contractor reasonably justify a price tag that's on par with fancy bloated non-government sites, for an no nonsense form + js approach?

Costs the same as what you would otherwise pay, plus it actually works?

>plus it actually works?

Heh. "That was the most unkindest cut of all."

https://www.google.com/search?q=unkindest+cut+of+all+quote

Also, "the emperor's new clothes".

Both relevant.

> plus it actually works

That’s the problem. Maintenance is big money for government contractors.

Because they're a business that will charge as much as they can absolutely get away with and will do their best to make the project and maintenance costs as bloated as possible.

The question is why there aren't people in the government with either the technical ability or the political clout to audit and push back at any point in the project.

It's really the people writing the requirements who are driving a lot of these things. Customers are used to Gmail, FB etc. and want similar experiences.

When the only tool you know is a hammer you tend to just go around smashing things

Because that's the mainstream, that's what's easy to procure, hire for, negotiate with vendors, that's the default, the preferred, the future proof, the supported.

And the tech doesn't really matter. I hate React with a passion, because Angular is so much more sane - in my experience. But it's fine. It's mature, it can be made to perform completely well.

The tech doesn't really matter. The people doesn't matter either. Even the costs doesn't matter as much as people think. What matters is political will, procurement culture, so systems and structures. This will influence (and bring) all the others in line.

Depressingly correct.

Variations of "nobody ever got fired for buying IBM", repeated forever.

No-one got fired for writing an SPA, but we did decide not to renew the contract for the next major update.

> the future proof

No, not that.

Because they want to program like they are mobile apps

This is a very simplistic characterization of what's happening.

First of all, for all the broken websites there are also a lot of websites that are not broken at all. It's also very easy to make a broken website using a completely server-side rendered website, and that actually happens often enough.

Second, SPA's decouple frontend and backend in a very strict way, which can bring enormous organizational benefits. Time-to-market is greatly improved, etc.

This whole "frontend vs backend" dialogue is basically white noise that completely misses the point. Use SPA or not, whatever, in the end it's just a tool to get the job done. Both are prone to errors when handled improperly.

A website that got it completely right is the Dutch corona dashboard called "Coronadashboard" created by the Dutch government: https://coronadashboard.rijksoverheid.nl. It's blazingly fast, extremely well-designed, looks great and the code is of exceptional quality. Also it's open-source, have a look at the code: https://github.com/minvws/nl-covid19-data-dashboard/.

The dashboard is completely written in Javascript. I truly believe a website with of such high quality would not be possible without frameworks such as React or Next.js (or whatever other framework and their respective tooling has to offer).

Closing note: let's try learn more from the websites that got it right than the ones that have failed. It's so easy to be critical, it's much harder to give some praise.

It kind of freezes up on my phone. Not intolerable but definitely slow.

It loads instantly on my Xr.

Why do you think it would not be possible to build a website of such quality without frameworks?

On a separate note, I think the dashboard is alright but I wouldn't call it excellent. It's a bit slow and some things, for example mousing over the map, are glitchy.

> Time-to-market is greatly improved

I've experienced and have witnessed quite the opposite with SPAs

> A website that got it completely right is the Dutch corona dashboard called "Coronadashboard" created by the Dutch government

Not sure what everyone else here is using but you're right, at least for me the website is running buttery smooth in both Firefox and Chrome and the code is of exceptional quality.

> I truly believe a website with of such high quality would not be possible without frameworks such as React or Next.js (or whatever other framework and their respective tooling has to offer).

I agree. I wrote my first lines of HTML & CSS almost 20 years ago and back then JavaScript dev was nightmare. People wouldn't even have been able to create an interactive website like the Coronadashboard. (Of course we're not talking about static websites here – these were already relatively easy back then.) Nowadays, JavaScript dev admittedly still is a nightmare but there are at least tools like TypeScript, Angular, React and so on that make things a bit less painful and allow experienced web developers to create exceptional frontends. I'm putting "experienced" here because the frameworks still come with some pitfalls and bad practices are still very common. (I can't believe how many tutorials about using forms with React still recommend updating the state and re-rendering the entire form upon every.single.keystroke.)

> Time to market is greatly improved

Can you please clarify this?

If you are referring to a web app time to market I mostly see otherwise.

Here is an example: create a form to edit user settings. In Rails/Django it is pretty simple straightforward. But if you go React then you have an API and a component in React and have to think about routes and security of API and validations on both FE and BE.

There are advantages for SPA probably but time to market is not one of them in this case.

If you are referring to creating a mobile app and a webapp then maybe React with React Native is indeed faster. With this I agree. But I personally prefer to wait for Hotwire to launch their mobile framework and use that.

Backend and frontend are different species and require different skillsets. It's much easier to scale from an organizational perspective using SPA's, especially in companies where software is not the core product (think non-tech Fortune 500).

Yes, I agree with you that organisational scaling is easier when having BE and FE handled by different people.

I am not yet convinced that optimising for organisational scaling could be technical benefits.

Time-to-market is 99% an organizational problem.

I'm not sure why you think this were written in pure js without a framework. It uses React and Sanity.

I honestly hate SPA's. They're not necessary in almost every single use-case, yet everybody is shifting their shit into one.

It’s because frontend devs are taught to use react, so suddenly every website unnecessarily becomes a react app. If every tutorial and class out there teaches people to use hammers (react) then people start using hammers to screw in a lightbulb or perform surgery.

Why SPAs? They're good when you develop capabilities API-first. When we build features, we follow an approach of making the feature possible (customer support can exercise the feature with PostMan or cURL) then making it friendly with a UI.

There will be some tweaks and changes to the API to support the UI, but it's rarely drastic, and it ensures that every single capability we build out can be exercised by some other kind of program somewhere.

If you're building components of a larger system (which we do), SPAs and web components atop back-end APIs make sense. If you're building a one-off fill-out form kind of application... No those don't make sense. You don't even need JavaScript for those, if you degrade into just HTML + CSS for users that have shut off JS.

Even if you develop capabilities API-first, you don't need an SPA, though. You can create some backend code that consumes your API and in turn serves separate web pages to a front end.

I really believe it's a case of resume driven development. I'm sure there are counter-examples, but the whole move to SPAs, from my vantage point, has been driven by tech people and not leaders. Self-inflicted.

You're making software engineers way more important than they are. They don't hold this kind of decision power except in the smallest companies. In most cases of SME and large enterprises, there is a VP, a director or sometimes a "chapter lead" pushing it (in my experience, 9/10 times they believe this push will get them a promotion, as they "helped to move the company towards an important new technology"); has nothing to do with resumes.

I've had the opposite experience in this specific case.

While RDD is a thing, the root cause is the stakeholders' requirements for more sophisticated and complex sites (whether smoother page transitions, more intricate effects, incessant demands to spy on every user interaction etc). It became harder and harder to do all this with server rendering and a rat's nest of jQuery. JS frameworks arose to meet these requirements and became an industry standard, and developers responded to market demand. It's all gone too far of course, but the stakeholders were as much to blame as anyone.

Yes, I agree for those cases where the SPA was created to match customer expectations. I'm talking about using it where it doesn't belong, which happens quite a lot.

what concerns me more than that is how government sites require google and the like (captcha and analytics at the very least), giving them opportunity to hoover up all of our sensitive data in one convenient place.

Yes definitely.

I was surprised recently as I had to fill in a massive form based site for UK NHS mental health survey stuff. The site appeared as a flat background old style early 2000’s sort of thing with bits of comic sans in it. I nearly died when I first saw it expecting a shit show.

But it turned out to be responsive and fast. It worked perfectly from end to end and had little to no JavaScript. It was by far the best thing I’ve used for years. There were over 100 page transitions in total. It wasn’t an SPA but a classic web site with little or no intelligence. Seemed to be backed by python.

I want this back.

> early 2000’s sort of thing

Right. It probably IS an old site and they've had years to iron-out bugs.

Nope. I spoke to the woman who issued us with an account and they just had it built for them.

> The site appeared as a flat background old style early 2000’s sort of thing with bits of comic sans in it.

That's surprising - even external stuff usually has to follow the NHS's design system.

https://service-manual.nhs.uk/design-system

SPA = single-page application

Thank you! It is hard to search for that term :)

Completely agree. And yet, were there ever better days? In the past simply fewer websites were online. I think a bad website is better than none.

At the same time the real question is why lots of governments wouldn't need to reinvent everything. That is maybe the original sin.

At least regarding the US federal government, it was a known issue that (a) the government wasn't willing to spend enough to hire quality software developers and (b) the government bureaucracy lacked a process to determine whether web software was "good." Specifically, no effective methods of software validation based on modern best practices (the processes they used were descended from the validation processes for material acquisition, which look extremely different from software engineering).

I'm not sure if the problems have been fixed, but they were both recognized and a process was put in place to address them after the healthcare.gov debacle.

> If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure.

Unfortunately the incentives are backwards. Typically governments have to choose the lowest bid. Those private companies you mentioned can make more complex tradeoffs.

Sometimes, of course (cough Florida unemployment and covid tracking sites), failure in performance is by design.

The New York Times used to be a mess on mobile where swiping back was a 5 second wait until the SPA synced. It is much better today, so either they ditched the SPA or have now fully simulated a browser’s back and forward behavior.

The founder of SvelteJS works at the NYT. SvelteJS works well on underpowered devices.

I went to go redesign my blog recently. I was intending to use the Go Template engine, but I'm not a frontend person so I wanted to use a frontend framework. I quickly discovered that most of even the purest of css frameworks did not have instructions for what I wanted to do. They all used Next.js, Webpack, etc and we're designed to be used in Vue or React. I love component frameworks for their simplicity, but everything that powers them is complex.

> Such sites should be using minimal or no JS. These aren't meant to be pretty interactive sites, they need to be solid bulletproof sites so people can get critical services

Government services were slow and unreliable before computers. The problems aren’t technological.

this isn't just a problem with SPAs. The quickly-built vaccine registration site I was using kept giving me 500 errors from Heroku.

This is the exact opposite of my experience.

When I click on a link, or click to submit something, and I realize that it's NOT an SPA, my immediate thought is "this is going to be a nightmare."

When I click a button, and it has to make a request to load the next set of html, fully replace the page contents, and probably submitted a post request that will have issues restoring the state of my form if I go back, etc, I feel like I'm on a DMV site from the 90s. Navigating something that is meant to operate as a cohesive application by instead using a series of markup displays is only ever going to be hacky at best. I love using SPAs, because they're actually applications, rather than snapshotted frames of an application running on a remote server.

I exclusively write SPAs these days and I think they are vastly superior for many reasons. The problem is that you can build a shitty product with good tools.

One of my duties is performance improvement, so I’m very familiar with problematic architectures. You can have an instantly loading informational SPA... I tend to use Gatsby for that. For more interactive sites, I prefer vanilla React with lightweight libs, code splitting and sensible caching rules.

I do agree that poor design, reluctance to refactor and lib/tracking heavy apps are very problematic. Isn’t that something that’s always been a problem in Webdev?

Reply on news.ycombinator.com