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