Web Architectures today, and Tomorrow

So this is going to be a narrative around the last kind of few decades, and it's just a viewpoint from one UI engineer.

This is a set of opinions from me, not of my employer, and I want to cast us back to 1968, and NATO, they developed a software conference to address what they had called the software crisis at the time, because the increasing complexity of hardware, and we're talking about, vacuum tubes to mainframes, this increasing complexity meant that software projects ended up over budget, over time, inefficient to build, late, difficult to maintain and run.

I'm glad they solved the issue for us, and now we no longer have to worry about this.

But one of the talks was from Doug McIlroy on mass produced software components, and he proposed, much like hardware, that we should be able to produce these reusable parts easier, cheaper.

He, in his thesis, said that he would like to consult a catalogue of offering routines in varying degrees of precision, robustness, time space performance, and generality.

Sure.

But I don't think he was talking about components in the same way that we're talking You and I talk about components today, right?

He was talking more about like composable systems and libraries and for context, Doug McIlroy worked at Bell Labs on the Unix operating system, which embodied a lot of these ideas.

It's do one thing well, was his term.

So why am I talking about a 50 year old conference?

I think the same ideas exist in the industry today, we're still, rebuilding the same components over and over, as has been alluded to, and, McElroy's talk focused around the growing complexity of hardware, I think that's still true today, and I think mobile plays a big part in that.

I think that the transition over the last few decades towards mobile, has been a, huge increase in complexity in hardware and I don't think that a lot of the web platform has really, been able to catch up in the same kind of time frame.

So we're still putting all this energy into building these experiences over and over again and in terms of a decomposable system, the web platform, It struggles with this.

It gives us a bedrock where we can place our libraries on top, but it just doesn't compose well.

And that's because in its inception in 1990, it was just for documents.

It wasn't designed for apps, right?

And so the history goes in the 2000s, there was this kind of resurgence, the W3C was busy, thinking about XML, which is this format invented to do all kinds of different things and XForms and XHTML this kind of stuff, but I think companies like Opera and Apple, Mozilla, even Google, they wanted to focus on, the business value that HTML could give us and evolve that, right?

So we had HTML5, CSS2, Google Chrome, and engines got faster, right?

They started being able to accommodate more and more JavaScript with this benchmark race with SunSpider and Kraken.

So one way we can paint this picture is that, the 1990s was maybe the rise of the document whilst the 2000s was the rise of the application.

And we saw the release of the iPhone, and we saw this new complexity, and this rapid change of, application development.

And then, from there, we had this, resurgence of, JavaScript frameworks and libraries, right?

These, compositional parts, and they filled the gap that was missing in the platform.

And, whilst they each had unique value add in their inception, I think they've veered towards convergence.

And they've converged around a handful of major patterns, and I think a big one is, state management, right?

And so this is this struggle for this decomposable web platform gave rise to these frameworks, but I think that the cost hasn't really been properly realized.

All of the costs of these JavaScript libraries are externalized onto our consumers, onto our customers, right?

And browsers have become this kind of vessel for, a JS virtual machine and little else.

And we're building a web platform on top of the web platform.

The cost of this compute and the network cost, it's not just, data deserts or fringe users who disable JS.

Hopefully I don't need to tell Australia about US East 1 and latency and, the speed of light has physical constraints, right?

Still needs to abide by the law of physics.

I think there's also a misinterpretation about Moore's Law.

We're not getting better phones, we're just getting more of them.

Alex Russell actually, speaks to this in great detail, and I think he spoke about this last year.

But if you have an iPhone in your pocket, you're part of the elite, right?

Your device is probably several orders faster than the average device across the globe.

And those numbers aren't changing, right?

The median phone is flatlining in terms of capability.

IPhones are getting better, but they're the only ones really.

And so if you're thinking about your projects scaling to the next zero, scaling to the next order of magnitude of your customer base, you're going to hit difficulties as you dive into this long tail, right?

The costs that have been hidden from you are going to be more and more evident.

And I think this is going to become a problem, right?

And if this is alien to you, I conjecture that maybe you're not measuring the right things.

But your technical teams might be talking about SSR and like the cost of the server, cost of goods sold on the server.

And this is user experience arbitrage, right?

It's like you are off, shooting all of this, onto devices in your customer's pockets, but, the experience gets worse.

But, this isn't your fault.

Going back to the mapping of the decades, we can talk about the 2010s as the rise of the era of frameworks.

But the results of all of this is that, the web needs to evolve with this, right?

And, that's not for one of trying.

In 2013, I think it was a somewhat epochal moment for the web.

This was perhaps our 1960s software crisis.

