The web app and the web site should be friends,
Oh, the web app and the web site should be friends.
One app likes to manage state,
The other site’s less than 48 (kB),
But that’s no reason why they cain’t be friends.
Clearly I shouldn’t plan on switching careers to go write a musical any time soon. 😅
All kidding aside, a debate continues to rage in the broader #webdev industry, and that is the question of what constitutes a web “site” vs. a web “app” and why the development techniques used for one vs. the other can vary so dramatically. It’s even been suggested that the web essentially “bifurcate” into two different (but loosely-coupled?) platforms. The document web as some folks call it would have one set of considerations and constraints, and the application web would have yet another.
A Clean Start for the Web by Tom MacWright is probably the best articulation of this concept. Tom’s also written a couple of seminal articles about web architecture in general such as Second-guessing the modern web and If not SPAs, What?, so it’s well worth your time to read through those if you haven’t already.
I have many thoughts on this matter (surprise surprise 😉), but I’ll elaborate on just a few key points which I hope may help us make sense of this and a possible path forward.
Point #1: The Dearth of Novel HTML-First Features Has Been Appalling #
How many articles, podcasts, presentations, and educational tracks are you familar with centered around JS? CSS? Now how many do you know of which are centered around HTML? 😂
I think this simultaneously causes two problems:
- Application Web people continue to feel smug in their ivory tower of abstractions, regarding HTML as little more than a “build target”. In fact, from that vantage point, the closer the markup can get to compressed bytecode the better. I’ve legit had web developers tell me they wish they could just ditch HTML entirely. WTF 😠
It might sound like I’m biased on the document web side, and perhaps I am, but that’s not really it. I’m biased on the HTML side. So by HTML lagging so dreadfully compared to the other technologies in the web spec, it seems to reinforce the notion that the document web has been sidelined in favor of the application web. And because of the anemic nature of HTML’s progress over the lifetime of the web, it subtly reinforces the notion that to be a fancy-pants web application developer, your knowledge of HTML doesn’t need to go much past
class= (or would that be
Point #2: The Progressive Unfolding of Advanced Functionality Will Be Supported by Next-Generation Tooling #
<div> tag soup.
I still feel like PE should be a valid methodology in our world, but somehow the marketing needs to change, because we’re just not winning this battle. Maybe there’s a way to view this not so much as a step-by-step methodology during development, but more as a spectrum of tooling and practices which will vary from project to project or even within a project from feature to feature.
Some are starting to call this approach islands architecture, and I really like that nomenclature. You start with the ocean, calm and sirene on the surface, and then feature-by-feature you define your islands of high-fidelity interactivity and code complexity within the vastness of the ocean.
Point #3: The Progressive Unfolding of Advanced Tooling Will Be Supported by Next-Generation Functionality #
See what I did there? 😜
As an important analogous programming concept to the one we just covered, I’m also highly recommending gradual typing. (Hat tip to Stephen Hagemann for his very thoughtful response to my recent Spicy Web article on static types.) Let’s throw gradual linting and gradual testing into the mix while we’re at it. 😱 Too often we’ve seen industry “best practices” suggest using heavy-duty developer tooling such as TypeScript, eslint, TDD frameworks, etc. for everything in an entire web project from Day 1. I really chafe at such a dictatorial predilection. (Say that ten times fast!)
This is what has made the web so outrageously successful for such a long period of time. Accessibility isn’t just a noble goal to check off for the public using a web page. Developer accessibility is also vastly underrated as a vital aspect of web development. The bar for entry to becoming a web developer must remain reasonbly low. As it stands, it’s become too damn high. (I’ll also throw out the Right to Inspect concept here, but that’s an article for another time!)
We shouldn’t have to debate enterprise-grade code/advanced tooling vs. fast code/minimal tooling as a binary yes/no consideration project-wide (much less company-wide!). Our environments should be sophisticated enough that we can opt-in however and whenever we need to. And to circle back around, our web toolkits and frameworks similarly should start at the most base level of simplicity possible, and then “evolve” in complexity—not “over time as the web industry grows” which has typically been the case (hence the mind-numbing amount of complexity we see today), but over our own time as we work on projects and features.
Bottom Line: We Just Need Smarter Tools, So We Can Be Dumber #
To sum up everything in some fashion, what I’m driving at is we don’t need a separate document web and application web, but we do need our tools to get a whole lot smarter so that we can easily pop back and forth from doing “document stuff” to doing “application stuff” and back again without breaking a sweat—as well as support a whole range of skill levels and performance/quality/maintainability trade-offs in-between.
As a clear way to illustrate this issue of tooling (and apologies for the blatant shilling of my open source project): before I started working on Bridgetown, a progressive site generator powered by Ruby, I built quite a few client projects using both Jekyll and Rails. Jekyll for the public-facing static site needed by an organization, and Rails for additional dynamic functionality (forms, payments) and content management and so forth.
Due to Jekyll & Rails both being Ruby-based software, you’d think they’d get along quite nicely in a monorepo and complement each other well, right? LOL. 😂 They often felt worlds apart, and when using Jekyll I’d miss all kinds of features and methodologies and mindsets which are implicit in Rails and server-side webapps, and when using Rails I’d miss all kinds of features and methodologies and mindsets which are implicit in Jekyll and statically-generated websites. You couldn’t even deploy them similarly! One would go off to Netlify or whatever to get statically-rendered, the other would go off to Heroku or the like for a fancy-pants database-driven installation. Wiring them up as if they were a single atomic “deployment” was a nightmare.
In other words, it was the “document web” and the “application web” in stark relief.
Fast forward to today. My over-arching goal as I work on Bridgetown and subsequently work on downstream projects using Bridgetown is to bring the full spectrum of the document web and the application web together in a single tool and truly offer that “opt-in only when and where you need it” developer experience. I have no hesitation in stating that it’s dramatically easier to get started using Bridgetown than Rails for a content-centric project. And I have no intention of stopping there. Obviously if your application needs are quite advanced, Rails is going to meet those needs far better than Bridgetown and the Roda web toolkit it melds with for SSR. But over time, I expect an increasing number of site/app hybrid projects will fall right within Bridgetown’s sweet spot.
Or maybe Astro’s.
Or maybe Rocket’s.
I think vaguely we all know where we need to head. It might just take a little while longer to get there.
P.S. Yet another analogous concept along these lines is the idea of the self-provisioning runtime…you wouldn’t even need to know how best to deploy your particular site/app! Just point your service provider at your repo, and it figures it all out. Static site? Check. Server containers? Check. Serverless functions? Check. Database? Check. Key/val store for caches? Check. Background jobs? Check. Global infrastructure at key times in certain ways to meet demand and decrease latency? Check. After all, why should you, O Human, need to know all those things? Shouldn’t the computers be smart enough to know how best to boot up and run their computer-y things? (The answer is yes. Obviously it’s a very hard problem to solve. But solve it some people will, I have no doubt.)