LIVE from JSConf Hawai'i

Alright, hello JSConf Hawai’i! Before we get started, I wanna talk a little bit about how amazing this conference has been. I mean, he was just talking about Hawai’i, but how about the variety that we have 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?

Before we begin, I’m Kball, I’m one of the hosts, I’m a regular on JS Party. If you want to find JS Party, go to any podcast app, search for JS Party, you’ll find it.

Alright, I am joined today with four amazing speakers. They spoke yesterday, but I’m gonna introduce them anyway. Willian spoke about TC39, the future of JavaScript; Sean spoke about Babel and some amazing things you can do with that with the language… I don’t know if I even need to introduce you two, you’re so famous; we have Lin and Till, who both spoke about WebAssembly.

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, how can we take all of these talks that happened independently and try to weave a picture together or where this is going in the future. We’ll just start, I’ve 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.

I wanna 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 we 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 are welcome to answer - are we gonna run out of syntax and operators? Is there room for a Tamagotchi operator? Where are we going?

I think this is a good question for Till, right?

So, I think there are, sort of, two different answers to this. One is we can, in theory, 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 “This is a new operator.” And the thin arrow is actually an example where we could have done that. When we introduced the fat arrow, the committee was pretty close to also introducing a thin arrow variant that didn’t capture this value, but otherwise would have operated exactly the same. The reason this was not done was measured complexity budget. And that is really what a lot of this is about - an operator has to carry its weight; it has to be specialized in a way that allows people to use it as an efficient mental abstraction, instead of just some weird characters on the page that make things unreadable. 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 grok.

So yes, we will over time introduce new operators, but we have to be extremely careful about which ones, and make sure that they are useful enough.

That leads into a question about the process of deciding what goes into this language. 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. We have five stages in total. That is, the strawman: it’s like, we have a conversation in the bar, and we are kind of drinking, and say “Yeah, what if we do this in JavaScript? Let’s try it.” And you try to present this to the committee, and then if you find a champion, and this proposal tries to solve a problem, you should shape the problem first, and then if you somebody to champion this and the committee decides that this is something that is worth more investigation, it goes to stage one.

Then they try to do a little bit more research on that and shape the syntax and the semantics of this proposal, and then it goes to the draft, which is stage two. Then they start to write the draft of the specification, and then sometimes they have some implementation bubble, and they send that to the developers to try that out.

After they find some consensus on the syntax and semantics of the proposal, the proposal goes to stage three, which is the time that they wait for some implementation in the browsers. I think then you see this implementation come into the Nightly version of Firefox, or Chrome Canary and so on. Then after everything is done and they find a consensus, they’ll send it to stage four, which is the last stage. Then they have a cohort I think in March, and then this goes to the next spec, which is in July.

Lin talked about similar feature advancement happening in WebAssembly. Is the process there similar, or how does the WebAssembly Working Group deal with this?

[07:46] There are a lot of similarities and a couple of differences. For WebAssembly 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 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.” In practice, as long as the engines as a whole all agree, things will advance. So there are 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 ASTs, and essentially having a much easier to parse version of JavaScript. What’s that gonna do to the demand for WebAssembly, where 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.”

I’d say that it’s actually pretty useful to look at the different kinds of use cases that inspired work on these two. For WebAssembly, a lot of the use cases were around desktop applications and games, at least that’s first inspired it. We’re seeing a lot of other use cases now. And what needed to happen there was actually – startup 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.

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 Webpack and in our dev tools, or the Gutenberg parser, 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. 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 you don’t have to think so much about how to design your system to optimize for startup cost. You can just automate this process of getting a quick startup.

Yeah, just to put a bit more on top of that - it’s different problems. Binary AST is something that targets the code start of a JavaScript application. It tries to make the compiling phase start faster, and WebAssembly is more about runtime, so how performant your code could be. It’s different things.

As far as I know, the community is not even sure if binary AST is something that needs to proceed, because for example V8 has a different way to parse the JavaScript. They parse JavaScript in a streamlined way… And the PoC they did so far was only in SpiderMonkey, so they need to try to assess if this solution is even a performance win for the other browser vendors as well.

[11:52] In Firefox we’re working on proving 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.” The good thing is the binary AST is a proposal where this is possible. If we were shipping a language feature and then at some point said “No, we changed our mind” and stopped shipping it, we would break code that depends on it. That’s not the case with binary AST. It’s really much like a minification step where nobody would only ship binary AST, at least for the foreseeable future, so if we at some point stop sending the header saying “We understand binary AST”, then we’ll just instead get a JS file and nothing breaks… So that’s good.

