Yoav Wiess is a Developer Advocate at Google on the Chrome team, and also co-chair of the W3C Performance Working Group. In this episode Yoav explains how JavaScript resources are currently being delivered to browsers, and limitations and downsides with these approaches. He then describes a proposal for an advanced JavaScript delivery method that addresses these limitations. When this proposal is implemented, it will enable much more efficient download of JavaScript into browsers, boosting Web performance. This is a public proposal, and Yoav invites the community to participate in the standardization process.

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Yoav Weiss.

AJ_O’NEAL: Yo, yo, yo, listeners. Welcome to another smooth episode on JSJA BBER. Today we have Yav Weiss joining us from, Yav, where are you joining us from? 

YOAV_WEISS: From France.

AJ_O’NEAL: And what are you going to be talking about with us today, Yav? I'm going to be talking about a recent proposal I made related to web bundles and being able to dynamically serve them in order to improve JavaScript bundling on the web. 

AJ_O’NEAL: And we're going to be learning all about that right after we finish introducing the rest of the panel. Today, we also have Dan Shapir. 

DAN_SHAPPIR: Hey, hey from Tel Aviv. 

AJ_O’NEAL: Amy Knight. 

AIMEE_KNIGHT: You're killing me, AJ. Hello from Nashville.

AJ_O’NEAL: and Steve Edwards. 

STEVE_EDWARDS: Hello from a very sunny and warm Portland. 

AJ_O’NEAL: Now we'll continue on with our show as we rock it with y'all from France. 

 

Your app is slow and you probably don't even know it. Maybe it's fine in most places, but then the customer loads the page up, that one page, and after a couple of seconds, their attention disappears into Twitter and never comes back. The reality is there are performance issues in your app and they're affecting your customer experience. What you need to do is hook up your app to Scout APM and let it start telling you where the slowdowns are happening. It makes it really easy. It tells you how slow things are and what the problem is, like N plus one queries or memory bloat. It's also built for developers. So it makes it really easy to identify where the fix needs to go. I've hooked it up to some of my apps and I saw what I needed to fix in a couple of minutes. Try it today for free and they'll donate $5 to the open source project of your choice. Just go to scoutingpm.com slash dev chat and then deploy it to your app. Once you do that, they'll donate the five bucks that scoutapm.com slash dev chat. 

 

AJ_O’NEAL: All right. So yeah, I think I was told you were part of the Google team. Is that true? Is that, is that part of what this web bundles thing is something about Chrome or Google, or is this different? 

YOAV_WEISS: That is true. So yes, I work at Google. I work as part of the Chrome team, working on various web performance related projects. This is actually, a problem that I've been thinking about a lot for a few years. So basically, even before I started at Google, but I was involved in Chromium many years before that. And essentially, the bundling formats that are used today on the web are, in a way, just a concatenated JavaScript, which poses a bunch of limitations to the way that browsers can optimize their loading. So this is a problem that I'm setting out to solve. 

AJ_O’NEAL: Okay. Well, we are all so confused about this problem because, you know, we all knew that lazy loading was going to be the hot thing and we're going to have these lazy modules and then all of a sudden HTTP two came out. So it was like, Oh, we're not going to have to bundle modules at all. Cause the world just turned into paradise. Everybody completely forgot about HTTP two. Nevermind that HTTP three is pretty much already out. And then we went straight back to let's make a big, huge, giant, eight-megabyte JavaScript file every time we can. What the heck happened?

YOAV_WEISS:  Okay. So with HTTP one HTTP requests on the web had an inherent cost because you could only send a few of those at a time. The browser could only send a few of those at a time. So if you were loading, let's say 40 different resources, that would take you 10 full round trip times, regardless of how much bandwidth you have. That was an inherent problem in the HTTP one protocol, but then HTTP two kind of solved that. And it solved that by enabling multiplexing of requests and responses. So send like the protocol enables the browser to send multiple requests and then receive multiple responses without waiting on, like without being limited to the number of requests in the air. So we had high hopes for that to fix the need for bundling, but we were soon disillusioned because bundling still has like, even if we got rid of the network latency cost of multiple requests, bundling still provides us with compression benefits because if you compress the JavaScript resources one by one, you often get significantly inferior compression rates to when compressing them together. 

AJ_O’NEAL: Well, hold on. That's confusing to me too, because I thought Gzip was the bee's knees and we were like actually compressions not that important speed is important and we switch switched over to broadly. But then I noticed some of the the caddy version 2 which is one of the you know Popular alternatives to nginx or apache. I don't think they even support broadly in the new version. So did broadly die or 

YOAV_WEISS: Broadly definitely didn't die broadly is supported in all browsers on the client side and it's actually so when done right, it provides 20 to 30 percent compression improvement over what GZIP can give you. But the problem with Brotli is that it's very CPU intensive to get right. So those 20 and 30, 20 to 30 percent improvements are something that's costing you a lot of CPU improvements. So it's not something you can do on the fly. This is something that you should be doing as part of your build process and not a lot of servers were prepared for that. So you have a lot of CDNs that are now supporting Brotli, but it took many years to get that support in place. So one example is Akamai, where I used to work before joining Google, where they have both on-the-fly Brotli versions as well as offline Brotli versions. So they detect, basically compress your resources that you're serving them lightly compressed initially, but then compressing them with a stronger Broadly 11 settings later on to get those 20 to 30% compression improvements. 

DAN_SHAPPIR: Correct me if I'm wrong, but even with Broadly, compressing a single large resource versus compressing that same resource effectively as let's say multiple smaller resources, let's say 10 smaller resources is probably going to provide you with better compression if you compress it as a single resource, right? 

YOAV_WEISS: That is correct. Yes. Yeah. Generally, compressing large bodies of text gives you better results than smaller bodies of text. 

AJ_O’NEAL: So it, well, I thought that wasn't true for gzip because of the way its windowing worked and it has like, it rebuilds a dictionary after it reaches a certain window size. Is that true or not true? And is brought that LZMA? 

YOAV_WEISS: So that is true for GZip. So GZip has a window limit of 32K, but it's still 32K is still a lot to, basically, it enables GZip to reach its compression, like reasonable compression benefits, which are to some extent good enough, broadly is significantly better, but still GZip is significantly better than nothing. But when compressing smaller files, so files that are, let's say, smaller than 1K each, then your compression ratios drop significantly. 

DAN_SHAPPIR: And I think there's also another important point here. Because if we don't bundle, and unless we're using something like resource hints to inform the browser in advance that some resource might be needed, we also create this sort of a cascade. That means that we download resource A. And only then do we discover that we actually need resource B. And then when resource B downloads, only then we discover that we need resource C. And often resource A is dependent on B, which is dependent on C, which means that maybe we can parse A, but we can't really execute A until we finish downloading C. So we create a sort of a waterfall, which we can avoid by bundling A, B, and C together as a single resource download. Correct?

