 There's a white dot on the screen. No, I don't know what that was. Make it nice and clean, or shiny. So. So. So. So. Oh, I didn't do so in my episode. You didn't? Missed that, talking about sprays. I'm rusty. Yeah. Rusty. All right. Look at this. Look at that. Recognize that? That's an import. It's an import. But MGS, look at you. All right, I know. Well, I know every time I do this and I don't put MGS, Matthias will just appear behind me next time I'm at the mirror. I know Andrea will appear and tell you that MGS is wrong. Look, I'm not getting into MGS versus JS. That's not the point of this. Because what I actually want to talk about is all of these things. Oh, many imports. Many, that's not real. Of different things. Well, that's the thing. Yeah, if you've used a build script before, you've probably done something like this. Oh, yeah. You definitely have, right? You've got all of this stuff. Yeah. But I show these ones specifically because all of these have web standards behind them in either progress or whatever. Yes. The data one, this JSON one is particularly interesting because this went into the HTML spec. It actually got merged. And then bugs got created for all the browser to implement. And then they all got closed and it got reverted. And that's what I want to talk about. That's interesting. Yeah. So. Wait, that's just quickly for the people who don't know because I actually don't know some of this. So WebAssembly is working on making them importable. And then Wazm would just be, in instance, off of WebAssembly module. I assume so. That's the one I know the least about. CSS. That's the very controversially named CSS modules. CSS modules, yeah. Which will give you a style sheet? Style sheet object, I think, or something like that. Yeah, it's an object that you would be able to put into a shadow DOM or the regular DOM. And then it'll apply the styles. It won't be applying the styles by default. HTML will give you, from this, I would assume, a document? A document. So that's very much up in the air. I think it will just be a natural document. This is the HTML modules proposal. Yes. And it's very much up in the air, but there's talk about if that HTML file has a script of type module and it exports things, then it will be named exports in there as well. It's kind of fancy. Interesting. Very much in progress. Jason, I guess, would give you whatever JSON.Pars would give you. Absolutely. All right, cool. Let's move on. So the idea is to enable something like this, where, oh, time zone data is something we've looked at recently, is finding out which time zone a particular country is in. That's something you don't want to be maintaining yourself. And then we go to example.com. Example.com, the best location for all time zone data, presumably maybe, I don't know. But when you import something from another website, there's a lot of things you need to consider, security-wise. Yeah, and generally, the only time I personally ever use third-party imports is prototyping, and I import from unpackage. Yeah, I've done stuff with Flickr API before. Oh, that's absolutely legit. Yeah, once you work with API, it's actually pretty common to do stuff like this. And so once you're using an import like this, if this fails to pass, or if it fails to connect, or if it fails a cause check, or DNS, blah, blah, blah. Yeah, your whole graph is gone. The entire module just will not run. Exactly. The static imports have to succeed, right? Yes, all static imports have to work before the whole JavaScript file will work. So yeah, that would be a problem. Slightly worse would be if the server hangs. It just takes forever here. Because then the user's just looking at a spinner. At best. At best, yeah. I mean, it would be a browser-level spinner if this is a script tag in your document. That's true. So yeah, that would be a shame. So I would always say, if you're going to do this, you would actually want to use dynamic input. Because then you can handle errors yourself and all of that sort of stuff, or provide a timeout. Something like that. Other things to consider is it could come back with valid JSON, but in a completely different structure to what you're ready for. Yeah, that's all. Yeah, I guess if they just update their API and be like, oh, we have this new format, it's much better, and your code doesn't know about it. Screw you. Off you go. You could validate stuff you could do. Because at some point, you have to have some trust in the other service. But, and this is where all the problems started, is this piece of code you're putting more trust into example.com than it looks like? OK. So this is being treated as JSON. Not because it ends in .json, but because it has this content. Right, because file extensions are pretty much meaningless on the web. Yes, apparently there is, I think, in the object tag. It pays a, like, do you remember the object tag? Yes, that's what. How to do fashion vets and stuff. I think there's code in that that relies on extensions. But other than that, yes, you're right. The web does not really do extensions at all. But this means that the server is in charge of how this file will be processed. Yes. And if at some point they go evil, they could just change that. Now, you bet code will be executed instead of just JSON parsed. That's not good. And it could be a while before you realize what was happening, because it could still be returning data, valid data. But it's now maybe looking into your DOM, finding out stuff about the user, reading all your storage, posting it somewhere else. They can do everything that JavaScript can do. Yeah, that's no. Yes. Yeah, so this is what happened. And everyone went, that's not great. With this example specifically, I thought about CSP. Like, you could say that I'm going to add a hash of whatever I expect to receive. But at that point, with time zone data, I could imagine that actually hash is not really that useful, because that might become about the summer time happens, or winter time happens. But yeah, that's a good point. There has been talk about trying to work around this with CSP. So you could look down the content. But even if the content doesn't change, maybe the situations where the content can say the same, the content type changes, and it is still valid. It's valid of both. Like these images who are also a zip file, if you just change them to .zip. Exactly like that. And that would be true for CSS, for CSS especially, because CSS has so much error correction. It's very easy for it to then be valid in another language, because you could just manipulate comments. This is scary. It is scary. So this has been shelved, essentially. This has been put on ice. But only the other ones are still fine. Jason's on ice, because Jason, which, so part of the problem here is the whole reason Jason was invented is because people were just including JavaScript to do the same thing. And it was, well, this is bad that it can execute code. We don't want that. We just want the data. So Jason was invented to just provide the data. And then this comes along and makes it entirely redundant, because it can now provide the data or execute loads of script. So yeah, they were like, well, that's a problem. But it's the same problem also true for CSS. The same problem is true also for CSS. Yes, absolutely. So that one is also on ice. So shelved off. It's all not happening. Well, we're unsure about HTML, because it's unclear whether, if you import an HTML module, if it can execute top-level script or not, that's still up in the air. Because if it can, shelved. Well, it's not getting a new superpower by changing from HTML to JavaScript. It can already execute JavaScript. Yeah, I guess. So that, and Wasm, I'm not sure about, because I couldn't figure this out just by looking at the standard. Well, WebAssembly is different in the sense that it will be able to run code, because WebAssembly can have a start function that runs on an instantiation automatically. Yes. But it doesn't have access to anything. But it might in the future, or is that? Yeah, it might in the future. I'm not sure, because the part of this ES6 module proposal is that not only can you import Wasm, but Wasm can import other files. And whatever those files export, it now can call. So it can import a JavaScript file. Which would then be executing an access your DOM. So that might be fine, then, because it already has those superpowers. It's not a problem. So yeah, we need to solve this problem somehow. And the problem we need to solve is that it's the other server which decides how this should be processed. And that shouldn't be, like, if you're already expecting execution to happen, that's fine. But if the server can suddenly turn something that wasn't executable into something that gets executed, that's the part that's dangerous. Yes, because that's completely different from how the most of the web platform operates, like, image tag. This is you, as the developer, saying, I want this to be treated as an image. And so if it's JavaScript, it doesn't run. Now, there's some wiggle room, like, even though this says .png, it could return jpeg svg. Content type is the only thing that matters. Actually, with images, we don't use content type. It's just sniffed the stuff. Oh, just sniff it. We might with SVG, I'm not sure. Might use content type. Well, so the thing is SVGs can contain script tags. But I think in an image tag, they're ignored. They're ignored. Yes, there's loads of SVG stuff that doesn't work in an image tag. So script is one. The other one is, like, anything that would fetch. Because you can't include an image from another URL. Can't include an image. Can't include a style sheet. Unless it's, like, a data URL. Data URL is probably fine. Yeah, I think if it's all in the same thing, then that's fine. You can still animate. Oh, yeah. Yeah, but otherwise, you're saying image, you get an image, or it fails. So the chat is, like, can we bring that to this proposal? And so this is all very much up in the air right now. Because everyone had gone forward with these proposals, and they went, uh-oh. So they've gone back to the start. But this is the sort of thing being talked about. It's, like, do we get something in syntax? So it's, like, import this as JSON. Yeah, that kind of makes sense to me. You're back in control. And then there's this one which links a little bit to what we were talking about, import maps. Yeah, I like this. This is taking the import scheme, but then plus JSON. Yeah. And so it's. I mean, it now has two schemes, like the import scheme and JSON. I'm not too happy about these specific syntax, but I like that they're just putting it into the, like, it's a special import because, yeah, I like that. Because this will then automatically, I guess, also carry over to dynamic import without changing the syntax of dynamic import. You would just still have, yeah. Exactly. That's a good point, actually. I don't know how dynamic import would work with this as JSON thing, whereas this would just work. Because it's not the function, right? Or the second parameter of not looking. Which would be a syntax change to the language. And maybe this would even carry over to fetch. Who knows? Interesting. That's a good point. Whereas, yeah, there is some precedent in the browser about this, because we have the view source. Oh, yeah, that's true. Scheme-ish, where you'd have that, and then HTTPS. And then on, and it's saying, interpret this resource in a different way. So there's some examples there. Is it actually standardized? Is it just like a? I think it's just something all browsers do. Like a convention that magically everyone is adhering to. Yeah, I think so. I think so. So this got me thinking about a bugbear I have with build scripts. And I think you shared the same bugbear. I think we have a talk about it, didn't we? Have we talked about it on the show before? No, didn't we give a talk about it? Oh, yeah, we gave a whole talk about it. We probably mentioned it on the show as well. And it's something like this. When I see this in a project, I look at it, and it's like, I don't know what's going to happen there. What is the something? I mean, now that it's a web standard, an emerging one, kind of, but sometimes people import an image, or a text file, or something that is not even a real fun. You're like, what's happening here? Well, the web standard says something would be one of these style sheet objects, whereas it's quite typical for it to be a CSS module. The other kind of CSS module, let the web pack variety, where this would be a map of class names to minify class names. And then it would just insert the, it's going to do some stuff. But to find that out, you're going to have to go into the build config, you're going to have to look through it. And sometimes it's like, oh, extensions like this, do this. Sometimes it's like extensions like this, but in this directory, do this. And then later don't accept if it's an import with this extension, but in this folder, then a completely different rule matches. Like there's, it can get really, really bonkers. Absolutely. And yeah, I don't like that. Because especially if this was like a .javascript, like a .js file, but in a particular directory, it's going to do something different. Or for a particular file, it does something different. Because, well, there's two problems there. One, it's not obvious. And two, if for some reason that part of the build script stops working, it's going to import it as JavaScript. Like the fall back is valid. The build is not actually going to fail, necessarily. But it might do something completely wrong when you actually run the code. And take forever to figure out. So I actually quite liked this webpack syntax. Or, well, I like the capability of you. The approach. Yeah. Yeah, because I see that. And I go, that's not normal. If this gets pushed to production like this, it will just fail. Because this is not a valid import per se. And failure is the right thing here. Yeah. Because it's not being processed. So it should fail early. It shouldn't maybe work somehow, I don't know. And they even allow it to be chained. And there's options here. So this is saying CSS loader, but modules are true. I mean, it does get unwieldy. Yes, it does. But I see that it's nice to be able to look at a JavaScript file, look at the import, and just from looking at the import, you can kind of deduce what the thing that is being imported actually will contain. Absolutely. And so we did a similar thing, didn't we? We did a similar thing. In rollup, we would make sure everything had a kind of weird scheme. And that's what would be picked up. And so yes, again, if this wasn't processed, it would fail early. Because it would just be like, this is not a URL. And the whole thing would just break. So I was really fascinated to see this sort of happen. Maybe we were trans-sensors. Yeah, we were. We're going to link to our talk in the description, because that's how this whole thing got started, obviously. Yeah, absolutely. So yeah, I think there's a real opportunity here. And I know Parcel, the other one that I've not mentioned yet, they're looking at something like this. They've been looking at special extensions, query string, a special scheme, some way of doing this. And it's come at just the right time for them, this whole thing, where we might actually need something standard in the language to save. If the tools can piggyback off the standardized way of encoding these kind of options into the import string, that would be great. Exactly, so what started as a kind of security oversight that just put the brakes on the loader specifications might actually turn out to be something that brings together both build tools and web tools. That's great. This whole thing got me thinking about build scripts in a bugbear that I have of build scripts, and I think you share it. Yeah. Shall I repeat that? Oh, we probably did we trigger OK Google? Amazing.