Skip to content(if available)orjump to list(if available)

The balance has shifted away from SPAs

miiiiiike

Hello folks and welcome to round 678 of the Least Interesting Conversation on the internet. SPAs are great when they're necessary and MPAs are great at what they do too. Thanks for tuning in, the series stands at 678 ties, see you again tomorrow for rounds 679, 680, and 681.

edanm

I think this is too dismissive of the post.

The post wasn't about "which is better, SPAs or MPAs". It was specifically "what has changed in the last few years that now make MPAs able to handle things that they couldn't before". I for one learned from this post since I don't keep up with the current state of browser implementations of various features, nor with the consequences of these features.

tomphoolery

I disagree, the post is itself a waste of time and energy because this is a problem that basically nobody cares about or is even aware of. It's not a real problem.

azangru

> this is a problem that basically nobody cares about or is even aware of

"Basically nobody" as a percentage of the global population? That's fine and as it should be. "Basically nobody" as a percentage of web developers? I strongly doubt that this is the case; but if it is, it is damnatory of our profession.

danjac

99% of the time the right answer is "use the best tool for the job at hand that matches your team and budget" but that won't generate the clicks.

rat9988

Because it is a useless answer. You don't answer "what is the best tool for the job at hand that matches my team and budget" by "use the best tool for the job at hand that matches your team and budget".

danjac

No, but you answer with specific analysis rather than generalizing clickbait.

kulikalov

Why do you think people upvote these discussions?

nsonha

Because it's popular? Do you think you've made a point now?

kulikalov

That was a genuine question, not sarcasm.

TekMol

Where are those SPAs everybody is talking about?

All sites I use regularly are MPAs:

Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub ...

Reddits new design is kind of a hybrid. It is MPA when you hop between subreddits and other pages. But it shows a post on the same page when you click on it in a subreddit feed. I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something, that the only "somewhat SPA" I know makes me switch to its MPA version regularly.

enra

Apps, not sites. It’s even in the name, Single Page Application. You probably shouldn’t build websites as SPAs but you probably should build most apps as SPAs.

Slack, Dropbox, Google, Notion, Spotify, superhuman, 1Password, Robinhood…

Basically most web tools/apps are SPAs if they have been built in the last ~10years. Github, Reddit and Airbnb were founded ~15 years ago when Rails was still a thing.

s__s

> You probably shouldn’t build websites as SPAs but you probably should build most apps as SPAs.

As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.

How much of that was naïveté vs. misaligned incentives I’m not sure.

In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.

teakettle42

OS developer here. You’re all naive children playing in our sandbox, arguing over what color to paint your sandcastles.

Or more likely I’m just bitter and old.

ericmcer

If you feel old you should try Next.js. I dove into it recently and joined the Discord channel, sometimes I answer questions. It is really interesting helping people who are creating complex apps by stitching together a bunch of npm modules while having absolutely no clue about the underlying implementations, or the basics of web dev and javascript.

MrBuddyCasino

People largely don’t think for themselves, every once in a while the firmware gets updated and they have a new opinion. All you can do is pick your battles, there is finite amount of credits to spend.

ChefboyOG

We are bitter and old, but that doesn't make us wrong ;)

brailsafe

I liked to put the line between whether you're required to sign in to use it or not. If none of the data was necessarily publicly accessible anyway, that's more of a spa suited interface

mostlysimilar

Rails is still “a thing” and is better today than it has ever been.

LAC-Tech

I avoid rails-style megaframeworks like the plague. I'm fine writing the glue code if it means I understand more of the stack, or it doesn't refuse to budge if I occasionally have to go "off the rails".

hirvi74

Really? I miss it sometimes. I haven't kept up with it in over 5 years (switched to .Net now).

I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.

charlie0

Same for Laravel, although it hasn't grown as much as Rails, the amount of batteries included is amazing. There's very little I've had to reinvent, unlike my Node JS projects, where there's too much time wasted in finding and learning 3rd party packages that are outdated in a year or two.

kache_

only because the companies that use rails are stuck on it :P

winternett

Amen, I fondly recall the days when browsers went back to exactly the same page and data that I was on before when I click the back button.

Database driven sites and apps have experienced great performance and functional gains since the marketing teams pushed SPAs onto everything and it's tragic that billions of dollars will be thrown off a cliff (once again) to refactor everything back to prior methods... Hubris always wins until it fails massively.

That being said, SPAs do work well for certain things, but people just keep losing track of the right shoe for the right foot.

vbezhenar

IMO the distinction is simple. You want Google to index your website. You don't want Google to index your webapp.

I'm aware that Google can run JS, but its support is limited compared to server rendering and there are other crawlers behind Google which probably will never be as sophisticated.

mhoad

It’s literally just headless evergreen chromium handling the rendering these days and has been for a while. It handles JS fine on the condition that you as a developer continue to think about accessibility.

Mordisquitos

Yes, sure. If you don't want Google to index your online service, one way to do it is to design the whole thing as an SPA, with all the added complexity and reinvention of the wheel that it involves.

The other way is to add a few lines to your `robots.txt`.

dmje

Couldn't agree more, been saying this for years. There are moments when an "app-like" experience is what's required - and that's mostly (not always but mostly) when these SPAish approaches are relevant.