YOAV_WEISS: That is correct when it comes to, yeah, so to ES module loading or to any. If you're loading scripts from scripts, then yes, you're creating a waterfall effect that is better avoided. So you're reintroducing, uh, latency as well as processing into the discoverability equation where if you're bundling those resources, then the browser already has them by the time it discovers that it needs them. 

DAN_SHAPPIR: And I actually think that there is like a third motivation for bundling, which I'm not sure that what you're talking about is specifically intended to address. But I know that bundling is used to address that, which is namespacing. If I'm going to be using the same library from two things or that I load within my web page, let's say I have a a blogging system and a commenting system that say are separate from each other and for some reason both of them use the same library but they use different versions of that same library and let's say versions that are incompatible with one another that's obviously a bad thing but it does happen then by bundling I can avoid conflicts between these two versions, correct? 

YOAV_WEISS: Potentially this is actually not necessarily something that my proposal would solve on its own, because generally the bundles don't, they don't create separate JavaScript namespaces, but they could. So the bundlers would still need to create that, it's the delivery mechanism won't necessarily solve it. 

DAN_SHAPPIR: Cool, I was just talking about motivations for bundlers, not necessarily what you're going to be talking about. 

YOAV_WEISS: Yeah. Yeah, so in terms of motivation, so there is that there is compression and then there's the fact that even though with HTTP 2, the cost of requests on the wire is not high. The cost of requests inside the browser and the fact that requests trigger multiple IPCs inside the browser. So inter process communication inside the browser as well as access to disk when the browser is querying the cache for each one of them. That adds up a cost on the client side that bundling helps us get rid of. 

DAN_SHAPPIR: Yeah, we web developers tend to forget that we sometimes put quite a bit of stress on the browser itself, that the browser needs to do a lot of work, that we're just making some sort of HTTP request, but it needs to construct the header. Like you said, it needs to query the cache. It needs to look up in all the cookies. It potentially needs to do quite a lot of work in order to just make that HTTP request.

YOAV_WEISS: Yeah, and having all the resources or all the relevant resources for one specific aspect of the site be loaded from a single bundle helps alleviate that pressure and helps get rid of those performance bottlenecks. So that's not an issue when we're issuing, for example, 10 requests. But we're like, when looking at bundles in the wild, there are often hundreds and sometimes thousands of small chunks of JavaScript encapsulated inside of them. And if we had to send a request for each one of them, that would add up. 

AJ_O’NEAL: Thank you, NPM. Yes. So again, with HTTP2, it seems like CDNs have adopted it, obviously. Like pretty much any cloud service, I think, has adopted HTTP2. When we're doing our local development, I think Go supports HTTP2. I'm not so sure about Python and Node kind of sort of has HTTP2 support, but Express is kind of a, let's say complete project. I don't think it's being actively developed anymore. And it doesn't look like there's any plans to support HTTP2 with Express, which maybe we don't need because it's primarily for APIs and CDNs and, and web servers like Caddy are where our assets actually are being served and I'm guessing traffic probably also supports HTTP2. So with HTTP2, like how important is it for us to consider HTTP2 and HTTP3? Like how is HTTP3 different? Do these matter or do we just really need to keep our focus in the web bundling space? 

YOAV_WEISS: That depends on your definition of we, I guess. So 

AJ_O’NEAL: Let's say we is us us lowly JavaScript developers that are producing apps for small to medium sized companies. 

YOAV_WEISS: Yeah. So generally at the application level, ideally you wouldn't have to care about that and you wouldn't have to care and newer protocols that come in. So HTTP two adoption that is typically you're like, I believe it's supported by Python, I believe it's a, so there is a wide range of libraries, but essentially what you need is for your serving servers. So your Apache, Nginx, caddy, to be able to support that in layers below you. And you don't necessarily care about like those bits. The server should just do the right thing. And the same is true for HTTP3. So HTTP3 has a bunch of advantages over H2 when it comes to data connections that are lossy 

AJ_O’NEAL: just because it handles this video audio streaming, not so much websites. 

YOAV_WEISS: No. So even for webs, so for websites, if you have a lossy connection, so a connection that loses many packets on it's on the way, which HTTP two, are you running a risk of being sometimes slower than HTTP one because you're working on a single TCP connection. HTTP2 is multiplexing multiple requests over a single TCP connection. And then if a packet gets lost, it needs to be reset. And that is blocking everything. With HTTP3, there is a move to UDP that is like, it doesn't really have the concept of a connection and it's handling its own retransmission mechanism. So if a packet gets lost with HTTP3 the sender will delay sending any packets on that same stream, but it can send packets on separate streams. So in a sense, if you have multiple requests and a packet for requests, like for the response for one of them gets lost, the response, that response will get delayed potentially, but responses for other resources will continue to flow through.

DAN_SHAPPIR: So what you're saying is that HTTP3 is just essentially better for, let's say, noisy Wi-Fi connections or for cellular networks, et cetera, the world that we're currently living in? 

YOAV_WEISS: Yes. 

AJ_O’NEAL: All right. So maybe I painted too much of a backdrop with the questions I answered, but for me personally, at least, I feel like this type of information is really relevant when we discuss the bundling aspect. But with that, I'd like to move more into talking about the bundling, which is supposed to be the main topic of the show here. If I can un-derail us, my apologies, tell us more about the web bundling. 

YOAV_WEISS: Sure. So web bundles, as a proposal from the Chrome team, was basically created in order to tackle the use case of being able to serve progressive web apps as a single resource for various emerging markets and use cases, and as well as for convenience purposes. So having a single place where users can download a single file and then have that file be, you know, be a progressive web app that they can install and use. And it goes hand in hand with another proposal called Sign Exchanges that will enable those bundles to also have an assigned origin so that you could know that publisher.com is the one that is responsible for that bundle and they are the one that signed off on that. 

AJ_O’NEAL: So this is almost sounding to me, just hearing what you're saying, more like a hybrid of AppCache and Chrome plugins. 

YOAV_WEISS: I wouldn't say AppCache, but it's in a sense... 

DAN_SHAPPIR: Nobody would say AppCache in any context.

AJ_O’NEAL: Appcache was great. I don't know what y'all are talking about. It was simple and easy to use. It just had bad caching. It didn't have cache busting at the beginning and I think that gave it a bad name for the rest of its existence. 

DAN_SHAPPIR: AJ, you're derailing us again. But I think that if I'm hearing what you're saying, Yoav, it sounds to me mostly like a web standard alternative for something like an APK or something. Like the way that you would bundle mobile applications or something like that.

