Navigating the Wild Seas of Native ES Modules by Gil Tayar | JSConf.Asia 2019

Subtitles section Play video

Nativ E s modules.
This is what I'm gonna talk about.
But first, 1st 1st make it work.
There we go.
So, um, I'm I go way back to the eighties.
Um, I tried the whole startup.
See, Theo thing didn't work out.
I'm probably gonna die a developer.
Ah, coding till the last minute.
Uh, testing the code is a passion of head since, like forever, Like 20 years.
I test everything I write.
How many people?
The right tests for the code.
Okay.
How many people write this for their CSS?
See, if you want to learn about it, come talk to me about Apple.
It'll zap.
It was all about visual testing.
We have a booth come over.
It will be interesting.
Ah, but I'm not here to talk about visual testing.
I'm here to make things work.
Okay, I'll stick here.
But before that surprise, Um, that's me.
The little baby.
That's my dad.
And in the background.
Would you know what that is at Singapore?
I was born here.
Yeah, uh, 50 years ago.
Who my age?
Yeah.
Uh, so it's an amazing experience for me.
I got here yesterday.
I just walked around and Oh, my God.
This this is this is this is home.
Just the last one.
My mother and me And I don't know, You probably recognize the pool.
It's probably very changed.
So Yeah, I'm home.
Thank you for having me Native Years modules.
Just a reminder for those of us who haven't used yes modules.
Ah, it's the export import thing where if you're exporting, you have a module, a file, and you export a function or export of value or whatever.
And then in another module, you import it using that syntax.
That is what I talk about when I'm saying e s modules.
Okay, so everybody's on board.
Most front, and developers know what that is.
Because Web packing and all those bundlers back in people less okay, what are native?
Yes, modules.
Um, the way I define it is yes, code that, you know, just works without without any, any problem.
And I'll explain that because back in 2015 I gave a talk.
It was called navigating the wild seas of US modules.
And I had to explain stuff like the syntax which isn't He doesn't need to be explained today.
Default, export transpiration.
The whole idea of Babel wasn't really used back then.
Not to mention bungling the idea of taking all that JavaScript code and bundling it into one file.
This whole idea was very knew.
I had to explain it.
And everything we take for granted today was needed to be explained.
And today you we all know this intact.
Well, almost all of you Transpiration is a given.
Everybody uses Bar Bell in the front end and bundling is like, Yeah, all right, all right.
And we forgot something.
We forgot that between 2015 and 2019 we had to go through the value of JavaScript.
Frantic.
Who remembers Javascript?
Fatigue?
There we go.
What's this whole?
You know, the configurations and we're back.
People got confused so much about all that and for the right reasons, it was difficult and still is difficult.
But today it's like, you know where pack, but Belle configuration how nobody sees the problem anymore.
But it's there.
It's not easy.
And native modules is trying to go back to the simpler times.
Yeah, um, trying to go back to the simpler times when we can just refresh the web page, and that's a day work.
No configuration, no web pack, No translation, no.
Nothing we want this much is to just work.
And we want them to work both in the browser and in no Js.
And this talk is exactly about that.
How the path is gonna be.
It's not Carry it and I will.
You will see it.
It's not there.
2019.
We're not there with this modules.
Native Yes, modules.
But I believe somewhere in 2020 and definitely in 2021 we will all be using its modules natively.
So remember me.
Let's you know, come out.
Come back in two years.
Hopefully.
And you will tell me you remember you're on.
That's a plug in for my c f B in two years.
Okay.
Ah, using its modules today we code with this modules were lots of files.
They're all importing and exporting thing.
And we're basically creating a dependency graph off files and modules importing and exporting one another.
And we take that we use wet pack or roll up or any bundler of choice.
We create one big file which we just stripped source that that's what it is today.
No native but believe it or not today, all modern browsers.
Meaning not I eat.
Okay.
No, seriously.
Who hates I, uh, I have to support it in my visual.
Great.
Anyway, all native yes.
Modules, all browsers, all modern browsers use native years marches.
You can just use them without transpiring.
And how do you do that?
First of all, your scriptures, just like any other.
But you don't scripture us a bundle your script just oh, the root of the application ab J as or whatever, but you add type equals module.
First of all, was that what's that type equals module thing, and the answer is, it's a new concept, exactly, not new.
It's from 2015 from East 66 to find two kinds of codes or two kinds of interpretations of JavaScript.
Code one is script.
That's the one we're used to and the others module.
That's the new one, and I'll explain.
Script is not allowed to use import or export.
That's the first thing easy.
And if there are little minor differences, for example, this this in the global scope is window or global or whatever global thing we have, and it's non strict by default.
If you want it to be strict, you add you strict module code is allowed to use import and export.
Obviously it's module code and this is undefined.
No idea why, but that this is true and it's always strict.
By definition, it's strict.
Always.
So Remember that script source ab Js this Israel This is from, Ah, front and testing workshop.
I'm giving I'm using native use motor skills because it's the simplest and I'm doing import controller from dot slash control dot Js and this just works.
Okay, No bundling, no nothing.
Browsers understand that without were packed.
So let's let's talk about that.
First of all, each import we have weakened see three imports here that each of them is a separate.
Http, get there Basically getting the controller dot Js file and there are no border bear specifies you have to start everything either in absolute your l http Collins less less whatever or a relative you're ill dot slash whatever or dot slash folder slash folders left whatever dot Js and you have to specify the extension because that's how Web servers work.
You need to specify the extension.
Okay, that's the three things a each import isn't http get no bear specifies like important low dash or import whatever and you must specify the extension and the execution model is cool.
It's not like today it's asynchronous, So all the loading and the parsing of modules is a synchronous.
It's happening in parallel.
So this is really, really fast and the ink in the sink execution wants the loading and parsing is done.
You first load in parts, everything a synchronously.
And then you start executing the modules that JavaScript and the modules bought him up Today it's synchronous tomorrow.
Once we have top level await.
Hopefully it will be also a synchronous.
But the $1,000,000 question is the question on everyone's mind.
Okay.
Ah, extensions and everything.
Can we take our NPM waistcoat, our Web Pakhoed, which uses imports and just use it in the browser.
And the answer is No, not yet.
Not yet.
Remember 2021 when I'm back here.
Hi, Jane extent.
Why first of all do when we import a relative like import something from dot slash food, Do we add a dodgy s today?
No, the Web packer if we're using note as the Dodgers automatically but in today's world in the browser will we need to add that no bear specifies.
I mean, without bear specifies, without importing packages like low dash and and whatever, we can't really work.
And the last thing is, I have hundreds of yes modules in my in my app.
Http getting each and every one of them that that's a killer.
We will talk about each one of these on how we will deal with them, and part of how we will deal with them is looking to the know Js part.
Uh, let's see how that works in notorious native yes modules in o Js.
And then we'll combine everything in and you'll see the whole picture now.
No chest already has a really good module solution.
Negative if you want.
It's called common, Jess, and it looks like this for all you are front and developers that don't trust back in developers.
I remember that, Uh, don't don't Don't go walking in alleys at night And don't I see her?
Ah, yeah, I've been both, by the way.
So okay, so require it's required uses require syntax.
It's not a sin tax, actually, a function which imports net and Dennis and no note fetch and whatever.
Very, very similar.
The syntax is similar to yes modules, but it isn't okay.
It's, um it's ah, specific to know Jason.
It's called common Js or C Js, in short and sm is yes modules in short.
So it's them and know Js has to take the existing system and slowly migrate to a totally new system, which is similar but not exactly the same, which is really, really tough.
And it's ah, it's Ah, it's a It's a It's a hard call, a tug of war.
Sorry.
It's a tug of war between two things between two goals.
First of all, forward thinking.
I want e s m and no J as we want.
Yes.
Mm.
No, just to be compatible with T c 39 with JavaScript specification, it has to be compatible to the letter.
It can't just do its own thing.
And the other thing it needs to be compatible with browser.
Yes, modules.
Why?
Because the module's working group in Node wants the whole thing toe work together.
Once coded is universal that works both in the browser and in no Js and works seamlessly together So that is one of the goals of no Jess Work modules Working group.
Not ignore what is happening in the browser.
Unfortunately, we need to go the other way.
We want to work well with common Jess, okay?
And we want to be somewhat compatible with the Web pack way of ism, as we've seen *** and browser is them are not the same.
We can't move from one to another, but we want to be somewhat compatible with them so that the migration process works.
Okay, so we have forward thinking gold and backward compatibility goals.
And a lot of times there's a conflict between them and we have to choose.
And, um, it's a discussion.
It's very, very, Ah, controversial.
But usually what its chosen is the forward thinking goals.
This will hamper migration probably.
But in the end, it will.
I think it will benefit everybody.
So let's see what they came up with.
No.
In No.
12 first of all not like require require does the same thing as we're pack.
You don't have to specify the extension so this won't work.
Import something from somewhere won't work.
This is better.
You must specify the extension dot Js But it's not Dodge A s.
It's M j s.
Or as I like to call it the Michael Jackson script.
Yeah, No.
So, yeah, it's actually module JavaScript or whatever J sm was was already taken.
So m Js is the new thing.
First of all, why extensions extensions?
Obviously.
Browser compatibility.
Remember, the goal is brother compatibility.
If browsers say that we need an extension, then we're going that way in No jail.
But why it dot m Js and not doctor?
Yes, because an ear some file is not a script, It's a module.
And it has different way of thinking about the code in there.
And if a editor tool, for example, wants to If let's say it's land, what's the yes Linda File?
It needs to know that this is a module.
This is module code and not script code.
So they decided on a specific stuff extension.
There are other reasons, but in essence, that is the point.
This was like they're idiots back there in the modules working group.
This caused a huge upward.
And we understand that developers love their JavaScript extension and and I understand there's, um there's you know, it's just an extension, but there's an emotion feeling to dodge A s.
I really understand that.
And so they came up in No.
12 with a solution which is type equals module.
So if you have a package a zon with type module in it a field ah, property than all the sm All that package the Js files will be a sam but then they will be on Lee a semi not common Js so you can switch between the two.
You can say I want this to be a regular package common Js Js file is ah common Js or I wanted to be ah Sam in Algiers Or use them So you have this dot m Js is always your Sam is always some code dot c Js is always c j s and dot Js is by default common Js But if we have type module than its is, um, weird.
But it's, you know, like compromise.
Like every compromise, nobody's really happy, which is good, uh, in in in common Js we can and weapon we can do something like import something and special fire directory.
Okay, this doesn't work anymore.
Well, almost If this doesn't work anymore if we have done index dot Js or index dot m Js That doesn't work anymore.
It works on Lee.
If some deer has a package Jason again, browser compatibility and this his bare specifies import something from low dash or from whatever package it is.
Obviously this works.
I mean, if that didn't work, no, no, J s program would work anywhere, but you can't use the index digesting in node module.
So package has to have a package, Jason with the main entry point.
And you can't rely on Index Tartarus.
But you're saying why do we need this whole thing?
Because bear specifies our anyway not backward compatible.
It doesn't really matter.
Whatever we choose in know Js because there are no ah bear specify IRS in in the browser.
Which brings us to yes, they're not specified there yet.
They're currently illegal if you try to put a bear specified in the browser code than it will blow up on dhe given error, but and it works in know Js.
But this was an opportunity finally, for the note people to start influencing the browser people okay for note saying look, we understand Bear.
Specify IRS.
We know how that eco system works.
Let's work with you people and define something that will make bear specifies work in the browser and be no just compatible and what they make.
What they came up with was import maps in war maps are needed on Lee by the browser.
No, Jess doesn't need them yet, but they're needed on Lee brought by the browser.
No.
J s.
If it gets a bear, specify it knows to look in the node modules folder right in the node modules directory.
But browsers don't.
So what you do is and let's look at the bright side.
We have a script type equals module, and it's importing low dash.
For example, that's a bear.
Specify WR two.
For this to work, we need another script type equals import map, which specifies all the imports.
So, for example, you have important moment and import low dash and the import low.
That says, if we're importing a bear, specify rhe than that bear.
Specify that will be the file for that bear.
Specify here.
So the browser looks into that conversion map and knows where.
Which http get to do to bring low dash end.
It's actually makes total sense and very easy.
There's a lot of details around it.
You can go and look import maps on the Web.
It's really interesting and really cool.
It's starting to become implemented in chrome.
Hopefully, other browsers will catch up, and we will have a substandard.
And it is a path to universal yes, modules, modules that work without any change, both in node and the browser.
And we're back, Um, and how will it work?
In node?
The idea is, or for browsers.
The idea is one to N.
P m.
Install or yarn.
Add your module that NPM install or yarn ad will modify an import map in the root of your in the group.
In the root of your ah package.
It will modify the import map so that browsers, a few script source to that import map will know exactly where things are.
So you will npm install your packages and then just import them using native syntax, and then nowhere pack is needed.
You will just refresh, change a file, refresh the page or do heart moderate loading and boom.
Everything works nowhere.
Pack no bundlers whatsoever.
By the way, the N p.
M.
Installed Think that updates the import map.
That's a speculation of mine.
Um so caution here.
So as we've seen, we get used universal native yes, modules.
Meaning knowledge is that we're both in the browser and in NPM land No j s et cetera, without any change.
And this is the most important thing in port maps will allow no Jason browser, Jess browser compatibility with no translation or bundling.
So let's review, um what about the problem of extensions for module files?
Note forces you to write extension.
So the everybody is basically saying when you're importing something or when you requiring something, start adding extensions to that thing because the world is migrating to having the extension in the import.
It may be a bit ugly, but that is the reality.
What about bear?
Specify IRS bear, specify IRS, which was a problem.
Now we have We will have import maps in a year or two.
Ah, and we've solved that problem.
What about http?
Getting everyone of my 100 modules Is that solved?
No.
And the answer here that I call it the black hole problem.
because I'm certain a lot of you have seen this.
Ah, the heaviest object in the universe.
And some of you haven't.
That's nice.
Uh, yeah, no modules is huge.
Um, lots of modules.
First of all, it's not that big because we want the not the deaf dependent you want.
The production dependence is most of the hugeness and note modules is having typescript the bell.
Where Pakis Linden.
All those development tools inside node modules.
It's like in Java.
Every project has the drive, a compiler and the eclipse and whatever development tools are inside.
This is the situation in JavaScript today, so it's not that big, but it's still too big for production.
It's still, like tens of modules, hundreds of modules, too big for production.
If I need to Http, get all of them.
That's a problem.
And I don't have a lot of time, eh?
So I'm not gonna, you know, expand on this.
The solution people thought was gonna happen was http to which allows us to bring a lot of files at with the same time and for the server to push all these files to the browser even before the browser requests them.
Ah, yeah.
Uh, that's better.
But it's not good enough.
There's an article on that I don't wanna I don't wanna talk about that.
Uh, it Sze like I do want to talk about that.
But I'm out of time and the other thing.
And I think the real answer is what is called the Web packages.
Um, solution where packages is upcoming standard which enables us to bundle files as they are as http resource is and give them to the browser and one time fascinating in a subject.
Again, I don't have time.
So wrap up.
I'm getting these signals.
Browsers support only relative press.
And it's lunch.
I know, I know.
Um, node support for relative passages is intentionally browser compatible, so it uses extension and uses m Js.
But if you really what?
Love your jazz used type module in the package.
A son bear Specify IRS.
Are there in node support for bear special fires and browser will becoming hopeful using the import.
My proposal and the black hole problem is a problem now, but it probably will be solved by technology, says http, too.
And we're packages.
So the future is very bright for his modules.
No din browser interoperability without the need for bundlers and France filers.
Simpler times.
People are coming.
Thank you very much.