I've been through cgi-bin, to ASP and PHP, to ASP.Net Web Forms and RoR and ASP.Net MVC.<p>I now work on an Angular 17 enterprise application.<p>Out of all of them, the Angular 17 application is by far the most enjoyable to work with. And I was brought into the SPA world kicking and screaming and muttering "get off my lawn".<p>But these points are not necessarily valid. We don't break the back/forward buttons, or page refresh, the initial payload is sizable, but less than many "non-SPA" websites outo there. And it runs a large enterprise. When we release a new update, nobody notices. In the corporate world, downloading a few MB that is compressed over the wire and cached on the client after it's sent ... people don't notice. There are single <i>images</i> on websites bigger than our platform.<p>The first compliment we got after releasing the Angular project was how incredibly fast it was. It's not bloated, I feel that is just an old way of thinking about it. Sure it's not pure HTML with bit of vanilla JS sprinkled in, but it's not going to slow your machine to a crawl (if done properly). Yes, "view source" is going to be a sea of JavaScript that renders HTML. Pure? No. Slow? No.<p>It's not one URI, it's /users/edit/104 and /departments/accounting/invoices/42. It allows bookmarks via deep linking.<p>Would I use a SPA for my personal blog? No, I'd use a static site. In fact, I've had them since the early 1990s and I still do have static sites up right now. But would I use HTML and vanilla JS for a large enterprise system? No. As I mentioned, been through almost every web framework since ASP in 2002. JavaScript since 1997. I know the pros/cons at this point.<p>There are too many SPAs out there, there is no question about it. It's because had a lot of developers go to bootcamps (or teach themselves) which ended up with a <i>lot</i> of JavaScript developers who knew some React. So that has been the go-to for "a website".<p>But I don't feel these points are valid about SPAs. 30 years into it, I'm happy I greenfielded with Angular on this most recent project. Smooth sailing.
I opened this expecting the normal grungy tirade of intolerance & an general small & petty disdain for JavaScript. But there was the authors name and I knew this would be something different and higher class! And how!<p>I feel like the essence of this page needs some kind of rallying flag, some moniker. "Web first SPAs" or "browsing-compatible SPAs," something that can be made recognizable where the web dev tech hipsters can start pressuring each other & companies into doing the right things and not letting their SPAs break the web! This should be <i>critical</i> & visible drive in all web architecture, but its not notable as it's own thing, only seen in the absence of normal good functioning; having a good name to rally around & hype up in the noosphere feels needed.<p>> <i>Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at. (Oh, I know there are exceptions to this rule, but they typically require effort — a lot more than many developers are prepared to invest).</i><p>> <i>My main beef with single page apps, or SPAs for short, is that they’re not "on the web".</i><p>I do see a decent amount of reasonably well built apps, albeit most handle one or two pieces not perfectly. But there's also plenty of dark world dark pattern apps where things you click on aren't links.<p>(Subrant: this is also one of the things that drives me the most up the wall about PWAs. PWAs throw away most of the best parts of the web! Urls are quasi invisible, there's no tabs (unless the app builder specifically builds around Tabbed Application Mode), there's no forward/back buttons, nor bookmarks. PWAs ironically are as regressively anti-web as it possibly can come! They happen to be built with web technology, but obfuscate all web faculties the user might have. Piss on you PWAs, you are trash.)
I feel that this argument is pretty outdated at this point.<p>Most new SPAs people build use frameworks like NextJS that solve all of the big complaints.<p>Sure, there's plenty of old, crufty SPAs from the pre-react-router days still out there. I also dislike those apps.<p>I guess my point is... there was a time when you could blanketly hate SPAs and be mostly right about the category. And you could be mad at a company for even daring to try because they were very likely to screw it up. But I think we are now past that period. SPAs are now pretty awesome and fast and good!<p>Edit: ah, this article is from 2016. Which actually was a very valid time to hate SPAs! Maybe this is a good moment to applaud the hard work of folks at Vercel for fixing the problem :-)
> Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab. They offer no way to link to something that I look at.<p>In my experience, this is very simple when using the Angular Router.
Indeed, it's difficult to not get it working.<p><a href="https://angular.io/guide/router" rel="nofollow">https://angular.io/guide/router</a>
> They have a URI, but only for the whole thing, not for all of those valuable things that are inside of it.<p>This isn't always true, and I wouldn't actually find it to be false more most SPAs I use. Its straightfoward to sync the URL with Javascript state. Most high grade SPAs takes URIs seriously, because they are still the primary way users share views with each other. Traditional URIs point to static resources, but most SPAs contain at least a record identifier, and possibly even a view state. Google Slides is a SPA, but I can easily share a URL with another person, and if they have access they will end up on the same slide as the one I was viewing when I copied the link.<p>> Business logic does not belong in the client, unless you like having to redundantly maintain the same logic in every kind of client you support (in addition to maintaining it on the server, of course — remember that you can never trust any client).<p>I don't see how moving view state management from the client to server solves this issue. Of course you can't trust the client, anyone can spoof API calls. But even basic forms have this issue. You can't trust a form just because you generated options on the server.<p>Also view logic is tightly coupled with the client UX. Moving it to the server does not magically make it reusable. Additionally, having client side logic often is more about displaying a list of possible options, than validating correct choices. Just writing server side validation does not eliminate the need for client side business logic.
Half of the article is just ragging on a specific subset of poorly designed SPAs (those that don't use HTML 5 history mode with proper server side routing set up), which the author acknowledges before finally moving onto other points.<p>The other half I'm not even convinced these are real problems:<p>> A fantastic example of the problems created by the SPA approach is parallelization of work. If you have a team of multiple people, or God forbid, multiple teams working on the same SPA, you need to come up with a good way to support this. Instead, you can just have each of those teams build their own web application. Each of those applications can be connected to every other one built at the same time by the same organization (as well as to every other web application residing anywhere, if you want to) — in fact relying on the core strength of the web.<p>This paragraph I guess presents a problem and it's "ROCA" solution, but the solution proposed works for SPAs too. You can just make multiple SPA applications.
I think that, in 2024, a lot of these problems aren't as bad as they once were, but when this article was written in 2016, SPAs really were a mess. Since then, people have mostly solved the URL problem and the back-button problem, and I think that if your organization has the headcount to support it, there are advantages to having the kind of very clean separation between your backend and your user interface that an SPA can provide. For instance, They can be developed by different teams, on different release schedules. Or, you can replatform your backend without rewriting your frontend.<p>Even so, I kind of wish that most websites still used old-school server-rendered HTML. I still run into all kinds of glitches that just could not possibly happen on a server-rendered site. As an example, I like to visit the Deutsche Welle website to catch up on European news stories that don't make their way to the US, and sometimes their site just flat-out doesn't load, because of some caching problem that I don't care about, because it isn't my problem as someone who just wants to read the news. Since the best DW's SPA architecture can possibly do is to make it look like server-rendered HTML, it's just nothing but downside to me personally. It might make sense for Deutsche Welle itself, but I don't work for DW, and I don't get paid to care about their problems.<p>In the end, I think the overall message of the article still resonates in 2024, even if it doesn't resonate as strongly now as it did when it was written. I think SPAs are good technology when they are used in the right way for the right reasons. But there's a kind of dogma surrounding heavyweight JavaScript frameworks, and I think it pays to be a little skeptical as a result.
I smile, because ALL modern tech try to do what classic Smalltalk environment have done in the past, see a Pharo video demo to get an idea, a DocUI, with active elements. Well, no modern tool so far have reached the same level of power. Modern webapps might have some of that power, but fails dramatically in flexibility and user control...
This may say 2016, but so many of these points still apply today. My biggest issue with these JavaScript-first sites (SPAs and React/Angular/Whatever) is that they break in weird and unpredictable ways. Some of my common complaints that I still see often:<p>- Pages never fully load because some JavaScript file timed out
- Browser history disappearing
- Middle-clicking or right-clicking links doesn't work
- Start typing in a form field while the page hasn't fully loaded, and then the form field clears itself when the page does finally load
- Modal screens only partly load or leave artefacts on-screen when dismissed (e.g. a random spinner icon on the page, or a part of the screen stays dimmed after modal is gone)
- Copy/pasting into form fields doesn't trigger actions (e.g. buttons stay disabled while they wait for a key-press to activate)
- Password manager autofill doesn't work because of some weird JavaScript validation script
- And. So. Much. More.
The biggest contender for breaking browser history and middle-clicking are the fucking Microsoft Admin Portals, especially the Azure Portal.<p>Oh. My. God.<p>I lost all trust in Microsoft when I started using these. It's like the devs don't know the very basics of web browsing, or they all use Macs and want to impose their preference onto everybody else.