YOAV_WEISS: So it can enable you to have some sort of an APK for a web app. As well as, so this was in a sense initial use case, not necessarily APK, but it started from mostly from emerging markets and being able to deliver offline content in a way that never talks to the origin to do original host. And yet the browser knows what the origin is. But when seeing the web bundles part of that bigger picture, I started wondering whether this is something that can be used to make JavaScript bundling better. Because JavaScript bundling on the web, I mean, bundlers are doing a great job. But at the end of the day, what they have available as an output format is just a concatenated JavaScript blob, which has two significant downsides. 

DAN_SHAPPIR: Before you proceed, just to clarify, if somebody's missed that point, when we're talking bundlers, we're talking about things like Webpack, like Parcel, like I forget the other one. 

YOAV_WEISS: Rollup. 

DAN_SHAPPIR: Rollup, exactly. That's the one I was flipping my memory. But that's what you're talking about, right when you're using the term bundlers. 

YOAV_WEISS: Yes, this is what I'm talking about. So build time tools that enable developers to take multiple JavaScript chunks from multiple sources and bundle them together in order to better deliver them. But that delivery mechanism, that output format, is just a large JavaScript blob. And that has two major deficiencies. One is in terms of caching, if any one of those chunks have to change, we essentially have to re-download the entire bundle. There is no way for us to modify bits and pieces of it. 

AJ_O’NEAL: And this is how, I mean, that's a problem that exists across the board for decades and decades now. Database indexes are that way. I mean, this is, but yeah. 

YOAV_WEISS: Yeah. But if you have like a 500k one meg bundle and you had a few characters changed in one of those separate chunks, then you have to redownload the whole thing, reparse it, recompile it, re-execute. That has a significant cost on the client side. 

DAN_SHAPPIR: You know, at Wix, for example, this is a really sore point because we make multiple releases literally a week. And our entire package is fairly large. So unless we intelligently break it down into segments that are likely to change together, we are almost constantlyD in a state of cash invalidation. 

YOAV_WEISS: Yeah, and breaking the bundle apart to bits and pieces that are likely to be requested together is a very delicate and like, it's more of an art than a science and it's like you have essential trade-offs that you're hitting, regardless of where you're taking it. So it's suboptimal. You can reach a reasonable compromise between cacheability and delivery, but it's suboptimal. 

AJ_O’NEAL: The way this works in Git is typically you have some sort of tag, and you can do a shallow clone of just that tag. And then as long as you're on a known tag, you can build up incrementally. So you could say, you know, clone tag V2, and then you could upgrade to tag V2.1 with only the deltas. And this could be relatively small. Is there, is there some solution like that that could work in this approach? 

YOAV_WEISS: That is definitely another thing that I looked at in the past. So essentially Delta compression. So you have well-known versions on both the client and the server's end. And then you say, my latest version is version N. Please give me version N plus what. But the problem there is that it requires to maintain strict state between all the servers and the clients. So in the Wix case where they release multiple times a week, they will have to now maintain on the server side, the uncompressed copy of each of their releases till, you know, for month and month, month backwards until, you know, in order to be able to reply to a client to a browser that tells them, here, I have this version. Now I want the diff from this to the latest. So, like, Delta compression schemes are possible, but they are typically not so scalable in the, like in the context of of the web. 

AJ_O’NEAL: Well, I mean, if you're focused on monthly active users, then you only need to worry about the last month. You don't have to worry about the last six years and that probably wouldn't be efficient anyway. But what's the solution or what direction are you headed with web bundles to help solve this or what compromises are you making? 

YOAV_WEISS: Essentially with web bundles, what we're getting, if we were to send web bundles instead of a JavaScript concatenation, then we have granular. Regaining control over granular resources. So each one of the resources inside the bundle has its own URL, has its own caching headers and can be cached separately. So we are essentially enabling our code to invalidate one of them and request something else instead, but not, we won't have to resend the entire bundle because each one of them can be cached separately. 

DAN_SHAPPIR: It's an interesting point, and it took me a while to kind of understand that. When Yoav graciously let me read his proposal, and it took me a while at the beginning to understand the point. And it finally kind of clicked for me when I started to think about the web bundles that Yoav is talking about as kind of like taking a snapshot or and zipped, gzipping a snapshot of a cache that like in the cache you have associated with each resource of metadata, which is the URL of that resource, which is the relevant caching headers and stuff like that. So you're like taking a snapshot of a cache and sending that cache to the browser to use as another caching layer, as it were. And then if a resource that the browser needs is in that cache, it can take it from there. And if it's not, well, the browser already is able to handle cache misses. So that was a very effective way for me, at least, to think about what Yoav is proposing. 

YOAV_WEISS: Yeah, that's essentially it. We're talking about having a bundle cache in the browser and then being able to populate that with web bundles which have access to the separate resources. And that solves the caching problem with the JavaScript concatenation. It also solves the multiple IPCs and client-side overhead problem because we are delivering all those resources as a single file. So we only require a single request to go all the way to the network stack and beyond. So it reduces the client-side overhead for that. 

DAN_SHAPPIR: So that explains how it addresses the issue of granularity. Although I do still have a question. So suppose I did get this sort of a web bundle that has, let's say, four resources inside of it, A, B, C, and D. And based on the cache headers, B are no longer valid and I need to go out and get newer versions of them. I can still use the C and D that I already have within that bundle. Will I now make two separate requests? So it's like a web bundle only the initial state and from that point on I'm back to requesting each resource independently or can it somehow then ask for A and B together? How would that work?

YOAV_WEISS: So that's the second part of the proposal. So web bundles is not my proposal. It's something that my colleagues were working on. The bit that I'm proposing to change there is exactly that scenario. So if I have parts of the bundle that are in cache, I can request only those parts and be able to receive a partial bundle. So essentially, what we're proposing is that as part of the HTML that tells the browser that this bundle even exists, it will also include a list of the resources that are included in the bundle, as well as its URL. And then the browser can examine those resources in its cache, realize that some of them are no longer fresh or that potentially it has some of those resources that it acquired from other bundles. So if you have multiple pages on your site, not all of them are reusing the same resources, and you may have separate bundles for them, but which overlap, which is the exact problem that you were talking about earlier, where you have to decide which resources go together and then try to split them up, but that's not 100% clean separation and you can have overlapping resources. Once the browser knows which resources a bundle has, it can communicate which resources from that bundle it needs to the server so that the server can just serve it with the right resources that it actually needs and drop from the bundle the resources that it doesn't need.

DAN_SHAPPIR: partial bundle on the fly or will it need or should it be like prepared in advance? It seems like that if it's a fairly large bundle, combinatorics kind of dictates that you need to create it on the fly. You won't be able to have all the possible combinations. 

