3 ms·

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

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

kaba0 4y ago
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 4y ago
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?
webmaven 4y ago
> 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 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 4y ago

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 4y ago

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?

webmaven 4y ago

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