On big, sprawling, multipage content-rich websites, not so much if at all.

It depends. Web people should have this tattooed on their foreheads.

mattgreenrocks

“It depends” never leads to thought leadership, though.

muxator

> Google

If you mean "google" as "google properties as a whole", then yeah (the fusion of google maps and google earth is something absolutely _mind blowing_ to see in a web browser, for example).

If you mean "google" as "the search engine", then I was perfectly fine with a server side rendered, non-so-much-semantic search it was until last decade. Advanced search worked well, fast as hell already. Hell, there were two search text boxes if you wanted to search for something else once you scrolled down to the bottom of the page.

eschaton

Nah, you should build most apps using operating systems’ native toolkits, and stop trying to pretend web pages are applications.

bowsamic

But then you have to build it three times for desktop and another two times for mobile

CPLX

If the Shopify ecosystem was the only example of rails in existence then rails would still definitely be a thing.

dingleberry420

> I actually are annoyed by the new Reddit enough to switch to old.reddit.com most of the time when I end up on Reddit. Not sure why. But maybe it tells something,

For me it's because the new design is hilariously slow in every way. And also it looks really, really bad. Meanwhile old.reddit.com loads instantly and doesn't burn my retinas.

mmis1000

For people don't know how slow it is. This is a issue I opened 4 month ago and hasn't been answered.

https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig...

jiggawatts

I didn't know Firefox had the capability to post performance traces like this!

Also... I wouldn't have thought that by default it would include screenshots of potentially private/sensitive information such as the the titles of other open tabs.

dredmorbius

Even old.reddit.com is annoying enough that I head first to https://teddit.net/ Principle advantage being that Reddit URLs are rewritten such that once on the site, you stay there. This isn't the case for either old.reddit.com or the even lighter alternative i.reddit.com, for which reverts back to www keep occurring.

dingleberry420

> This isn't the case for either old.reddit.com or the even lighter alternative i.reddit.com, for which reverts back to www keep occurring.

FWIW if you're logged in you can go to your profile and make it so www.reddit.com just shows old reddit

tshaddox

YouTube, Facebook, Instagram, and Twitter are the obvious examples from among the top 10 or so most visited websites in the United States.

TekMol

What is SPA about YouTube? It feels completely MPA to me.

NovemberWhiskey

Minimize a video so it's playing in the corner of the browser; notice that the video continues to play seamlessly as you navigate around the site. You can't do that in an MPA right now.

323

It's an illusion. If you look carefully you'll see that all YT content is loaded dynamically, starting from a blank page with a blank video player.

tastemykungfu

If it feels completely MPA to you - then they pulled off their SPA implementation :)

Akronymus

I have a redirect set up for shorts to redirect me onto a normal site. As youtube loads the content dynamically, then sets the URL it doesn't work unless I open the short in a new tab or do a f5.

Seems SPA to me.

eyelidlessness

The only distinction that matters is whether it has a client-side router. If it feels like an MPA, and doesn't feel slow, that can be easy to miss. But it’s still a SPA.

Jcampuzano2

When an SPA feels snappy enough/works well enough that you confuse it for an MPA, it means they are probably doing it right.

littlecranky67

Also maintaining fullscreen play during video changes (playlists) is only possible in SPAs. In an MPA, every page re-render would require user interaction to go back into fullscreen again.

epistasis

I think new Reddit is intentionally terrible, and incorporates SPA attributes, purely to make the experience unpleasant and drive app usage. They offer old.Reddit.com so that some core users don't leave, but those users might not be needed forever, if a different user base can be cultivated.

littlecranky67

I've been developing SPAs as an independent contractor for over 8 years, and not a single of those SPAs is public facing - they are all enterprise line-of-business apps used internally. Sometimes I wondered how employing a team of 10-15 developers to develop an SPA for 1-2years (plus maintenance) is profitable, if your targeted user audience is 2,000-3,000 internal employees of that business.

My current gig for a smaller corp (<50 employees) I am with 3 other developers (1 FE, 2 BE) and all that team has been doing for almost 1.5 years is to develop a SPA webapp that is exclusively used by the on-call phone support staff, which are no more than 4 actively working supporters at the same time. Admittedly, the business customers deal in huge amounts of money so having qualified phone support is a must here, and upselling/sales also happens on those calls.

bratbag

I have worked on similar projects in finance, where various regulatory requirements prevent using adhoc internal tools.

It's either use an application provided by an authorised third party (who take a cut of every transaction) or become directly authorised to run solo with your own application that meets legislative requirements.

eyelidlessness

GitHub is definitely not an MPA. Or at least most of the core functionality people use for work isn’t. It feels like one under ideal network conditions, but if your connection stalls you can see its routing stall before any attempt to load a new page.

msbarnett

GitHub is an MPA Rails app that uses turbolinks to make page transitions quicker, which is what you’re seeing stall. No routing is done client side.

maxloh

Navigations within the same repo are powered by client side routings (e.g. from "Code" tab to "Issue" tab).

bdcravens

Github is a Rails app, and leverages Turbolinks which does partial page renders (but still keeps routing server-side)

88913527