YOAV_WEISS: Not necessarily created on the fly, but you need to subset it on the fly. So you have on the like at build time, you create a large bundle that contains options that you need for that particular page, all the different chunks or multiple bundles, but essentially you have a larger bundle that is created the build time, and then at serving time, based on the request headers received from a browser, the server would be able to subset that bundle. It needs to be a slightly smart server, but it doesn't need to maintain state. All the information it needs in order to that bundle will be contained in that request. So essentially the request will contain a bit set of all the resources that the browser actually needs from the bundle, if that makes sense. 

DAN_SHAPPIR: I think it does. And how will that look like in the browser? I mean, how would I configure my, like you mentioned PWA. Would it need to be a PWA to use this feature? Would it be something in the manifest? Would it be something in HTML? How would I use that feature as a web developer? 

YOAV_WEISS: As a web developer, your build process will create the bundle that serves the JavaScript for your page. It will, at the same time, also create a link tag that will include, so one like what we're proposing now is a rel equals web bundle. Then it will also have a resources attribute that contains a list of URLs that are contained in that bundle. The browser will then take that list of URLs, examine them against memory cache to see which of them are cached and which of them are not, and then create a bitset that will be encoded as a request header and sent back to the server. So the server will get a request for a specific bundle URL. It will get it from disk. And then with that bundle and the bit set, it will know how to subset the bundle to exactly the list of URLs, the list of resources that the browser actually needs. 

DAN_SHAPPIR: Oh, that sounds really cool. But if I'm thinking about it and maybe I'm missing something, it seems to be in a sense kind of like a sophisticated resourcing type of a mechanism. That means if the server supports it, I have this link request, it goes out, it downloads the bundle. If it doesn't, then I just end up downloading each resource independently. If I understand correctly. Is that correct? 

YOAV_WEISS: Yes. If the browser supports it, then yes, you will like it. It's progressive enhancement. If the browser doesn't support web bundles, you will just download those resources separately. 

DAN_SHAPPIR: So the one potential downside that I see with this is that, let's say Chrome supports it, but Safari doesn't, because Safari doesn't support things. And so I got this wonderful delivery mechanism that really speeds up my Chrome or Chromium-based browsers, but is really dog slow on Safari which is not a problem that they have with current bundling technology. So what do I do about that? 

YOAV_WEISS: So in that case, in case that there would be lag and support, you will need to have basically maintain both pipelines until, so you will have the fast bundles in one URL that you give to Chrome. That's a far just like you give all browsers so far just ignores that. And then, yeah, you will need to change your HTML at the serving site to address non-supporting browsers and serve them with different types of bundles if this is the trade-off you're choosing to make. You can either have a simple server-side that will be slower in non-supporting browsers or a complex server side that serves those two pipelines. 

DAN_SHAPPIR: So it could be something like client hints or something that's similar to indicating browser could say in the request, hey, I support web bundles and serve me the HTML that uses web bundles or something like that. 

YOAV_WEISS: Accept headers is what I have in mind. 

DAN_SHAPPIR: Oh, okay. 

 

Hey, folks, are you trying to figure out how to stay current with React Native? Maybe you heard that Chain React Conference was canceled and you're a little bit sad about that. Well, I borrowed their dates and I'm doing an online conference. So if you want to come and learn from the best of the best from React Native then come do it. We have people like Christopher Chedot from Facebook. He's gonna come and he's gonna talk to us and answer questions about the origins of React Native. We're also going to have Gantt Laborde from Infinite Red and several of the panelists and past panelists from React Native Radio. So come check it out at reactnativeremoteconf.com. That's reactnativeremoteconf.com. 

 

DAN_SHAPPIR: Cool, so this sounds like a really awesome feature. Which version of Chrome are we gonna get it in?

YOAV_WEISS: caveat that this is a personal proposal. For now, there are a few folks internally that are also excited about it, but it's still very early stages. So it needs a bunch of work in order to be a reality. There's also work that needs to be done in terms of compression because we talked earlier about the fact that Brothely provides 20 to 30% benefits over GZIP. At the same time, Brotli compression, if we want to get those compression benefits, it's not something we want to do on the fly. So when we're coming to subset resources, it's not necessarily like if we were to naively just recompress them with Brotli, like we're either leaving compression on the table or we are making our servers extremely slow, which is bad. If we were to do that right now, we would probably compress them with something like Brotli level 5 or level 6, which are good, but not as good as Brotli 11. And I currently have an intern working on a project that is essentially trying to figure out a way to reuse an already compressed Brotli 11 file and recompress it in an efficient way. So that we will be able to get ideally, broadly 11 benefits at broadly six costs, or that's the ideal. This is still an ongoing project and this is a major feasibility challenge, let's put it this way, to enable this. If it's not feasible, then we'll still be able to get compression benefits from broadly 6, but it will still not be in that ideal state of maximum compression with zero trade-offs. 

DAN_SHAPPIR: If I can make a suggestion, I would say that what you can think about doing is if you're going to be delivering a relatively small subset of the resources, then having a slightly less efficient compression is not such a big deal. So you can try to think of a cut-off point that above above a certain point if you need everything except A, and A is kind of small, then just deliver everything, including A, and use that broadly compression that you got from the get-go. But if you only need to deliver A and everything else to stay the same, well, deliver A with G-Zip, because it's not going to make that much of a difference anyway. 

YOAV_WEISS: Yeah, I agree that it's a trade-off. I'm still hoping for the ideal outcome here of, you know. The best compression, maximum cash granularity, zero trade-offs. If we can't make that because it's not feasible, then yes, we can definitely make some of the scheme work with some trade-offs around compression. 

