7 ms·

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

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/ https://jasonformat.com/application-holotypes/

vosper 4y ago
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.
- dylan604 4y ago
  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 4y ago
    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.
    - lazide 4y ago
      It’s risk/reward trade offs. If you can afford high risk (React at the beginning?) and it works, you’re in a sweet spot for a long time. Most of them don’t pay out though, and most JS frameworks that got started around that time died long ago.
- sodapopcan 4y ago
  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.
mwattsun 4y ago
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://seforum.se/2019/01/08/the-history-of-hotmail/ https://en.wikipedia.org/wiki/Holotype https://en.wikipedia.org/wiki/Holotype https://en.wikipedia.org/wiki/Paratype https://en.wikipedia.org/wiki/Paratype
- vosper 4y ago
  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.
- kaycebasques 4y ago
  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 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!
  - SOLAR_FIELDS 4y ago
    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.
  - webmaven 4y ago
    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.
- arthurcolle 4y ago
kaycebasques 4y ago
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 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 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 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 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-architecture.html https://www.usability.gov/what-and-why/information-architect...
sanderjd 4y ago
Yeah this is super helpful!
my69thaccount 4y ago
The holotypes that are best expressed as SPAs don't belong on the web.
- lazide 4y ago
  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.
- wrycoder 4y ago
  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.
  - svachalek 4y ago
    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.
  - boogies 4y ago
    > 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.)
    - mikeryan 4y ago
      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.
karmasimida 4y ago
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
cpitman 4y ago
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 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?

vosper 4y ago

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.

dylan604 4y ago
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 4y ago
  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.
  - lazide 4y ago
    It’s risk/reward trade offs. If you can afford high risk (React at the beginning?) and it works, you’re in a sweet spot for a long time. Most of them don’t pay out though, and most JS frameworks that got started around that time died long ago.
sodapopcan 4y ago
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.

mwattsun 4y ago

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://seforum.se/2019/01/08/the-history-of-hotmail/ https://en.wikipedia.org/wiki/Holotype https://en.wikipedia.org/wiki/Holotype https://en.wikipedia.org/wiki/Paratype https://en.wikipedia.org/wiki/Paratype

vosper 4y ago
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.
kaycebasques 4y ago
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 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!
- SOLAR_FIELDS 4y ago
  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.
- webmaven 4y ago
  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.
arthurcolle 4y ago

kaycebasques 4y ago

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 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 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 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 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-architecture.html https://www.usability.gov/what-and-why/information-architect...

sanderjd 4y ago

Yeah this is super helpful!

my69thaccount 4y ago

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

lazide 4y ago
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.
wrycoder 4y ago
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.
- svachalek 4y ago
  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.
- boogies 4y ago
  > 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.)
  - mikeryan 4y ago
    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.

karmasimida 4y ago

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

cpitman 4y ago

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 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?