The best apps seem to be fully MPA or SPA. The hybrids have UX problems. It's arbitrary some things require a hard page navigation, and others don't. I mean, it's probably an intersection between product/engineering teams, but as a user of an application, I have no real visibility into that nor concern for it; I just see the dichotomy.

null

[deleted]

pkamb

Old.Reddit.com does some kind of page-reload every time you navigate back to the subreddit from a comments page. Incredibly annoying and makes Hacker News feel blazing fast by comparison.

Does anyone know how to block that page reload and associated movement of stories and scroll position on the page you're returning back to?

egypturnash

I do not know how to stop it and I hate it so much.

null

[deleted]

bmacho

Replace the button you click with

    history.back()
with tampermonkey?

nickreese

Author of Elder.js (mentioned in the article) and avid lover of both MPA and SPA.

Daily I am writing MPAs for SEO assets and SPAs for internal dashboards used to manage the huge amount if data collection our teams do.

It really boils down to what you are building.

Google is decidedly terrible about indexing JS for sites with a low crawl budget. Why make your life harder. That is why I wrote Elder.js. Statically generate everything, sprinkle in interactivity where needed.

But for internal dashboards I developed a internal framework to spit out crud apps based on nothing more than a couple graphql queries and a couple yupjs validations. It is a breeze and adding new data collection fields takes minutes so I and my team can focus on stuff that drives business value… instead of crud.

As with everything picking the right tool for the job makes the job a lot easier. Don’t give into the hype one way or another.

zmmmmm

They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether it's one page or ten but it does simplify things enormously that I can maintain a single model object and not have to persist it in and out of local storage or even worse have all the complex UI state replicated on the server side to maintain continuity, just because the user clicked a button or something. Especially with reactive frameworks where updating the model automatically triggers re-rendering of the UI everywhere it needs to, a whole piece of complexity in your architecture just goes away.

theonething

I actually see having to manage client side state as one of SPAs' greatest downsides. You're literally doubling the complexity of your application. Now you have to maintain state on both the server and the client and it becomes a great effort to make sure they don't get out of sync.

The way I see it, the state of an application resides in the server, more specifically, the database. Let's keep it there.

bowsamic

If you have a UI, you have UI state, so you’ll have to synchronise it somehow

theonething

If your UI is rendered on the server, then your UI state remains on the server. It just ferries that state to the client. There's no synchronization involved because it's synchronized by default.

my69thaccount

SPAs suck at client side state, they barely work with the back button or scroll bar and if they do its because its reimplemented in JS.

nighthawk454

Not browser state, but application state. Lot more boilerplate and glue to do that on server side and ferry it back and forth.

infogulch

But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.

nightski

I build internal apps for my clients and this ship has sailed. They love the interactivity and quickness of a SPA. For a while I was doing application per page type of apps and it worked fine. But honestly maintenance has become a lot easier just making it a SPA. I have no idea why I'd go back to having to maintain a JS entry point per page instead of just one for no benefit whatsoever.

Reading HN you'd think 99% of development is landing pages and blogs. Maybe it is? lol. But I have a feeling many here develop a lot more sophisticated applications including but definitely not limited to data analysis, charting, workflows and business processes, statistical analysis, optimization, and having a reload on every little operation makes things significantly slower from a user experience perspective.

eyelidlessness

You should take a look at the frameworks mentioned in the article. They each address some or all of your concerns. The distinction here isn’t going back to “old school” MPA development, but a trend in component frameworks towards shipping more truly static HTML and less unnecessary JS.

For the landing page/blog type experience, Astro is a great fit. Qwik is probably a better fit for your use cases as it’s intended for more interactive apps. But both can span that interactivity spectrum. I can’t speak to where Elder fits on that spectrum, not having used it and having little experience with Svelte.

I’m disappointed not to see Marko mentioned, as it’s been in this category for years and used at scale at eBay. It fits very well in the middle of the interactivity spectrum.

Anyway, it’s worth checking all of them out just to even see what’s happening in the ecosystem. I’m personally very interested in Qwik‘s familiar React-like DX with what they call “resumability”: their alternative to hydration; components compile to fine grained chunks and resume from state serialized to HTML, rather than re-running the original component on load.

BigJono

No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. People need to stop bringing in that complexity when they don't need server rendering.

This is basic software engineering shit, and it boggles me that the industry can't get it right. Same kind of code goes in the same place and runs in the same context unless you specifically need to do otherwise. No reason not to route and render on either the client or the server unless you absolutely need both.

Trying to get fancy is how you end up with a truckload of bugs you wouldn't have otherwise had. I've been on like 5 projects that have spent months dicking around with Next or Nuxt or Gatsby or whatever rubbish, lighting client money on fire, for a portal behind a login that doesn't need to be indexed and would work totally fine as an SPA.

eyelidlessness

> No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them.

Should was probably too strongly phrased, shouldn’t definitely is. The suggestion wasn’t “hey go learn a new framework, your current solution isn’t up to date” or whatever. It was really, very sincerely, “the frameworks discussed in article agree with you, you oughta keep an open mind”. Encouraging both a general, and clear area of interest, spirit of curiosity.

I don’t get the sense that you have or want that curiosity on the topic, by all means stick with what’s working and carry on.

