I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the limitations of this approach quickly become evident; in those cases, I use reactive component frameworks like Vue and React.

But there's also approaches in between! For mid-complexity sites / apps, I've used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing to generate more repetitive parts. I've also used hybrid approaches, where vanilla HTML / CSS / JS is used for more static parts of the site and Vue is used for more dynamic parts. You can use Vue in full-on SPA mode with "server-side rendering"...but you can also just generate HTML server-side as you would have before, then progressively enhance parts of it with Vue / jQuery / whatever.

I've also used "unfashionable" frameworks like Spring before, simply because it met the client's available in-house expertise. As developers, it's incumbent upon us to step back, assess the task / team / environment at hand, and pick tools accordingly.

On the whole, I'd say that I loved it. It is _staggering_ how quickly you can knock pages out when you're not coordinating data representations across different pieces of your app. The static-ness also lets you embrace a kind of UI feature simplicity. Does that form _really_ need live validation, or can we just pop the errors after submit? The latter is the only option unless you wanna (a) either vanilla Javascript or JQuery the interactions or (b) start shipping a React bundle down to this page. And thus, form validation was part of the request/response cycle, which further speeds up development.

It does get a little awkward when a static page starts having dynamic features begin to creep in. You have to decide when to awkwardly cut over to having that page powered by React.

That said, without a framework supporting this kind of development directly, I'm skeptical of how well it would work on a team. I did this style on a solo project, so there was no one complaining about 'mixing technologies' or bemoaning 'why don't we just use React everywhere.' I imagine that the first time we rewrote a page in SPA tech because it picked up enough UX to warrant it, people would be up in arms about how much time we've 'wasted' by not doing it in the first place.

Why is that?

Why do so many static websites and blogs use SPA technology for all their pages?

It can’t be that it’s just to make me mad (although it works). Are people insane? How does spending 10x the $ and effort for a worse result make sense?

In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work.

SPA apps are like building a browser, in a browser, and on the server. You lose some built in functionality and have to ship the framework down to the client.

There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks.

The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse.

Also the code you have to write is much shorter comparing to frameworks.

I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.

Nevertheless I encourage you to check out this presentation:

https://youtu.be/AdNJ3fydeao

Which explains the idea much better than I ever could.

Two things had me sold on this:

1. They managed to make the thing so easy to use, that even people who's line of work involves mostly Excel sheets were able to create something useful after a short introduction.

2. The output is relatively readable JS. There are some surprises like a few one-letter method names, but overall you could open up the source of a running Svelte app(provided it weren't minified) and figure out what it's doing just by reading the code.

The approach taken by Elixir’s Phoenix framework is so fast because it avoids all of those pitfalls. Most people have to do a double take when they see the speed comparisons.

Here’s a great write up: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...

If this is a factor, rearchitecting the backend wouldn't necessarily be easier than an SPA rewrite. But it's not a fundamental limitation of server-side rendering.

There’s no other explanation.

It's like "Please stop enhancing stuff it's good enough" - I like to enhance stuff, yeah it has costs but you can master them. That's definitely not the end of it. I hope we will do better. Maybe your "problems" will be resolved as well!

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.

I also think that being nice to mobile (data efficiency) and being fast (UX latency) are starting to show as moderately contradictory values.

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.

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.

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.

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 might be the best summary of how I feel about web development that I've read in a fair while.

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.

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

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.

You're blaming SPA but as usual it's just people not caring about polishing application UX.

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

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?

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.

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

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'm starting to think I need to clarify that paragraph :/

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.

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)

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.

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.

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.

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.

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.

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.

[1]: https://arp242.net/easy.html

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.

And that was not claimed. The point made was that they are _popular_ because they are "easy"; no comment on being "better".

Bandwagon fallacy. In all fairness popularity is never a qualified descriptor of competence or performance.

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

Sure, for lightweight development it’s not bad. But, that stack is highly optimized for a specific kind of problem and is extremely limiting.

So in what way does if differ from traditional MVC? In MVC, the final output is HTML strings. Easy example: supposed you have an array of Posts in your controller, and a HTML template. The final result will be the combination of both of them. But when the HTML strings get sent to browser, you lose the array !!! It's gone. The client never receives an actual array, just DOM nodes.

In Front-end framework SSR (NextJS or NuxtJS), what you work with is a component. A component can have data (an array), and the data is pushed (serialize) as-is to browsers. On the browser, you won't ever have to work with low level DOM nodes. You continue to see the component and data in its original form. This is the biggest win of SSR that is easily overlooked.