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.
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.)
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.
I've always felt that DDD is more of a meta-paradigm than a paradigm per-se, and shops that "arrive" at it have actually always been themselves examples of the practice in itself, as opposed to being instances of itself.
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.
At the time, it seemed rather earth-shattering to be programming in the same language on both the front-end and the back-end without a browser plug-in or applet. The possibilities such an arrangement opened up seemed potentially vast.
Up until that point, it had been a basic assumption that the front-end and back-end had to be done in different languages if you wanted a site/app above a certain quality threshold (though Java applets and Silverlight (C#) had previously provided a way to run the same language on the front and back ends).
I didn't find it ridiculous. There were real, tangible benefits, like sharing the same validation code on the frontend and backend. Would I make it the sole reason to choose a given language? No, but there was demonstrable efficiency to it.
> 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.
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.
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 [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!
> 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.
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
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.)
Neither the users or the providers want or care about some desktop p2p/self hosted accounting software. It’s an advantage of offload the risk and accountability.
I think there is also some circular logic when looking at the pricing models for SaaS products. Customers use them because they are the best, but they are very likely the best because they have constant revenue from subscriptions.
So maybe you paid $100 for photoshop and used it for 3 years but now you pay $10/month for photoshop which is more expensive but that’s all more money going in to the product. And with a business tool, the better it is, the more money users make using it. So it’s worth paying more for a better product.
Though I must say, for my small non-profit, the $650/yr for QBO is rather stiff. I only stay with it because I know I’ll be able to find a replacement accountant who understands it. As opposed to, say, gnucash or ledger.
>Is there any reason the desktop version couldn’t do that
There is no reason any experience cannot be replicated on any computing device, barring hardware limitations.
There may however be reasons why things are easier done with one architecture than another, and there may be business reasons (not necessarily of benefit to the consumer) why a particular way of doing things will be preferred, and sometimes it will just be because the people who have been tasked with making something are comfortable making it one way and that is the way they will start because - as we are often told on sites like HN - when making something go with what you know if your purpose is to ship.
What would you suggest? Would it be like Valheim (any many other games) where if you want to collaborate, one person needs to be the host and run their copy of the app and if they aren't running it no one can work?
Or are you suggesting the average user would some how spin up a server and run some software and maintain that server so that all the collaborators can access the thing 24/7?
Me, I love that from any of my 7 machines I can access my docs, spreadsheets, tax info, etc. If I have to use a native app then I can only access it on machines that have that app installed. The app might not even exist on some of the machines I use but a web browser does.
As far as I could ever tell the desktop version of QuickBooks was only some sort of Electron or WebView wrapper around the site. Not knocking it - it worked fine. But that was the main reason I was surprised when they End of Life’d the desktop version.
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.
[1] https://jasonformat.com/application-holotypes/