If your comment was paired with downvote, I do want to thank you for the comment. It’s refreshing to get a perspective on why someone didn’t like something I said, when I wouldn’t have that insight otherwise.

linkjuice4all

I've been mixing React with static exports from WordPress. It's unbelievable to say that I actually like this solution after spending years and years with PHP, custom JS front ends, then jQuery and the backend frameworks.

React continues to get better and is great for highly interactive and customized experiences. Browsers are also making it more usable so it's just up to the front end devs to make sure history state and other stuff is accounted for.

WordPress continues to be terrible but accessible to the masses for your landing page and blog stuff. That means your design and content team don't get bogged down in the app dev process and you don't have React slinging fixed/static content. They can just bash stuff around in WordPress and export the static pages for a quick deploy.

purplerabbit

What do you mean by “static exports from WordPress”? (never used WordPress before)

linkjuice4all

The Simply Static[0] plug-in exports all of your WordPress pages and assets into a directory that you can deploy. It basically renders the entire site and takes a snapshot of the rendered HTML.

You'll lose dynamic features (but ideally you'll be doing that stuff in your React app) but the static site is very quick and you'll avoid some of the security headaches of a public WordPress instance.

[0] https://wordpress.org/plugins/simply-static/

andybak

> Reading HN you'd think 99% of development is landing pages and blogs.

I would have said "Reading HN you'd think 99% of web sites are web apps". Most of the web is content with a light smattering of interactivity

> They love the interactivity and quickness of a SPA.

It's very easy to avoid the full page load without needing to go full-on SPA.

> I have no idea why I'd go back to having to maintain a JS entry point per page

I'm not sure what you mean here. "Progressive enhancement" was an excellent idea that didn't stick around for long enough.

ebiester

This is where I think the confusion lies. When I think of the tools that my teams build, they effectively are internal and external tools that happen to use the browser as a platform because nobody was able to converge on a universally-installed tool like java web start. Web applications proliferate because it entirely circumvented the problems of installing software.

The places people are most enamored with SPAs are tools that effectively replace desktop applications. Consider Jira or Trello. These are effectively applications that happen to live in the browser. If you built progressive enhancement on trello, it would effectively mean building a parallel application.

Multiple page applications do not have the ecosystem to make these tools easier to build. I have built these applications before SPAs became the dominant modality and after. The MPA has a long way to go to make this a good experience.

Now I think it's great that content apps are moving away from SPAs. I think the only reason that people did this was to avoid the white flash, frankly, and I'm glad that chrome has solved this. I hope nobody is using react to build their content in 2022.

However, we have a long way to go before MPAs could replace SPAs in web applications. (And frankly, that time would have been better spent in building a tool that is truly fit for purpose rather than overloading the browser DOM, but I fear that ship has sailed.)

stult

I think there is a mismatch between the types of web content that the general public most interacts with and the types of web content which tend to have lots of development resources devoted to them. The ratio of SWEs to users is much, much higher for niche (typically B2B or internal business line) applications, which often require a fair amount of interactivity and custom logic. Whereas the vast majority of random web content used by the general public probably can just be hosted as static sites or server-side rendered apps with better performance and lower cost. HN then just reflects the underlying demographics of the industry and has a disproportionate number of people who work on niche applications where SPAs are still the more appropriate tool.

Which makes sense given the economics. Consumer facing content is generally free to users and funded by ads so the dev costs need to be amortized across more content, which tends toward a lower touch, more scalable approach like static pages where there isn’t much if any custom logic on any given page of content. Businesses on the other hand are willing to fork over cash directly to solve their problems so you get higher touch, more custom solutions where SPAs are relatively more useful.

Also software engineering by its very nature automates routine tasks, reducing their costs and manual complexity dramatically over time to the point that a SWE isn’t needed to carry them out. So none of us work on static sites because at this point it doesn’t take a highly skilled engineer to set up, host, and scale one. One day SPAs and cloud native and k8s and all the latest fads may reach the same level of simplicity, and we will all be working on tuning hyper parameters on ML models or whatever else becomes the de facto cutting edge for the field.

lobocinza

> I hope nobody is using react to build their content in 2022.

Unfortunately they are. People are using React for things that aren't apps.

nathias

I can't even imagine a person being "enamored" by Jira.

rahilb

The grand parent comment is likely referring to ‘deep web’ apps that you or I will never see, which probably replace a series of excel spreadsheets and email conversations.

mmcnl

Most of the web is content, but websites rarely are SPAs. If you only consume content you would hardly know about the concept of SPAs.

I think it's weird to compare websites with web apps. Instead web apps should be compared to desktop applications. So many applications in the corporates have been replaced by web apps. In the company I work for there are 0 "desktop" applications other than Office, and even those applications you can use using a web browser. Then you see a massive shift and that balance is not shifting away at all.

sanderjd

> Most of the web is content with a light smattering of interactivity

Absolutely right. But is that what most people here are working on? Aren't content sites like this largely a solved problem?

jabart

If your non-spa app requires a page load per an operation, my opinion is someone built it wrong. You can do a lot with < 200 lines of JS to make a page interactive.

Legacy apps were rebuilt as SPAs and rebuilding them made them faster.

