SPAs are an anti-pattern.

Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.

There are very clear reasons for SPAs to exist.

1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user.

2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist.

3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed.

This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.

> Prevent reloading of the page every time the user clicks a link,

You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications

> Better emulate the feel of mobile applications,

That's pretty weak defense.

> Once the browser downloads and caches the bundle on initial load, the user can revisit the page

Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long.

All 3 of those reasons sound very reaching to me.

And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA.

Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.

> Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.

Are you legitimately worried about unloading third party libraries into memory on the browser??

unloading third party libraries _from_ memory.

or else gaining the ability to freeze their code and all derived/generated code from accessing the dom/network/etc.

Few things annoy me more in this world than when someone "responds" to arguments by quoting half of them to construct and attack a strawman instead of the argument they're supposedly discussing.

Please don't dilude conversations like this, it doesn't do anyone any favors.

You're not using that word correctly, since this is not a pattern it's an architecture.

Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases.

No comment on whether SPAs are worth anything though, I reserve my opinion.

architecture doesn't contain patterns? architectures don't follow certain patterns?

you've never seen certain architectures that smell because they're not following an established pattern?

So, it's an anti-pattern of an architecture.

The way in which we consume and deliver via internet has moved on from the early days of the web. It's no longer just text, images and links. There's much more to it now, and SPAs are a reasonable step forward to providing richer experiences online with more functionality.

Not sure you could ever call them an anti-pattern.

> It's no longer just text, images and links.

Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.

I'd say a big part of the web is gaming, chatting, interacting. A lot of that content updates every few seconds. Without JS, websockets, ajax requests etc, do you suggest users load the entire page again whenever they want to see an updated view?!

Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!

As another poster said: The right tool for the right job.

Also, a SPA is not the only option with Javascript.

How would the site we’re communicating on right now be improved if it were rebuilt as an SPA?

Threading could be clearer. Less data would need to be loaded on each page load. I can imagine that a lightweight SPA to handle the a few standard views (e.g. listItems, itemDetails, profile, changePassword, submit) would cut down data transfer by a significant margin (20-30%, maybe more). The UI could also be much better on mobile, and we could give users the option to cache certain pieces of content offline.

Offline use already works great, unlike in any SPA I've ever used.

1) Load the page.

2) The page is now fully loaded and ready for reading without any need for further network requests.

For even more offline use, try printing it! HN threads work superbly when printed, again unlike most modern sites.

I don't think printing is a viable solution for most users. I'm guessing most would want to download the comment threads to their phone so they could read them later in situations where connectivity is patchy (eg train/plane etc).

Right. You can do this now by loading the page in a background tab, leaving the tab open and then going offline. Works great.

Or you could reimplement newsgroups (but with less interoperability) as an SPA, which in theory would work great (once you work out the kinks) but in practice would suffer from all kinds of little issues in the from-scratch reimplementation of everything. For example, printing would probably forever be a wishlist item in the backlog.

What you’re suggesting is heresy on HN. It’s true, a little bit of interactivity, fonts/padding/spacing would improve HN. To this day my thumb covers both the upvote and down vote button.

Yes, the UX on mobile leaves a lot to be desired in my opinion. The two things that are going for HN in its current form is the fact that it's lightweight and fast.

A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.

I have yet to see this...

You can check out nodebb for example, tons of JavaScript and quite frankly it’s a better forum experience than reddit or HN:

https://community.nodebb.org/category/2/general-discussion

I also love when i visit a website with a simple markup and minimal js. Not everything should be a react/graphql isomorphic SPA, but have you checked NotionHQ[0]? The whole thing is a single page react app. People use it to build wikis, manage projects and even create blogs and job postings. All that using client-side rendering. It doesn't load as fast as hackernews but most people seem to love it either way.

[0] https://www.notion.so/

I’ve had the displeasure to use this once at a client and I was amazed that they managed to make text editing lag.

I've never heard that somebody disliked vmware vsphere as an spa. the older flash one however...

You still need js for interactive apps, SPAs avoid the spaghetti mix of html rendering and rendering client side.

The most common reasons for building a SPA:

* That is the design pattern dictated by your large framework.

* Maintaining state is absurdly simple, but it requires original code if not using a big framework.