DAN_SHAPPIR: By the way, there are two things that really excite me about this proposal, which is why I'm really happy that you're pushing this and talking about this with us. So one has to do with performance. I deal with performance day in, day out. And anything that can improve performance is really, I really like it. And we're all delivering a ton of JavaScript, which is unfortunate. But it's currently the reality. So anything that can be done to more effectively deliver at least the JavaScript, all the JavaScript that we're using, is definitely a good thing. So that's one thing that really excites me about this proposal. The other thing is that I think that we're in a sort of an inflection point with regard to how we use modules on the web. So up to recently, we didn't have ES module support in the browsers themselves. So we were kind of forced to use bundles, whether we liked it or not, to a great extent. And now, all of a sudden, essentially, I think all modern browsers more or less support ES modules. And by the way, I have to say that I'm currently working on several projects where during the development process, we're just using the raw modules. So we don't have to bundles and we don't have to use resource maps. We're just using the raw source code and it's wonderful. It's difficult for me to explain just how great it is to be able to debug code at the original source code level. It kind of throws me back to where we were way back when, like 10, 15 years ago, but it's so great and it just works wonderfully. But then we have to package it and currently the way to package it is to use something like Webpack and all of a sudden if you've got a problem in production you're back where you were and the code doesn't look like the code that you wrote and there's all sorts of issues and especially all sorts of issues because we had Gil Tayar by the way a few episodes back. I'll post the link to that show. And he was talking about how bundlers deal with the import statement differently than the way that browsers deal with it because of the whole NPM thing and absolute paths versus the logical paths and so forth. But I highly recommend anybody who's listening to us to listen to that episode if they have not. And that creates a significant disconnect between how I can use ES modules with the browsers on the web as they were meant to be used, and how I can use them with the bundlers that I currently have to use in order to effectively distribute my code. And it seems to me that the solution that you're proposing fixes that, because it just means that I theoretically could just use those ES modules with those absolute URLs and they're logically separate, but they're technically bundled together. And it's like the best of both worlds, seems to me. YOAV_WEISS: So I agree that this also solves a huge, huge delivery problem for ES modules. ES modules, as defined today, basically their loading pattern is waterfall-like. So the browser has to download the route in order to discover with modules that module imports, and then it loads them and discovers the next ones, and so on and so forth. There are ways to pre-declare that with module preload, but that's not ideal. And being able to bundle modules into a single, like being able to use web bundles while keeping ES modules and not turning them into something they're not, is definitely an advantage here. I was initially also hoping that this will enable us to start executing the ES modules earlier. Because the other problem that I didn't really talk about with bundles today is that they need to be able to... JavaScript cannot start running until the entire resource has reached the client. So if I have a one-megabyte bundle the browser can decompress it on the fly. It can start parsing it on the fly. There is a project to eventually also, like at least in V8, there are plans to eventually be able to compile it on the fly. So compile it, the JavaScript as it comes in, but execution is bound to having the entire file. Like you have to have the entire file in order to start executing it. That's just how JavaScript works. And that's really different from just a comment. 

DAN_SHAPPIR: That's really different from how HTML works, for example, where you are able to execute or actually render, let's say, the HTML as it's being delivered. You don't have to wait for the entire HTML to download before you start rendering it. 

YOAV_WEISS: Exactly. And if we have the bundled approach versus the unbundled approach, so the bundled approach is better for delivery. But the unbundled approach is better for execution because each small JavaScript file can be executed independently. So the browser doesn't have to wait for the entire MEG to download before it can start executing something. And with ES modules, so bundles can solve the delivery problem of ES modules, but they cannot currently solve the execution problem of ES modules. Because with ES modules, similarly, you have to download the entire module tree in order to start executing it. And there are a couple of changes to the way these modules work that will need to happen in order to enable that kind of streaming execution, if you will, of the module tree. One is that currently, if you have an error, JavaScript error anywhere in the tree, nothing must execute. And that is something that will need to change in order to enable parallel execution of the parts of the tree that are, as they are discovered, because you want to be able to have late errors, and you want to be able to start executing the modules that, you know, need to be executed first. And at the same time, if you discover an error later on, you want to be able to stop the execution there and have an error there. 

DAN_SHAPPIR: I'm going to interrupt you for a second, because I just want to verify that I understand correctly what you're saying. So I apologize for this interruption. But suppose I have a module A that imports both B and C. And B and C, both of them don't import anything. What you're saying is that, let's say A arrives. The browser sees that it needs to download B and C. B arrives C hasn't arrived yet. Theoretically, I could execute B because B is not dependent on anything really, but you're saying that currently it can't because if there's a bug in C, then B shouldn't run. That's, that, did I follow you correctly? 

YOAV_WEISS: Exactly, yes. This is exactly the scenario. And- 

AJ_O’NEAL: That sounds really weird to optimize for an error. It seems like we should optimize for the happy path. 

YOAV_WEISS: I agree entirely. Yeah, so, but this is something that we'll need to, basically this is not how ES modules are currently defined. So if we want to optimize for the happy path, we will need to change that aspect of ES modules. Another aspect of ES modules that we'll need to change is that right now between execution of different modules in the same tree, the browser cannot run anything. And if we want to be able to, execute the tree as it comes, we need to enable the browser to run microtasks between different modules so that if B arrived and executed and C hasn't arrived yet, the browser doesn't freeze and do nothing until C arrives. That makes sense. 

DAN_SHAPPIR: Yeah, I can understand why you're there doing it because otherwise you're introducing a lot of... The whole execution thing becomes so kind of indeterminate. If things execute in some sort of random order, and if they modify some sort of browser-level APIs, you could get really unexpected results if you don't preserve some sort of an order. 

YOAV_WEISS: So the order in the module where you can eagerly execute, the order is preserved. It's just that it's not guaranteed to all execute at the exact same task. You can have different tasks between them. And yeah, it shouldn't execute different. Like, ideally, we can make sure that it doesn't, like... 

DAN_SHAPPIR: Basically, you're saying that life is hard. 

YOAV_WEISS: Yeah, you can't have all those different modules execute as a single code base, as well as, like... You need to either prevent anything from executing in between, and then, yeah, you have a significant delay, or we make things faster and make sure that people don't step on their own toes. 

AJ_O’NEAL: Well, a big part is just the parse and the compile. So even if we don't execute, if we just get the parse and compile out of the way, and in a lot of applications, that is the core of what slows down the browser. I mean, obviously, if there's a lot of DOM manipulation, that'll slow it down. But I think parsing and compiling is more time intensive than the actual running of the script. 

YOAV_WEISS: I think that varies. Parsing and compiling is definitely time intensive. Parsing is already done in parallel or can be done in parallel in V8. Compiling is something that I know people that want to work on, so it's definitely in the future at some point, but it's not enough. Execution is still a huge chunk. 

DAN_SHAPPIR: Yeah to weigh in on that from my experience. It would have been correct had we all not decided to use React, for example, because React Hydration, as an example, or React rendering, is often just this huge chunk of execution. And like you have said, Google has made significant inroads in terms of parsing, for example. And Brian, Chrome already does it. It parallel parses JavaScript resources as it downloads them which is another motivation to break a large bundle into more smaller and manageable parts. 

YOAV_WEISS: Yeah. 

AJ_O’NEAL: All right, well, I think we need to start wrapping up here. Is there anything, Amy, you had one question, right? 

AIMEE_KNIGHT: I did. And because I've been in and out, work is kind of on fire today. So I haven't been able to devote as much time as I usually do even though I like desperately wanted to be here today because it's interesting. But have we talked about the advantages of web bundles over native apps? Because as I did kind of join back in, that's something that I'm thinking about. Because I always prefer to use what comes out of the box with the web by default and only add on when I need to. So I'm kind of curious if this changes the game as far as having to do. If I can now consider maybe just building my website and using web bundles over building a native app. 