"Spinning wheel of doom" is used by users now to describe delays in both SPA and non-spa web applications. Same tricks to make a SPA feel responsive work for both styles.

dymk

In 200 lines of JS, you can add maybe an interactive file uploader, or a tooltip implementation, and some form validation. But good luck doing anything of "business-tool" complexity in 200 lines that constitutes an application.

Spivak

Yeah I’m so confused what people think “interactivity” even means, like do people think interaction ends at “make the hamburger menu open and close?”

cjbgkagh

I find the more interactions I add to a non-SPA the more SPA like it becomes.

sanderjd

Yep, but with ever-more wheel reinvention.

sanderjd

I relate to this so hard. It's hard to know what other people work on, but I haven't worked on a web site in over a decade, and it's just honestly hard for me to relate to people who can't understand the user experience benefits of within-page interactivity.

jhgb

Are you sure that something like PJAX wouldn't bring you like 80% along the way from MPAs to SPAs, as far as "interactivity and quickness" is concerned? Or did you already try that?

null

[deleted]

my69thaccount

Do your clients have any accessibility needs?

Etheryte

Accessibility has nothing to do whether your page is cut up in one way or another. You can build accessible pages that are SPA and unaccessible pages in any other way all the same. Most if not all accessibility issues stem from lack of education on the matter, rather than technical limitations.

paulryanrogers

One can drive screws with a hammer. It will just take more effort.

my69thaccount

SPAs are inaccessible by default.

tomphoolery

> Blog posts are making the rounds listing all the challenges with SPAs: history, focus management, scroll restoration, Cmd/Ctrl-click, memory leaks, etc.

I guess? Like, who is implementing all this BS themselves? Every time I've written a SPA, my framework and/or routing library handled all this crap for me. None of these "challenges" were ever problems for me, and this sounds like another case of programmers creating an issue where there actually isn't one.

If you use a proper framework or routing library that changes the history state of the URL, it's pretty much impossible for users to tell whether something is a SPA or an "MPA". So who cares?

nullbytesmatter

And yet, a large portion of big websites using SPAs don't seem to have functioning back buttons. If a billion dollar company can't get it to work properly I doubt anyone else can.

tuyiown

> If a billion dollar company can't get it to work properly I doubt anyone else can.

Billion dollars companies rarely delivers high quality software, especially in the UI area.

SebastianKra

Back buttons in web apps are hard regardless of SPA or MPA. I've seen many MPAs fail, for example after checkouts or form submissions. The problem is just more prominent with SPAs because they usually feature more complicated navigation.

Perhaps for privacy reasons, you don't get much control over the built in history: you can push, replace and pop. Maybe you could implement your own history, but then you need to somehow keep that in sync with the browser.

If someone knows a good approach, I'd be interested.

presentation

Or maybe that billion dollar company's users don't change their preferences based on back button behavior so they feel no need to fix it.

kaycebasques

Discussions about website architecture become a lot more productive when you use Jason Miller's holotypes idea [1] as your starting point. "Holotypes" is kinda just a fancy word for the common top-level uses of the web. E-commerce, search, media player, etc. With that foundation it becomes obvious that SPAs make a lot of sense for some holotypes and a lot less sense for others. We waste time when we talk as if MPA or SPA is appropriate for all website architectures because neither are and never will be. The uses of the web are just too broad at this point.

[1] https://jasonformat.com/application-holotypes/

mwattsun

