I took a month from my last post to reflect on what the future of the internet might be. To recap, the internet is in a precarious state, from but not limited to the following:
- it’s lost many of its great protectors
- it’s being actively exploited as the ultimate propaganda machine
- it’s frustrating and burning out its maintainers
But is it unsavable? On the contrary; I still believe the internet itself can be a powerful vehicle for good. I can’t speak on the first 2 problems, but I can on the last topic: frustrating and burning out its maintainers. Because what better way to save the internet, than to make the barrier to entry as low as possible to allow the right people to help build it?
So in that vein, I think the internet is long overdue for a (realistic) reimagining. Keep in mind what follows is complete imagination; an utter shot in the dark. Assume HTTP and the underlying protocols all still exist, but what if we could reinvent the fragmented HTML/CSS/JS mega-ecosystem with all the server-side languages, frameworks, preprocessors, and bells and whistles that come with it? And if we did, could we make lives easier? Here are 4 ideas to make web dev more maintainable:
🔗future 1: overhaul HTML
HTML was originally created to easily create rich documents. Problem is we’ve been building highly-interactive web apps for years. And because of that disconnect, we have to build the same UI components, over, and over, and over (and over) again.
Although one solution to alleviate this sisyphean task would be to ditch HTML and the “document” idea altogether, HTML is responsible for some of the most accessible interfaces we’ve ever built. Screen readers and a suite of tools revolve around HTML’s design, so simply throwing it away would mean decades of setback for less-abled individuals.
What if we kept HTML, but made it do more out-of-the-box? What if instead of building the 5,672nd
multiselect in [framework of choice], we could instead add a
<input type="multiselect" /> to the
page and be done? Or how many terrabytes of npm packages could be reduced if browsers shipped a
“But there IS
<select multiple> already!“ some will say. But I know you’ve never used that—and
only that—to add that interaction to your site. It hasn’t worked for mobile devices in years. And I
know you’ve never used an unstyled
<input type="date"> to fully power your hotel or
airline-booking website. Google—the biggest advocate for the
<dialog> element—doesn’t even use it
anymore in its Material Design for web.
“But the Web Components spec!” “But HTML5 was designed to create custom interactions!” I’m not saying that there’s been no reason, or thinking, that led us to where we are now. I’m simply disagreeing with it.
Look at how far native development has come—both iOS and Android have common UI that works, and works well. Why are the default HTML elements so garbage? And why is it impossible to style most of them?
🔗how it will help
For web we spend so much time setting up projects, build tools, and remaking the same UI components as others with almost the exact same results, it feels like we’re all too tired by the time we get to the actual work. By having a much more usable set of UI components baked into the browser, we could more quickly create sites and content.
🔗how to get there
We need a new community-oriented HTML spec that saves us from building the same UI elements over and
over and over again. And we need a new browser that supports all of these. We need all the 1300+
proposed elements not only to ship, not only to be stylable (looking at you,
<progress>), but primarily to be usable without styling.
One better future for the internet is if politely, and with all due respect, the HTMLWG takes a seat while the community builds one central UI solution to serve the needs of the modern web. We can have it if we build it (and if you want to build it, contact me!).
🔗future 2: bye bye browsers, hello native
What if we ditched all that? What if, instead, we shipped experiences like apps in iOS or Android? Consider:
- Native apps have built-in offline mode (unlike the web, which requires complicated setups like service workers)
- Native apps have unmatched performance, being compiled rather than runtime scripts
- Native apps are more bandwidth-efficient since they don’t have to be redownloaded every time they’re used
- Native apps can offer similar accessibility because more of the device can be used
- Native apps can offer a wider range of experiences, partly by way of being closer to the hardware; partly due to the increased performance.
Of course, I’m not saying anything new or revolutionary. The Web vs Native debate has been talked about ever since the arrival of the Apple App Store (arguably as a continuation of the classic desktop application vs web software debate). But the reality is that even Apps need APIs, web servers, HTTP, and all the infrastructure the web resulted in. We’d still need REST, GraphQL, and whatever comes next, using the variety of languages we have available. The difference is we say goodbye to the browser, and let apps do the heavy lifting now.
Assume there’s a development environment that lets you build native applications for every target (for example, Flutter). Assume that one codebase could generate native clients for all major desktop and mobile OSs. Also assume there arises some open way to produce apps that’s not gatekept by a corporation like Apple or Google (like npm or GitHub—though corporate entities— have fostered an open, community-powered marketplace where anything may be published for free).
Assuming all those roadblocks were removed, what’s stopping us?
🔗how it will help
🔗how to get there
So the trade I’m proposing here is a vastly simpler web environment, and the next-generation of experiences. In exchange? We only need to give up the archaic yoke of browsers that have hindered progress. We employ a model to experiences similar to npm or GitHub, where experiences can not only be downloaded; they can be examined for security.
“That’ll never happen,” some may say. But let’s put a spin on the current reality for a bit: isn’t Google the only way you can use the internet today? Isn’t Google just a shittier app store in its current form? What if we could improve everything across the board? We could with native, if we solved the discovery and oversight problems.
🔗future 3: jamstack, except it works
- Static Typing in JS: What if TypeScript became a part of the language spec? It would not only mean more reliable applications; it would also drastically simplify and speed up build tools
🔗how it will help
One could argue this is our current path, merely a projection. This makes the bet that it’ll get even worse before it gets better in terms of complexity and knowledge required. But the payoff some, new, “holy grail” future framework that will make everyone’s lives easier.
🔗how to get there
Several things need to fall in place to pay down the debt we’ve been accumulating for a while. If we do decide that JS is the foundation, and not HTML, then we need build tooling that handles all of the above:
- Doesn’t load any JS to the client if it’s not needed.
- When JS does load to make the page interactive, it only re-renders the interactive parts, rather than blocking the main thread and hijacking everything in the browser.
- Doesn’t require agonizing compile times that cost time, money, and headaches.
While this the closest direction to the one we‘re heading in, it’s a humbling reminder that some of the biggest, hardest pieces have yet to fall in place—mostly the SSR part. And it’ll take a lot of work yet before the “bet on JS” has actually paid off.
🔗future 4: a tale of two webs
Tom MacWright’s A clean start for the Web outlines a Document Web and an Application Web coexisting, a little like combining futures #1 and #2 above. While this is an idea that I’ve been thinking about for a while, I have to give Tom the credit, because he wrote it down and I didn’t (also he puts things into words better than me; why are you even reading my blog again? Go read his!).
So one could argue that this is either a migration or experiment towards an alternate future, but it may end up being a viable path for longer than Tom devotes space for in his blog post. In summary:
- Document web is for reading. Wikipedia, news, blogs, etc. Basically squarely inline with HTML’s original design.
- Application web is for everything else: mapping, shopping, games, entertainment. All the rich interactive experiences do back to native.
🔗how it will help
This pays down the technical debt we’ve been mired in for over a decade, by splitting apart concerns. This recognizes that the load we’ve placed upon HTML, CSS, and JS has been too great for too long. But rather than force documents to live in native-land (solution #2), we give documents their own environment, perfect for them: Document Web. And all the “web app” stuff we architect a new medium for.
🔗how to get there
I think in this future, too, browsers go away (out of my predictions, that’s 3/4 futures, if you’re counting at home). Something browserlike will replace it, sure, but would be so reduced in purpose I’m not calling it a browser.
Similarly, we have the same stalemate as future #2 where there is no central service to deliver applications other than Apple’s App Store and Google’s Android marketplace. What could that look like? What could an app “standard” resemble? And could it be openly-governed?
🔗we desperately need a new future
Above all else, we really need to change how we build the web not for ourselves, but for those who will come after us. The internet was architected to be a bastion of free speech and radical democracy, but that light has been fading for some time. I believe the central contributor to this is that only privileged, educated, wealthy individuals have been building on the web. And so, historically, the web has looked, sounded, and gatekept by these elite few.
Likely none of these will come to pass; likely each of these has a mountain of hidden complexity that is harder to overcome and contains more problems than our current system. But I’m a big believer in taking a step back, and looking what we have. And I believe that anyone that does this, honestly, can’t be satisfied with the web ecosystem we’ve built for ourselves.
Being dissatisfied with the status quo of how the web is built isn’t just a good idea; it’s necessary. We need it to change. This web development shit is difficult enough for experts with years of experience and education to pull off. Imagine how alienating and frustrating it must be for newcomers! And with all that’s going on in the world, we have never needed the internet to be less white, and less male, than it is now. But sadly, that’s not changing..
Reducing the complexity of the web isn’t just a “nice to have” for our own sakes. It’s the very thing that will save our souls.