YOAV_WEISS: So I think that the need for building a native app is not necessarily huge, at least when it comes to capabilities. 

AIMEE_KNIGHT: Yeah. I guess I should have clarified that question a little bit more. I mean, there obviously are still use cases where a native app is going to make sense. But if we're just talking about like, we're talking, like I've been Googling a little bit as I've been joining back in about, you know, like the ability to have like offline support and stuff like that. So do you think like, I guess my question, a better question would be is, do you think this is going to like open up the possibility that I could consider using this instead of a native app more often? 

YOAV_WEISS: So it all depends on the reasons why you wanna build a native app, but for offline support, service workers is a essential primitive that enables offline support on the web, even if AJ really likes AppCache. Web bundles will potentially give you a better way to deliver a service worker-based web app to your customers. Potentially, they will be able to download this as a single file as compared to multiple resources, potentially if combined with sign exchanges it can enable you to host your PWA on an arbitrary server. So post it on a CDN, but your users will know that it's coming from you. And whenever they interact with that app, they will communicate with your server as if it's a same origin server. There are a bunch of use case this opens, but yeah. So on that front, I wouldn't say that this is a game-changer because I think the game is was already changed previously. But I think it can help for a bunch of app-like use cases. 

AIMEE_KNIGHT: That makes sense. And I feel bad. My question kind of came in as I've only been able to participate and listen to 10% of our conversations. But yeah, that makes sense. 

DAN_SHAPPIR: I would like to add on top of what you have said. I think that if you're looking at it from the technical perspective, then there were various friction points or limitations around web applications that kind of in certain scenarios forced you to use native applications instead. And I think that the web bundles mechanism that we were talking about today is one more technical restriction or limitation that is being removed. Another one by the way- 

AIMEE_KNIGHT: That makes good sense, thank you. 

DAN_SHAPPIR: Yeah, another one by the way that we'll be talking about in the future with another Googler is about Project Fugu which provides all sorts of APIs and capabilities that have previously been associated just with native applications. But there are other reasons that people build native applications except that there are marketing reasons that people build native applications because it's really important for marketing to have a presence on your device and send push notifications. And currently, at least on iOS, the only way to do that is with a native app. 

AIMEE_KNIGHT: Yeah, that makes sense.

DAN_SHAPPIR: With iOS 14, it looks like it's going to stay that way for a while. 

AIMEE_KNIGHT: I've been off the Twitter's too a good bit, so I don't quite know exactly what's going on there, but I know something is. 

DAN_SHAPPIR: Yeah, it's more of the same, more or less, on the web front, unfortunately. 

YOAV_WEISS: Yeah, WebP support is exciting, though. 

DAN_SHAPPIR: Yeah, but it's just exciting in that it should have been there years ago. 

YOAV_WEISS: I don't disagree.

AJ_O’NEAL: Anyway. Well, I, I'm not even going to ask that question. All right. We're, we're at time. So let us rapidly wrap, wrap up. You have, did I say your name correctly this entire time at all? 

YOAV_WEISS: Yeah. 

AJ_O’NEAL: Okay. Good. 

YOAV_WEISS: All good. 

 

Are you freelancing or mood lining, or maybe you've thought about going out on your own every week? We have a group of developers at various stages of a freelancing journey on the freelancer show to talk about becoming better at freelancing. We also bring in experts to talk about marketing SEO and delivering high quality to clients. So if you're interested in going freelance or you are freelance, check it out at freelancershow.com. 

 

AJ_O’NEAL: Do you know about picks? Did that get explained or shall one of us go first? One of us will go first. You'll get what it is. We just pick stuff. All right. I'm going to, I'm going to do like raise hands. Who's ready? 

DAN_SHAPPIR: I've got a pick. 

AJ_O’NEAL: All right. Pick it. 

DAN_SHAPPIR: Okay. So I just have just one pick this time and the pick is a Charlie Gerard. Charlie, who I had the pleasure to meet at conferences, is a web developer that does amazing things with AI and web-enabled devices and stuff like that. So she just does websites that you control with hand motion and gestures, or even with your mind. She recently built an application where you could zoom in on using by raising one eyebrow and then zoom out using the other and weird stuff like that. And just like today or something like that, Apple is in the conference, announced this amazing application for the Apple Watch that basically notices that you're washing your hands and then starts counting down for you for 20 seconds to make sure that you're washing your hands long enough apparently really important, people don't know how to count down from 20 these days. So she just went ahead and implemented something similar just using web technologies and using ML to detect the sound of running water and trigger the countdown. So it's literally a web application that listens to the the speaker and if it identifies the sound of running water it starts counting down. It's really cool that she's been able to do that on the web. I'll share a link to the tweet where she announced it. But if you're looking at that tweet, I highly recommend following her on Twitter and also looking for her talks on YouTube because she's just amazing. So that would be my pick for today. 

STEVE_EDWARDS: Now, I already had an app on my watch. I call it a clock. Either that or there's the hardware one that I wear on my wrist called a watch. You're maybe I'm too old school for something like that. 

AJ_O’NEAL: That is kind of weird, Steve. I don't, I mean, what are we living in like 2015 or something? 

STEVE_EDWARDS: Yeah. I was going to say that's so 2018, I guess. 

DAN_SHAPPIR: So, so basically you're also going to tell me that you use your smartphone to actually make calls. 

STEVE_EDWARDS: Yeah. I wasn't going to admit that, but I might as well admit that here on the air that yes, I do use my phone for calls. 

AJ_O’NEAL: Smartphones make calls. I got to figure out how to do that on mine. I thought it was just for like video chat. Oh, who knew?

DAN_SHAPPIR: and Facebook. 

AJ_O’NEAL: So Steve, you want to go next? 

STEVE_EDWARDS: Certainly, since I contributed so much to this episode. 

AJ_O’NEAL: Lurker! 

STEVE_EDWARDS: I'm going to go with something from the Vue.js community, just because that's where I spend most of my time in the JavaScript world. And that is with the most recent release of Nuxt, which is 2.13, they have a full static mode that previously has not been able. So you could do if you ran Nux Generate, it wasn't truly a static mode because you would still have to call fetch or async data to get your data from wherever you're getting your data as compared to just pre-rendering an entire set of HTML files and distributing that like a Gatsby site. So with 2.13 which was just recently released, they have a full static mode and you have a target option that you set and it generates everything as full static HTML that you can deploy. As you see, Fed, I know that's something that's been working on. They've been working on for a while on views on view. I think last week we interviewed Debbie O'Brien, who's the head of education for the Nuxt organization. And she was definitely very excited about that release. And I know a lot of people are. So anyway, that's my pick. 

