all right hello jazz comp for ye before
we get started I want to talk a little
bit about how amazing this conference
has been right I mean he was just
talking about Hawaii but how about like
the variety that we've seen on stage we
have seen Moana we have seen natural
hair we have seen Tamagotchis I mean
let's give it up for the organizers a
little bit for putting this thing
together right so for those who are not
from actually show of hands who knows
what J s party is a few of you alright
so J s party is a podcast but more than
that it is a weekly celebration of
JavaScript and the web we get together
every week and talk about cutting edge
content what's going on with JavaScript
what's going on with related topics I've
heard conferences described as the place
you go to learn what you should be
learning about well if you can't make it
out to conferences every week you can
get that anyway by listening to Jay s
party we do come to conferences today
we're here we're going to do a live
episode this is you are live with us
typically when we do an episode we
broadcast it live as we do it there's a
slack channel you can come and slack
with us as we do it here we don't have
the slack channel so I'm relying on you
all to give us that live feel but we are
going to be digging in with our some of
our amazing speakers from yesterday and
kind of going a little deeper and trying
to make me make them uncomfortable and
ask questions that they hadn't thought
about
so before we again I'm Kay ball I'm one
of the hosts I'm a regular on Jays party
if you want to find Jay s party go to
any podcast app search for Jay s party
you'll find it last night somebody was
trying to do that on Spotify and it
didn't work and so I was frantically
slacking people what's going on it turns
out the search term was not matched
properly so we fixed that but search for
Jays party wherever you do podcasts you
will find us alright so I am joined
today with four amazing speakers they
spoke yesterday but I'm going to
introduce them anyway
Willian spoke about tc39 the future of
JavaScript Shawn spoke about Babylon
some amazing things you can do with that
with the language I don't know if I even
need to introduce you to you're so
famous but we have Lin until who both
spoke about webassembly
and what we're gonna dig a little deeper
on today is this idea of the future of
JavaScript of web development where is
this going you know how can we take all
of these talks that happen independently
and sort of try to weave a picture
together of of where this is going in
the future so we'll just start I had
prepared a few questions if you all get
a burning need to ask questions you can
raise your hand and I'll probably call
out to you but we've got plenty so don't
stress so I want to start actually
talking about the JavaScript language
itself
Willian introduced us to some of the
proposals that are there for advancing
the language and I noticed that there
were a lot of operators involved in the
pattern matching there was a new arrow
operator it wasn't the fat arrow were
used to with arrow functions it was the
thin arrow with the piping there was a
pipeline operator and I'm kind of
wondering I'm gonna throw this to
Willian first but any of the panelists
you're welcome to answer are we gonna
run out of syntax and operators like is
there room for a tamagotchi operator
where are we going I think this is a
good question for to you right so I
think there are sort of two different
answers to this um one is we can and see
if we invent an arbitrary amount of
additional operators and make them work
somehow just put two characters next to
each other that currently would be
invalid and say listen you operator and
cynic was actually an example where we
could have done that when we introduced
the federal there the committee was
pretty close to also in producing a
scenario variant that didn't capture
this the this value but otherwise what
if we actually operate it exactly the
same and the reason
this is not done was mention complexity
budget and that is really what a lot of
this is about that
an operator has to carry its weight it
has to be specialized in a way that
allows people to use it as a an
efficient mental abstraction instead of
just some weird characters on the page
that make things unreadable and if we
didn't keep that in mind then the
language would be more and more just
sort of this weird stuff on the page
that nobody can clock and so yes we will
over time it would use new upgrade earth
but we have to be extremely careful
about which ones and make sure that they
are actually useful enough that leads
into kind of a question about the
process of deciding what goes into this
language you know we talked about tc39
and the stage one that was going on
there but maybe can one of the panelists
spell out the stages that things go
through as they advance in the
JavaScript language okay I can try that
one okay we have like a five stage and
d'Oro like that is the stromwell
it's like you have a conversation bar
and we are kind of drunk and say yeah
where if with those days in JavaScript
let's try like and and you try to
present this token to the committee and
then if they and if you find a champion
and and this proposal its I tried to
solve a problem like yeah you should
shake the the the the the the problem
first and then if I have a simple four
champion in this and you you and the
committee decides that this is like
something that worth more investigation
so they goes to the stage one so then
they try to do a little bit more
research on that and shaped like if it's
a syntax like shape the syntax or in the
semantics of the this proposal and then
goes to the draft which is the stage two
so then they start to
right the draft of the of this
specification and then sometimes they
have some implementation bubble and and
and sent to the to the developers to try
that out and then after after they find
some consensus on and syntax I'm in send
mailings of the the proposal that goes
that this proposal goes to the go stage
3 which is the time that they wait for
some permutation the browsers and and I
think like then you see this
implementation coming to the nightly
version of Firefox or Chrome Canary and
so on and then after everything's done
and the final consensus will seem to
stage 4 which is the last stage and then
they have a cohort I think in March
right and and then this goes to the next
spec which is in July then you talked
about similar feature advancement
happening in the web assembly is the
process they're similar or how does the
web assembly working group deal with
this there are a lot of similarities and
a couple of differences so for a web
assembly you do have also four stages
that look pretty similar there is a
difference in advancing between the
stages which is that with tc39 you need
really full consensus that happens at a
meeting individuals from different
companies can object whereas with
webassembly it's more the different
implementers
really it's what they do is technically
they take a vote and people can say I
strongly disagree I disagree I'm neutral
I agree
strong agree and practice really as long
as the engines as a whole all agree
things will advance so there are some
some technical differences but it really
is fairly similar
nice digging into one of those proposals
that Willian talked about there's this
concept of binary a STS and essentially
having a much easier to parse version of
JavaScript what's that going to do to
the demand for web assembly we're one of
at least the initial value propositions
was hey this stuff can be compiled so
fast that we don't need to worry about
that initial startup phase so um I'd say
that it's actually pretty useful to look
at the different kinds of use cases that
these two that inspired work on these
two so for web assembly a lot of the use
cases were around desktop applications
and games at least the first inspired it
we're seeing a lot of other use cases
now but and what needed to happen there
was actually a start up time is
important but that wasn't the critical
thing there it was execution how fast
the code is running rather than how fast
it starts up and for so it was really at
the time about bringing new things to
the web that weren't already on the web
now we're seeing that you can actually
speed up things that are on the web like
the parser that I mentioned that is used
in web packet and our dev tools or the
Gutenberg part which is 86 times faster
but that's really a different use case
than taking something like Facebook or
Gmail and trying to make it start up
faster binary AST is really specifically
targeted at the problem of startup cost
and so with binary AST we take this
process that's really complicated and
manual today where you have to do all of
these things to improve your startup
times like code splitting and we
automate a lot of that to make it so
that um you don't have to think so much
about how to design your system to
optimize for start-up cost you can just
automate this process of getting a quick
startup
you know just to put a bit more on top
of that like they are trying to it's
different problems like for like binary
it is something that targets the code
start of a JavaScript application so it
tries to make the compiler face it start
faster and and and where the same is
more about like runtime so how fast your
how performing your code could be so
it's and pre its different kind of
things and they are I think as far as I
know like the community is not even sure
that if binary ST is something that
needs to proceed because for example v8
has a different way to parse the the
JavaScript like they have like extend
their parts JavaScript in a streamlined
way so and and the POC that did so far
is it was only in spider monkey so they
they need to try to assess this if this
solution is even true it's a performance
win for the other browser vendors as
well we are in Firefox we're working on
moving this out and I think it is right
for other vendors to say well show us
the numbers before we go and duplicate
the effort here and the good thing is
frankly is T it's a format where this or
is is a proposal where this is possible
if we were shipping a language feature
and then at some point said I know we
changed our mind and stopped shipping it
we would wake code that depends on it
that's not the case with binary ST it's
really much like a minification step
where nobody would only ship by anyway
as G at least for the foreseeable future
so if we at some point stopped sending
the header saying we understand binary
AST then we'll just instead get aj s
file and nothing quakes so that's good
I don't want to say something more about
the motivation here I think it's really
important to look at this holistically
we want the web to be
platform where you can ship or do you
deploy applications of all sizes to and
to make that work we need to pull all
the levers that we have access to we
can't just say well this seems kind of
good enough so let's let's not continue
working in this direction we need to do
what we can for start-up performance in
all kinds of ways we need to optimize
one-time performance using the right
language for the job for individual
modules and going forward we'll
eventually also want to look at similar
things for the other parts of the
platform like HTML and CSS and stopping
at some point because we feel like this
is fast enough for what people are doing
now is selling the platform short so in
Shaun's talk we in Shaun's talk you
talked a lot about compile time
optimizations and I think this is
something that clearly lends itself well
in the web assembly world what you were
talking about with treating binary
estie's is essentially a minification or
compile step where do you all feel we
are in the sort of build systems around
web development you know it feels like
we've come a long way in the last few
years but does that mean that we're at
about as good as it's going to get or we
are at step one of 10 or you know how
far is this stuff going to go it's a
very broad question I am far from an
authority on this but I think I think we
were definitely at the beginning of
build system innovation in fact like you
know a lot of these pieces were were
cobbled together and invented separately
and that's why people complain that
there's no integrated end-to-end thing
from from you know NPM installed to web
packed Babel and and and in having
conflicts between like all this all
these different parts of the system make
on boarding to web home and difficult I
think there is some reason there is some
struggle against like mning such a
complicated build system is a
it's the original spirit of the web you
know like you used to be able to just
drop some JSON to HTML and that's true
but the same time the way we use the web
has also changed a lot and so our tools
should evolved accordingly and there
should be there should be more
innovation on this yeah I mean and like
as much as you know I talk about Trent
compiling to JavaScript but I think that
obviously there's a huge case for
compiling to web assembly
well I think that as you point out the
the use cases that we're doing web
development for have changed and I think
in your talk yesterday on web assembly
you talked about taking this concept of
the web platform and expanding it beyond
what we traditionally think of as the
web how far do you think that goes is
eventually every type of development
using the web development model and
platform so in in the talk yesterday I
made this sort of offhand joke about
stealing your Bitcoin wallet which of
course is based on real world events and
it's no joke it's it's something that
has actually happened applications an
application that you trust where you
rightfully trust the author of that
application still going behind your back
and stealing your money literally well
almost
blockchain and this problem won't go
away without us doing anything about it
and the way I see it we can do something
about it in two different ways either by
locking everything down through
Authority going through app stores and
letting the apples of this world dictate
what you can and cannot consume in terms
of applications in media
or by going away from something that is
otherwise incredibly helpful and
[Music]
increases the stability and product of
our applications and the productivity of
developers and there is code we use
screw platforms like NPM or for West we
have kway teow which is very similar and
it's not scalable to try to weave you
the entire code therefore the hundreds
of thousands of packages published there
all the time and we see that it's not
scalable because nobody is doing and
nobody could possibly do it and so we
can give up on this code we use or we
can say well let's work on things such
that you don't have to trust all of this
code and to do that we need wrapper
sandboxing we need to be able to say I I
don't as long as the application can
only run in this directory you say I
don't usually care about whether it
tries to steal my Bitcoin wallet because
it can't
I need don't need to trusted him in this
regard and for that we need to bring a
sandboxing model that is essentially
similar to what the web provides to
development outside the web in a way
that still allows these applications to
provide the value you want from them and
we are working on that when I was
tweeting about your talk I had a someone
who does native development respond and
say hey do I really want my applications
running in a browser isn't that going to
be a little heavy wait isn't that going
to slow everything down and will that
give me the access that I need how do we
address those concerns from folks who
are used to being able to essentially
access everything and run at a
bare-metal level so that I'm glad you
mentioned the access everything he
mentioned me in that tweet as well and
this idea of a developer accessing
anything on your system that is great
for the developer is really not great
for the user as till was just talking
about
it opens up it opens you up to so many
different security vulnerabilities so
it's not just the web that has locked
down on these things you're actually
seeing the operating system start to
lock down in these things as well
Apple is actually starting to lock down
on what their application developers can
do and I think that as developers see
better systems for providing this kind
of ability capabilities but with a
security around them they'll start to
accept it too because it protects them
if they're reusing code from other
people it protects their applications
from the kinds of exploits that they
could potentially be vulnerable to which
I think most aboveboard developers are
in favor of not putting their user
systems at risk there's also actually a
kind of funny part to this when I looked
at this Twitter conversation yesterday I
then looked at the timeline of this
person who had posed these questions and
just a few days ago they had compared
iTunes and epimutations about how badly
it works and had compared it to Spotify
and said this is how an application
should be done it went smoothly and it's
really well done and at the same time
they complained about how all these web
apps need an entire browser quantum well
Spotify turns out to be an electron app
that brings its own browser wizard so
turns out the web platform actually is
maybe further ahead and they realize
awesome so coming back a little bit to
the languages that we're using to build
this out you know Lynn you highlighted
the need for easy and fast data exchange
and we saw yesterday some discussion of
typescript and I know there's a lot of
type discussion the JavaScript community
right now we also one of the things that
web assembly gives us is you know the
ability to use languages like rust and
other things that have these
guarantees when we're talking back and
forth between these different
environments is there a mechanism within
webassembly
for translating those type guarantees
kept only that is up to tooling and the
rest - webisode mutual chain that we are
working on actually could uses
typescript definition files for the web
assembly modules so that you can work
with them in a sporran a type way and
you have to you have to pass in the
pride types and you have something to
have some kind of layer that converts
what the web assembly module could uses
into something that you as a JavaScript
developer can consume and currently all
you have to interact with the episode
new module are numbers instant float so
all that that one we can understand
going forward that'll change Lynn talked
about the garbage collection proposal
for web assembly and I'm actually the
tc39 champion for the accompanying typed
objects proposal where we will have
strongly typed JavaScript objects where
you don't only have the type of the
object itself but all the fields on that
object are strongly typed and in a fixed
location in memory so that they can be
efficiently accessed both in web
assembly and in JavaScript but you will
still want to have typescript definition
files to see what that structure is and
to have you editor give you hints about
how to interact with that object so that
won't go away and actually think
typescript definition files are the
right way to quote - that there's some
so I'm not too clear about this but
there's some discussion about the the
soundness of like the soundness of a
type system and I'm told that typescript
isn't well it's not something by default
and that could be a hurdle I don't fully
like is that something that you all
consider in terms of your discussions
so the parts of the type system that we
need for this are about the most really
oh yes they fake ones and that part is
sound there's a subset yes it's
absolutely small Chinese anything there
is something interesting for the
typescript team to consider going
forward once we add garbage collection
support to webassembly they could
actually go and compile parts of your
typescript to webassembly to make it run
fast but because the types of type
system is unsound and because even
without that it doesn't make sense to
compile all code to Java to to whoever's
in me instead of JavaScript they could
do it on a per function level and if all
engines have these fast calls said
Linden talked about yesterday and
actually published a blog post about a
few months ago then itself doesn't
matter which part of the system a
function is implemented in and the
JavaScript compiler could really that we
find way and decide back and forth back
web but something is good for this
javascript is good for this let's
optimize all the things I want to
mention that there are two experiments
done on JavaScript to compile to
webassembly one is about the double-a LT
which is kind of you write a JA
JavaScript ish language that combines
that with the whoever thing and there is
another one called a same script script
which is a subset of typescript that
compiles down to the web assembly so
yeah I'm interested in see how they they
do this and how this can work out like
maybe this could be a good starting
point for writing JavaScript and see how
this goes like back and forth on
webassembly all of this discussion about
the many fold possibilities here
reminded me of an ongoing conversation
that that folks are having about how we
preserve the on-ramps to web development
it used to be that you just get started
you do a
little bit of HTML you can do your CSS
and JavaScript right there and you're
already in and it's straightforward and
easy and now we're getting into this
polyglot language world we're getting
into complex build chains we're getting
into complex frameworks Lin I know you
do a lot of thinking about how to
explain code concepts to people I know
that this is a surprised question
because it just came up now I didn't
prep you on this but do you have
thoughts on how we make keep making this
accessible to folks that is a question
that has come up a number of times
because people are worried that when you
introduce something like web assembly
does everyone then have to learn web
assembly in order to be a web developer
and I think that the answer is no I
think that we can actually all of the
web developers can benefit from web
assembly without ever having to learn it
if we have people like the react core
developers re-implementing core parts of
react then people who are using it won't
actually have to know anything about web
assembly they'll just see that the you
know Dom deafening algorithm is going
faster because the api's that are on top
of it will stay the same and so I think
that we can provide kind of this ladder
basically add another few rungs to the
ladder that you don't actually need to
climb if you want to you can climb those
extra wrongs and learn how to do web
assembly development but that you don't
need to to have the same level of
proficiency that you do today and
actually benefit from web assembly
without having to learn it yeah I have
thoughts I mean I agree I think as we
like this industry is still super young
you know you don't and and as we
professionalize and go deeper it's the
the the learning curve is going to steep
in and like that's not it's not an
argument to stop development you know
and I think it's an argument for more
people at every level particularly
intermedia to
to do to produce content to teach each
other I'm a big proponent of learning in
public what you know whatever you just
learned you are the world's most recent
expert at even though you may be you may
not have like a hundred percent of the
knowledge or you may be me
maybe incomplete and missing out some of
the history of something but you're our
best place to explain to other beginners
as well because you you have the
beginner's mind and that's something
that experts don't so I think that we
should have more of that awesome I think
we're getting close to where we're gonna
have to wrap up for the next speakers to
come in but I want to go around
potentially to each of our panelists and
ask you for a quick hit you know what is
one of the things that you are most
excited about coming in the future of
web development and that can be
JavaScript specific that can be
webassembly specific that can be kind of
global big picture of where the platform
is going whatever layer you want to hit
it at and in whatever order because I
once again I didn't prep you on this
sorry throwing you a few curveballs but
what is something that gets you really
excited about the future of web
development cuz I mean from where I'm
sitting
we're where it's at like this is amazing
the stuff going on in this industry is
phenomenal and you know this is an
exciting time to be alive
I personally am very excited about how
far the the web as a platform is going
out of just for the web for example now
you can create a PWA and install an
unknown Windows machine so I'm very
excited about that because like as a web
developer I would I I'd like to do
something more than just like web sites
so yeah I'm pretty excited about it
so I do a lot of I spend a lot of my
time in the reactor wall ecosystem I
guess
and so concurrent reactors kind of like
the next thing that's that's being
released by the by the VI team and it's
seems to be like you think that we're
kind of done with like rendering thing
rendering like lists of items on a page
but there's so many nuances and and ways
to declaratively make
you know user and if declare user
interface that's better and I you know
I'm very much looking forward to the
release of that over the next year I
think that there there are a bunch of
things that I'm excited about I talked
about a bunch of them in the talk
yesterday but I think the thing I'm most
excited for is web assemblies
integration with the garbage collector
in the browser because I think that that
opens the door to so many different use
cases where we use javascript and web
assembly together and where we use web
assembly for the parts of an app that it
really makes sense for and speed up a
whole bunch of these apps I'm excited
about tearing down barriers between the
web and all other platforms in both
directions so Kevin Lee if you want to
have or in the past really we this is
has sort of changed now in the past if
you wanted to have a an application
available on desktop systems and Android
and iOS and also the web you built one
portable application core for all these
other platforms and then individual user
interfaces for all of them and then you
built the web version completely
independent from all the quest or you
have to choose to not have that or not
have the other ones and we are changing
that where the web platform can be one
of the others where you have a portable
core and you build a web specific user
interface using web technologies that's
the one direction the other direction is
bringing webassembly to other use cases
in similar ways to how node what
javascript you are the use cases and to
the degree that web developers get more
comfortable with using web assembly and
not all of them have to of course but
those that do we open new worlds for
them we open the ability to go into tiny
Nicias where javascript would not be the
quiet language and apply their abilities
there
really blurring the lines between these
very two different platforms that's what
I'm really excited about all right so as
we wrap up I want to get a hand for all
of our panelists here they're pretty
amazing yeah I mean I don't know how I
got so lucky to get to pick the brains
of these types of folks but it's it's a
pretty amazing thing and if you like
hearing from folks like this every week
take out your phone right now look up
j/s party you can listen on the web if
you really don't want to subscribe you
can listen wherever you want and we
bring content from conferences we have
regular guests we've had you know folks
like John Risa Khan the show we've had
folks you know just incredible stuff and
you know I I listen to every episode not
just because I'm on the show a lot of
times I'm not on the show and I just I'm
like alright I got to hear what they
said that's amazing so check it out
thank you all for coming thank you thank
you
[Applause]