* The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without.

That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).

I'll offer up another reason, which I feel is a little more accurate:

* Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) Because most frameworks push users towards a SPA, you end up following the path of least resistance and developing a SPA.

I would argue most websites never require any of those. When any of those are required they don’t need a giant framework to achieve maintainability. All that’s needed to achieve maintainability is a competent developer who values both simplicity and written documentation.

This sentiment frustrates me. The majority of web developers today are application developers. I've spent the past 5 years delivering business applications via the web as a platform. The web has a lot of advantage as a platform: no install, cross platform, networked by default. But the web was not designed as an application platform, so making it into one is complex. Business applications have inherent complexity as well, and managing all that complexity is a non trivial task.

Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.

I would qualify this: The web is simple when one uses it as intended. (hyperlinked documents that may or may not have interactivity beyond the hyperlinking and embedded media or animations etc.) The web is complex when one attempts to do "GUI by RPC". If one is OK with page reloads, this asynch remote folder browser hypercard thingy is fine. If one seeks to replicate the event-loop desktop "window"-based application one will have the use-case for large frameworks as one will literally be re-inventing all the wheels, which they tend to do, as this is not the default behavior of the application we call a web browser.

Complexity in web products is largely the result of developers who don’t care because they need to ship a product only if that product is written in an extremely familiar way. That’s a product of people who don’t know what they are doing opposed to inherent technological impediments.

I form this opinion as a professional web developer with 20 years experience.

I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as an interface for searching/filtering/editing entries, there is only so much that can be simplified. And yes I know all of that can be done with vanilla JS, but I've done it both ways and I prefer the framework.

Just to chime in here. To be clear, I think dropping a vdom implementation into a page is a good middle ground between full blown “framework” and “roll your own js”. I’m not familiar with vue, but I’ve used React (a library!) to great effect on pages that require that extra bump of behavior.

It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary.

* And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.

I doubt your customer specified dependencies as a business requirement.

I always enjoy a good faith discussion, but if you aren't going to respond to what I actually wrote there's no need to continue this. I _know_ the functionality I mentioned can be shipped without a framework. I _have_ shipped web apps without a framework. I've personally found the overhead of designing and enforcing an ad hoc framework to be not worth the effort.

...almost... i'll accept "an SPA on one server-side route for that one complicated page that's full of bells and whistles."

and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...

Another big reason is that developers want to deliver a specific user experience that is simply not possible with the default page loading functionality of most browsers.

You mean the specific experience when back buttons aren't working? Or when urls don't make sense? Or when you can't just share the content by copying the url because it no longer identifies the conten? Or when you can't say if something is loading, missing, or broken?

This is my user experience with SPAs regarding navigation.

If an spa is behaving like that, the coders have failed at their job.

"PHP is fine, it's just poor developers making bad sites".

And then people stopped using PHP.

PHP wasn't good, fine maybe, though I understand it's better now.

it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)

It’s hard to make the claim that PHP is a bad language and also claim that very similar complaints don’t also apply to Javascript. They’re both languages defined by their popularity in spite of how poor the language actually is.

javascript is a dumpster fire.

unfortunately it's the only actually viable language in the browser.

> And then people stopped using PHP.

Evidence?

In my experience, PHP seems to be more in use now than ever.

A quick HN search shows PHP’s unpopularity. Check the Stack Overflow survey if you need a second opinion.

Conversely, I’m gonna need evidence that PHP is more popular than ever because that absolutely is an extraordinary claim.

People stopped using PHP in which planet?

Exactly.

Use better SPAs.

Agree. There are a lot of bad SPAs out there, but that's a testament to how easy they are to get started with and their popularity.

That doesn't mean good SPAs don't exist - many do!

That’s arguably the best reason to develop an SPA. But I don’t think the linked article is arguing against that as much as arguing against using “SPA think” in places where the user experience really doesn’t require it. There are web sites which are basically magazines/blogs whose reading functionality relies on JavaScript. Building a web site like it’s an app may give some advantages to the developers, but it’s almost always a slower, and sometimes more fragile, experience compared to just delivering HTML.

What's a big framework to you? is React one?

It's already in the name Single Page _App_. If you're not building an app, you probably aren't best served using an app framework.