I'm generally opposed to jargon in tech writing so the use of 'holotype' caused me to look it up. I'm not sure it works. For example, by the definition Hotmail should be the holotype instead of GMail, which would be the paratype. (if I'm reading it right, I am not a zoologist.)

How Hotmail changed Microsoft (and email) forever

https://seforum.se/2019/01/08/the-history-of-hotmail/

https://en.wikipedia.org/wiki/Holotype

https://en.wikipedia.org/wiki/Paratype

heavyset_go

Something rubs me the wrong way about unnecessarily obfuscated jargon for relatively simple concepts in web development. The term "isomorphic code" has been living rent free in my head for like a decade and it still drives me nuts.

aaronbrethorst

Big Thesaurus Energy is a pox on clear communications.

mattgreenrocks

The goofy thing is how quickly that term fell out of the vernacular, and how few people (other than you) even stop to be amazed at the ridiculousness of it all in hindsight.

recursive

This is how I feel about "serverless".

arthurcolle

> if I'm reading it right, I am not a zoologist.

This had me in stitches. I'm also not a huge fan of obfuscatory jargon, irrespective of how cromulent such language may be.

dvngnt_

but then you used the word "cromulent"

pdonis

> by the definition Hotmail should be the holotype instead of GMail, which would be the paratype

I think in this particular case the term "holotype" is being overloaded; it means both "general category of applications" and "what this author takes to be the canonical application in that category". I don't think an exact parallel to the zoological usage is intended.

kaycebasques

For sure it's a terrible name (sorry, Jason ;P). In my other comment I talk about my experiences pitching this idea when I was https://web.dev content lead. There's something about this word that is an immediate turnoff and prevents people from really looking deeply at it. Which is a shame because it's such a useful mental model.

Names are important!

webmaven

Could archetype/al/ical (or possibly prototypal) have been used instead? Both have associations with artefacts (usually authored and manufactured, respectively) rather than gathered specimens.

SOLAR_FIELDS

Sometimes when going deep into a subject I have to pause and explain that it’s a very specific name for what we are talking about and while it may seem pedantic, Naming Things Is Actually Incredibly Important. IMO naming things properly is at least 25% of a good system design.

vosper

Yes, they could have just listed examples and done without the “holotype” term. I don’t think it detracts from the point of the post, though.

vosper

Thanks for this, I liked it.

I’d recommend anyone who’s posted for/against some web practice to read it.

Maybe one day we could all collectively acknowledge that people work on different stuff, with different goals and under different constraints, and there isn’t actually one right way to build for the web. It’s such a tiresome part of HN.

sodapopcan

I don't believe that (all of) the people who get frustrated by these things don't understand that different problems require different solutions, it's when the majority of the industry (or more likely an influential minority) starts to say, "Hey! Let's build EVERYTHING this way" that that people start to complain. And I say this is warranted as it affects the job market. SPAs have their place (highly interactive applications that more closely mirror traditional desktops apps, I would say, the main one) but so many companies out there are developing their apps as SPAs that have no business being such and some of us would rather not have to deal with that (I've experienced this first hand).

The other side (or one other side) of the coin, of course, is that our industry is super new and we're all still figuring it out. I always liken out industry to thinking about how long it took to standardize the hammer design we have to day. I don't have the exact stats, but I'm thinking it was probably 100s of years and our ancestors had many a fight over a big rock vs a plank with a bit small bit of steel on the end of it being the better choice.

dylan604

Yes, just like _____ written in [Go|Rust|flavoflav].

However, at the beginning of every project, this conversation should be had. What are the needs of the project, what gets us there fast while still allowing to grow after scopecreep, what is going to allow for maintanence and future needs?

Picking the latest tech just because it's a new project and you want to use the NEW on it just for the sake of it will probably mean finding yourself painted in a corner in the future (or maybe not the original dev, but those that are forced to follow).

vosper

Of course, a discussion should be had, choices should be weighed.

But since you mentioned “new just for the sake of it” I’ll mention that I think that’s overplayed, too. If you picked React when it was new, or GraphQL, or NextJS, then you probably made a pretty good choice. Backbone was the first of the modern MVC frameworks to get traction (someone will correct me on this) and if you’d chosen that when it was new it would also have been a pretty good decision. Kafka’s still around and going strong, wouldn’t have been a bad choice early-on.

cpitman

Thanks for the link, it is an interesting and obvious way to have clearer conversations.

Multiple types have a recommendation to use "turbolinks-style transitions", which was new to me. So I did some research, and it's basically another take on "just render html server-side, and let a framework take care of AJAX-ifying it". I've seen some attempts at this before, like the UpdatePanel's from ASP.Net Web Forms back in the 2000's.

It looks like Turbolinks itself is defunct, but has been superseded by Turbo (https://github.com/hotwired/turbo), and I only see chatter in Rails communities. It also looks like there are some other alternatives.

Are people actually using "turbolinks-style transitions"? And if so, what are you using how is it working out for you?

kaycebasques

I think it's also relevant to mention that I spent a lot of time thinking about whether web developers at large should use SPAs or MPAs. It'll take a bit of my history to explain.

I was content lead for https://web.dev from 2019 to 2021. My job was to create and execute the content strategy of the site. The mission of that site was [1] to provide actionable insights on how to build better websites. But the big challenge is how do you provide guidance for the web at large?? We know through MDN surveys, HN discussions, Twitter, etc. that many web developers are drowning in uncertainty around how to architect their website. Which framework to use is a key uncertainty. MPA or SPA is another one. So to me this was the obvious opportunity for https://web.dev. Help web developers make better architecture decisions and the overall web experience is bound to get better. But if you've seen web developers talk on Twitter you know that these are landmine topics. If you don't handle it extremely delicately and respectfully and fairly you are setting yourself up for a tsunami of vitriol. This is 10x true for anything that the browser vendors do or say (a lot of Googlers work on https://web.dev).

So here's where holotypes comes in. When I read holotypes I see a very useful framework for understanding website architecture. And it provides a way to logically/fairly recommend SPAs or MPAs. The answer is that it depends on your use case. If you're building a content-heavy, interaction-minimal site like Wikipedia then no duh an MPA is probably the right call. If you're building a media player like Spotify though then a SPA makes a lot more sense. You can use the same logic to figure out which framework is probably best for you.

So going back to my personal history. I pitched holotypes as the overarching information architecture [2] for https://web.dev. It didn't really go anywhere. The main reason was that I was just too green as a leader/manager to push through a big change like this (or I'm just not a very effective leader/manager in general). I still think holotypes is a phenomenal way to think about website architecture and I'm honestly sharing all this to encourage someone to carry the torch and create a website that guides you through which website architecture (and framework) to use based on your holotype. Happy to chat with anyone about it further just poke around on my HN profile page to figure out how to contact me.

Also hopefully it goes without saying that this is all just my personal opinion/experience and doesn't represent Google. I'm not even working on the web anymore. Working on Web DevRel for Google or any of the other browser vendors is very delicate work and to all my former colleagues I hope I shared the history respectfully/accurately. My intention here is to share a key idea on how to make the web better (help web developers make better architecture decisions) that I'm never going to personally pursue. If you do this "guiding architecture decisions based on holotypes" idea right it doesn't really matter who "owns" this because all of the decision weighting logic/data will have to be rigorously fair/balanced/open or else it will never take off because one of the vested interests in the web developer ecosystem will mount a campaign to discredit it.

[1] It probably still has the same mission. I'm only saying "was" because I'm no longer on the project. I quit Google in June 2021 for a sabbatical and returned last week working on something very different, Fuchsia!

[2] https://www.usability.gov/what-and-why/information-architect...

webmaven

> It probably still has the same mission. I'm only saying "was" because I'm no longer on the project. I quit Google in June 2021 for a sabbatical and returned last week working on something very different, Fuchsia!

I don't know your background, but this sort of discussion predates the web by quite a bit, though the labels, affordances, and other factors change considerably due to spatial versus temporal constraints.

In HCI (and later on, usability) circles, these were the Multi Document Interface, Single Document Interface, Tabbed Document Interface, and (largely informally) IDE interface debates: https://en.m.wikipedia.org/wiki/Multiple-document_interface

In fact during the days of the early web, quite a lot of experimentation and development was done on making browser windows (especially chromeless ones) participate more fully in the desktop environment as objects such as floating toolbars and widgets. Other efforts were focused on expanding the browser to displace the desktop OS (eg. the Netscape "webtop", or more recently, Chrome Apps).

The details of the pro vs con arguments aren't exactly repeated, but like history, they certainly rhyme, and are similarly affected quite deeply by the capabilities and defaults of the underlying platform, like whether the desktop environment has a global menu bar.

kaba0

I also think that with today’s choices of web technology, separating solutions by “holotypes” is the correct thing to do. But on non-web platforms there is no such choice, yet every holotype has a place. Sure, other platforms has sometimes different requirements, but I do believe that ideally there should be a single unifying way for both kind of webpages/applications.

yhoiseth

Thanks for sharing.

Have you considered adding a “business app” category? Thinking of things like CRMs and learning management systems. Maybe Salesforce would be the holotype?

karmasimida

the balance should come from the business requirement, not something as top-down as if the frontend development works like physics that it has some intrinsic principles to drive into a destined more advanced stage.

this is most likely not true and drunken kruger syndrome

sanderjd

Yeah this is super helpful!

my69thaccount

The holotypes that are best expressed as SPAs don't belong on the web.

wrycoder

Isn’t QuickBooks Online a (multipage) SPA?

Running it on the desktop is far inferior, because a great advantage of QBO is the ability for several people, distributed worldwide, to work on the same account at the same time.

boogies

> Running it on the desktop is far inferior, because a great advantage of QBO is the ability for several people, distributed worldwide, to work on the same account at the same time.

Is there any reason the desktop version couldn’t do that if Intuit wanted it to? (I imagine they just artificially limit it to encourage customers to ditch indefinite license purchases in favor of monthly SaaSS subscriptions, ie. it has little to do with technical advantages of the web and much to do with the profit advantages of software that stays on Intuit’s servers.)

svachalek

Yup same with Google Docs. And there are plenty of other SPAs like Google Maps that just work so well that way, that it's hard to see the argument for banning them.

lazide

100% agree, and people are have been slowly figuring that out. The front runners were the mobile App folks. But it’s going to take awhile for the tide to turn fully again.

I’m curious if Java desktop is going to make a resurgence, or something else will. Platform native Windows dev never really died, but the market definitely shrunk.

zkirill

Our web product went from AngularJS to React to Angular to Angular + Spring. The addition of Spring helped us introduce a useful constraint: if you can build it as an old-school page with Spring, don't put it into the SPA. Angular is reserved for deep core business logic and UI which would be impractical to build anywhere else. One of the biggest benefits is reducing our Angular project complexity, making it easier to keep current with Angular updates. I am happy to hear that SPAs are no longer sexy because this sounds like the landscape has matured. For example, Angular started doing LTS releases.

dimgl

This sounds needlessly complicated.

arcturus17

Now your design system is probably all over the place and you have to know two ways to build a view, and have to decide every time which one to use.

zkirill

You invented a problem. SPA team and Spring team have separate responsibilities. Our customers don’t care how it looks beyond ergonomics and functionality. It took us a long time to shift away from “SPA all the things” mentality.

zkirill

Maybe, shoot me an email if you want to chat about it kirill at getfillet.com

88913527

As someone who works on design systems, I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS.

If all the teams use client-side rendering, I can ship the design system as an NPM package of React components, and you can use tools like Storybook to run visual regression tests without standing up your full environment.

I know I'm speaking tactically here, but a shift away from SPAs seems like a loss for shared UI components and design consistency. I can't just give a CSS file (which is portable across tech stacks) and leave it to engineers to write accessible HTML; there's huge value-add in isolating a11y in something like a React component abstraction.

adrianmsmith

> I struggle with the concept of consistency in MPA's. If every team has their own tech stack, you'll inevitably end up with multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in NodeJS. If all the teams use client-side rendering, I can ship the design system as an NPM package of React components

That's true, but if your various teams are allowed to use various server-side programming languages and frameworks, what's to say they're not allowed to use various client-side frameworks as well? E.g. one team uses Angular, the other React, the other Vue, etc. Then you're back to having the same problem.

regularfry

"Everything is simpler if we all use MY tool."

I get it, there's a sort of lowest-common-denominator argument going on here, but it is still an enforced consistency which ignores the benefits of giving teams the freedom to choose the best tool for their specific job.

88913527

You end up with a Frankenstein application where different product areas feel like they were built by entirely different companies. There's a real price to giving that much autonomy to each development team. You want teams to be empowered, but there has to be ground rules. Having to unwind the "every team had all the freedoms" and having dozens of databases and hundreds of microservices makes implementing anything cross-cutting (auditing, analytics) a slow-as-molasses multi-quarter initiative.

bestinterest

My issue with design systems is that inevitably the team using the internal companies design system has to implement custom components (usually early on) and try to match the feel of the design system already in place.

I'd rather go custom for a project and semi match the already in place feel of the company's UI standards. Then we're only bottle necked by our internal team and not an external team.

Thinking more on this, I'd love the https://tailwindcomponents.com setup for internal design components? Seems like the best of both worlds but does move the base from React/Angular components to Tailwindcss

mrtksn

SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore. The client devices are very capable and the networks are fast, it's very logical to offload the rendering to the client.

I doubt that MPA is coming back but for things that don't need to be SPA in first place, going back to being MPA is reasonable.

jhgb

> SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore.

That feels like creative accounting of code to me. Is the rendering really simpler, or does it merely happen in a different place?

mrtksn

Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy).

Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases. For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.

jhgb

> the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy).