Members of the W3C, co signed this document to tighten the feedback loop, between the platform and development, in the industry.

And they tried to get new low level primitives to serve as building blocks, to decompose the web platform into these, constituent parts.

And so while innovation in frameworks continued, I think browsers have been getting more capable.

And you've probably noticed this, right?

We've got, service workers, input APIs like pointer events, new low level APIs like WebUSB.

Browsers have also, historically had these internal observer APIs that are now being exposed.

We've got these new exploratory APIs around, CSS.

I think the list goes on.

One big, one big change here, I think, has been web components.

But I think that the story has fallen short.

Because they solved the view part of the model view paradigm.

But views are nothing without their models.

And so one of the kind of disappointing failures of this era was Object Observe, which was this idea that you could, track an object's mutations over time, and this became, this could become the model part of, the view.

But this was deemed too complex.

It didn't really go anywhere.

And frameworks lived on from this.

And so But, frameworks have since kind of converged around this idea of reactive observables for managing state and so frameworks like Angular or RxJS, MobX, they've all converged around this idea of reactive programming and in 2015, it was proposed to bring this, into the language through JavaScript, and it's been kicked around for a bit since then.

But, I promise you don't have to read the code in this slide if you don't want to, but, the web, community incubator group is now proposing this as a new standard, right?

And this, the point of this is to close this kind of platform gap between, the browsers and the frameworks.

So observables, they in my mind, they sit alongside things like streams and promises.

And they're able to close this architectural gap.

But also, if we do look at the top frameworks by popularity, a lot of them have converged around different reactivity models, like fine grained reactivity.

Svelte has this concept of runes, and a lot of the other frameworks have this concept of signals, Embers calls them computer properties.

This is nothing new, In 2010, Knockout introduced this idea of observables, and now most of the frameworks have converged around this, and so has the platform, right?

So this is new work in development to build out signals as a protocol within the language itself.

And again, closing that gap on all of these frameworks.

And this isn't … frameworks and, standards groups vying against each other.

This is a collaborative effort, and so the signals work is being, developed in combination with the Angular, Ember, Preact, Quick, Solid, Svelte, Vue, all of these teams working together to try and unify this.

I think that observables and signals are both complementary.

And so yeah, I think that they closed this value add around frameworks.

And so Global Client Side State Management, which was the central pitch of these frameworks, in their inception, it can be thought of as a solved problem, at least hopefully one day.

To, paint a vision of the future as well, there's nascent discussions around proposals, around things like DOM parts, right?

And so this syntax might look very familiar to you if you've ever, dealt with the templating language, and we're trying to bring this into the platform, right?

And a lot of these, parts of this story needed to be told through things like signals first, because this is the kind of feed in mechanism, right?

And so I think one day, as again, this is very nascent, maybe a vision of the future, but we could be looking at HTML, as an intrinsic, part of HTML having this kind of templating syntax.

I think some of the puzzle pieces are starting to come together.

Let's dial back to the 2000s though, because I also think we saw the design industry maturing.

So we had design patterns and design systems, I actually work on this design system, and so this was like a realization of, Branding libraries, sorry, branding guidelines that existed time immemorial, UI libraries like YUI and jQUI kind of bridge this gap between what we have now, which is these design systems that kind of introduce branding and interactivity together.

They introduce this new vernacular for applications to speak to their users.

We can't talk design without talking about CSS.

I think CSS, as we have seen, has made huge strides in catching up to the innovation of the decade.

And we look at something like view transitions and it blurs the line between MPA and SPA.

And every passing month, there's new, CSS proposals.

I just wanted to highlight a couple of these.

I think this is awesome.

But we're finally getting mix ins in CSS.

And also if statements.

So CSS is becoming a real language.

But design systems aren't just about styling pages.

They're not just about branding them to a company's color palette.

They are about this language of interactivity.

And something like Google's design system is arguably the most used design system.

I think it coincides with the design language of the Android operating system and it has these new paradigms of interactivity.

And it's not just big companies, throwing their weight around, right?

WebAwesome just raised three quarter of a million US dollars, to build their component system.

And it used to be called Shoelace, it's now called WebAwesome.

There's a clear and evident need for something to evolve in the platform here as well.

And when you look at film, forms built, with a built-in form styling, it's really not hard to see why.

In 2019, Edge switched from Chakra and Edge HTML to using Chromium.

And with that, Greg Whitworth led the form styling effort to address some of the issues with form styling.

The change was that it resolved some key accessibility issues in form styling, but it gave us more tolerable defaults, but we needed bolder action.

And luckily, at the same time, Greg founded the Open UI Group.

