> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours.
Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text.
And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web?
This is some special kind of madness and I wonder when it will stop.
This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job.
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 a side project I recently tried the middle ground approach and absolutely loved it. There was really only one part of the application that had complex user interactions, so that was the only place that I shipped a React bundle. The rest was just plain ol' templates and HTML.
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.
AT&T’s website account pages only serve static html. But they are rendered by js and I have to wait looking at a loader after every click.
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?
Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.
I've made quite complex web apps with pure CDN-imported (i.e. no Webpack/NPM) Vue as a starting point. They work well, are easier to debug, and get the job done faster. Of course, it's a good idea to take that monolithic JS file and split it up into components for easier future work, but I've found that working like this leads to fewer "tooling hell" headaches.
My rule of thumb is if you arent building some social / multimedia type of experience a SPA wont do much for you that you cant get done with HTML and CSS.
Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this.
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.
JIRA is a case study in bad UI/UX and web anti-patterns, IMHO. I think my team at work is finally ready to ditch it in favor of basically anything else.
One of the managers at work swears that JIRA is the next great thing to happen to us. From all the negatives I have heard I get the feeling that the request to adopt it getting stuck somewhere in our parent company is a good thing.
The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.
The saving grace in these cases is that often the reader mode would work with the HTML just fine and you don’t need to wait for the useless 3MB JS bundle which you may have blocked. The same reader mode trick sometimes works against subscribe-to-read-the-rest-of-the-article paywalls and no-scroll anti-adblock modals, too.
Of course I agree that if you’re only showing text with a few interactive enhancements, you can probably get away with jquery. The trouble is that too often a few enhancements turns into a few more enhancements, then a lot of enhancements, and then you end up with a huge mess of jquery spaghetti. It quickly becomes comical to claim that jquery would result in fewer bugs than pretty much any post-backbone UI library or framework you can think of.
I don't use jQuery much these days, but you can absolutely write quality jQuery code that is well structured and architected. It doesn't need to devolve into spaghetti code. It doesn't have guard rails like some frameworks might, and it's base examples don't really promote non-spaghetti code, but it's not that difficult for experienced JS devs to write good, high-quality jQuery code.
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.
I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve performance & scalability so it would meet our users' needs is too much.
That’s true in a lot of cases mainly because of the approach to rendering. So many languages focus on rendering the entire HTML structure before sending the first byte back, specifically so that the page can be wrapped in a cache. This forces a lot of memory allocation to build up strings and parts of strings that takes time on its own, is often repetitive over the same HTML tags and then all of that has to be garbage collected at the end of the request.
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.
Your older app may be serializing a lot of work. For instance, it could be issuing 10 SQL queries, one after another, which take 200ms each to answer - that's 2s total just waiting for the database. Compare to a JS client which issues 10 backend API calls, each being a 200ms request from the server's perspective (and the JS may parallelize many of those requests)
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.
Why stop now when we got so much out of it? Maybe we will have even better solutions coming now that we have learnt so much.
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!
> 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.
Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC.
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.
Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text.
And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web?
This is some special kind of madness and I wonder when it will stop.