Drawing a circle artificially around a portion of your code and saying "look, now the circled part doesn't need to change!" feels like creative accounting to me as well. If you have multiple clients, the code for multiple clients still has to live somewhere, so it's not like the whole system that you need to build is getting simpler.

Pretty much the only actual difference I can see here is the ability to use more of client's CPU time to run your applications. I'm sure there's applications that could profit from that.

> For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS.

But if you don't do your logic in JS but do it in PHP on the server, you don't need a JS person. And if you were using Seaside, you wouldn't need an HTML/CSS person since everything would be just Smalltalk at that point. It's again just moving stuff around, but someone still has to do that.

I guess one situation where this argument might apply would be if one of the two language options was difficult to hire for.

> You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.

Not even this argument seems any less artificial to me, since if you're ditching something, I'm not quite sure why it matters where you ditch it from -- unless you have no control over one of the sides. In that particular case, I could see this as an argument. If you're forced to do a client for an already existing server, you're obviously justified in doing a pure client-side solution for anything that doesn't exist on the server yet. If you're building your own server, this limitation is removed.

hw

> Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients

I’d argue it makes it more flexible, but not easier. It’s so much easier rendering html serverside than having it all done separately in React.

> Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases

You now also have to worry about versioning and/or coordinating releases. Mobile clients demanding a different set of APIs than web client. use graphql? Rest?

