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.
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.
> 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.
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.
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.
> 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.
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.
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.
We are bitter and old, but that doesn't make us wrong ;)
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
Rails is still “a thing” and is better today than it has ever been.
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".
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.
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.
only because the companies that use rails are stuck on it :P
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.
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.
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.
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`.
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.
“It depends” never leads to thought leadership, though.
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.
Nah, you should build most apps using operating systems’ native toolkits, and stop trying to pretend web pages are applications.
But then you have to build it three times for desktop and another two times for mobile
If the Shopify ecosystem was the only example of rails in existence then rails would still definitely be a thing.
> 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.
For people don't know how slow it is. This is a issue I opened 4 month ago and hasn't been answered.
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.
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.
> 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
YouTube, Facebook, Instagram, and Twitter are the obvious examples from among the top 10 or so most visited websites in the United States.
What is SPA about YouTube? It feels completely MPA to me.
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.
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.
If it feels completely MPA to you - then they pulled off their SPA implementation :)
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.
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.
When an SPA feels snappy enough/works well enough that you confuse it for an MPA, it means they are probably doing it right.
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.
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.
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.
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.
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.
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.
Navigations within the same repo are powered by client side routings (e.g. from "Code" tab to "Issue" tab).
Github is a Rails app, and leverages Turbolinks which does partial page renders (but still keeps routing server-side)
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.
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?
I do not know how to stop it and I hate it so much.
Replace the button you click with
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.
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.
Not browser state, but application state. Lot more boilerplate and glue to do that on server side and ferry it back and forth.
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.
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.
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.
> 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.
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.
What do you mean by “static exports from WordPress”? (never used WordPress before)
The Simply Static 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.
> 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.
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.)
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.
> 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.
I can't even imagine a person being "enamored" by Jira.
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.
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.
> 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?
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.
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.
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?”
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.
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?
Do your clients have any accessibility needs?
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.
One can drive screws with a hammer. It will just take more effort.
SPAs are inaccessible by default.
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.
> 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.
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.
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.
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
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.
Big Thesaurus Energy is a pox on clear communications.
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.
This is how I feel about "serverless".
> 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.
but then you used the word "cromulent"
> 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.
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!
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.
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.
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.
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.
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.
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).
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.
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?
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  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  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.
 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!
> 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.
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.
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?
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
Yeah this is super helpful!
The holotypes that are best expressed as SPAs don't belong on the web.
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.
> 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.)
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.
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.
This sounds needlessly complicated.
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.
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.
Maybe, shoot me an email if you want to chat about it kirill at getfillet.com
> 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.
"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.
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.
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
> 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?
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.
> 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.
> 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.
Rendering on the server-side requires transfer of state, so you know the context. For example did you expand the 3rd expander or not?
Well, they did say it made the server code simpler, not server+client code.
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
> 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.