I do 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 a platform where you can ship or deploy applications of all sizes too, 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 not continue working in this direction.” We need to do what we can for startup performance in all kinds of ways, we need to optimize runtime 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.

In Shawn’s talk - you talked a lot about compile time optimization, and I think this is something that clearly lends itself well in the WebAssembly world, what you were talking about with treating binary ASTs as essentially a minification or compile step… Where do you all feel we are in the build systems around web development? 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 gonna get, or we’re at step one of ten, or how far is this stuff gonna go?

That’s a very broad question… I’m far from an authority on this, but I think we’re definitely at the beginning of build system innovation. In fact, a lot of these pieces were cobbled together and invented separately, and that’s why people complain that there’s no integrated, end-to-end thing, from npm Install to Webpack to Babel, and having conflicts between all these different parts of the system make on-boarding to web development difficult.

[15:53] I think there is some struggle against – having such a complicated build system is against the original spirit of the web (you used to be able to just drop some JS onto HTML) and that’s true, but at the same time the way we use the web has also changed a lot, so our tools should evolve accordingly, and there should be more innovation on this.

I talk about compiling to JavaScript, but I think that obviously there is a huge case for compiling to WebAssembly.

Well, I think that as you point out the use cases that we’re doing web development for have changed, and I think in your talk yesterday on WebAssembly 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?

In the talk yesterday I made this sort of off-hand joke about stealing your Bitcoin wallet, which of course is based on real world events… And it’s no joke. It’s something that has actually happened. 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; it’s blockchain. And this probably won’t go away without us doing anything about it.

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 and media, or by going away from something that is otherwise incredibly helpful, and increases the stability of applications and productivity of developers, and that is code reuse through platforms like npm. Or for Rust we have crates.io, which is very similar.

It’s not scalable to try to review the entire code there for 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. So we can give up on this code reuse, 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 proper sandboxing, we need to be able to say “As long as the application can only run in this directory, I don’t actually care about whether it tries to steal my Bitcoin wallet”, because it can’t, and you don’t need to trust it in this regard. 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 there, and we’re working on that.

When I was tweeting about your talk, I had someone who does native development respond and say “Hey, do I really want my applications running in a browser? Isn’t that gonna be a little heavyweight? Isn’t that gonna 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 we’re on a bare metal level.

[19:45] I’m glad you mentioned the “access everything”, you mentioned me in that tweet as well… This idea of a developer accessing anything on your system - that is great for the developer, but it’s really not great for the user. As Till was just talking about, 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 systems start to lock down on these things as well. Apple is actually starting to lock down on what their application developers can do.

I think that as developers see better systems for providing this kind of capabilities, but with 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 above-board 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 posted these questions, and just a few days ago they had compared iTunes and Apple Music and complained about how badly it works, and they had compared it to Spotify and said “This is how an application should be done. It runs smoothly, and is really well done.” At the same time, they complained about how all these web apps need an entire browser runtime. Well, Spotify turns out to be an Electron app that brings its own browser with it… So it turns out the web platform actually is maybe further ahead than they realize.

Awesome. Coming back a little bit to the languages that we’re using to build this out. Lin, 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 in the JavaScript community right now. One of the things that WebAssembly gives us is the ability to use languages like Rust and other things that have these high-level guarantees. When we’re talking back and forth between these different environments, is there a mechanism within WebAssembly for translating those type guarantees?

Currently, that is up to tooling. The Rust to WebAssembly toolchain that we are working on actually produces TypeScript definition files for the WebAssembly modules, so that you can work with them in strongly-typed way… And you have to. You have to pass in the right types, and you have to have some kind of layer that converts what the WebAssembly module could use into something that you as a JavaScript developer can consume.

Currently, all you have to interact with the WebAssembly module are numbers, ints and floats, are all that that boundary can understand. Going forward, that will change. Lin talked about the garbage collection proposal for WebAssembly, 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 WebAssembly and in JavaScript. But you will still want to have TypeScript definition files to see what that structure is, since you have the editor give you hints about how to interact with that object. So that won’t go away, and I actually think TypeScript definition files are the right way to approach that.

[23:52] I’m not too clear about this, but there’s some discussion about the soundness of a typed system. I’m told that TypeScript is not sound by default, and that could be a hurdle. Is that something that you all consider, in terms of your discussions?

The parts of the type system that we need for this are about the most trivial, basic ones, and that part is sound.

So a subset of TypeScript.

Yes. It’s absolutely small, tiny.