> front end and the back end are agnostic to each other

This is good in theory but in practice when you have to replatform the backend for example, it is often for reasons such as separating out concerns, refactoring, rewrites, or moving the frontend over to a new system etc and that usually ends up with the frontend needing to change as well. The frontend is coupled with the API contract that the backend provides and is not entirely agnostic to each other.

This is pretty similar in nature to monoliths vs microservices where monoliths are by far a simpler architecture.

quickthrower2

It happens in one place, where state can just be a JavaScript object, which is what makes it simpler.

Rendering on the server-side requires transfer of state, so you know the context. For example did you expand the 3rd expander or not?

null

[deleted]

hombre_fatal

Well, they did say it made the server code simpler, not server+client code.

jb3689

Was HTML rendering ever a concern in terms of complexity? No backend engineers at my company do any frontend because JS is a large hurdle. Sending data to the frontend requires serializing and deserializing which duplicates logic and tightly couples two components we’re trying to separate by technology. You need to deal with a slew of new failure modes when your backend can die at any time - particularly if you are lazily fetching like most apps do.

Personally I think the only reason to ever use an SPA should be performance when sending data over the wire is significantly cheaper than sending new templates or when your frontend code needs to handle very complex states. An SPA can also be a good option if you want to dog food your API layer

mouzogu

> client devices are very capable

my browser is using 5GB of ram on three tabs.

> and the networks are fast

yeah, if you work next to the data center.

throwaway4good

For internal apps in the corporate world, all I see now is SPAs based on vue react or angular.

For consumer facing websites, where search engine viz is a concern and less is known about the clients browser, maybe it is different.

coding123

So can we really claim these as MPAs? This is all using the same architecture of SPAs but it moves it to the backend. Technically that's still an SPA that moved the rendering to the server and instead of shipping JSON and telling the browser to update with the new JSON it's the server sending HTML that the browser is told to replace a part of the screen. It's really just the same thing but with a twist. This is not "MPA" tech, it's SPA tech with new bells and whistles. MPA tech (PHP, CGIBIN, etc..) is dead and not coming back.

If the author states this, I would be on board - we're shifting to shipping HTML chunks.