Gauge – Low maintenance test automation! Gauge is free and open source test automation framework that takes the pain out of acceptance testing.
OneMonth.com – One of the best places to learn how to code…in just one month. If you’re interested in taking your career to the next level head to OneMonth.com/jsparty and get 10% off any coding course.
Fastly – Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com.
- Pattern Matching (thin arrow operator)
- Pipeline Operator
- Binary AST
- Typed Objects Proposal
- W3C Process
- WebAssembly security model
- Walt | Alternative Syntax for WebAssembly
What the Panelists are Excited About
Play the audio to listen along while you enjoy the transcript. 🎧
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.
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.
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.
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.
[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.
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.
[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.
Back and forth.
[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.
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.
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.
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!
Our transcripts are open source on GitHub. Improvements are welcome. 💚