Hey, folks, welcome back to another episode of JavaScript Jabber. This week, on our panel, we have Steve Edwards.
Yo yo yo, come in at you live from Portland. I'm filling in for a j since he's not here right now right.
We also have Dan shpier.
Hey sitting in the air conditioning room in hot and sunny. Tell the league.
I'm Charles Maxwood from Top End Devs and we have a special guest this week and that's your weiss. Do you want to introduce yourself?
Let people know it.
We've had you on before, so I think some people know who you are, and then.
There may be a few they don't. They should.
Yeah, sure I can introduce myself.
So hey, I've been working on web performance for way too long, trying to solve it and so far not being super successful. I been working on browsers since twenty twelve, and initially on my own, then at a Kamai working on both browsers and server features, then at Google for a few years, and nowadays I'm at Shopify, still working
on the web platform amongst other things. I co chair the Web Performance Working Group and I'm one of the doink api owners, which is basically the folks that sign off on features getting released in Chromeum.
The working group is what it's worth mentioning is part of the W THREEC.
Yes, yeah, yeah, the W three C Web Performance working Group. Yeah.
I would like to point out that it's from a visual standpoint, it's easy to tell how smart he is by his haircut, just saying so, yeah.
He's one of these guys that shapes his head even though he has hair.
Yeah yeah, I wouldn't define it as has.
Hair, but yeah, well got made only so many perfect heads and the rest he covered with hair, So that's right.
I like to say that I'm also I'm an invited expert on that same working group. The guy who invited me over it is job, so I'm very thankful for that.
I'm thankful for contributions.
So yeah, doing fighting the good fight, trying to make the web faster for everybody's sake.
So, Yo, we got this document from you about JavaScript loading, and it's interesting because it starts off with you changed jobs. So you want to kind of give us some context on that and then we can jump in and talk about JavaScript floating.
Yeah sure, so yeah, So basically, I, like I said, worked on Chrome at Google for five years up until a few months back. And yeah, and earlier this year I changed employers. But the good thing about open source is that I get to do a lot of the same things with a different head on. Basically, I've been working on making the web faster by default, I've been doing that before joining Google, and I get to do that afterwards. So I continue to work on on Chromium.
I now also get to work on WebKit, which is a refreshing change and the only thing with I guess with the change from working for a browser vendor to working more like closer to the industry, it kind of helps to keep me aligned with what developers actually need, because working for a browser vendor is great, but it's also it makes it hard to keep up with what actual developers are doing because browser developers are not Web developers,
at least not really. Yeah, and working as part of the you know, quote unquote industry makes it easier to make sure that my work is actually aligned with what people need, So that part is something I'm very very happy about.
Yeah.
Other than that, there aren't a lot of commerce voices amongst people who work on browsers, so I'm very happy to bring in that perspective to those discussions.
That's especially interesting given that probably the organizations or the web that's websites web apps that have potentially the greatest need for web performance or see the greatest impact from improving web performance are commerce related websites. In many cases. Yeah, there's always those you know, research papers showing like Amazon increase their revenue by a trillion dollars because they spend up loading time by five milliseconds or something along these sides.
Yeah, I don't know about these exact numbers, but but yeah, basically performance is very important. There are a lot of public case studies about the relationship between web performance and conversion rates. And I'm biased, but it seems to me that it's like crucial to have that kind of influence on you know, on web standards and and where the web platform is going.
Yeah. By the way, the Google driven website web dot dep which is an excellent website, has a case studies section which actually has real numbers, not numbers invented by me, that describe how companies did in fact significantly increase their conversion, their income or whatever thanks to improving performance. And like you said, it's it's not really surprising. Uh, you know, it's we have We're in an age of you know, little patients and a lot of distractions, and if your
website takes too long, too low, then people will go elsewhere. Yeah.
If if you remove friction, good things happen in general.
Yeah, it reminds me of when I told someone that the said that the pipeline or the funnel at the previous company that I worked at is implemented in Angular. Their response was, don't let angular get between your customers and potential customers and the payment something along these lines. But but yeah, it is important to reduce friction as much as possible, and improving performance is certainly a good way to do that.
So we're talking about the JavaScript bloating today, So how does that get into this friction or frictionless performance set up.
So I've been unhappy with the way that JavaScript is being loaded on the web for a long while, but haven't been able to move that too much just yet.
But it's essentially I think that in many ways, when we're looking at web performance and loading performance, there isn't really a good way to load JavaScript, and the main advice that web performance folks can tell people or have been telling people is just to load less JavaScript, which is correct but not necessarily useful in today's web development environment. If you can load your site with less JavaScript, you should.
But at the same time, there are a lot of JavaScript based but like even for those, loading performance matters. Loading performance matters because your users interact with your website. They will right click and open a new tab, they will reload your browser will unload your app in the background in order to save memory. And in those cases you're you're effectively heating reload even if you even if your if your site is you know there all day.
There are a lot of interactions where loading performance matters. So essentially there are no good ways today to load scripts. And yeah, then and I as part of we started enumrating the different number of ways of that you can load scripts. But it's essentially if if you go back to the basics, we have blocking script that are you know, they are not a good pattern because they are blocking
the parser from processing the rest of the document. There are acink scripts who are not necessarily a good pattern because they are racing and will potentially get in the way of more important things if they happen to load earlier.
And we have deferred scripts who are really like, it's a relatively well defined model and it doesn't block the parser.
But at the same time, they are often like they're always loading in a single milestone, a single point in time in the page life cycle, and that may or may not be sufficient.
So I think though it is important to mention that. Even though so talking about blocking scripts, which are the most obvious way in initial and kind of the oldest way, I guess, because really, if you don't say anything else, then a script is blocking by by default, like this is the way the web was originally built. It's it's problematic, like you said, it's usually bad, but it's needed because sometimes you need to do some things before rendering can proceed.
So it's it's when we say blocking, what it really means is render. Blocking means that when the browser hits that point that script tag, it has to stop rendering until that script finishes. I know that some browsers do hacks around that, but really, at the logical level, that's what it means, right.
Yeah, But there so there is a better alternative to that, which is blocking equals render, which gives you essentially it gives your acing script or deferred script, the ability to block rendering but not block the parser, so the browser can continue to do work, but the user doesn't see things flashing around before that script.
Oh yeah, I forgot that one, and maybe I should have even added that to the list. In this In this context, it's you know, the web is something of you know, like an archaeological site. You know, it's it's layers upon layers of history. And and the thing about the web is that once something has been implemented, it can almost never be taken away and must be supported
forever and ever. So in the very olden days, I think it was brendan Ike that introduce the concept of document right, which enabled JavaScript to kind of inject content into the HTML stream, into the document downloading stream, and therefore, because of that, scripts had to be blocking, because you couldn't proceed with processing the HTML just in case something happened to be injected into it. Now nobody uses document well, I can't say nobody, but hardly anybody uses document right anymore.
It's like a fraction of a fraction of a percent of websites, I would say, But it still needs to be there. You're smiling, you off, so I'm guessing more websites. Maybe sure, and we can let me see, probably like SSL VPNs or something. Use it for evil in the various things, or maybe all sorts of firewalls or whatnot. Use it for crazy stuff. But it's not something that. Let's put it differently, ninety nine point ninety nine percent of web developers don't use it, but it still needs
to be supported, so it's still there. So scripts are not just render blocking. They're download and parsing blocking, as it were. And like you have said, if you put loading equals render, then you're telling it basically telling the browser. Look, you need to pause the rendering because maybe I'm doing logic around dark mode and I don't want content flashing
or something, so you need to pause the rendering. But I'm not using document, right, I promise, so you can actually continue parsing stuff because I won't be modifying the download the documents stream. So yeah, I to be honest, like I said, I actually forgot about that. That option. Another, by the way, interesting option is again if you have a blocking script, whether it's in the head or the bottom of the body, that also kind of modifies the behavior as I recall.
It modifies the priority. It's not like the script will block parsing whenever it's discovered, but if it's discovered at the bottom of the document, that like parsi're blocking, doesn't have a huge effect because there's nothing more than that actual script to parts, so it's blocking nothing behind it.
So if you're some browsers, yeah, we talked about it with Robin Marx, some browsers in that scenario would actually reduce the priority you have the script download, some don't.
Yes, yeah, the whole Yeah, so there are generally for
blocking scripts browsers. All browsers nowadays have a mechanism or all all commercial browsers like if I'm not sure about for example, ady Bird, but all big browsers have a mechanism where they continue to parse the document in order to speculatively fetch resources when they're when they encounter a blocking script and yes whenever, Like a blocking script of the head would have a higher priority in some browsers than a blocking script at the bottom, but all the
like the priorities as well as this speculative preloading of assets of resources, none of that is specified, so every browser can pretty much do their thing and Web developers shouldn't really rely on it. Yes. So basically we have multiple, multiple ways to load scripts. I am unhappy with all of them. And then we have essentially for like the future of script loading for the last I don't know how many years have been yes modules and.
One more thing before we get to yes modules. I think that another key aspect that confuses people when they think about script loading, but really any asset loading in the browser, is that the difference between important and urgent isn't always obvious. That some stuff is important because the page can't work without it, but it might not be urgent, as in that certain things need to be downloaded sooner.
So for example, in this day and age of SSR and SSG, where we present stuff visually before it actually becomes interactive, Like there's a difference in time between when a page is seen and when a page becomes interactive. You might say that visibility is more urgent than interactivity. As long as the difference between the two is sufficiently small. It's a painful thing because because sufficiently small is a problematic definition in and of itself, and if it's even
slightly too big, it becomes a real problem. Like the page literally doesn't properly respond to user interactions, which is worse than slow, it's really broken. But yeah, I still think that this distinction between what is urgent and what is important, Like what is important is stuff that the page can't properly work without. If a certain image, for example,
is not downloaded, that's not necessarily important. If it's if it's doesn't get in the way of the pages operations, so you get a broken icon, you know, you could still work. On the other hand, let's say if the CSS doesn't download, then there's a good chance that the page becomes totally illegible. So that's kind of really important, and it's also urgent because you need that CSS really quickly, and JavaScript can be somewhere in the middle between these two.
Yeah, yeah, I guess fonts also is you know, one of those assets which is like there's no good way to load them because they are potentially important for branding and user experience and whatnot. But if they don't download, then you fall system fonts. That's also like it's still a usable site. So yeah, there's also so it's an
interesting distinction between important and urgent. I think that there's also no current way like Another interesting distinction that there's no way to express today is the difference between when you want the script to load and when you want the script to execute, and at least for acing scripts,
those two happen at the same time. As soon as the script is loaded and the main thread is clear, that script gets executed, and that may or may not be the right choice depending on when you need that script. So there are scripts that you want them to like load earlier, but still want to be able to control their execution either manually, and then you can use preload for that, but that is hacky and cumbersome or otherwise.
The only currently official milestone you have in the page life cycle is the down content loaded when the whole HTML finished parsing, that's when the third scripts trigger. And yeah, there's no way today to express different preferences there.
And again there is even a middle step in between the two that's kind of less important but still exists that people might want to be aware of, which is the parsing. So you're really downloading the script, you're parsing the script, and then you're executing the parts the parted script. Now. Per my recollection, some browsers, not all browsers can parse the script as it downloads. Some of them can even do it off off of the main thread. Some don't.
Some bundlers get in the way of this by putting all the script inside strings and then converting those strings into scripts, which I never really understood why bundlers do that, but some of them do.
I did not know that. That's that's interesting, and that seems.
Yeah, I think webpack does that in certain situations, at.
Least I wonder if it's dev mode.
I don't think so. I think that if you I don't. I don't think it's defoe necessarily.
Okay, that's that's interesting, and that can also that can get in the way of yeah, of parts like a parallel parsing in the background. It can also maybe get in the way of code caching, although I guess if those strings don't change then eventually yeah, I'm yeah, not sure, but it's it seems less than idea.
So you were saying that we can separate so the downloading and parsing can happen together. Not even so we can actually download without parsing by prefetching. We can download and parse together but not execute by preloading, or we can just load the script which does all three or maybe avoid some of them if you've already prefetched or preloaded.
Yes, but the problem with the script loading, like if that the most straightforward mechanism for just loading the script doesn't give you any control regarding to when that script is executed, at least when you're going with acinkscripts and like we deferred as well give to you a certain point in time in which your script will execute.
And yeah, so talking about the sink scripts for a second. So sink script scripts become a sink either because you explicitly put the sync attribute on the script tag or if you've added them dynamically into the HTML. Then there are sync by default as I recall, or if there are our modules by default of sync or deferred. I always forgetfer.
Modules are deferred by default.
Okay, So those are the two scenarios in which it's a sink. A sink, as its name implies, downloads without blocking. It downloads the background. But the problem with it, as you said, is that it's executed as soon as it's finished downloading, and the browser can execute it if we'll execute it. Yes, I mean that there's no guarantee about order of things and what else the browser or may or may not have done.
Yeah, and beyond the lack of guarantees regarding ordering, I've seen a lot of cases in the past where you know, people have some scripts are critical for rendering. They are like they contain they render the main content, and other scripts aren't. People load all of them with acing scripts.
And then if you naively preload those scripts. Basically, if if you make acing script go faster, some pages will get slower, some pages will get will get faster, and some will see a mix of like essentially both where some parts of the like some parts of the critical experience, get faster, but then they there are other scripts that should have run later that get in the way because execute execution times essentially grabs a hold of the of the main thread for things that aren't critical.
Yeah. So again you're you're saying something is not urgent, I'll make it a sync. But what you're not taking into account is that the browser will start downloading it immediately, even if it's a lower priority, and if it happens to be a relatively quick download, then it might get executed faster than you expect. Ahead of more more urgent stuff, and if its execution is lengthy for any reason whatsoever, because it loops up to a trillion or what, then
you're basically stuck. So you either need to write if it's your own script, you need to write it in a way that ensures that it doesn't execute really too soon, or alternatively, you might want to load it at a later time, not just using a sin.
Yeah, and in the past, I've seen optimizations that preloaded things and made like made everything slower because those acing scripts ran too too early.
And again we kind of spoke about it with Robin as well. The reason that people preload scripts. You might ask, if I'm loading scripts up front, why would I preload the scripts? You know, it seems like a useless operation. But the thing is that preloading actually impacted the download priority or could impact the download priority, which could make
the scripts and I'm making air quotes download faster. These days, you've got more let's call it the natural way of doing it, which is the fetch priority attribute.
Yeah, but you also have you know, there are systems out there who detect scripts as get for example, scripture or else from run data and then automatically preload those in order to accel, Like, let's get all the scripts that loaded before FCPO or LCP, preload them and then
make things faster. And some of those scripts are in HTML and could have just had the fetch priority, but some of them are laid discovered and are dynamically injected through other scripts, and that part is not like it's less trivial like in those cases helps more.
Also, we used to.
Have a thing called server push, which even like loaded these scripts even earlier, and those kind of optimizations often ended up with basically results, Yeah, bimodal results. Some pages get way faster, some pages get way slower, and.
Some pages get faster in some scenarios and slower in other scenarios, like depending on network conditions and stuff like that. Yeah, so we live.
So what do we do?
Then?
It sounds like you're kind of outlining what the issues could be. But then, yeah, what do I, as the regular old web developer do to make this better?
So right now, I don't really have I don't have a perfect answer. I can, like, I think, as a web developer, you should probably prefer deferred scripts over.
As is the good baseline. Always start with defer with you when you can.
Yeah, with the caveat that deferred scripts all run in a singe like all of your pages. Deferred scripts run in a single task and they don't get interrupted. So that could be a source of responsiveness issues because there is that.
I think you need to explain what that means.
Okay, sure, Let's say I have a page with ten different deferred scripts from different sources. All of these scripts will run one after the other without the ability for browsers to interject and handle events while all those scripts are running. At least that's the current Chromium implementation, and I believe other browsers follow the same pattern. It's not really defined in like the spec doesn't force that kind
of behavior as far as I know. But at the same time, it will be somewhat risky to change it because pages can break if side effects can now be interleaved in between in between the first scripts. So basically what that means is that, yeah, we can't handle any events between those different scripts. We can't handle any micro tasks, any promise resolutions, and that.
Going back to your example. If we've got ten scripts and each one of them runs for one hundred milliseconds and effectively your browser is stuck for a whole second and won't respond to any user interactions doing that one second, which might be less than idea.
Yeah, so, yeah, so I would like my baseline recommendation would be deferred scripts, but there's this caveat to take into account. If your scripts are if you expect those scripts to run for a long while, then maybe deferred script is not the best option. There are currently there's current effort to modify this behavior, but yeah, it's not not trivial because there is risk compatibility risk in changing it.
So essentially, yeah, I think that today's best option is maybe, like yeah, somewhere in the between a SC and defer, but both of them have drawbacks.
I think that that most bundlers or most meta frameworks either put use defer with all the downsides because like we said, it's it's the best of the worst, or alternatively, they use blocking scripts at the very end of the document. I think those are the most common ways that most frameworks use because it's also the safest approach in a lot of ways.
Yeah, I guess.
And as we said, there are two ways to get deferred behavior. Either you add the defer attribute or you put the type equals module, which makes your script anes M module and then it's deferred by default.
Yeah, which kind of brings me to the problems with because they are also not.
Like they are.
How a lot of people, at least a lot of people around me are writing code. They are not necessarily how a lot of people are delivering code. Bundlers. A lot of bundlers are turning es M into kumjas or other classic script patterns. And the reason for that is that if you deliver yes modules to the browser and rely on that, essentially have static imports as part of what you deliver. Those static imports are by definition discovered late. The browser needs to parse that first script in order
to discover the second layer of imports. It downloads them, it parses them, and only then it discovers the third layer of imports, and so on and so forth. So by definition, you're hitting a waterfall pattern if you are delivering yes modules as is to the browser.
And those and those static imports, if I recall correctly, are are blocking right?
They are blocking the script from running. Yes, they all and Yeah, essentially the whole module tree will wait until everything is loaded, and only then will it execute in a single task, similar to how the fur like it. Basically, you wouldn't have a way to interrupt the browser won't have a way to interrupt this single task of script while it's running. So the territory will load at once.
But if you I don't know if you remember, but it is the browser itself responsive during that import or is it kind of like an alert or something?
Uh? So the renderer will not be so while everything is downloaded, the main thread is still free. It's just when when some like when something when when the module three starts executing, that's when the main thread.
Blocks, so execution so execution is blocked, but not the browser until imports finish. Yeah.
Yeah, the download of the imports is done a smous okay, but it's it's late, Like there's a discoverability problem know about them until it parses, Like doesn't know about the next layer until it parses the layer about it?
Okay, but there is at for that kind of isn't there with module preloads or stuff like that.
Sure, but you would need to module preload the entire tree in order for in order to solve this discoverability, you would need to module preload the entire tree. And one more thing that I was surprised with when poking at Yes modules from like slightly closer, import maps are which are maybe I should first start by talking about
import maps. So essentially, import maps enable us to map module specifiers to URLs, and that has a very strong attribute of enabling us to avoid invalidating entire trees if a single module has changed. So if we have a module that is changed, typically when bundling modules, we are maintaining a hash or a version of that of that module in the URL itself, and those hash invalidations because it essentially if one of the leaf modules have changed,
that it's URL has changed as well. That means that the module that refers to it also has a content change that changes its hash, which then propagates up all the way up the module tree.
Oh so kind of bubble up the module tree if any leaf kind of changed exactly.
Incidentally, I'm just going to point out that import maps is what Rails uses now.
Is it's.
Yeah, the whole it's kind of the whole DJH thing I think is avoiding bundlers and relying on the built in browser capabilities, which means yes modules, the built in es modules and import maps.
Yeah, so import maps are great for that purpose, but they are also, at least today, are rather fragile, and there can only be a single import map in a document, and it has to be the first bank that loads inside of that document. So if you have any module script that loads before an import map, import map throws,
and nothing of what it does is valid. And if you have a very large JavaScript app that has let's say a few thousand modules, which I've now heard multiple real life examples of in multiple companies, you would have to load all of these thousands of modules into your like the mapping for all of those modules will have to be part of your initial import map, which is the very first thing that your h email should contain in line, So there are, yes, there are no ext
no support for external module, external import maps.
And external life better and better. Yeah, I guess, I guess I see the reason. I mean, given that it's so urgent and so so fragile, you don't want it as a separate document that you need to go and and and download on the side. But but still it's it's not wonderful too to have this huge thing stuck at the very beginning of your lovely semantic document.
Uh. Yeah, so I tend to agree. I think that we like. Basically, what I've spent a large chunk of my day to day on is trying to figure out what a spec for having the ability to have multiple modules, multiple import maps, and then merge them. What would that look like? And yeah, so I'm I'm basically I think this is one of the more urgent problems for both there large JavaScript apps, but also for smaller ones that
don't necessarily have control over their entire content. I don't know if you like then if you imagine your days at Wix, like, there are a lot of CMSs that integrate content from multiple places. Some content is, you know, coming from the platform, some content is coming from your customers and their third parties, and you integrate all that together. And if any one of those folks is using an import map and another was using modules before it, everything breaks.
Yeah. I'm also thinking of stuff like Google Tag Manager or any other kind of pixel system which could theoretically or ideally benefit from such a mechanism. But again, and you're bringing in resources from multiple vendors, from multiple ur ls. You know, it's it's it's having a single source of truth and everything else ignored is a is a very problematic motor.
I agree, and I think like the yeah, dynamic scriptloading from third parties, I think that's a very interesting use case here as well. And yeah, that's so so basically I think, yeah that right now there are a bunch of issues with ES modules and important maps and yeah, I'm I'm on my you know, starting my path to fixing them.
And it can get even more complicated if you throw web workers into the mix, I would imagine.
To be honest, I haven't even thought a whole lot about web workers in this context. I mean there are, yeah, because right now they don't have a way to like web workers don't have important.
Maps, and they need it because you can actually Okay, so first of all, we talked about the various ways to load scripts. So web workers are another way to load scripts because if you do a new worker, the parameter you specify is the script file that gets loaded into that webworker. So effectively, here's another way to load scripts. Not only that, there's a parameter that controls whether or not the script that you load into the web workers
is ESM or not. It's ESM or Classic I think, and the default is classic, but it might beesm so you might be loading an ESM script into the webworker, and then you definitely would need some sort of a mapping mechanism to work with the worker. Yeah, pun intended or pun not intended?
I agree? And right now, yeah, import maps are only defined for documents and for worker. You don't really have where to inline that import map today.
So would it use the do you again, I don't know if you remember, but would it use the documents the parent document? So it just doesn't have a map at all, And that's it. I can kind of get it because it might be a shared worker and then where or or a service worker, and then where would it take the map from? But the web worker I don't know.
Maybe yeah, yeah, to be like, I think it's a very valid case. And yes, yeah, module workers are the future, especially because import scripts for classic work is also.
Very like that's it's a product. Yeah, yeah, it's bad. I let's put it this way. I made Wicks significant loaded scripts and sweat workers scripts significantly faster by hacking around import scripts, which is yet another way of loading scripts into the browser. And I won't even go there.
Because it's loading them like if you have a list of scripts, they will load sequentially.
Synchronously and sequentially.
Secretly and sequentially. And yes, uh and that is like without any good reason.
So yeah, so or it sounds like you're working on a new standard, get to handle some of this, So what what does what is that look like? And what are kind of the hang ups getting there?
So yeah, So basically I've been like, I'm planning to work on a bunch of standard improvements or web platform improvements on that front. So the very first thing that already shifted that was missing from my perspective for ES modules is integrity sub resource integrity. So SRI if you're familiar with that for regular for classic scripts, you have an integrity attribute where you can say only execute this
script if it matches this hash. So if as part of my build process, I like I have controls over my built process, then I upload these assets somewhere and then when the site loads, I want to make sure that my assets match what I think they should be and no one, no malicious actor has switched them up in between.
Been in the middle kind of attack.
It's not really men in the middle. It's more of a like you know, I don't know if there is a fancy name for it, but basically the content swap at rest, so the content is uploaded to your hosting provider and then someone with the keys can swap it to add malicious payload. You want to avoid that scenario. You want to have integrity checks in place in the browser.
So you can actually put an attribute on the script tag that says this is the check sum that my script should have and if it doesn't, then just no digit.
Yes, same for CSS and preloads, and that's it. You can't do that for any other type. But that is sufficient because images are presumably not very important, and at the same time they are also harder to pull off, like harder to do that integrity check without slowing them down.
But this piece was missing from module imports. So if you have dynamic imports for modules where you want to load the critical scripts upfront and then dynamically load stuff you need for later once things calm down or once the user did something, those scripts didn't have any way to get an integrity check without jumping through many hoops because it didn't have like there was no native support for is modules and integrity checks, so the first step
I took in that potentially long path to making U script loading better is to add that kind of that kind of support with an integrity section as part of the important map. So that has lended in Chrome last week, hitting stable last week, and it's on its way to Safari eighteen, which is presumably gonna hit users sometimes this fall.
So that.
Yeah, yeah, I'm it was a relatively relatively fast project. Basically, I during a flight put together initial prototype, initial spec and uh rudimentary tests and then like the whole thing took roughly two weeks.
To you built Chrome while on the flight.
Yes, this is what.
I fight.
Interesting, Yeah to each I guess.
So you've got the integrity check.
Yeah, that was the first step. I think that the next step is probably the multiple important maps and dynamic important maps. Okay, I think that that's the the next thing to reduce fragility and and and generally, yeah, make it more more feasible for large apps to use import maps because the cash testcade problems that they solve are real. But yeah, that the blocking nature is blocking.
Yeah, but that opens interesting questions like unless I'm I'm overthinking at maybe, which is possible. I do that, but it for example, it means that script A can control where unrelated script B loads from. I'm kind of kind of it's kind of like what I would do with a service worker in a sense, like I can tell it it says this RL, but actually downloaded from that URL. So with dynamic import maps.
So with dynamic import maps, essentially you would have like you wouldn't have the ability to redefine a script that was already loaded or a script that was already defined in another import map. So you wouldn't be able to redefine specifier.
So it's not like cascading. It's kind of like a join sort of a thing, a.
Join where you know first in stays kind of yeah, no variety, Yeah, and that is still up for grabs. Like I have an algorithm in mind, I will like, once I have a pr up, I will definitely share it with the world as well as with you. And yeah, I'm happy to get feedback on that. But I think it's Yeah, I think that the model where you can't, yeah, you can't override something that was already defined gives us
enough safety for some definition of safety. I mean theoretically, like it, import maps are essentially scripts that are running in the top level documents context, so they can like the fact that they can override things is not a security risk because you already like you introduced the vampire into your home kind of kind of scenario. But at the same time, we don't want developers to be surprised, and we don't want import maps that are coming from
different sources to collide. So yeah, we want this to be as predictable as possible.
There's a question on Twitter from Gall Weiseman. I'm sorry if I say your name wrong.
My friend as a guest.
I think yeah, but he asked about a compromise script can potentially leverage an I frame to bypass the SRI checks dictated by the top document and thus load a remote third party script that's not allowed to load.
I think the I think is in parentheses. Is that being taken into consideration? So this is back on the SRI.
So knowing Gall, I'm sure he has a scenarian mind that I don't, but I think that that non verifiable. Like an I frame we're talking like, does he mention like same origin cross origin because.
It would have to be the same origin otherwise.
It because otherwise it's irrelevant. Yeah, the same origin I frame. If it's compromised, then yeah, it would have a different as like it would have a different integrity Like the import map doesn't apply to same origin I frames, so it would be able to load that script at the same time. I wouldn't expect the cash to Like if that script is cashed from the same origin I frame, I wouldn't expect it to be loaded at the top level without failing, like because one has integrity checks and
one doesn't. So I would expect the browser to fail that load at the top level frame.
I also actually have a question like looking at all the stuff that you're doing, so the sr EY, the the the module maps, also the work on compression dictionaries. I think we had Patrick Meaning on the show to talk about it. All this stuff is about how to better load JavaScript into the browser so that we don't need bundlers as much, or that bundlers can be maybe less heavy handed than they are. You're you're shaking your head.
That's not so I think we need butlers. I think that there are some issues with like physics when it comes to loading a lot of small modules into the browser. Browsers have overhead like per request overhead, that overhead is unlikely.
Mhm, just cookie, look up inter process communication.
Yes, foundations all that. Like that takes time and it I think at the time we looked at Chrome and it was around like one to two millisecond per a resource, which is not awful unless you're loading five thousand resources. And in that case, you're talking about like ten seconds just to get the thing. Like even if it's on disc and if it's like zero RTT on the network, it still takes a long time to load these assets. If you so, then those are is unlikely to go away, go ahead.
In those cases. Isn't the problem somewhere else? I mean, if your applications designed in such a way that you don't have any sort of segmentation and you're loading five thousand assets, it just it just kind of seems disproportionate, you know, like is this really the problem over here?
But but AJ, this is kind of the DHH model. I mean DJH basically said, and I'm kind of paraphrasing, like let's not bundle at all, which means that the structure of your code in your code base is the also the structure in which the code loads. Now if you're one of those people who likes to put every function or every component in their own separate file, then you can end up with and it's a large enough project, you will end up with thousands of resources.
Well, maybe you shouldn't do that. Maybe that should be a signal that's a bad way to code. Stop doing it.
So very large. If you have a very large team that's building a very large web app. Let's say you know Facebook, they have a lot of people working on different parts of the app. They share code, there are a lot of modules involved.
So well, but that's more for the benefit of investors, like trying to show continual growth by continually hiring more people, not because people are needed. Like Twitter fied seventy percent of their workforce and Twitter got better.
I would argue that got better part, but.
Yeah, it didn't get worse. It's not slower, it's not less reliable.
I think the point is is you've got you've got so so let's say that you've got things broken up by components, and you've got the components of different files, like we're talking about that. There are a lot of things that are really convenient as far as like developer ergonomics that come from that, and that's why we do
it right. But at the end of the day when we deliver it to the browser, the point is is that you can pull all of that together with a bundler and deliver one deliverable and reduce a lot of that overhead, which also makes sense. And I'm a big fan of having tools that solve the different problems in the right way. And so that's where I'm I'm sitting here and agreeing with Yoev on this, even though I am you know, I generally agree in a lot of
cases with the AGEH. In this case, it makes a lot of sense to have that bundler pick up those things, and you know, any of the other tiny bits that kind of have similar responsibilities, and then something like import maps solve some of the other issues where I'm pulling in a bunch of third party stuff and saying, Okay, I need this, and I need this, and I need this and I need this, but I'm not necessarily fiddling with that stuff.
And I'll put it and I'll also phrase it in a different way. If I'm using a compound language like I don't know, like a se or raw or whatever.
There is a.
Separation between how the code is organized and how the bytes are delivered for execution and unless and and the D model for better and worse cancels this separation. If I prefer using a lot of small files, it's a choice, a choice that you might not agree with, but it's a legitimate choice for some organizations. It means that I can't use the D model or the D approach without paying a potentially hefty price for it.
Fair, I mean, I I agree with that. I just I've seen code bases where it's one function profile. It seems it's almost like a meme. It's so popular, but it's just it's it's silly. I mean, you can't even understand the context of how a button fits into something because you got look at ten files to figure out.
That.
Yeah, I'm thinking, I'm thinking, I don't know. I was thinking, why would something have five thousand files. I wasn't even thinking of the like one function per file, because I wouldn't think a serious business would do that.
I don't know that. Yeah, I don't think it's a one function profile, but I think it does like it does result like code sharing between teams does result in a lot of small modules. They're not necessarily a single function but they are a single functionality. And I don't know if this is the like, the best way to develop or the west or the worst way to develop. Like I said in the beginning, I'm not really a web developer. I pretend to be one once in a while, but I'm not doing that in like in my day
to day, I'm mostly hanging on browsers. But it is a legitimate way to deliver software on the web, and we should like and I think that bundlers are essential for that part, both for the browser overhead as well as for compression ratios, because if you're compressing very small files, you will compress them very poorly compared to large files. That's impressed very well.
So yeah, but then we have the compression dictionaries, which mostly solves that.
I don't think they will solve it for very small like you would still have to deliver the very small files once and you would still have a very like I think compression dictionaries solve a different problem with bundlers, or at least in my view, like they could solve it as well to some extent, but they in my view with bundlers. One of the issues with a large bundle.
One of the issues is you're losing caching granularity. If any single function, a single character inside that bundle changes, you have to download the whole thing back again, And compression dictionaries will help us avoid that, at least on the network.
Yeah. So, but my initial point was kind of different. We're doing a lot of things that impacts the platform in a way that certainly affects how bundlers work or should work. How much corporation are you guys getting from the bundle makers, because it seems that they should be significantly involved in all this effort.
So at the time, I think maybe on the podcast we were talking about like web bundles and a long while ago, and bundlers were very much part of the loop on this. And Daniel Ehrenberg from Yeah, I don't like he may have been at the Gallia, he's now there's at Bloomberg. He was super involved in bringing the bundler community into the room. And there's a TC thirty nine tooling meeting that we talked about multiple times at the time about web bundles, and I think that they
are like they were super supportive. I think that once this what I'm talking about will reach a more mature level, I would be very happy to talk to them, and I'm assuming that they will be similarly supportive, because none of them like essentially this is all not like talking about maybe like improved bundlers and improving the output of bundlers to deliver better experiences. So I think it aligns
well with everyone's goals and intentions. In the meantime, a lot of the bundlers are very configurable, and you can you can go a long way just by mucking around with roller plugins. And that is at least the approach that I'm taking now with the various prototypes that I'm working on.
Which means that you're effectively compatible with is built, which means that you're effectively compatible with VAT.
Yeah, I love VAT any same So sorry just came out anyway. Yeah, because like I said, you know, I follow along with rails and DHH. I mean that's kind of where I live my programming life. But I'm using deep on my RAILS projects. I'm not using import maps, so but but I kind of want to jump back over so you so far we've got compression dictionaries we've got import maps, doing multiple import maps, We've got SRI. I mean, what other things are you proposing to fix this stuff?
So proposing is a bit of a like, you know, a big word. I have ideas that I want to play around with. One of them is defining different controls as to when the scripts are loaded versus when they're executed, and defining more milestones for the browser to execute deferred semantic scripts other than just dumb content loaded. So maybe adds more milestones around first render like FCP fired, Now execute these other scripts, unload fired, execute these other scripts
after onload. Things along those lines are things that I'm planning to play around with. I'm I guess what you mean.
What you mean is like declarative support, because programmatic support already exists. For example, obviously for onload, I can do windowload equals sure, and I can specify god to execute on the onload.
Yeah, So I would love to play around with a polyphyll of what declarative support for that would look like and see if this these kind of models give us any benefits in terms of execution, and then if they are, then this would be potentially something to to propose as new keywords that will enable us to better load scripts without the you know hacking through like preloading the assets
and then executing the the script manually in different midlstones. Yeah, so this is one thing I'm thinking I'm playing around with. Another is with stream execution of bundles. So we talked about the fact that bundles are you know, if anything changes inside the bundle, then the entire bundle gets invalued in the cash and you need to download a new one. But besides that, bundles also delay execution because you have to download the entire bundle before you can start executing anything.
But because we are starting off from ESM, we could maintain those module boundaries and then recreate them in the browser in ways that enable the browser to execute the modules separately. And there's a TC thirty nine proposal around module declarations again from Daniel Ehrenberg that I mentioned earlier. I am playing around with the userland prototype to see what that gives. It requires a lot of hats, both on the butler side as well as on the browser side,
but we'll see where that gets me. I still haven't seen it working yet, but you know, yeah, I'm hopeful that this would be a successful module to start executing earlier.
An interesting idea that just occurred to me while we were speaking is you were talking about declaratively controlling when scripts execute. It might be worthwhile to also have declared or to try out declarative ways of controlling when resources or scripts start downloading. Like I want to download something synchronously, but I don't want to for to start downloading before the LCP because I don't want it to get in the way in the way of the LCP in any
shape or form. Yeah, but by the way, another and it's worth mentioning that if people who are listening to us find all this stuff interesting and have their own ideas, they can basically, you know, participate in the W three C Where Performance Working Group and make their thoughts hurt.
Yeah, for sure, that's so. Some of these things are like, some of these things are hacky projects that haven't gotten anywhere just yet. Some are going to probably live mostly as what wg prs against the htmlspec. But all of this is something that we can and should discuss in the Web Performance Working Group. So yes, if folks are interested, feel free to hit me up. I can like, yeah, join the calls and yeah, make your horses hard.
Yeah, it just sounds like a good place to kind of start to wrap up to it. Is there a list of these proposals or these ideas somewhere that you have your or are we kind of it right now?
I need to write it down. This is all like there's a list of things I put together for this for this podcast, but it's like not something I can call but yeah, I need to write down this as a master plan to improve script loading and and then yeah, I need to publish something on that front.
Cool. Well, if people have ideas, how do they join that working group? I think that might be an interesting place to go.
Yeah, basically the main path. So if they work for a W three C member, then they can just join and ask their AC representatives to to join the working group and yeah, and that's it. Otherwise they can pin me or or the yeah or Nick Jansma, who's the other chair at AKAMAI, uh, and yeah, we can you know,
talk through the issue with them. Yeah, I'm pasting a link to the web performance to the working groups page where you can you know, if you're double member, you can join through there and otherwise, yeah, just email me or Nick Jansma and we can.
Set you up.
They're like, we're available over email, over there's the web performance slack group that a lot of people are on, and yeah, otherwise you know on the internets.
Good deal. All right, Well, I'm gonna go ahead and slide us into our picks. But this has been really fascinating. But yeah, let's do our picks a j do you want to start us off picks?
Let's see what have I got. My wife and I recently watched the Jason Well we start. We've started watching the Jason Bourne trilogy, but we started with the best one, which is Born Supremacy, and she liked that, so we're probably gonna watch the others as well. So I will I will pick the Born trilogy because it's kind of a kind of a cool movie and.
She has a sufficient context.
I well, I when the movie started, I told her, okay that the thing is, this guy is basically James Bond, except he wakes up one day with amnesia and is trying to figure out what he's doing. And this is the second movie, and we're starting with this one because it's it's better. And if we started with the first one, you like it, You might not want to watch the rest of them, but they yeah, you know, they're they're all the kind of the same movie. It's kind of
like Terminator and Terminator too. It's the same movie. It's just way better production.
By the way. By the way, I'm one of the few people, I imagine who've actually read the Ludlam book before they even watched the first movie.
So there's there's like ten books, aren't there to be honest.
I don't remember the problem with Ludlam is that all his books kind of are the same book.
Uh, well the movies are the same movie, so that tracks. But I mean the same thing with James Bond, right, yeah, I guess. Yeah, So there's that. I'm still motorcycling, still absolutely love it. And ah, I'm trying to think if there's there's anything else worth worth picking I do. I do have to rescind a pick from earlier. I at one point i'd picked Silicon Power drives. I've I love
Silicon Power for micro SD cards. They have been amazing. However, I had ordered about sixteen of the Silicon Power SSDs. Actually I don't think it was that many. Yeah, well it was about that many. Four of them have failed over the course of the last year and a half. And this is in a server environment. And they told me, you know, I got a business account with them. They told me they would, you know, warranty them for the server.
They'll warranty them, but they fail. And we've also got sixteen Crucial MS five hundreds and not a single one of them has had a hiccup. So I guess my pick would be Crucial m X five hundreds. If you are if you're putting together a server and you want the best value drives, I have to switch my pick on that to being Crucial. Silicon power is like half the price. But you don't want to be going to your data center replacing drives except for when you have to,
So I'll pick those my picks. Steve, what are your picks?
Well, before we get to the high point of every episode, I came across an interesting blog post or article whatever you want to call it, on how can news about open Ai? And you know, we've been using AI more and more in my work, but in a you know, in a scope limited sort of capacity based on our own data. But the title is how does open ai Survive?
And it's a pretty detailed walk through the business model and what open ai would need in terms of huge growth of money and just a bunch of unprecedented things to happen in order of them to survive over the next couple of years. So if you want something as a cure for insomnia, it's pretty good, I think. But it's also pretty interesting if you're into reading about open ai. Says they seem to be on a lot of tips of everybody's tongues these days.
We kind of spoke about this subject when Steve Sowell was on the show. I think I I kind of have tongue in cheeks, said that, like the only company actually making money off of the AI revolution is Nvidia.
Right because of the chips. Right.
Yeah, Well, I'm looking forward to where we can just download the model on you know, when when open eye goes out of business and they and they open source the model. I'm happy to download that, you know, forty gigabytes on my computer and run it off the power of my mag book.
I think there's the Olama model model that you can from Facebook. I think we are, which you can already download.
It's that's true, and it's it's better in some ways than chat GPT three, but it's not better than chat GPT four.
Oh yeah, the way the way that I understand it, and I'm still learning about this stuff, but yeah, it's good for a baseline if you're going to train your own stuff on top of it, right, to give it better context. But yeah, the GPT four models are much more comprehensive and give better answers.
I mean, they do have access to every book that's ever been made in every journal, and because they get asked questions like, so are you using copyrighted content that's you know, like paid content that you're just putting into the model and making available to everyone, and you're gonna face major lawsuits And they're like, oh, well, you know, it's hard to say cause I don't know exactly where all the data comes from, but it's definitely data that's
available online. So you know, your your olama is like basically Wikipedia, stack Overflow, you know, it's it's the big sites. But GPT four to zero is all of the content the humanity has ever created. There's not going to be a GPT five because there's no more data.
Left, all right, And then moving on to the highlighted.
Unless they just to say, unless they start putting in pictures of cats, because there are always new pictures of cats, always always.
Some of those are gonna be AI generated too.
That's why I'm paying the twenty bucks a month. And best cats, the best.
Cats, the cats with six fingers.
So I am suing the doctor who delivered my baby. My son now has to grow up without a liver.
Delivered anyway.
Sorry, sometimes you got to explain him. I was attacked by a flock of sheep yesterday, but luckily I was only grays.
That one's sort of bad.
We can see that there. We can see that.
Right there, right there. They raised and then I love this one I got. I thought for sure I'd get shot down on this next month of people loved it. I was.
I was gassing out my Honda Accord the other day at a gas station and a snarky Tesla owner asked me how much I spend on gas.
I said about five minutes.
That was That was well done, And I need to make a remark on Tesla. By the way, they are the number two per capita, as in per Tesla owner versus per other car owner. They are number two and most likely to get into a wreck and they are the number one motorcyclist killers. So if you own a tesla, wake up, get your hands on the steering wheel, watch what's in front of you. Don't run over people. Okay, thanks.
By the way, about the delivered, it kind of reminded me. There was this scene from Monty Python The Meaning of Life movie where they not on his door and they said, you're you're registered organ donors. Yes that we've come to collect.
Oh boy, yes that.
My favorite scene from that particular movie is the guy in the restaurant.
Oh, just midir, that's all.
No. I think my best one and my favorite one is that every sperm is sacred song and dense routine. Mm hm.
Anyway, those are my picks, Dan, Why don't you just keep us going?
Where are you picked?
Not exactly a pick. The twenty twenties have sucked so far, and this year has not been different in any way, shape or form. And a week and a half ago, are Lovely and Beloved My mother, lovely and beloved mother in law passed away. So it's been really tough week for us. So I would like to dedicate my part of this show to her memory. I miss you, deary. We all do and that's all I have.
Yeah, yeah, losing people's hard Yep, all right, I'm gonna jump in with some picks. I usually do a board game, and so I'm gonna do a board game. We played this yesterday. What we've been doing with my family is we we've been picking a game that we haven't played in a while out of our collection and then, you know, we play it and we decide if we want to keep.
It or not.
And the one that we picked up was Imagine If. And this is more of a party game, which I have to say generally are not my favorite games. I mean, this one's fun. I just sometimes when I'm in the mood for a board game, I usually want something that's gonna make me kind of think and strategize the stuff. You know. The party games aren't that way. But this one's a fun one, especially if you're all part of the same group that know the same set of people.
You just you write down names around the outside of the board. There's a marker, you roll the die, you move it that many spaces, You pull a card and you read the card and it's imagined if Betty were a type of shoe, which one would she be right, and then it's like a stiletto, a hiking boot you know, a baby booty, right, And so then you everybody has one through cards numbered one through six in their hand.
They put one face down, you flip them over. If you're in the majority then or if you're in the group that has the most I guess that doesn't mean you're in the majority, then you move up one. If you're the person who read the card, you move up two. And then you do it again. There's a space for challenge, and that one you pick another person that you think you're gonna match with. You roll the die again, you
move the marker, you read the card. The two of you put down your numbers, and if your numbers match, you move for and if you don't, then you move back to And my eight year old sabotaged me by challenging me and then picking a number that she knew I wouldn't pick so that I wouldn't win. That's the way that game went last night. But overall, it's fun game. Board game. Geek weights it at one point two two, which means super simple. I mean I basically explained all
the rules to you in less than a minute. But it is kind of a fun party game, and so you know, we had all of our family members and then you know Grandpa who wasn't there. So anyway, I'll go ahead and link to the board game. Geek listing in the comments only show up on Twitch, YouTube, and Facebook, so if you're watching on Twitter, which is where most people are watching, you just have to go look it up. It's Imagine. If drop the e at the end of Imagine, put iff at the end, you'll find it and then
other picks. So my my oldest son is eighteen and his favorite movie is A Quiet Place, and so we went and saw A Quiet Place Day one. I mean, no spoilers. He said that some of the people are in the that are in A Quiet Place Day one are in a Quiet Place Part two, which I haven't seen, but they're pretty minor characters, so I guess it is kind of an origin story for that group of people that you'll see in a Quiet Place Part two. But it it was good.
You know, it's not.
It's not the best movie I've ever seen, but it wasn't something I regretted going to see in the theater. So I'm gonna pick that.
And there's A Quiet Place Day one. Then there's a Quiet Place, and then there's like still a Quiet Place.
So A Quiet Place is the first movie they made, and then A Quiet Place Part two apparent is a second movie, and then this one a prequel that they made.
It's like the Star Wars prequels that came out.
Yeah, that's that doesn't sound like good?
Yeah? Well yeah, anyway, so I enjoyed those, so Mike, I'm gonna pick that. And then.
Okay, yeah I was. I was just confused about it. It actually is called part two because I did see those, yes, but I didn't remember what the name of the second one. It literally is called part two, got it?
Yep?
Yep.
So yeah, so I'm enjoying those. And then one other TV show, so I'm picking nothing technical, I guess is. I was browsing through Netflix and I saw that they did a live action Avatar The Last Airbender, and so I watched a few episodes to that with my same my eighteen year old son, and we enjoyed those. So I'm gonna pick those. That's that's it. That's it for my picks. You have, Do you have some picks for us?
Sure? So the first one I guess is hiking or I don't know if I had more than that, but like, basically, it took me way too long to realize that I practically live an hour and a half from the Alps and I should go up a mountain every time I get an opportunity to do that. And yeah, so it's like hiking is the best. Almost everyone can do that, and even if you second it at first, you get better. And yeah, it's great for your health, it's great for your mind, and yeah, everyone should hike more.
I can confirm in a test that you do live in a beautiful area, but given that you live in southern Fronts, that's not really surprising. Yeah.
Yeah, but at the same time I think everyone, not everyone, but if you live next to a mountain of some sort, you should go up at once in a while. That's that's what I say.
Yeah, it's it's interesting you bring that up because.
A.
J and I hear we live pretty close to the mountains here too, and boy, there are some amazing hikes to go on. Yeah, definitely, if you have the opportunity get out and see it, or get out and see the world, and you even go to Denver. Those are the best mountains, even better than Utah Mountains. On the plains, you're you want to kind of get out towards the but yeah, the mountains mountain.
I met Colorado Springs. I mean I meant to say Colorado. I didn't mean to say Denver. I meant say Colorado. But we were. We took a weekend trip to uh Colorado Springs area to see the Royal Gorge Bridge and the Garden of the Gods.
The garden is gorgeous.
I went to college just a couple of miles from there, so that was a popular place to go hang out.
Red bikes out there and stuff.
Yeah, and we went whitewater rafting.
Yeah, I did that Friday too. Good times cool.
Yeah, gorgeous too.
Yeah.
Never been to Utah or Colorado, so I should probably do that at some point.
Come on out.
Well, Utah is awesome.
My daughter and I did a sort of a loop around uh Utah two three years ago. We met up with Aj and his family when we were down there and uh, you know, went did the loop come down through a canyon lamp through Moab canyon Lands and what try across from canyon Lands. Can't remember in the downs to Lake Powell and come up over to Bryce Canyon. Oh arches, they had arches and canyon lands and Bryce Canyon and Lake Powell.
And it's awesome. It's really pretty. Didn't hit Zion, which we would hit Zion, but it's it's an amazing.
The only the only science. Yeah, the only problem is that the US is just so big, so getting from one place to the other requires so much driving.
Isn't it around the same size as Europe?
What?
Oh, k utah is the same size as Europe.
It's you know, the same size as some of the European countries.
Yeah, I mean it's I think it's big. Like, yeah, it's a lot of a lot of driving involved.
I would concur that driving around all of Europe would also require a lot of driving. The thing about Europe is that it's especially if if it's most it's less about the scenery. In most cases, it's more about like you know, art and architecture and stuff like that, and then things tend to be closer together. Also they're better rightways.
I stand correct, The United States is twice the size of Europe. Ohw or the European.
Union, which is not oh yeah, well like half of Europe is Russia.
So yeah, it's interesting.
Yeah, but when when I lived in Italy, Italy is basically if you took Arizona or Utah and you stretched it out to the length of California, right, So so anyway, you get different geographic deals when you go to different countries. But yeah, I mean you can roughly say, you know, land size, you know, some of the Western States are as big as some of the bigger European countries. So anyway, I'm gonna gohe and wrap us up. Thanks for coming
you off. This was really fascinating and hopefully yeah, we get some more ideas coming your way and we can see some of these things, you know, come to fruition and make the Internet better.
It's been fun.
Yeah, whatever you can do to actually make the web platform and the Web itself better is a literal win for everybody.
All right, Well, until next time, folks.
Accent