Comment by antihero
4 years ago
This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser.
However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.
Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per say, they will mostly have buttons, which will have a some sort of defined action. Perhaps these buttons will navigate to some other screen in the application, however, reloading all of the client side state every time one does this is absurd to say the least.
Finally, from a technical perspective, having a clear separation of concerns by having code talk to an API as opposed to HTML being rendered on the server, you remove a lot of complexity.
It feels like the people who write these articles don't actually remember how utterly shit the jQuery days were.
He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
It does feel like the tiring contrarianism type of heading as opposed to a particularly well thought out article.
In the same way I feel lesser able coders seem to dwell on shit-slinging against tech that is proven, works, and has solved innumerable problems when they bang on about how things were so much nicer with vanilla JS and how frameworks are lazy and slow or something, in order to cultivate a sense of superiority.
Any well made tech has it's place, skill and experience are about knowing which tech should be used where.
>> He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
That's not true, though. If you read [his next blog post](https://gomakethings.com/how-to-make-mpas-that-are-as-fast-a...) you'll see he has lots of experience with architecting an advanced multi-page application which works and behaves much like an SPA.
It makes his anti-SPA post kind of redundant and a bit hypocritical, but he clearly knows roughly what he's doing.
I think it's just regular old click bait.
`
First of all, this is uncalled for. Second of all, it's not even an SPA. Maybe do the slightest bit of research before slinging shit at someone?
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
https://news.ycombinator.com/newsguidelines.html
Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand.
I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection.
Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection. An SPA with good caching does, in fact, feel like a native app - in lots of good ways.
>no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection
Wait, what. Don't basically all browsers nowadays keep previous pages in memory exactly not to do this?
If you read [his next blog post](https://gomakethings.com/how-to-make-mpas-that-are-as-fast-a...) you'll see he has lots of experience with architecting an advanced, cache-heavy multi-page application which works and behaves much like you describe.
Yeah, interesting.
I think that approach is fine if you have an application that's light on interactivity (like school curriculum or tutorial, in his case).
And I agree 100% on the service workers (Seriously, I'm right there with him - they're magic). I would also recommend leaning more heavily on persistent storage (localstorage/indexdb) but I'm also trying to handle offline only cases.
I think some of the advice falls down when you're genuinely trying to create an interactive experience. I probably won't expound much farther, since I really try to keep business out of HN, but... I write applications that have been used for following treatment programs in education environments - think speech therapy or ABA for autistic students, where the user is inputing data frequently - as often as once a second - and the UI is updating in response to calculations done client side, that influence the instructors program and plan in real time.
It's a lot of screens, often customized locally on the application, and removing JS (or even just writing pure js) hurts a lot. That's... hard to do with minimal js. Really, really hard.
>Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on
This doesn't happen because the browser caches the last page.
> However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all.
in the same way how re-rendering the screen in a 3D game for every frame does it. Or how you buy a new pair of jeans instead of meticulously learning how to patch the old ones. It solves a lot of problems even if it sounds suboptimal. It was the standard practice when computers and networks were much much much slower, therefore it cannot be that bad.
I think SPA and their entire ecosystem give some sense of optimality to purists which is probably shortsighted and wrong.
jQuery days were bad?
there were certainly people that committed war crimes with jQuery. Just like every other framework in existence. I yearn to return, honestly.