In Conversation: Hui Jing Chen and Keith Cirkle with John Allsopp

Introduction and the Challenge of Framework Dependence
John Allsopp initiates the discussion by posing the challenge of reducing dependence on high-level frameworks while acknowledging their past significance. He questions the path towards leveraging the web platform more directly and invites Hui Jing Chen and Keith Cirkle to share their perspectives.
Costs of Frameworks and the Path to Migration
Keith Cirkle highlights the hidden costs of frameworks and advocates for open discussions about their long-term viability. He suggests a gradual migration towards leveraging the web platform's capabilities, emphasizing the interoperability of web technologies.
Collaboration and the Human Problem
Hui Jing Chen emphasizes the importance of collaboration between spec developers, browser vendors, community groups, and framework owners. She frames the challenge as a human problem of inertia and sunk cost fallacy, suggesting that aligning frameworks with native web features is a key strategy.
Web Components as a Bridge
John Allsopp introduces web components as a potential bridge between frameworks and the web platform, prompting Keith Cirkle to elaborate on their role. Keith explains how web components can lower framework costs and seamlessly integrate with existing systems, citing GitHub's use of web components within a React-based architecture.
Q&A: The Web Platform's Evolution and Challenges
The discussion opens to audience questions, with Jared raising concerns about the web platform's slow evolution and the risk of delivering large features too late. Keith and John respond by discussing the deliberate pace of web development, the difficulty of removing features, and the Extensible Web Manifesto.
The Web's Unique Architecture and Longevity
Hui Jing and John discuss the web's unique architecture, its longevity, and the deliberate nature of its evolution. They acknowledge past mistakes and emphasize the ongoing nature of web development, highlighting the importance of continuous evaluation and improvement.
Accessibility Considerations in New Features
An audience member raises the issue of accessibility traps in new CSS features. Hui Jing acknowledges the challenge and explains the ongoing efforts to integrate accessibility considerations early in the specification process. Keith highlights the work on interoperable accessibility test suites.
Encouraging Developer Participation in Web Standards
The panelists encourage developers to participate in web standards development, emphasizing the accessibility of pathways and the benefits of involvement for both individual teams and the broader web community.
The Web as a Universal Operating System and its Gaps
Andrew asks about the web platform's potential as a universal operating system and its current limitations. Hui Jing and Keith discuss hardware access as a major gap, highlighting the web's security-first approach and the challenges of securely exposing hardware APIs.
WebAssembly's Role and the Future of JavaScript
John Allsopp brings up WebAssembly and its potential impact. Keith downplays the performance benefits of WebAssembly for DOM manipulation, advocating for less JavaScript and more platform use. He sees JavaScript as valuable for exploration and innovation, while HTML and CSS offer more declarative and concise encoding.
Speculation on the Web's Future and the Role of LLMs
The panelists discuss the limitations of the web compared to native applications and speculate on potential future breakthroughs. John introduces the topic of large language models (LLMs) and their integration with the web through technologies like WebGPU and Web Neural Networks.
Conclusion and Thanks
John Allsopp concludes the session by thanking Keith and Hui Jing, summarizing the key topics discussed, and highlighting the speculative nature of some of the emerging web technologies.
I guess the challenge is how do we get from where we are, where we're heavily invested in these kind of relatively high level abstractions, which I think, how would we feel about the abstractions?
I think there is a real, like they solved a real problem at a real time.
I think that needs to be identified and acknowledged.
But we've invested so much training, so much capacity, so much tooling in these particular solutions, whichever one they happen to be.
How do we get from there to less dependence on these frameworks?
What is that path?
What does it look like?
And I ask that because I guess we were a room full of people who think about the technical direction of their organizations.
They think about, what they're doing now and what they might be doing in a year or three or five.
So what is that?
What does it look like?
So again, I think it's worth exploring the costs of the frameworks that we have, right?
There are a lot of hidden externalities with these, so we need to have adult conversations about that.
We need to think about if they continue to serve us over the next decade, because genuinely I think there's real costs to these that aren't being explored.
But yeah, I think it's going to look like a bit of a long migration, right?
I don't think anyone wants to rewrite their entire application.
I think it would be a bad idea to do that.
But we can leverage more of the platform, we can explore, a lot of these new technologies are solving not just the core problem, but they're solving a whole set of ancillary problems, right?
And so there's still value there to be had in that migration, but you can do it far more piecemeal.
And, the, that's the wonderful thing about the web platform is that, the interrupt story is there, you can still leverage all of these bits as much or as little as you want.
So I, I think that's maybe the next five or ten years will be a slow, walk away from some of these frameworks.
I feel like what Keith has described and what I've mentioned in the interop stuff is the fact that people are now working together.
You have the spec people, browser people, then there are community groups, and even the framework owners themselves.
I think that is pretty much key if we do want to move people closer to the web platform, is to show the average developer that it's not a, it's not a conflict, right?
It's that your framework can play well with native features as well.
I think that's probably the most reasonable path forward, because what you've described is not a technology problem, it's not a, it's a human problem.
It's a human problem that we are creatures of inertia.
There's also the sunk cost fallacy, I spent a good five years of my youth on it, I am not rewriting it.
It's fine, you don't have to rewrite it.
So rather than targeting the individual developers themselves, I think going a little high level, hitting it right at the framework source, you love, this framework, this framework, is now working with the platform, I think that's a very good way to facilitate this move toward the web platform, if you ask me.
So the one thing that we didn't necessarily talk a lot about, but Keith's gonna talk a lot about tomorrow, are web components.
So how, is, to me that feels like a really important part of this story, because they do play nicely, particularly with the most recent React that we're seeing, they do play nicely with these frameworks, and do they give us a kind of, a kind of bridge, a yeah, absolutely.
And how do you see that playing out?
And what might, if I'm a technology leader, thinking about architecture, how should I be thinking about web components and how they are part of the story of frameworks and our current work practices?
Yeah, so they, interop, really nicely with all of the available frameworks.
They can lower a lot of the cost of the frameworks, right?
They kind of chip away at the problem.
And so you can integrate them, again, as much like the rest of the web platform, you can integrate it as much or as little as you want, and so like at GitHub, we, have a React based system, but a lot of the underlying components are just web components under the hood, so for our application engineering teams, they can still use, React as they would, but actually underneath, without them needing to know, that the, power behind it is driven by web components.
Yeah.
You heard it here first.
Have we got any questions for the floor?
I think that there's going to be amazing brainstrust here.
So if you have some questions and thoughts about these issues and the technology in the platform, Zach's got the mic.
Who have we got?
Oh, Jared up the back.
He's the man who knows a thing or two about the web platform.
Oh, hang on.
We'll jump.
Hang on.
Who are we going with first?
Yeah, all right, we'll go over to Jared, but use the mic this time, Jared, and then we'll jump to you.
Web platform has grown massively along the way, but I think, seeing what I'm seeing here, the changes, that these changes are now much more, prescriptive of technology and, signals, for example, right?
Yeah.
The speed at which W3C moves and Chromium, and to get a feature from spec to implementation is, years.
But it's, the, life cycle of some of these technologies can be weeks inside the web community.
What happens?
Do you think that the web platform growing in this way is going to be as the features get bigger and bigger, they're no longer just CSS3 specs, it's an entire way to do a X, that you run the risk of delivering too, big a feature too late, and the web has moved on, and that's useless, and now, but now the web platform is carrying huge amounts of weight for these features?
Yeah, I think that is why the web moves so slowly, because we want to get it right.
And you saw, the object observe, was an attempt at state management, but it didn't fit, with the ecosystem at the time, and without vendor buy in, these things can wither on the vine, and so it's I feel like the web platform is a bit like legal legislation, right?
It encodes like a system that is already in place and there's a large enough latency that they can look a little disjointed, but it's usually because, there's a lot of, there's a huge body of work before that piece of legislation comes in that describes the problem, or many, the many attempts that, were tried, can fall in and out, right?
Yeah, and yeah.
To, take a example, NodeJS modules, right?
It took so long to deliver the modules that people had moved away from the way of doing modules when it was delivered, so there was a lot of community backlash about modules, and people still think today that it delivered a worse technical solution, but now we're stuck with it.
Do you think that the web platform is going to suffer the same thing when you're delivering these large scale features now?
An observable platform is a big thing with a lot of technical requirements.
You need, a thread pool.
You need all of these sorts of things underneath in the browser engine.
And then if we put all that complexity into the browser engine and you deliver observables and the community walks away from it because they find a better solution, what then?
I don't think that observables need a thread pool, but that's maybe neither here nor there.
The web is, I get your point, yeah, I think the web is, like it's very difficult to remove things from the web, but it's not impossible.
And so if people genuinely aren't using the thing, or if it is too complex for browsers to maintain, they can always pull it out.
And it depends on the particular flavor, but I think about AppManifest, right?
It caused some fairly severe issues, and service workers better explained those ideas, and and because it only affected performance, it was quite easy to pull AppManifest out.
But I think that, yeah, for these features that are harder to remove, there's a lot more rigor that goes into, defining them.
And that's why something like observables has been nearly a decade in the making.
Modules, I think, is its own political thing, right?
Yeah, we got to talk about the history of ES5 and yeah, Alright, now we'll keep this one for a whiskey later and we'll move on.
Yeah, Very interesting conversation, but we're going to move on.
So over here, Oh, okay.
Apparently bring the whiskey . Alright.
But I guess it speaks to, like you mentioned, the web, manifest, what was it?
The web application app manifest?
Yeah.
What was it called?
App Manifest, I think.
I know about that one, which was a douche bag, which just finally got pulled out of Chrome, I think, right?
Yeah, no, the Web App Manifesto.
2013 What?
Oh, the Extensible Web Manifesto.
Extensible Web Manifesto.
I think that was a really strong attempt to address that.
I think.
The web is this unique …, it is an operating system, it is a document, it's doing a thing that no technology has ever really done before.
And it has a longevity to it, which is both incredibly powerful, but as Jared's alluded to, a real kind of millstone.
Maybe we should marvel, we shouldn't so much criticise how badly it's done, but really marvel that it works at all.
Yeah, if you think back to 20, sorry, 1990, right?
So Web, the web, the first web browsers, like no operating system that exists now, Unix kind of, existed.
Like it, it has outlasted everything and we've had these multiple iterations on app platforms and it's extraordinary that it works at all.
And I guess it, will it collapse under its own weight at some point?
I don't know.
It's, I'm hoping not, but.
I think you make a very salient point, is that if we really take a step back and think about it, the way the web was architected is very unique, right?
What other platform allows you to access… if you have Microsoft Word, 97.
It's not going to be able to work.
It's versions are themed.
You can't even open the documents for like, those.
I couldn't think for the life of myself, another piece of software that operated the way the web decided that this is how we're going to do things.
And I, like I said, there's nothing that is absolutely perfect with no flaws and there's nothing that's absolutely bad either.
So the web.
Has these capabilities, and therefore, everything's very deliberate.
For example, there are CSS features that have been requested from 20 years ago, and then they've, we've only seen them now.
Of course, they're like technical limitations in terms of from browser engineering perspective, it took this many years to get to this point.
A lot of the requests were ahead of its time, but the long and short of it is that every decision that goes, and it's not there haven't been mistakes, right?
Like there, there is on the JavaScript side, on the CSS side, like the orange, CSS orange, you, this is just an Easter egg.
You go figure out why orange was a mistake.
And, I think what you raised, what John raised is absolutely valid.
And I, I don't think that there's like a clear, this is the solution to this thing.
I think it's more of something that we have to do it, see, evaluate, do, see, evaluate.
Because sometimes I think as humans, what we end up being is we end up being lazy because I spent so much effort, so I built this thing and I'm going to leave it.
It's The work is never done, right?
You can't say, I went to the gym today and I did a lot of things and then I'm done.
I don't have to go to the gym for the rest of no, that's not how it works.
Sorry to disappoint everybody.
Life is disappointing.
Kevin.
Diana, when do we run?
Oh, I've got a few.
So we'll get Kevin, then Andrew.
I think this is mostly a question for Huijing.
In the past few years, I've, there have been a few new CSS features that have landed that seem to have broad support, but there's like an accessibility trap.
There's like an unsolved accessibility problem.
And as a leader of front end engineers, I have, in a few cases, had to go, yes, that's in all our browsers, but still don't use it.
Because it makes accessibility worse.
Definitely.
How is this, I, know there's fresh proposals about, around things like reading order and how we're going to solve for that.
But I'm interested more in the meta question of how do you see accessibility being grappled with in the conception of new features for the web platform?
Is that changing?
That's a very good point.
And, I think one of the things that I did mention is the fact that the specification people and the browser people are really pushing to be open in everything they do.
Because it used to be an ivory tower, right?
They were on GitHub, I think, I want to say from 2010, maybe 2012.
So there's this period of time where, spec authors would just talk amongst themselves.
The best part is they didn't even write web code, they wrote C, engineer code.
So there was this big gap.
And fast forward to today, that, that's the exact issue that they're trying to address.
So folks like yourselves, accessibility experts, raising these, early on in the process, or make, explaining, this is the use case, the feature that you pushed out, it's either it's a bug, or it's the spec is wrong, etc.
It won't fix things overnight, but yes, just to answer to your point, yes, I think this is a move in the right direction.
I think the other thing is to, how do we get more developers to feel like they can participate in the process?
Because it always seems like, I said, standards, just, you imagine, these people in hooded cloaks in the basements during cold ones, no, they're very normal, and it's more of, some, it could even be, like, a new developer who's, who happens to just realize that this is a thing.
What I realized when I talked to people who are developers is they doubt themselves first rather than doubt is the browser.
And I do wonder, it's I think the bigger issue is how do we make involvement in the specs and, to a certain extent like browsers, you don't have to write browser code, but like just raising a bug.
So you're part of the QA team, which is all of us, is how to, how do we just make this a very common thing to do?
So I think, I could add to that because, one of the big efforts, around like interop has been this, interoperable set of test suites, the web platform test suite, and, it's just HTML and JavaScript, right?
Anyone can write these tests, they can contribute to this, GitHub repository.
All of the browsers run it as part of their CI.
Historically, up until now, a lot of, the ways that the browsers, implement accessibility hasn't been properly tested within these test suites.
So a lot of browsers internally will have, test suites that just, spit out a tree, an accessibility tree based on the HTML, but they're all internal, there's no interop, right?
And so if you're seeing, cross browser of bugs with accessibility, this is likely the, cause of this, or the kind of second order effect of that, but the work is being done here, and so we're, like, I'm actively involved in trying to test more of the accessibility of browsers, but it's a big amount of effort, but hopefully, watch this space, and I think a lot of, hopefully a lot of cross browser bugs will start to be resolved once that effort ramps up.
But it is an area of active investment.
No, and it occurred to me that this is a group of code leaders, and therefore you can nudge your team toward participating more in the I was going to make that point, right?
Like Apple doesn't say, Hey, come test our stuff.
It's Here you are, here are the APIs, take them and leave it.
And by the way, these are ours, right?
So there is this opportunity to be heavily involved.
Absolutely.
And we've all, we all know that pathway through, from people really just using the web through to being instrumental in development of features.
And even think like the incubator groups, the W3C, which brought us things like, image tags and so on.
There is an opportunity to be heavily involved, right?
Which benefits your own team, your own organization, and the web more broadly.
So that's something I definitely would encourage people to look into.
Those pathways really are there.
There's no quicker way to level up someone to becoming a domain expert than just like throwing them at these problems and being like, go fix accessibility in our application.
Just [inaudible] inside Google and such things either burnt out because It was, hard work, or they got affected by the layoff, so there's there is, there's now there's now, unfortunately a bit of a glut of that tech people working on, who used to work on the accessibility features inside Chrome, the engineering teams unfortunately did get impacted.
So if you want to get involved, now's a, fantastic time because you'd be able to make massive impact on a very important part of the web.
And these groups are unbelievably small, right?
The ARIA working group is a rotating cast of maybe less than 20 people, and they're solving, they're trying to solve at least accessibility for the entirety of the web, I think there's this kind of narrative that there's like this, trio of trillion dollar companies that control the web, but that's not their only product offering, right?
They're not just three companies that ship three web browsers, they're three companies that do a huge amount of stuff, and yes, they have like hundreds of thousands of employees, but the browser parts of those, … minute fraction, like a lot of them have teams of less than, I don't know what the Safari team looks like now, but as pre COVID 2020, as far as I knew, there were like three of them.
I'm like, are you sure?
Okay.
Yeah.
They've hired a bunch.
They have hired a bunch.
Since then, right?
In the scheme of things.
For such a, 20 billion dollar kind of revenue unit, they're a pretty small team.
Revenue per headcount at Safari has got to be the highest of any product in the history of the world.
That sounds about right.
I would think.
Andrew, did you have a thought?
I did.
So I'm just curious to get some perspective on what do you think of the browser and the web platform as the kind of universal operating system?
And what do you think would be the gaps that exists to, to leading into that idea, essentially.
We're not thinking very hard, just the, the gap, the moment you said gap, like hardware access, like the first thing that popped in my mind.
So you're thinking about like Web, Web Bluetooth, those sorts of APIs?
Yeah.
The, big problem is, navigating those APIs in a secure way.
And, traditionally operating systems, Sandbox.
Some insider information I don't have, but, operating systems have been historically horribly insecure, and, only recently have we been, like, operating systems have had more, sandboxing APIs and, certificates and all that kind of stuff.
But, the web has started from a security perspective, and so a lot of these APIs are being added with that view in mind, right?
If you look at the permission models on, Android and iOS, they've been retroactively added, but, you still can't get to a contact list from a web app, and that's, there's good reasons for that.
So the one thing I would throw in there, I was going to bring up before, but I think is very pertinent to that, is WebAssembly and that sort of technology, and how do you see that as fitting in to this story I think WebAssembly is great for offloading some of the cost of JavaScript, but you're still going to have the binding layer between the DOM, and the cost of that isn't, JavaScript, the expense is putting that stuff over the wire, and that doesn't change when you have Wasm versus JavaScript versus anything else, right?
You still have to, somehow serialize a bunch of information, send that to the C++ of the browser, and then the browser can figure it all out.
I think that while Wasm is, or WebAssembly is a really cool idea for, like generic computation on the web.
I don't think it's going to magically solve, some of the problems that we have with JavaScript.
I think the answer is less JavaScript and more platform use.
And I think, JavaScript is a very good, exploratory framework for, allowing you to in, innovate on ideas, but hopefully what should happen is things like CSS and HTML are like the declarative way that we can encode a lot of these ideas, into, like a much kind of, more condensed format, right?
And your, JavaScript is like line by line logic, whereas like HTML, like we see with Popover, can do a bunch of stuff that, because a lot of that same logic, almost literally the same logic, is just hidden behind the browser's hundreds of megabytes of C, or C++.
Yeah, I don't, at least as of now, 2024, I'm not really sure that the, we're at a point where performance on a local, device with a lot of direct access to a lot of API, so to speak, can overtake whatever we can provide on the web yet.
Like I feel like this needs to be a lot more smart people thinking about the possibility because latency, you can't run away from latency at the end of the day.
So unless I don't know, quantum computing, so like instantaneous.
And in my mind, we need a breakthrough to another level before, I know this sounds very sci fi or whatever, but I feel like right now, in this realm of how, where we are operating, probably not yet.
We need something like, to, get us there, not sure.
I'm just being speculative, guys.
No, you're good, I like that.
Before we wrap, is there any more questions, or anything else you'd like, burning issues, you really need salt?
Oh, okay, we've got the source, all right.
Share, share with me.
I'll show you later.
It's not that interesting.
It's a blog post written back in like 2002 and all they did was took a percentage and then multiplied it by a spec.
Oh, they mathed it, oh, disappointing.
So there's no actual truth or source to the data.
There you go.
All right, we haven't solved the problem.
So I'll wrap up with a bit more sci fi then.
We got a little, so obviously right now, particularly we saw with Apple recently and all the big tech platforms talking about, inference, on the platforms, large language models or reasonably large language models on device, the web has a story with things like WebGPU and, what's not coming out, Web Neural Networks, so to what extent do you think that Is going to be important?
Is something people should be thinking about?
Or is it a bit of a sideshow right now?
What do you, what's your feeling about these sort of technologies in the web?
I do not have a good answer for that, I'm afraid.
Yeah, it's not really my area of expertise, but I guess as a purely end user perspective, right?
Like all these LLM things.
It might not answer the question.
But I feel like things, that they're still, they haven't escaped the hype cycle yet, so it's very hard to discern, they, is it really going to change things, or is it just going to be another tool in the toolbox, because when you look at ChatGPT for example I actually see a number of pluses, in that if you don't know what you're doing, you're gonna end up being a victim of hallucination, and maybe, it's like, it filters out.
Whether you know what you're doing or not.
The other thing I thought was a positive is it forces developers, which again, generalization, notoriously poor at expressing themselves clearly.
It forces you to be better at communicating if you want a good answer.
I don't, at the end of the day, it's a tool, right?
A knife can be used to slice a watermelon or slop someone's head off.
The problem's not the knife, it's the idiot wielding the knife, right?
Did not answer your question, did I?
No, but that's all right.
This is definitely one for whiskey later or, whatever drink of people's choice, alcoholic or otherwise.
Now I just thought I would bring up a few of those technologies as well.
Because we focused a lot, on the developing the front end, the interactive, the design engineering, however we want to describe it.
I think that it's also interesting to know there are a number of these kind of much more speculative and deeper technologies that are emerging on the platform, and I think they're worth people knowing about.
We, we covered them a bit at a couple of our recent conferences, and in fact, we hopefully will be doing a bit more of that as well.
But I thought I would bring those up, particularly given how au courant, the kind of large language models are.
But the web isn't being entirely left out of that.
Yeah.
But, now we've reached the, literally there is a giant thing outside my window in the hotel I'm staying and it's, I don't know what it stands for, it just says GPT.
And it isn't to do with chat GPT or openAI, but anyway, we can't escape it.
And now we've reached, finally, we spent all day not talking about it.
Large language models, and we've arrived there, so it's probably time to finish.
So with that, I would really like to thank both Keith and Huijin for this session right now.