> Has it occured to you you might simply not understand the advantages of this approach?
I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier).
> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain.
I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain.
Even the auto-frameworking approaches are starting to surpass old school web development for "classical" web purposes. I can tell when I'm on a static documentation site and things work almost instantly. JavaScript is both the reason why some websites feel faster and other websites feel slower.
I also think that being nice to mobile (data efficiency) and being fast (UX latency) are starting to show as moderately contradictory values.
Do you believe that SPAs are more difficult to build than building the same functionality with server-rendered HTML and jquery on top?
In my experience, that would only be true in the most trivial of SPAs. I’m thinking like a blog with AJAX “like” buttons. A good rule of thumb for me is that as soon as you have some interactive widget that involves adding and removing items from a list where the individual items also change interactively, you’re probably better off ditching jquery because things are about to get messy.
> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier).
You're right, I should have been clearer. Emphasis on develop and maintain.
If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want and it'll be done in 5 minutes.
But if you're building something that will scale beyond the current page, that will need more features in the future, etc then it's not a viable approach. And I'm not saying SPAs are necessarily the best choice/tool available, but they're definitely going to be easier to work with than HTML+jQuery, unless the requirements are ridiculously basic.
> I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain.
Lots of devs adopt technologies for fun; because the approach is interesting; because they want to learn; because they're bored with their current stack.
But this is different. This is a huge movement within the ecosystem moving towards a very specific model. The model is not necessarily the best in every situation, but the pros that come with it are significant.
And honestly, nowadays in modern browser JS, if an app is simple enough to build with jQuery, it's simple enough to build without any third party lib.
> You're right, I should have been clearer. Emphasis on develop and maintain.
Did you ever think that you might want to put the user experience first?
Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results.
But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
This kind of terrible state management is super widespread and really annoying. I agree that lots of folks seem to have have spent the last few years thinking more about their build chain and tooling than about basic UX.
And this is why I like Parcel. It's by no means perfect but having pretty much zero config and still being able to jump into using pretty much whether system you want with a simple command is nice.
Frankly I thought jQuery was a horrific way of building stuff, and moving to a declarative approach like React is a huge step forward. Most complaints I've seen about it are due to incompetence or misunderstanding.
This specific example really just applies to all naive implementations of AJAX infinite scroll, which far predates the rise in popularity of SPAs.
Discourse, a forum written as a SPA in Ember, changes your URL as you scroll to each post. Even if you scroll down and let javascript load in more pages of content, the URL will reflect the post you’ve scrolled to, and will jump right to it if you go somewhere else then click Back, or just load the link:
> Did you ever think that you might want to put the user experience first?
I like react for SPA because it means It makes it easy to build a pretty solid user experience. The best example I had was when I was building the login + info portal for inflight wifi. We used server-side rendered React to give them an operational page without JS, and then enhanced it when the JS loaded in, and then precached additional content to make the pages load instantly.
The react + webpack ecosystem made this _really_ easy. Inlining the critical css for the base type + login form was stupid simple.
At the end of the day, there are lots of tools and its up to developers to find the best tools for the job. Sometimes, developers make the right choice. Other times, developers make the wrong choice. If you have a dysfunctional team/org, you're probably not going to build much great regardless of the tools you choose.
Whether pagination is saved (like ?p=6 in url) doesn't have anything to do with SPA vs SSR. Just like an SSR /search endpoint that uses POST over GET so you can't just save/share the query.
You're blaming SPA but as usual it's just people not caring about polishing application UX.
But in the YouTube case I don't even have pages! But anyways, When not going the SPA route I get all this for free. Navigating the search result pages automatically ends up in the history. 0 lines of Js required. Also since the whole page is generated server side even the scroll position within the result page is restored properly. Again 0 lines of Js. This already worked in the 90s. Today it doesn't, and we call it progress.
We had plenty of sites in the 90s breaking due to using POST on almost every navigation, or embedding a sessionid in the URL that would break the site when being bookmarked/shared
You could build even worse horrors using <form target="..."> to update frames/iframes... partial page updates without javascript. This still lives on in some oracle web applications...
> Did you ever think that you might want to put the user experience first?
As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev.
SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have their natively-unsolved problems, so this is moot.
> But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
> I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
Nope, that was just a small addendum in relation to my example since experience has shown that often times the back button is broken in different ways depending on browser. Having just one engine left would at least mean some more consistency here, but that's about the only advantage I can see in that.
> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so.
Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more resource intensive (it's not infrequent that my laptop fans start spinning), buggier, and harder to use. I don't think this is surprising, because "maintaining state" is great and all, but it also means that once that state goes sideways your app goes sideways, too.
Does this describe every SPA? No. Does that mean that every template app is better? No. But is the average SPA app worse than the average template app? In my experience it is (although I will admit I lack empirical data).
I don't think that popularity is a good yardstick. jQuery is clearly not the optimal way to develop web-apps – this post was never intended to argue as such, merely to argue that it's better than vanilla JS that I've seen advocated quite a lot recently – so people go to "alternative" solutions which lacks the problems jQuery has, but that doesn't mean these solutions don't create different problems on their own.
I don't know what the optimal way to develop webapps is, but I do know that the current generation of SPA frameworks isn't it. Probably some sort of hybrid approach, or a completely different one that hasn't been invented yet, is. In the meanwhile, a template-based approach is much easier to understand (less can go wrong), and is probably the best approach for many (though not all) websites.
I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app).
I'm starting to think I need to clarify that paragraph :/
I inserted the word "often" now: "Those apps are often easier to develop, tend to be faster".
The entire topic is complex, and like I said the main point wasn't about template vs. SPA, although I felt like something had to be said about it, as it's obviously related and something of an elephant in the room.
I don't think there is One True Way™, but I also feel that many apps are actually a lot less complex than people seem to think. For example the main competitor for the app I'm working on now (unpublished MVP that's still WIP) is a SPA, and I feel like my simple template-driven app has a much better UX. You just don't need all the complexity, there is so little benefit you might as well not bother. I think this describes many apps.
Would HN be better as an SPA? I don't think so, and I suspect that a "SPA HN" would be harder to develop and get right.
Probably - "Has it occurred* to you you might simply not understand the advantages of this approach?" makes you sound pretty dismissive of the parent comment's points.
Also - as someone who disagrees with you I don't see any compelling points in things like:
> "So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so."
You're on HN - there's a huge chunk of us who are attempting to KISS web development. You're not wrong that React and Typescript are wonderful tools - but they're absolutely not the only way to develop things.
Also you may want to address people's worries about SPA development if you want to convince people it's not as bad as they're saying. (like performance - which is a huge reason I keep my light-weight vanilla-style apps the way they are)
I think there's a canyon between outright calling an approach "madness" and simply… understanding its advantages, yes.
Performance is a concern, and that's one of the main reasons why serverside rendering is being adopted as a technique. So when OP berates the existance of SSR, I have to wonder if they understand the larger picture. If it's rude for me to point this out, I apologize for being rude; my point still stands, though.
I don't think the SPA approach is the end-all-be-all but I'm definitely happy to have adopted it for my current project (a mid-size web app mixing classic list views and a few more complex bits and pieces here and there). Had I done it with jQuery, I'd still be building it; and had I done it in my classic hybrid approach, I would not have as many options as I currently do when building new pages/views.
I think you need to clarify as well, because if someone tells me it is easier to maintain solution X than solution Y I naively expect it must be because solution X's users will have it better than solution Y and complain less, requiring less fixing of user experienced problems.
Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA? Unless you control for that, I’d be willing to guess that the difference in bugginess is simply due to SPAs having a more complex set of features.
> Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA?
How about rewritten apps like reddit, that's as like for like as you can get? There are a bunch of apps/categories (things like JIRA) that were once template style and are now SPA style, the SPA version are nearly always worse.
I'm an old php dev, still doing server side development exclusively, and these are genuine questions:
1. What tooling is there available? Do you mean something along the lines of vim or IntelliJ?
2. How do these techniques make the user experience better, compared to e.g. ajax?
So here's the thing about the JS world: You have access to essentially all the tooling ever developed for frontend dev. Linters, code formatters, IDEs, etc. Tons of crazy techniques invented to speed up development (hot-reloading in various frameworks; remote debugging with the various browser inspectors…).
All this becomes available to your server development experience the moment you choose to share the language. And having developed with Python for over a decade, I can safely say I no longer enjoy doing that after seriously using typescript for just under a year. This also does have to do with the IDE; VSCode with TypeScript is a better dev experience than Python with any of the popular Python IDEs, even with added typings (python types are awful).
> 2. How do these techniques make the user experience better, compared to e.g. ajax?
They don't. They do enable you to take advantage of them in order to make a better user experience, but you still have to actively pursue that. Someone gave the example of Reddit lower down which is possibly the worst SPA I've ever seen on a popular site. OTOH, if you look at well-built NextJS websites, they're often ridiculously fast both to load and to use.
> If it were, developers would not be flocking en masse towards SPAs and the like.
Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.
This has nothing to do with an "Argumentum ad populum". I'm saying devs are flocking towards it because it's a lot easier to work with and maintain.
There's a lot of reasons why this is true. One is using a single programming language. Another is having the server app be aware of the entire app rendering rather than just templating-in bits and pieces. I could go on but that's not the point I'm trying to make.
> I'm saying devs are flocking towards it because it's a lot easier to work with and maintain.
Two things: first, my experience (and perhaps definition) of "easy" is different. I wrote an entire different post about that[1], but the tl;dr is that SPA may be easy to make things with, but it's hard to debug things, which is a more important measure of "easy" IMHO.
Another example would be accessibility (screen readers, etc.) Last time I tried, it was much harder to get that right with SPAs (not impossible, just hard).
Second point is that there are many other factors than "easy to work with and maintain". I already mentioned some of that in my other reply.
I agree with the definition of "easy" in your post, and Docker is an excellent example of hell on earth. But I've not had that poorer debugging experience with SPAs, so I don't see what makes them harder to debug. I can't possibly have gotten that lucky?
The hardest problems I've had to debug on my SPAs usually had nothing to do with the SPA stuff and more things such as obscure yarn or typescript bugs/behaviour. These classes of bugs exist in all languages and frameworks.
> Another example would be accessibility (screen readers, etc.) Last time I tried, it was much harder to get that right with SPAs (not impossible, just hard).
I'm very confused about this. What about SPAs makes this any different than regular boring HTML? If anything, having easier access to a component model should make it easier.
> If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so.
Bandwagon fallacy. In all fairness popularity is never a qualified descriptor of competence or performance.
> Has it occured to you you might simply not understand the advantages of this approach?
> Putting aside how useful it is to only have one language to learn in a stack...
Glad we are not talking about this - I'd have to point out that "I do not have to learn/understand" is a bad continuation when one starts with the claim the other was ignorant.
Decreasing stack complexity is a noble goal, regardless of how familiar you are with the stack as a whole. If a project used both cmake and autoreconf, you'd probably be the first one to call for a rewrite of one to the other (or both to your favourite third).
It decreases onboarding time, simplifies hiring, and reduces cognitive load when you yourself have to work with it.
If you want to decrease complexity the first thing to go would be the modern front end stack with it's own build tools, package managers, run times, servers and languages.
