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'd say that we, developers, often move to overcomplicated and difficult tools/approaches.

Smart people with simple problems, we get bored, I guess. There's a lot of boring work out there.

I agree though, I went from Angular to ASP.NET back to React, and server side despite being less 'flashy' was much more productive with less effort.

> 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.

> 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.

This might be the best summary of how I feel about web development that I've read in a fair while.

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:

https://discuss.emberjs.com/t/services-a-rumination-on-intro...

> 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.

Funny that a mere two mo ths ago, when I posted this, many on HN begged to differ:

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