[Music]
nativist modules this is what I'm gonna
talk about but first first first make it
work there we go
so I'm I go way back to the 80s I tried
the whole startup CTO thing didn't work
out I'm probably gonna die developer
coding till the last minute testing the
code is a passion of had since like
forever like 20 years I test everything
I write how many people the right test
for their code okay how many people
write this for their CSS see if you want
to learn about it come talk to me about
applitools Apple it was all about visual
testing we have a booth come over it'll
be interesting 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 that's me the
little baby that's my dad and in the
background do you know what what that is
that's Singapore I was born here yeah 50
years ago ooh my age so it's an amazing
experience for me I got here yesterday
and just you know walked around it oh my
god 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
nativist modules just a reminder for
those of us who haven't used es modules
it's the export/import thing where if
you're exporting you have a module a
file and you export a function or X
for the value or whatever and then in
another module you import it using that
syntax that is what I talk about when
I'm saying
es modules okay so everybody is on board
most front-end developers know what that
is because web packing and all those
bundlers back in people lists
okay what are native es modules right
the way the way I define it as es 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
es modules and I had to explain stuff
like the syntax which isn't he doesn't
need to be explained today default
export translation the whole idea of
Babel wasn't really used back then not
to mention bundling the idea of taking
all that JavaScript code and bundling it
into one file this whole idea was very
new I had to explain it and everything
we take for granted today was needed to
be explained and today you we all know
the syntax well almost all of you
translation is a given everybody who's
barbel in the front end and bundling is
like yeah right and and and we forgot
something we forgot that between 2015
and 2019 we had to go through the valley
of JavaScript fatigue who remembers
JavaScript fatigue there we go what's
this whole you know the configurations
and webpack 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 we're back
Bob L configuration hell 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 trying to
go back to the simpler times when we can
just refresh the webpage and that's it
work no configuration no web pack no
translation no nothing we want as much
as 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 going to be it's not
there yet and I will you will see it
it's not there 2019 we're not there with
s modules native ES modules but I
believe somewhere in 2020 and definitely
in 2021 we will all be using es modules
natively so you know come I'll come back
in two years hopefully and you will tell
me remember you were wrong that's a plug
in for my CFP in two years okay
using these modules today we code with
es modules we have lots of files they're
all importing and exporting thing and
we're basically creating a dependency
graph of files and modules importing and
exporting one another and we take that
we use webpack or roll-up or any bundler
of choice we create one big file which
we just stripped source but that's what
it is today no native but believe it or
not today all modern browsers
meaning not ie okay seriously who hates
I I have to support it in my visual grid
anyway all native is modules all old
browsers all modern browsers use native
modules you can just use them without
transpiling and how do you do that first
of all your scripture is just like any
other but you don't scriptures a bundle
your scriptures to the root of the
application app J s 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 it's actually not new it's from
2015 from es6 es6 defined 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
for there are little minor differences
for example this the this and 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 index
obviously it's module code and this is
undefined no idea why but this is true
and it's always tricked by definition
it's strict always so remember that
script source app jeaious this is real
this is from a front-end testing
workshop I'm giving I'm using native es
modules kids because it's the simplest
and I'm doing import controller from dot
slash control yes and this just works
okay no bundling no nothing browsers
understand that without web bank so
let's let's talk about that first of all
each import we have so we can see three
imports here that's each of them is a
separate HTTP GET they're basically
getting the controller JS file and there
are no bears specifiers you have to
start everything either in absolute URL
HTTP colon slash whatever or a relative
URL dot slash whatever or dot slash
folder slash folders left whatever dot J
S and you have to specify the extension
because that's how a web servers work
you need to specify the extension okay
that's the three things
h/h import is an HTTP GET no bear
specifiers like import load - 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 asynchronous it's
happening in parallel so this is really
really fast and the ink in the sync the
execution once the loading and parsing
is done you first load and parse
everything asynchronously and then you
start executing the modules that
javascript and the modules bottom up
today it's synchronous tomorrow once we
have top-level await hopefully it will
be also asynchronous but the million
dollar question is the question on
everyone's mind ok extensions and
everything can we take our NPM waistcoat
our web pack code which uses imports and
just use it in the browser and the
answer is nope
not yet not yet remember 2021 when I'm
back here
hyejung extent why first of all do when
we import a relative like imports
something from dot /foo do we added rjs
today no the the web pack or if we're
using node as the dodgiest automatically
but in in today's world in the browser
world we need to add that no bare
specifies I mean without bare specifies
without importing packages like lodash
and and and whatever we can't really
work and the last thing is I have
hundreds of es 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 and how we will deal
with them and part of how we will deal
with them is looking to the nodejs part
let's see how that works
in in node Reyes native is modules in
nodejs 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 areas and it looks
like this for all you front-end
developers that don't trust back-end
developers I remember that don't don't
go walking in alleys at night and I see
her now I've been both by the way so
okay so require it's it's required users
require syntax it's not a syntax
actually a function which imports net
and DNS and node fetch and whatever very
very similar the syntax is similar to es
modules but it isn't okay it's it's
specific to node.js and it's called
common J's or CJ s in short and SM is es
modules in short so yes I mean no 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 a it's a it's a it's a
a tug of war sorry it's a tug of war
between two things between two goals
first of all forward thinking I want es
Eman no Jas we want es mi no J's to be
compatible with tc39 with with
JavaScript's 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 is
modules why because the the modules
working group in node and wants the
whole thing to work together once code
that is universal that works both in the
browser and in nodejs and works
seamlessly together so that is one of
the goals of nodejs 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 GS okay and we want to be
somewhat compatible with the web pack
way of esm as we've seen web pack and
browser ism 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 goals
and backward compatibility goals and a
lot of times there's a conflict between
them and we have to choose and it's a
discussion it's very very controversial
but usually what is chosen is the
forward thinking goes 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 you
know in no.12 first of all not like
require required does the same thing as
web 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 Jas but it's not yes it's MJS or as
I like to call it the michael jackson
script
yeah
so yeah it's actually module JavaScript
or or whatever jsm was was already taken
so MJS is the new thing first of all why
extensions my extensions obviously
browser compatibility remember the goal
is browser compatibility if browsers say
that we need an extension then we're
going that way in node.js but why it dot
MJS and not dodge yes because an ESM
file is not a script it's a module and
it has different way of thinking about
the code in there and if an editor tool
for example wants to yes let's say yes
lint what's this lint the file it needs
to know that this is a margin this is
module code and not script code so they
decided on a specific extension there
are other reasons but in essence that is
the point this was like they're idiots
back there and in the modules working
group this caused a huge uproar and we
understand that developers love their
JavaScript extension and I understand
there's a there's you know it's just an
extension but there's an emotion feeling
to dot J 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.json with type module in
it a field a property then all the ESM
all that package the j s files will be
ESM but then they will be only a same
and not common J's so you can switch
between the two you can say I want this
to be a regular package common J s J's
file is a common J's or I want it to be
a SM in all J's or ASM so you have this
dot MJS is always yeah yes M is always
yes M code dot CJ s is always CJ s and
that j s is by default common j s but if
we have type module then it's es m weird
but it's you know like compromise No
but is really happy which is good we in
in in in common jazz we can NN webpack
we can do something like import
something and specify a directory ok
this doesn't work anymore well if this
doesn't work anymore if we have dot
index jsr index dot MJS that doesn't
work anymore it works only if some deer
has a package.json again browser
compatibility and this is bear
specifiers import something from low -
or from whatever package it is obviously
this works I mean if that didn't work
no no js' program would work anywhere
but you can't use the index J s thing in
node module so package has to have a
package.json with a main entry point and
you can't rely on index dot Reyes but
you're saying why do we need this whole
thing because bear specifiers are anyway
not backward-compatible it doesn't
really matter whatever we choose in
nodejs because there are no bear
specifiers in 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 specifier in a
browser code then it will blow up and
give an error but and it works in nodejs
but this was an opportunity finally for
the node people to start influencing the
browser people okay for note saying look
we understand bear specifiers we know
how that ecosystem works let's work with
you people and define something that
will make bear specifiers work in the
browser and be node.js compatible and
what they make what they came up with
was import Maps import maps are needed
only by the browser no js' doesn't need
them yet but they're needed only brought
by the browser no js' if it gets a bear
specifier it knows to look in the node
modules folder
in the node modules directory but
browsers don't so what you do is and
let's look at the right side we have a
script type equals module and it's
importing lodash for example that's a
bare specifier to for this to work we
need another script type equals import
map which specifies all the imports so
for example you have import moment and
import load - and the import load that
says if we're importing a bear specifier
then that bear specifier that will be
the file for that bear specifier so the
browser looks into that conversion map
and knows where which HTTP GET to do to
bring lodash in 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 standard and it is a
path to universal es modules modules
that work without any change both in
node and the browser and web pack and
how will it work in node the idea is or
or for browsers the idea is once you npm
install or yarn add your module that npm
install or yarn add will modify an
import map in the root of your in the
root in the root of your package it will
modify the import map so that browsers
if your script source to that import map
will know exactly where things are so
you will npm install your packages and
then just import them there using native
syntax and then know where pack is
needed you will just refresh change the
file refresh the page or do hot module
reloading and boom everything works no
we're back know bundlers whatsoever by
the way the npm install things that
updates the import map that's a
speculation of mine so coffin here so as
we've seen we get used universal native
is modules mean
knowledge eels that were both in the
browser and in npm LAN nodejs etc
without any change and this is the most
important thing import Maps will allow
no Jason browser J's browser
compatibility with no translation or
bundling so let's review what about the
problem of extensions for module files
node forces you to write extension so
the everybody is basically saying when
you're importing something or when
you're 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 specifiers bear
specifiers which was a problem now we
have we will have import maps in a year
or two and we've solved that problem
what about HTTP getting every one of my
hundred modules is that solved nope and
the answer here that I call it the black
hole problem because I'm certain a lot
of you have seen this the heaviest
object in the universe and some of you
haven't that's nice yeah node modules is
huge lots of modules first of all it's
not that big because we want the the not
the dev dependency we want the
production dependencies most of the
hugeness in node modules is having
typescript bubble web pack is lint and
all those development tools inside node
modules it's like in Java every project
has a Java compiler and Eclipse and
whatever development tools are inside
this is the situation in in 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 more of modules too big for
production if I need to HTTP get all of
them that's a problem now I don't have a
lot of time so I'm not gonna you know
expand on this the solution people
thought was gonna happen was HTTP 2
which allows us to bring a lot of files
at were at the same time and for the
server to push all these files to the
even before the browser requests them
yeah that's better
but it's not good enough there's an
article on that I don't want to I don't
want to talk about that
it's it's it's 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
solution the web packages is a upcoming
standard which enables us to bundle
files as they are as HTTP resources and
give them to the browser in one time
fascinating a subject again I don't have
time so wrap up
browsers support only relative paths and
it's lunch I know I know
node support for relative path is
intentionally browser compatible so it
uses extension it uses MJS but if you
really love your Jas use type module in
the package.json bear specifiers are
there a node support for bear specifiers
in browser will be coming hopefully
using the import map proposal and the
black hole problem is a problem now but
it probably will be solved by technology
sister HTTP 2 and web packages so the
future is very bright for its modules
node and browser interoperability
without the need for bundlers and
transpilers simpler times people are
coming thank you very much
[Applause]