It's July 3rd, which means that an exciting new standards document has just been published by the folks at Ecma International. That's right, the 21st edition of ECMA-74: Measurement of Airborne Noise emitted by Information Technology and Telecommunications Equipment is finally here — and if you thought the 20th edition was a banger, man oh man, just wait until you see this one.
Let's see; what else is going on? What else, what else. Oh, welcome back to the JavaScript for Everyone newsletter, by the way.
Aw, no — no, c'mon, don't go! I didn't forget! I would never forget this, the most wonderful time of the year. In fact, why, look there, just outside; gleaming in the summer sun and adorned with a comically oversized bow! It is not some lousy car, the purchase of which I neglected to discuss with the rest of my household — it's the brand new 2025 ECMAScript specification!
Yes, as happens every June, since 2016, the latest edition of the ECMAScript standard was formally published just a few short days ago. If you're not familiar with the link between "ECMAScript" and JavaScript, the short version is that ECMAScript is the open and standardized scripting language that informs implementations of our very own JavaScript. A feature added to the ECMAScript standard is a feature added to JavaScript. Why? Well, the legal-eyed among you might notice that "ECMAScript" is a name notably free from any licensing baggage — "JavaScript," historically speaking, not so much. It's a whole thing.
There are a couple of exciting new additions in this one — new helper methods for working with iterators, sets, and promises, for example — but the addition I've been following the most closely is import attributes.
You might be familiar with the concept of using import to import non-JavaScript assets like CSS or JSON, especially if you've worked with a bundler like Webpack, or even RequireJS way back in the day.
import newsletters from './newsletters.json';
There’s a problem with this, though. As anybody that has downloaded a JPEG that was secretly a WebP can attest: file extensions don't necessarily speak to the contents of a file, and Media types (formerly and still very commonly called "MIME types") are a mutable thing. There's nothing stopping that newsletters.json file from being served up as real-deal JavaScript, leaving you potentially importing executable code. For all we know, newsletters.json could be served up with a Content-Type: text/javascript; charset=utf-8 HTTP header and contain:
export default (function () {
document.querySelector('body').style.transform = 'rotate(180deg)';
/* lol; lmao */
})();
So to address this at the language level ES2025 introduces import type attributes. Just like it says on the tin, type provides you with something akin to TypeScript-style type checking for imported files — it allows you to explicitly declare that the imported file must have a given Media type and tells JavaScript how to handle that file's contents:
import newsletters from './newsletters.json' with { type: 'json' };
/*
result:
Failed to load module script: Expected a
JSON module script but the server responded
with a MIME type of "application/javascript".
Strict MIME type checking is enforced for
module scripts per HTML spec.
*/
There's a pretty good chance you've seen this syntax in use already, despite not being final-final until last week. Browsers try to play a few moves ahead of the standards process in order to gauge developer interest and nail down the kind of gritty specification details that can only come from putting a feature to use in the real world. The downside is that those pre-standard implementations will evolve and change alongside the specification work, which is why you might have seen a similar syntax using the assert keyword instead of with to accomplish the same thing. The assert syntax didn't end up making the final cut.
So far type attributes only apply to JSON modules — arguably the most common use case. Once the dust has settled on the feature itself, we'll potentially be able to make use of this new pattern for all manner of files: CSS, SVG, fonts, maybe RealAudio files if Santa got my letter. The sky will eventually be the limit.
Now, some of you, I know, have been reading this newsletter with jaw set and eyes wide with panic. "How will this new specification — these alterations to to the very fibre of JavaScript itself — impact your course writing," you wail to your inbox. You fall to your knees, the anguish simply too much to bear. "Won't you have to go back and change a bunch of stuff?"
No, do not cry for me, fair reader! For I am once again shielded by the concept of "One JavaScript," which we touched on briefly in the last newsletter:
[JavaScript] makes sense for something that can be infinitely expanded, but cannot, per a principle known as "One JavaScript," be changed or fixed. —JavaScript for Everyone Newsletter #4 - We're Gonna Get Weird
You better believe I’ll be including some of the latest additions to the language in the course, but that doesn't mean I'll also have to comb through the latest version of the specification to see if they fixed, I dunno, math. JavaScript will continue to grow more powerful and more featured over time, but what's done will never be undone. That's good news for instructor and student alike: anything you learn will always be a part of the platform, from janky old var to — officially, as of last week — type attributes.