DAN_SHAPPIR: I think that static site generators are really an excellent progression in the web. We are looking at wix of applying essentially the same pattern as well. It's, it's just the right thing to do in so many cases. 

AJ_O’NEAL: Gem stack. 

DAN_SHAPPIR: Yeah. Yes. Gem stack. Exactly. 

AJ_O’NEAL: All right. We're going to Amy. 

AIMEE_KNIGHT: So my pick is something that looks really good actually. And I'm going to start digging into some of this already bookmarked a bunch of the links because I like to watch like YouTube videos and stuff while I'm kind of getting ready in the morning. So I've bookmarked some of the networking ones, but it is a website called teachyourselfcs.com. And I thought about sharing this on Twitter, but the person who created the site, some of his thoughts seem to be like they could be a little bit controversial. So I decided otherwise, and I'll just share it here instead. But I personally like kind of the sentiment behind his opening, which is that he is categorizing developers into two types, type one and type two. And for the type ones who don't have a traditional CS degree, you know, he kind of says, you know, you in order to really have a fulfilling career, it kind of like behooves you to learn computer science. If you come from a bootcamp background and stuff like that, just because, and like this is computer science, but it gets into networking and all kinds of other stuff. But you know, you're able to, I think debug at a lower level and not just kind of, you know, cough things up to magic. You actually understand what's going on. 

AJ_O’NEAL: This is very controversial, Amy. We're gonna get a lot of blow back on this. You should teach yourself your craft. 

AIMEE_KNIGHT: Dare I say, but you know, I think, I will say, I think there's room, you know, there's a, there's a wide continuum of people and their progression within their career. But I really do like the way that he phrased that. I think understanding your craft at a lower level like this, for at least me, does make it very rewarding and fulfilling. And not only he potentially will be paid more and all of that, then maybe that's a motivator for some people. But it looks like there's some super solid content in here. He breaks it up into programming architecture algorithms and data structures mathematics operating systems networking databases compilers Distributed systems all kinds of stuff. So that'll be my pick for today. 

AJ_O’NEAL: That is freaking awesome. I'm looking at the site right now 

AIMEE_KNIGHT: Yeah, it's got like textbooks and YouTube channels and stuff like that different courses 

AJ_O’NEAL: All right, I'll go next so we can save the best for last. Don't disappoint us. I'm gonna pick So for you know, a lot of us we know of the Beatles we know, you know the that the number one hits. But we don't get the Beatles because we didn't grow up with the Beatles. Like we know that they're important. We know that they're influential. You hear me talk all the time about musics, particularly VGM. But today I'm picking an album from the Beatles, Abbey Road. And the reason that I'm picking this, the first Beatle albums that I got, cause I like albums. I like being able to hear something from start to finish and kind of get a sense of the progression or what the artist was trying to convey. And you don't get that with the number one hits. You get that by listening to an album. And my first album, cause I Googled what's the best Beatles album. And everybody pretty much unanimously agrees Dr. Sgt. Pepper's Lonely Hearts Club Band, which gosh, I can't believe I said that right. That's gonna be the first time I've ever said it right that quickly. But it's not a good album to get started with the Beatles. Cause you listen to it and it's kind of like, eh. You kind of have to already be familiar with the Beatles, I think in order to appreciate that. So I did another Google search. What's the best album to start with the Beatles? And Abbey Road, and there was another one, I think it was the White Album. I don't remember for certain, but Abbey Road and one other album were kind of like, everybody was saying one of these two, because it's a little earlier on, you get a feel for kind of their progression. Before the long name one that I just mentioned that I won't dare to try to say again, because I'll get it wrong where it's kind of their sharp turn, where they do lots of weird stuff. That's why people like it, was a kind of break and fresh and changed some of the sound. But Abbey Road is really refreshing. It has a lot of dynamic range, which is something you just don't get in music today. The opposite of dynamic range would be punk music, where every instrument is exactly the same volume and most pop music today. Abbey Road is almost startling with the amount of space between sounds. So I put it in my car and started driving with it and I was just blown away by the dynamic range and a lot of their good songs that you're familiar with. So if you are not really clear on why the Beatles are important or you're just one of those music type people that hasn't gotten into it yet to understand the context of how we got to where we are and obviously the Beatles were an important part of that, I'm going to recommend that you get a copy of Abbey Road and I got the copy I got I don't believe is remastered and typically you want to stay away from remastered because remastered means dynamic range has been removed and the album has been compressed so that everything is normalized with the same volume throughout the album and especially when you're listening to music that wasn't intended to be listened to that way such as the Beatles you want to avoid remastered albums if you can and this one might be remastered but it's not the one that specifically says remastered. And I definitely can tell that there's a lot of dynamic range in it. So that's, uh, that's my pick. And I linked to this specific exact one that I got. And then I'm also going to pick Dino, which some people mistakenly called deno. But if it's Dino dot land, it's obviously Dino and it's got a dinosaur for its logo. So it's obviously Dino. Everyone who says deno is wrong except for, I will accept the argument that node.split.sort.join would produce a word that sounds like deno, but deno.land and the dinosaur logo mean that it's actually Deno. It's kind of everything that node isn't. It's kind of the opposite of node, but the same as node. It's TypeScript. So you don't have to deal with all the garbage and the babble. And like, it's just TypeScript. And as much as I've railed against TypeScript as JavaScript, TypeScript as its own language with its own thing, I think is good. And you don't have to deal with a million different bundle systems. It's just its own thing. And that makes it beautiful. It's got an Achilles heel, which is that it doesn't have any sort of package management. In fact, the people that are maintaining it fight against the idea of package management. That makes me kind of want to shoot myself in the head because it's like for everything that it's good at. They may have just destroyed it completely by ignoring, you know, get that we've had for the fat past, what, 10 years now that is obviously the right solution. I mean, the way that go packages work is just phenomenal. Rust packages are just, you know, one tiny pinprick below-go packages. And for them to come in and say, no, we just kind of wanted to be screwed up. And everything has to be web URLs. I just I'm a little confused about that. I hope that they come to their senses because I think that Dino could be something really awesome and could just blow node out of the water by giving people what they want. A language that isn't TypeScript, that's kind of fluidish like JavaScript, or a language that isn't JavaScript, that's kind of fluidish like JavaScript, but that's opinionated and doesn't have a million different transpilers battling against each other to make it uber complicated. It's like, it's simple. It's well-defined, you can bundle things into distributable binaries. I won't go on more about it because I've already wasted like half an hour here. Uh, but Dino's great. So check it out. 