That’s what I’ve been thinking, yeah.

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 type system is unsound, and because even without that it doesn’t make sense to compile all code to WebAssembly instead of JavaScript, they could do it on a per-function level. And if all engines have these fast calls that Lin talked about yesterday, and I actually published a blog post about it a few months ago, then it sort of doesn’t matter which part of the system that function is implemented in, and the TypeScript compiler could really very fine-grained decide…

Back and forth.

“WebAssembly is good for this, JavaScript is good for this. Let’s optimize all these things.”

I want to mention that there are experiments done on JavaScript to compile to WebAssembly. One is Walt, which is kind of – you write a JavaScript(ish) language that compiles down to WebAssembly. Then there’s another one called AssemblyScript, which is a subset of TypeScript that compiles down to WebAssembly. So yeah, I’m interested to see how they do this and how this can work out. Maybe this could be a good starting point for writing JavaScript and seeing how this goes back and forth from WebAssembly.

All of this discussion about the manifold possibilities here reminded me of an ongoing conversation that folks are having about how we preserve the on-ramps to web development. It used to be that you’d just get started, you’d 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. 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 fo thinking about how to explain code concepts to people. This is a surprise question, because it just came up now, I didn’t prep you on this, but do you have thoughts on how we keep making this accessible to folks?

[28:07] That is a question that has come up a number of times, because people are worried that when you introduce something like WebAssembly, does everyone then have to learn WebAssembly in order to be a developer… And I think that the answer is no. I think that all of the web developers can benefit from WebAssembly without ever having to learn it. If we have people like the React Core developers reimplementing core parts of React, then people who are using it won’t actually have to know anything about WebAssembly. They’ll just see that the DOM diffing algorithm is going faster, because the APIs that are on top of it will stay the same.

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 runs and learn how to do WebAssembly development, but you don’t need to to have the same level of proficiency that you do today and actually benefit from WebAssembly without having to learn it.

Yeah, I have thoughts… [laughs] I agree, I think this industry is still super-young, and as we professionalize and go deeper, the learning curve is going to steepen… And that’s not an argument to stop development; I think it’s an argument for more people at every level, particularly intermediate, to produce content, to teach each other. I’m a big proponent of learning in public. Whatever you just learned, you are the world’s most recent expert at, even though you may not have 100% of the knowledge, or you may be incomplete and missing out some of the history of something… But you are at the best place to explain to other beginners as well, because you have the beginners mind, and that’s something that experts don’t. 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 wanna go around potentially to each of our panelists and ask you for a quick hit - what is one of the things that you are most excited about coming in the future of web development? That can be JavaScript-specific, that can be WebAssembly-specific, that can be global, big-picture of where the platform is going - whatever layer you wanna hit it at, and in whatever order, because once again, I didn’t prep you on this… Sorry for throwing you a few curveballs, but what is something that gets you really excited about the future of web development? Because from where I’m sitting, we’re where it’s at; this is amazing. The stuff going on in this industry is phenomenal, and this is an exciting time to be alive.

I personally am very excited about how far the web as a platform is going out of just for the web. For example, now you can create a PWA and install it on a Windows machine. I’m very excited about that, because as a web developer, I’d like to do something more than just websites… So yeah, I’m pretty excited about it.

I spend a lot of my time in the React world/ecosystem, so concurrent React is kind of the next thing that’s being released by the React team. You’d think that we’re done with the rendering lists of items on a page, but there’s so many nuances and ways to declare user interfaces better. I’m very much looking forward to the release of that over the next year.

[32:03] I think that 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 WebAssembly’s 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 WebAssembly together, and where we use WebAssembly 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. Currently, if you want to have – or in the past, really; this has sort of changed now… In the past if you wanted to have 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 rest. Or you had to choose to not have that, or not have the other ones… And we are changing that. 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 one direction.

The other direction is bringing WebAssembly to other use cases in similar ways to how Node brought JavaScript to other use cases, and to the degree that web developers get more comfortable with using WebAssembly… 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 niches where JavaScript would not be the right language, and apply their abilities there, and really blurring the lines between these different platforms. That’s what I’m really excited about.

Alright. So as we wrap up, I wanna 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 a pretty amazing thing. And if you like hearing from folks like this every week, take out your phone right now, look up JS Party. You can listen on the web if you really don’t wanna subscribe, you can listen wherever you want. We bring content from conferences, we have regular guests… We’ve had folks like John Resig on the show, we’ve had incredible stuff. 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 am like, “I’ve gotta hear what they said. That’s amazing!” So check it out.

Thank you all for coming, thank you!