| 00:50 | <sideshowbarker> | bkardell: yeah, every web app still has a URL, and the thing at the end of the URL is straight to WASM That is, the thing at the end of the URL is a single binary, a single executable, completely just object code — a single And so then for that app, all that the browser does is just to load that single binary into memory and execute it — execute it in the existing WebAssembly execution environment that all browsers already have. And that’s all in contrast to what browsers need to do now with the current HTML/DOM+JS+CSS stack, which is: browsers must load three different things into memory: they must a DOM tree/object, a JavaScript global object, and CSS cascade/Stylesheet object — and then also keep those three in sync through all the DOM mutations and everything |
| 00:52 | <sideshowbarker> | With this WABI alternative, there’s no DOM at all, there’s no JavaScript global at all, there’s CSS Stylesheet at all |
| 00:53 | <sideshowbarker> | Instead, browsers load only the binary object code for the app, and just execute that |
| 00:55 | <sideshowbarker> | And the WABI binary is the equivalent of statically linked object code — that is, it has all of its dependencies already compiled in, and doesn’t need to link into anything else nor load anything else |
| 00:56 | <sideshowbarker> | So a WABI binary can contain its own layout engine, and its own complete runtime |
| 01:00 | <sideshowbarker> | As far as that goes, one analogy is how server-side Java apps can be built today — which is that you use jlink to compile a single binary that embeds a JVM runtime and all the Java libraries that the app depends on (and so, users don’t need to have a Java runtime installed on their systems to run that app, because the app itself contains the runtime) |
| 01:04 | <sideshowbarker> | But that analogy is not at all exact, because in that case the binary is an architecture-specific binary that can only run on a single platform — that is, a Windows binary, or a Linux binary, or a macOS binary. But a WABI binary is not architecture-specific but instead is a portable binary in every way that WASM binaries already are |
| 01:08 | <sideshowbarker> | I think the loading code that’s currently required in browsers for HTML/DOM loading and JS loading and CSS loading may be the single most complex part of browser implementations, and may be one of the most fragile parts — in the sense that it’s prone to regressions and to new bugs getting introduced that are hard to troubleshoot |
| 01:11 | <sideshowbarker> | And at least I can say from experience as a patch contributor to Chrome, that loading code is just incredibly complicated and intimidating to try to work on. Chrome has an entire team that’s devoted to just that loading code. |
| 01:14 | <sideshowbarker> | And for web apps (as opposed to documents), all that loading code arguably should be unnecessary anyway — it’s just a side effect of having needed to bolt an application-execution environment on top of a model that’s not fundamentally designed for running apps but instead is just designed for laying out documents |
| 01:19 | <sideshowbarker> | So there is huge value alone in just being able to cut out the need for all that loading code, and all its complexity, and (over the long run) all its ongoing maintenance cost in implementations. (Though, because this is the web, implementations would also forever need to still retain all that code — to run all the content that exists on the web now — but over the long run, developers building web apps would mostly move to targeting WABI instead, and most web apps would be running in the WABI execution environment instead.) |
| 09:55 | <Andreu Botella> | annevk: About URLSearchParams has() and delete(), do you think use counters would be helpful to see if they're called with extra arguments? |
| 12:54 | <jub0bs> | Posting here for more visibility: https://github.com/whatwg/fetch/issues/1601 |
| 14:14 | <Domenic> | So there is huge value alone in just being able to cut out the need for all that loading code, and all its complexity, and (over the long run) all its ongoing maintenance cost in implementations. (Though, because this is the web, implementations would also forever need to still retain all that code — to run all the content that exists on the web now — but over the long run, developers building web apps would mostly move to targeting WABI instead, and most web apps would be running in the WABI execution environment instead.) |
| 14:15 | <Domenic> | (Try using a Flutter Web app and you'll see what I mean!) |
| 14:18 | <Domenic> | Has anyone seen https://github.com/ada-url/ada? |
| 14:21 | <sideshowbarker> | Domenic: I think mobile is the place where the current HTML/DOM+JS+CSS stack is not working well — as far as providing good user experiences for end users on mobile |
| 14:23 | <sideshowbarker> | I think it’s clear that we began to lose a huge segment of developer share around 2009 when the iPhone really took off and Android did too, and we were busy enough anyway, in the following years, with just trying to evolve the core web runtime in the necessary ways, with the features that were needed for good app experiences on the web to viable at all even on desktop |
| 14:24 | <sideshowbarker> | …and we have not won those developers back |
| 14:24 | <Domenic> | I think that problem is two-pronged. One, "document-like" web sites/apps are bad on mobile because of cookie banners/ads/etc. "App-like" mobile web apps are few and relatively hard to build well, but it also seems clear if the developer puts in enough effort they can get good results: see e.g. Twitter or Uber. For the rest, are developers not putting in enough effort, or is it too hard to put in enough effort because the web's UI framework is bad comparatively? I could see it being the latter. I doubt having everyone download a UI framework per web app, created by indie teams, would be a good solution though. |
| 14:25 | <sideshowbarker> | yes, the web's UI framework is bad comparatively |
| 14:25 | <Domenic> | Reasons developers might not put in the effort are mostly around: capabilities gap; lack of app store access. There's some really interesting UX research by Chrome folks about this |
| 14:25 | <Domenic> | E.g. teams which tried to build web apps but found when surveying users that the users found the web app less trustworthy than a native app---the web is where all the viruses come from, etc. |
| 14:26 | <Domenic> | (Or just, the competitors were on the app store, so users assumed something must be wrong with the web app if it couldn't make it through the app store process.) |
| 14:26 | <sideshowbarker> | I think the core reason currently starts from the reality that users currently choose mobile apps because the user experience of those apps is relatively much better than they get from web apps |
| 14:27 | <sideshowbarker> | and developers choose to write native mobile apps because those mobile apps provide a better user experience for users, and are relatively dead simple to create using available SDKs and tooling |
| 14:28 | <sideshowbarker> | developers do not need to be stellar developers in order to create mobile apps that end users will actually use |
| 14:28 | <Domenic> | It's not clear there's any one core reason, such that if you fixed it we'd change things. I suspect it's a bunch of self-reinforcing reasons, which have trapped us in an inadequate equilibrium. E.g. if you could snap your fingers and fix the web's UI framework, the app store stickiness and capabilities gap remain. If you could fix the capabilities gap, the other two issues remain. And even if you could magically fix them all, the historical inertia remains. It's not great. |
| 14:28 | <sideshowbarker> | they can instead just develop mobile apps only, with much less trouble and pain |
| 14:29 | <sideshowbarker> | …and they forgo creating web apps because, in practice currently, their users prefer native mobile apps anyway |
| 14:31 | <sideshowbarker> | And I think the reason that SDK and authoring-tool vendors don’t consistently provide mechanisms for generating output for the web runtime with a great user experience is: in practice it’s still so incredibly hard and costly to implement and maintain the code needed to generate HTML/DOM+JS+CSS output that provides a great user experience on mobile |
| 14:31 | <Domenic> | It's a potential hypothesis that it's easier for a company to create two good native mobile apps than one good mobile web app. I'd give it somewhere around 50% odds. I don't think WABI is really related to that hypothesis; building a good web UI framework to make app development easier isn't something that framework developers have been unable to do because the browser doesn't have a native MIME type handler for application/wasm. |
| 14:32 | <sideshowbarker> | yes, I think the “potential hypothesis that it's easier for a company to create two good native mobile apps than one good mobile web app” has proven to be true thus far |
| 14:33 | <bkardell> | I think the core reason currently starts from the reality that users currently choose mobile apps because the user experience of those apps is relatively much better than they get from web apps |
| 14:33 | <Domenic> | I think it would remain incredibly hard---in fact, probably be harder---if you chose to restrict yourself to WebGPU + ARIA + whatever when creating this hypothetical better-than-iOS-and-Android-SDKs web framework. |
| 14:35 | <bkardell> | I agree with Domenic on this ^ |
| 14:35 | <sideshowbarker> | well part of the context around this is, we’ve been trying with the current stack since at least 2009 to create an ecosystem where better-than-iOS-and-Android-SDKs web frameworks can be developed and can flourish — but it has not happened |
| 14:35 | <Domenic> | (and the user experience will at the very least involve a long download time for first load, which is not a great start.) |
| 14:36 | <sideshowbarker> | (and the user experience will at the very least involve a long download time for first load, which is not a great start.) |
| 14:36 | <bkardell> | But also i feel like this aria part (much if it really) needs a little meat to be able to even discuss it. The "and aria" i feel like is handwaved but load bearing |
| 14:37 | <Domenic> | Again, I think it's really unclear whether iOS/Android SDKs are that much better. Remember that Flutter and SwiftUI are based on the React paradigm, which was pioneered on the web! |
| 14:38 | <Domenic> | My hypothesis is that the gap comes mainly in a good control library, and having stuck my foot in that area for a half-year and failed with a small team of Googlers, it comes back to my earlier point that you basically need major institutional buy-in (e.g. a large team working for 5-10 years) to get to the same level that Windows/macOS/Android/iOS have gotten to. |
| 14:39 | <Domenic> | Saying "you have WebGPU, raw HID events, and some ARIA thing---community, please build a good control library!" seems like a recipe for disaster to me. |
| 14:40 | <Domenic> | Flutter's tried for some number of years, don't know the size of their team, and the apps still feel quite unnatural to try to use on both Android and the web. |
| 14:40 | <sideshowbarker> | My hypothesis is that the gap comes mainly in a good control library, and having stuck my foot in that area for a half-year and failed with a small team of Googlers, it comes back to my earlier point that you basically need major institutional buy-in (e.g. a large team working for 5-10 years) to get to the same level that Windows/macOS/Android/iOS have gotten to. |
| 14:43 | <sideshowbarker> | But part of what’s implicit in the design sketch as Hixie wrote it up is that the primitives would not all need to be implemented at once anyway |
| 14:44 | <sideshowbarker> | We could start with just the “ABI to spawn a JavaScript environment” piece |
| 14:44 | <Domenic> | The primitives are all already there; the only novel thing in Hixie's writeup is the new MIME type handler to remove the need for a one-line HTML document. (And, I guess, the magic world where we get Safari/Firefox to implement WebHID.) |
| 14:45 | <Domenic> | The document is basically "what if Flutter apps could save one line of code?" |
| 14:49 | <sideshowbarker> | my understanding of implementation costs could be naïve, but it seems to me there is in fact a non-insignificant real cost to currently needing the HTML and JS “glue code” for WASM apps to run, and to needing to parse and load that |
| 14:49 | <Domenic> | Cost to who? |
| 14:51 | <sideshowbarker> | I meant, cost to browser implementors relative to a new code path that didn’t require it |
| 14:52 | <Domenic> | Nah, no cost. If you have a JS escape hatch/bridge of the type Hixie's doc talks about, then the JS -> wasm step is free from that. And the HTML -> JS step has been implemented for ~20 years. |
| 14:52 | <sideshowbarker> | I see |
| 14:53 | <Domenic> | Building something that was straight wasm would be more costly, as you'd have to figure out what kind of document that produces (presuming you don't want it to just auto-generate <html><canvas></canvas></html> like .pdf generates <html><object></object></html>; I feel like the latter would violate the spirit of the thing) |
| 14:53 | <Domenic> | (And you need a "document" in at least some broad sense, so that you have some idea of what the back/forward button does, and what other windows see when they reach into yours.) |
| 14:56 | <sideshowbarker> | would it absolutely have to create a document at all? could it instead be done without even instantiating a document at all but instead having a new kind of object that the browser operates directly? |
| 14:57 | <sideshowbarker> | ah, I see you answered that already |
| 14:57 | <sideshowbarker> | so Hixie responded somewhat to that already, in his Twitter thread, I think |
| 14:58 | sideshowbarker | looks |
| 14:59 | <Domenic> | Yeah I mean it's conceivable you could invent something new, and have some sort of Document-like facade when other parts of the browser or other websites look at it, but it's unclear what the gain is; especially if the point was to reduce implementation complexity, I am quite sure that sort of thing would not reduce it. |
| 14:59 | <Matthew Phillips> | Saying "you have WebGPU, raw HID events, and some ARIA thing---community, please build a good control library!" seems like a recipe for disaster to me. |
| 15:00 | <Noam Rosenthal> | it would very quickly be "you have WebGPU, raw HID events, some ARIA thing and flutter"... |
| 15:08 | <Matthew Phillips> | A more interesting question to me is not why developers aren't using the web as much for these app-like experiences, but why the web is not used even for document experiences. For example, why isn't the web the dominant way that readers read ebooks? Why isn't it the dominant way that publishers publish ebooks? |
| 15:08 | <Matthew Phillips> | Lack of integration with stores is part of it, but that can't be the only thing or public domain books would be read on the web, and I don't believe that they are. |
| 15:13 | <bkardell> | I agree it's useful to look at other stuff there too, but I also think anyone looking for a the technical why on any of these is trying to force simplcity where it doesn't exist like that in practice. There are tons of reasons and often they aren't even techinically good or necessarily logical. |
| 15:17 | <Domenic> | The ebooks question is quite interesting as a smaller test case of the app question. I like that; I hadn't thought about it much before. |
| 15:18 | <Domenic> | Possible answers: the web is bad for commercial distribution; HTML subsetting allowing a wider tooling/device ecosystem; the technical lack of packaging format makes parts of the pipeline awkward |
| 15:21 | <bkardell> | Why people use 'native apps' is many things. It's a combination of the fact that the app stores tell us we should and the app store is by the same people who make the OS, and sometimes the device too so as customers people say "seems legit". It's the fact that sometimes people like the app store... If you're looking for a thing you open over and over again it's very handy - you think of it as an app and you don't want to search the web for that... You want maybe somewhere where you can see how many other people got it and read some reviews and comparisons -- a lot like why you would use a brick and mortar store... You have some sense that you can learn somethign about the quality. In practice I think that is mostly bunk - we need to do better than what we do, but yeah, same reason people like amazon reviews/purchase data, etc. You can't get that easily today with the web. But also then we built this whole movement where businesses which would do great with a PWA and who could build the great UX, etc still think they gotta build the native thing and use their site to push you to it, which again makes users think "oh, I guess that's better"... Basically that is a self-fulfilling prophecy even if all other things were equal (I think they aren't, but still) |
| 15:21 | <Domenic> | Public domain books do exist on the web, e.g. Project Gutenberg, https://standardebooks.org/, things like the Rust book etc. But the online reading experience is not great for those in my experience. E.g. my bookmarks get lost among a sea of other bookmarks; reliance on scroll position instead of pagination |
| 15:22 | <Domenic> | (And of course, no Kindle integration) |
| 15:23 | <bkardell> | Public domain books do exist on the web, e.g. Project Gutenberg, https://standardebooks.org/, things like the Rust book etc. But the online reading experience is not great for those in my experience. E.g. my bookmarks get lost among a sea of other bookmarks; reliance on scroll position instead of pagination |
| 15:26 | <bkardell> | ebooks are differently complex than apps in a way because standards have changed and moved venues and probably they tried to solve a lot of problems before we had critical things in place. It would be really great to make that wonderful at last |
| 15:26 | <bkardell> | now they can at least all display math :) |
| 15:27 | <Domenic> | Can they, though. Publishers still tend to use pixelated pngs for math in the eBooks I've seen. |
| 15:28 | <Matthew Phillips> | now i kind of want to build some ebook web components. |
| 15:30 | <Matthew Phillips> | Building an ereader in HTML/JS shouldn't be that difficult, I can't think of any technical limitations that prevent it. I think things like Project Gutenberg don't have great web ereaders because not enough of their users use it, to make it worth their while |
| 15:30 | <bkardell> | Can they, though. Publishers still tend to use pixelated pngs for math in the eBooks I've seen. |
| 15:30 | <Domenic> | Kindle |
| 15:31 | <bkardell> | (can was referring to browsers can, sorry) |
| 15:31 | <bkardell> | kindle has their own rendering engine for that |
| 15:32 | <Domenic> | Yeah I meant it's more of a publisher pipeline thing, presumably |
| 15:32 | <bkardell> | yeah |
| 15:33 | <bkardell> | also another (I think) critical thing is the next gen rendering engine reworks in theory enable a lot of that stuff to actually be practical -- like pagination, etc... previously kind of very shoehorned, but we have good fragmentation design etc now |
| 15:33 | <bkardell> | so like, the web today would be a much nicer basis IMO for all this if we were coming at it fresh today |
| 16:37 | <bkardell> | "shouldn't be" means ideally or today? The guttenberg thing is very chicken and egg. I have only read a few books digitally and all but one has been public domain. I just like physical books 🤷 in fact, I like physical book stores still, and libraries :) Even as a lover of the web, any kind of digital is still just not my ideal choice for most of my actual book reading. |
| 16:39 | <bkardell> | I think if you were solving this problem today you would probably not come up with .epub |
| 19:14 | <TabAtkins> | As an avid ebook user, I believe the ebook "issue" is almost entirely (1) payment/drm, and (2) pagination. For the latter, it just turns out that pagination is usually a bad UI pattern on the web and scrolling is better; books are one of the rare places where the opposite is true. |
| 19:15 | <TabAtkins> | Related: good book rendering involves some algorithms that have bad worst-case runtime complexity but are perfectly fine for rendering things like book pages. |
| 19:15 | <bkardell> | I will agree those are a very big part :) |
| 19:16 | <TabAtkins> | So once you're inventing pagination yourself, doing the rest of book rendering is actually quite simple and avoids most of the problems with replacing the web (no need for a bunch of input controls, complex layouts, etc) |
| 19:17 | <TabAtkins> | So the cost of doing it all natively, vs wrangling the web into doing it when you're trying to tweak things at a level below the primitives it naturally exposes, just leans pretty heavily towards native, and that's not unreasoanble. |
| 19:18 | <TabAtkins> | I'd certainly like good book rendering on the web, like we could just iframe an epub and it would Just Work, but it would be a pretty large effort with very questionable return on value. |
| 19:19 | <bkardell> | why would you need to iframe it? |
| 19:19 | <TabAtkins> | I mean, loading up a http://example.com/book.epub would work just as well, sure |
| 19:20 | <TabAtkins> | but assuming you were rendering a reader site around it |
| 19:20 | <bkardell> | right. I think that used to work in ms briefly |
| 19:21 | <bkardell> | maybe not well - idk I never used it... I just think I remember someone, maybe rossen showing me some talks |
| 19:30 | <Jake Archibald> | I'm always surprised that folks think UAs would produce an excellent epub reader, given how bad things like HTML date inputs were (and continue to be, depending on UA) for years |
| 19:46 | <bkardell> | kinda curious how those are related - I definitely think what Matthew Phillips is saying is that books are documents about text, you know the thing the web is supposed to be great at. Date pickers, are mostly used in stuff that is more of a stretch for that model |
| 20:02 | <TabAtkins> | Yeah, I'm not seeing the connection. Several browsers rendered some form controls in a relatively shitty manner (tho I've seen worse in userland; rarely, but still), but that doesn't seem to have any bearing on how everything else is rendered. |
| 22:19 | <Ian Hickson> | fwiw, i think the "but then you'd have a million frameworks all reinventing text editing" argument doesn't match reality. we've run the experiment. there aren't a million frameworks on android, there's a half dozen real ones and maybe a dozen more small ones. on the other hand the web has literally thousands and more pop up every year. they don't reinvent text editing, instead they reinvent other things, but they still exist, in a way that just doesn't happen on other platforms. i'm not sure i 100% understand why, but i think it's curious nonetheless. also, "save flutter one line of code" is exactly what this proposal is, yes. i mean, it's more like "one stub file" than "one line of code", but it's basically the same thing. the idea is for the web to recognize it's in 2023 not 1991, so that when you boot a web app it doesn't have to first get you from real mode to protected mode and then from protected mode to long x64 mode (or rather, from 1991 CERN document mode to 1997 DOM mode to 2020 Wasm mode to 2023 WasmGC mode etc). everything this proposal suggests is already possible, the proposal is just to clean up the technical debt around it. |
| 22:22 | <Ian Hickson> | there's shades of the 2004 w3c apps & compound documents meeting in this, where mozilla and apple (and microsoft and sun!) were telling the w3c they can either get on the train or be left at the station, except this time the train is wasm&webgpu :-) |
| 22:43 | <bkardell> | there's shades of the 2004 w3c apps & compound documents meeting in this, where mozilla and apple (and microsoft and sun!) were telling the w3c they can either get on the train or be left at the station, except this time the train is wasm&webgpu :-) |
| 23:06 | <bkardell> | we are saying completely different things about how we interpreted its relationship to 2004 I think though :) |
| 23:26 | <Ian Hickson> | WPF would have been amazing, i'm still surprised microsoft didn't succeed at that |
| 23:26 | <Ian Hickson> | it only really lacked two things, a security model and vendor-neutrality |
| 23:27 | <Ian Hickson> | this is our opportunity to finally get there 20 years later though |
| 23:27 | <bkardell> | if you squint at your proposal the right way does it resemble flash a little? |
| 23:27 | <Ian Hickson> | it resembles flash a lot |
| 23:27 | <Ian Hickson> | flash was a huge boon for the web, with a few fatal flaws, the prime of which was again, lack of vendor-neutrality |
| 23:28 | <bkardell> | ok 😆 I was afraid to say that because I didn't want to insult you or something, but it is what I was saying too |
| 23:28 | <Ian Hickson> | it's kind of amazing that nothing ever really took its place |
| 23:28 | <Ian Hickson> | SVG i guess sort of did |
| 23:28 | <Ian Hickson> | but not like back then |
| 23:28 | <bkardell> | this thing called html 5 came along and told it to stop |
| 23:28 | <bkardell> | :) |
| 23:28 | <Ian Hickson> | well, html5 was sort of orthogonal to what flash did |
| 23:29 | <Ian Hickson> | html5 was more about stopping xforms |
| 23:29 | <bkardell> | that might have been the intent |
| 23:29 | <Ian Hickson> | i think apple had more of a hand in killing flash than html5 |
| 23:29 | <bkardell> | but we also got canvas and animations and all kinds of things that made flash less necessary |
| 23:30 | <Ian Hickson> | somewhat. but those animations that flash made? we never really got them back. |
| 23:30 | <Ian Hickson> | youtube provides the non-interactive version i guess |
| 23:30 | <bkardell> | svg coming :) |
| 23:30 | <Ian Hickson> | if svg was going to do it, it would have done it already |
| 23:31 | <Ian Hickson> | anyway, i think wasm+webgpu is going to enable a whole category of things that we've been lacking every since flash and wpf died |
| 23:31 | <Ian Hickson> | (whether or not we do the thing i proposed) |
| 23:31 | <Ian Hickson> | we see it already in the kinds of apps people are making with flutter on web |
| 23:31 | <Ian Hickson> | like Rive |
| 23:31 | <bkardell> | youtube is interesting I was saying the other day how i wanted to write a post called Howard the Doc about this idea that how you think about what it is you're doing is hard and you always have to kind of squint at it. A doc is one model, but like, flash's was a movie. Hypercards was a stack. |
| 23:33 | <bkardell> | none of those are apps, but what is an app? When you look at the UI history the web and native clearly cross pollenate one another with ideas on how the model should be |
| 23:34 | <bkardell> | like Rive |
| 23:34 | <bkardell> | anyway, i think wasm+webgpu is going to enable a whole category of things that we've been lacking every since flash and wpf died |
| 23:38 | <Ian Hickson> | rive.app, it's the first google result for "rive" |
| 23:38 | <Ian Hickson> | not familiar with webxr |