DAN_SHAPPIR: Before, before we move to you Av, I just wanted to make, to make two comments about your, both your picks. So I'll actually start, I'll make it really brief. So with regard to, to Dino, I agree with, with most everything you said. I just want to mention in case it's not clear that you can use type, that Dino does have native support for TypeScript, but it also has native support for JavaScript. So if somebody prefers to continue using JavaScript- 

AJ_O’NEAL: Just stop, stop, stop, stop, because then people are going to use CoffeeScript and they're going to use JSX, and then the whole thing is going to fall apart and it's going to be worthless. Let it be TypeScript, just let it be. 

DAN_SHAPPIR: I still had to say that, so that's one thing. And the other thing that I actually wanted to say in the show today, and it kind of slipped my memory, is that- The web bundles that we were talking about today in the context of the browser could be really interesting in the context of Dino as well. And I'd probably recommend to you all to talk with the Dino people about this. And about the Beatles, which you talked about before, I'm going to share a link to a YouTube video for those of you who are familiar somewhat with the Beatles but want to get a greater appreciation for it. So it's a composer, Howard Goodall, I hope I'm saying his name correctly, did an amazing show in which he kind of analyzed Beatles music. And he literally claims that the Beatles kind of saved music, as it were, that music was like adding, it was kind of the sort of a dead end. And along came the Beatles and literally saved music. And it's a really, it's an excellent program. And I highly recommend watching it the link to the video on YouTube, highly recommended. 

STEVE_EDWARDS: So just to clarify, now the Beatles were Robert Plant and John Bonham in that group, right? 

DAN_SHAPPIR: Ha ha ha ha. This way I don't take away from the amazing achievements of Led Zeppelin, but- Oh, Led Zeppelin, sorry. 

STEVE_EDWARDS: I get them all mixed up, all those British rockers. 

DAN_SHAPPIR: Yeah, but they were influenced by the Beatles. So he's not saying that the Beatles are like the be all and all, but he's saying that the Beatles put music on the right path that a lot of bands came afterward and kept the ball rolling. 

AJ_O’NEAL: I would love to know, I wanna learn more about who influenced the Beatles, but when you listen to Abbey Road, you can hear a little bit of where Jimi Hendrix came from. You can hear a little bit of where, I forget some of the other ones, but there's definite artists where I could hear, this must have come either from the Beatles or from wherever the Beatles got it from. This style of music is permeating. 

DAN_SHAPPIR: So listen to, do watch the show that I provided the link for because he also talks about that, about the Beatles own influences. 

AJ_O’NEAL: I will, I absolutely will. 

DAN_SHAPPIR: With classical music and stuff like that. Anyway, that was my interruption, so I'm done. 

AJ_O’NEAL: That was awesome. All right. You ready? 

YOAV_WEISS: I guess. Yeah, so I didn't really prep for this. 

AJ_O’NEAL: That's why we gave you lots of time. 

YOAV_WEISS: Lots of time. 

AJ_O’NEAL: Yeah, that is.

YOAV_WEISS: That is true. So my pick would be a recent addition to the web, a recent shift in Chromium for now, but hopefully will be adopted by more browsers soon, which is scroll to text. So for me, this is the first time in 20 years that we are modifying or extending URLs. One of my own personal pet peeves is that when linking to various documents and blog posts, they don't always have the part of the article or the part of the blog post that I want to link to doesn't necessarily always have an ID attached to it, or it doesn't have a way. The HTML doesn't always have a way for me to link directly to part of the article. So if I wanted link to a specific point. In some cases, if the HTML is, you know, it was written by someone else and I'm out of luck, I can't link to this specific piece, I have to tell people, here's the article, go find this. And scroll to text, essentially fix that by enabling us to add the specific text that we want to link to as part of the URL itself. So there's a weird in order for that to be web compatible. So there is a squiggly line and equal signs and whatnot. But eventually, you can just, like, there is an extension that enables you to specific text that you want on a blog post. And then you can share a link directly to that. So currently, that just works in Chrome. But for other browsers, it just falls back to the original URL. And they just go to the article itself. And hopefully, other browsers will also adopt that and will enable in-document linking on the web at large. 

DAN_SHAPPIR: I recently experienced this. I forget in what context, but it was kind of surprising. I mean, I clicked a link and it skipped to the middle of an article and then highlighted the relevant text in the article. Like I said, oh, OK. I know that there was a little bit of a controversy around this feature, though. I know that some people didn't like it. Although some people don't like anything, but... 

YOAV_WEISS: Yeah, so URLs are a fundamental part of the web. And when you're extending that, yeah, there was some initial pushback that essentially resulted in changes to the proposal to make it more compatible with web content and with what other browsers are doing. So yes, there was slight controversy around that, but I believe it was... Yeah. In my view, it's a feature that advances a fundamental part of the web. 

DAN_SHAPPIR: Can you use a regular expression as part of the search? 

YOAV_WEISS: Not at the moment. Theoretically. 

DAN_SHAPPIR: Because I'm thinking like a developer. 

YOAV_WEISS: Yes. So theoretically I could see something like that possible other than the fact that regexes are like infinitely hard to compute. So I would like, I wouldn't want to use regex, but maybe there are like maybe there's room for patterns that are you know cheaper to compute than regex. So yeah that's that's it for me. 

AJ_O’NEAL: Alrighty well thank you for coming on the show today. I learned a lot. I think we all learned a lot, though I don't want to speak for everyone else, but I assume they're just as stupid as I am as well as our listeners, so they must have learned a lot. 

DAN_SHAPPIR: You hang up AJ, so you have. How do we how do people contact you? Oh yes! If people want to like get involved in this emerging standard or they just want to talk to you in general, what's the best way to contact you? 

YOAV_WEISS: So I'm on Twitter at joavice. So as well, I guess, yeah, that's the best way to grab my attention. I'm drumming an email, so email is probably not a good avenue, as I think you understood in our recent exchanges. 

DAN_SHAPPIR: I was really offended. 

YOAV_WEISS: Yeah. So yeah, just Twitter at your eyes and feel free to ping me like either like publicly or DMs. And I'm happy to help with anything web performance related and like Chrome in general. 

AJ_O’NEAL: Awesome. Well, again, thank you for coming on the show. It's been such a pleasure. I wish we could have had more time. Perhaps we can get you on the show once again to talk more because I think there's just so much to go over there and with that Adios 

YOAV_WEISS: Thanks for having me. 

DAN_SHAPPIR: Bye. 

YOAV_WEISS: Bye 

 

Cheers bandwidth for this segment is provided by cashfly the world's fastest CDN deliver your content fast with cashfly visit Cache EFL y.com to learn more