What would <html app> do? 🤔
The Web can continue to evolve by taking the long term view and chipping away with adding necessary functionality, and eliding some of the mistakes (albeit hard).
However, I have been pondering if we should be exploring some bigger bets:
- First, looking at certain verticals (content, commerce, apps) and prioritizing web platform features and tooling to make them successful holistically
- Second, breaking out of the “browser” and be progressive all the way to the native platforms by adding escape hatches
Now, let’s take another look at building the UI for apps on the Web in a very webby way, embracing what’s good about HTML, CSS, and JavaScript, but really re-thinking it for apps.
Don’t let evolution get in the way
Evolution is resilient and special. Pair it with immense time frames, and life will find a way, even as many experiments will be left on the way side. One of the strengths of the Web is how it evolves as a platform, but it can be a double edge sword.
We can’t expect to constantly evolve while keeping the entire history front and center. We have fragments in our DNA that go back to the birth of life, but much of it is very much hidden and ignored.
We can embrace evolution that allows us not to keep the baggage around. If you look at a hello world web app, that supports a decent set of browsers, you will find yourself setting up resets of sorts, meta tags, and a series of cruft. This cruft creates cognitive overhead for developers.
In hindsight, we will always make mistakes in the platform and come up with solutions. One simple example that we all know, is that of box-sizing.
I don’t want the default content-box model, and instead agree with Paul from 2012, and many since, who recommend we go all in and flip the default to: box-sizing: border-box;
In 2021, the vast majority of your users will be coming at you via an evergreen modern browser. This is huge, and allows us the ability to flip to a modern-first approach of development that doesn’t tax all of our users for the lowest common denominator. Finally, we can speed up evolution!
While it’s phenomenal that old content sitting on the Web can still be browsed (but of course, this isn’t always true, plenty of old content breaks), it also means that browsers are constrained. They can’t just flip the defaults because *new* content is being developed using new ways, thus we are a lil stuck.
How could browsers do the best job they can at rendering all content, including great content written many moons ago, whilst allowing for new content?
Multiple Rendering Paths
Remember quirksmode? I still see developers accidentally finding themselves confused, because they have put their document into quirks vs. standard mode.
We also have AMP, which forces a constrained mode, optimized for documents keyed off of:
<html ⚡ lang="en">
So, what if we took a leaf out of these books, and had something like:
<html app lang="en">
This could give us a way to tell the browser that we want a new world, one optimized for apps rather than documents. A way to trigger a reset. This would give us a chance to re-think building web apps that still uses HTML, CSS, and JavaScript and feels very webby, but in a sane way for the app use case that is quite different to content.
What could we see?
App-oriented Layout
I love our Grid and Flexbox world, but we could also look into constrained layout modes, working closely with tooling vendors as the Android team did when they shipped their most recent layout systems.
App-oriented Components
Take another look through the HTML spec and the various elements you have built in. I bet you will find some elements that you have never used, such as <aside>. There are a ton of document focused elements, which is great!
But we stopped. While it’s great to abstract and create our own components, either through Web Components themselves, or via framework abstractions that spew out div soup, why haven’t we undergrounded the great learnings from the ecosystem? My kingdom for tabbed UI, and the good ole UITableView! Fortunately, I am seeing more exploration and appetite for this!
App-oriented Data Flow
When you are building rich web apps, and you try to really build your app offline-first, with optimistic UI, you run into a lot of issues around data and syncing.
We just saw James Long dig into the mess that is IndexedDB and the lack of a portable WebSQL/SQLite. What can we do to really enable experiences that can rely on data?
Are we forcing it? What about WebAssembly?
But wait a minute, are we barking up the wrong tree here? Maybe the solution is to keep HTML, the DOM, and friends for the content Web? Or maybe content++… allowing for interactivity but not as far as full on apps!
With WebAssembly, we could keep URLs, but have them toss back apps that are WebGL renderers! We could just use Flutter for Web as an example. This would allow many runtimes to evolve on top, and bobs your uncle.
While this may make sense for some use cases, and I love that Flutter developers have a path to Web, I don’t think that we should cede all apps to this model, as it naturally ends up with blobs at the end of URLs, and we lose a lot of what is great about the HTML/CSS/JS web.
I know that it is quite niche, but I love how Chrome Extensions can compose and hack the Web. This is a super power akin to an after market for car parts. Someone can create functionality that helps you with another services, and I would like more of that, not less. The Web is fantastic at streaming UI, and we can do more to make this all work well with apps, versus the years of fighting against it and downloading the world before rendering anything.
Thus, I find myself dreaming of layers, or adding the primitives that allow for evolution, but also having another go at baking app UI right into the web as a first class citizen, instead of it being a render target with so many foot guns and uncanny valleys. I dream of a studio of tools, aligned with the platform, to make this possible working hand in hand.
And then I wake up to see debates around a simple alert(), and how hard it is to make changes, and I once again ponder escape hatches that allow us to make bold changes.
It’s complex and hard to make some moves, as when you have a platform you need to make sure that both:
- developers have a happy path, know when they are doing something sub-optimal and how to fix it, and make that happy path the one that doesn’t lead you there
- and, we minimize the attack surface to make it as hard as possible for bad actors to do harmful things to users and businesses.
And there’s often the rub, as the same capabilities and loopholes can be used for both.
Apps were born on a document platform, and we are still lacking a holistic web-first app platform that could unlock experiences that have great attributes from the web, but are also more fun and productive for developers to build.
What is in your app mode?