And this is an initiative to look at why some of these frustrations exist with forms.

And so we, charted, we surveyed and asked what the most, frustrating elements are and found that design systems are, rebuilding some of these elements over and over again because they lack the kind of interaction, that we were expecting.

And so we've done a load of research as well, charting a lot of this stuff.

And so this is like a mapping, a matrix of all of these components, across all of these design systems in order to try and, answer these questions of, how we can resolve this.

And the result is this kind of journey of breaking down an anatomy of things like the select element to try and create new capabilities so that it's easier to utilize the built in select, but also customize it, and add your own variants, slowly extend what's possible without having to reinvent the wheel.

And so this is, again, a vision of the future where we could say if you wanted to inject different pieces of HTML to replace bits, like the button, if you want to customize the selected option text, we can introduce an element, right?

We can use datalists to drive some of these options, we can put richer data inside of the option tags, so that something like this doesn't require, kilobytes and kilobytes or even half a megabyte of JavaScript just to do, right?

This should be a couple of hundred lines of CSS at worst.

But it's not just about customizing the form controls, as we saw with popovers, this is a result of the fallout of some of this work, right?

We want to enable richer UI experiences, and we want to explain parts of the platform.

And popovers is a result of this, so it's how does a select behave?

It has a popover.

And so we've explored this and managed to, put something into the standard, which is a popover that kind of sits above everything on the page and it solves real problems that designers and design systems teams have, right?

Popovers are immune to positioning and overflow bugs.

They sit on a top layer.

There's no more z index.

Z index can stay in CSS2 where it belongs.

If you've ever used something like React Portals, you can just stop, right?

This solves the React Portals problem.

This isn't contrived code, this works today, as we saw, but also it's being used today.

And so this is a little website that I work on, the tooltip here is a popover, as is the menu, right?

And this has solved, literally thousands of lines of code can be removed now, by utilizing these features.

It's literally turning thousands of lines of code redundant.

And so this has led us to, interesting new directions about, exploring declarative button behaviors.

We're calling this invokers, so that we can issue commands, this is the kind of bread and butter stuff that UIs are used to doing, but we have to bring in so much scaffolding to get there, but we want to try and dismantle that, right?

We want to try and close that gap.

And while we're looking at the low level pieces, we're also thinking about the high level.

And some of you may have read this article by Brad Frost on the global design system.

I think it captures some of this need to provide bigger building blocks and have a more cohesive whole for HTML.

OpenUI is committed to exploring this further.

We want to, provide these tighter integration loops.

Much like the Extensible Web Manifesto, we want to, have these tighter integration loops to feed back into browsers.

And OpenUI is an open community, right?

Please come and join us.

So, let's try and send it home.

So we've got state management, closing this gap, between observables, with observables and signals, the value add of these frameworks is gonna be less and less, we've got like real templating, a real, chance of doing real templating, we've got a built in view with custom elements, CSS is now as expressive as SASS and these other, CSS frameworks that we're using.

We're working on more extensible form controls, we've added these new layering of, UIs.

And we're adding, these built in button behaviors, with invokers.

Alex Russell has this like seminal article, called The Market for Lemons, and he says that the 2010s was a lost decade, for the web.

I think he gets a lot right in this article, but I disagree with the premise.

I'm, more optimistic about where we, have been and where we are now.

And so I look at what's been done.

I see a bit of a renaissance in the web platform, right?

I see this value gap closing, and I see that, I think we're going to see a decline in the, moat that are being put around frameworks.

So as we close the decade, I think that we're going to see a bit of a realignment.

Towards, web platform technologies, and into the 2030s, I think we're going to see a renaissance of the web platform.

At least I hope.

Who knows?

So what are the next steps?

I think you can set your teams up for success, measure the cost of the platforms that you have, try and find the hidden externalities, try and find the cost of goods sold, the scalability challenges that you have.

Have a continuous conversation with your teams.

Help your team scale to the next zero, and that might take a different shape than what they're used to today, right?

I think we have, readily available pieces of this technology, where you can poise yourself for the next decade of tech.

Things like popovers, view transitions, they enable new ways of, building your applications without relying so heavily on these frameworks.

Signals and observables can be polyfilled today, but I think there's more important steps, right?

You can use your voices to lobby for changes like this.

I think it's worth advocating for this change.

If you're on IC or TPM, join us on Open UI, because we're really interested in closing this feedback loop.

We want to hear from industry partners.

Let's continue having this conversation, right?

I think we need to find a way where we're going to take the web, but it's our platform.

We're all stakeholders, we can get a lot more from it if we try.

That's all I have.

Thanks very much for your time.