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.
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.
Question: which subreddits does Reddit block from the browser? Genuinely curious. Are they also blocked from third party apps like Apollo?
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.
——
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.
I have no idea what your objection to "this" is. Object Oriented code can be bad sometimes but so can procedural code.
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 ...
If jsPerf is down try http://jsbench.github.io/
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.
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);
40k loc. I wrote an ESLint rule to error on this in both statements and expressions.
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.
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.
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.
For a practical example try this: https://github.com/prettydiff/semanticText
For a practical example try this: https://github.com/prettydiff/semanticText
> 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.
sometimes it can be done right.
And it uses a framework :-)
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?’
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.
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=
Looks like the core site is Rails but it seems they use a bit of everything. Preact, Go, Node, etc
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.
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.
No, not that.
Variations of "nobody ever got fired for buying IBM", repeated forever.
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.
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.
That’s the problem. Maintenance is big money for government contractors.
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.
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.)
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.
I am not yet convinced that optimising for organisational scaling could be technical benefits.
I've experienced and have witnessed quite the opposite with SPAs
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.
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.
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.
That's surprising - even external stuff usually has to follow the NHS's design system.
Right. It probably IS an old site and they've had years to iron-out bugs.
At the same time the real question is why lots of governments wouldn't need to reinvent everything. That is maybe the original sin.
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.
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.
Government services were slow and unreliable before computers. The problems aren’t technological.
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.
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?
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).