Show notes
Episode 212 While at NDC Oslo, Jon talked Steve Sanderson about Web Development in 2020 - future JavaScript features, adventurous optimizations, and constraint-based styling. This week we've also got a full transcript (thanks to Damian Guard!). Download / Listen: Herding Code 212: Steve Sanderson on Web Development in 2020 Show Notes: Hello (0:34) Steve summarizes his NDC talk on the future of Javascript ES 2015 & 2016 (0:52) Jon asks if ES 2015 and 2016 is the new name for ES 6 and 7 Steve explains how the standard body are going with yearly updates (1:25) Jon asks what some of the new features are Steve talks about how it looks so different and how the import and class features help Polyfils & transpilers (2:14) Jon asks if he can use those features today Steve explains the polyfills and transpiler options (2:46) Steve talks about the Babel transpiler open source project and why people should write ES 2015 code today What about Typescript? (3:19) Jon asks if Typescript is still an option Steve explains how Typescript is a transpiler and provides some similar features as well as strong typing Web Components (4:05) Steve talks about web components, how they're not implemented in browsers today and the polymer.js project that can bridge that gap Steve talks about scoping, the Shadow DOM and how components are encapsulated from the rest of the page Async & await (06:04) Steve talks about his interest in the upcoming async/await support and how it goes further than promises in order to clarify the flow of success and errors Steve mentions that Babel can polyfill async/await support today Generators (7:30) Jon asks for an explanation of generators Steve compares generators with the yield function of C# and explains how the function is marked with an asterisk to signal it is a generator (8:08) Jon asks if this is the end of promises Steve explains that generators are built on top of promises and how they can chain waiting for multiple ones sequentially Emscripten (8:53) Jon asks about Emscripten Steve talks about the Emscripten bytecode format and how it can make Javascript faster as well as providing the foundation for new web languages Steve talks about the LLVM bytecode converter and how it only really works with languages like C and C++ that don't have a runtime like Swift, Rust, Go etc. (12:06) Jon asks about the demo compiling SQLite Seve talks about why SQLite works when others don't. Shared Array Buffer (12:48) Jon asks about the Shared Array Buffer Steve talks about how Javascript took an isolated approach to parallelism and how Shared Array Buffer allows the breaking of this boundary to enable some high-performance parallelism (14:05) Jon mentions how the ASP.NET 5 team are doing similar things for performance Grid Style Sheets (15:00) Jon asks about Grid Style Sheets Steve points out the "Grid" in Grid Style Sheets refers to the company behind it and not the approach which is a rule, constraint and solver layout system like Auto Layout in iOS (17:14) Jon points out it's Javascript and so people can use it today Steve talks about where it might go and explains how variables are much different to typical variables (18:34) Jon asks about the animations in the demo and Steve reveals it's a CSS transition Jon and Steve discuss how GSS and CSS might not mix well together Steve warns GSS is really cutting-edge Jon asks about debugging constraint rules and Steve agrees this is a challenge right now Goodbye (20:30) Jon says goodbye as Steve heads off for his plane. Transcript [00:00:17] Jon: Hello and welcome to Herding Code. I am sitting here at NDC speaking with Steven Sanderson or Steve Sanderson, sor ry. Steve: Either's fine with me. Jon: Either's fine, great. I caught the tail end of your talk yesterday. It was fascinating, you were talking about future Javascript features or browsers features. Steve: That is right - I was trying to predict the future of client-side web application development. I don't know how accurate my predictions will be but some of them are fairly safe bets like we're going to start using ES 2015/2016 stuff pretty soon and then there's a whole raft of other features coming towards us. [00:00:52] Jon: Ok. So that was actually the first time I've seen ES 2015 and 2016. I think I've heard in the past ES 6 and 7. Steve: Yeah, it's just a bit of new marketing really. The folks behind the standards there have basically committed to bringing out a new update every year. So we've got this annual cycle rather than up until know it's been every five years or every ten years in one case. So given that it's going to be annual it it sort of makes sense to give the name a year. Jon: Right, yeah, definitely. Kind of like Visual Studio has done. Steve: Exactly. [00:01:25] Jon: So what are some great features there in 2015/2016? Steve: Yeah OK so ES 2015 was previously known as ES 6 has got to be the biggest set of changes that have come in Javascript since it was first introduced. If you look at something that's written with ES 2015 syntax - if you've never seen that syntax before you would probably not even guess it was Javascript. It looks really different. So you've got import statements - which give you a clean alternative to having loads of script tags. You've got actual classes which are the same at runtime as regular Javascript prototypical inheritance but gives you a nice syntax for declaring that you can remember. Jon: We're finally taking advantage - class has been a reserved word in Javascript forever, right? Steve: Oh, yeah, I think that might have been the case. [00:02:14] Jon: Can I start using those features? I know there's some poly-fills and transpilers or whatever. Steve: Yeah, I'd say if you want to start using ES 2015 today it's really not as difficult as you might think. Assuming you want to target all browsers since, let's say IE 9, then you can basically use almost all of the ES 2015 features. You just need to use a transpiler. The one that everybody seems to be most into at the moment is called Babel (BAY-bel) or some people call it Babel (BAB-bel). I don't know what the right pronunciation is. Anyway it's an open source project that will take your ES 2015 code and produce an ES 5 equivalent of it. It's really fast, easy-to-setup and to be honest with you I can't think of any good reason not to be doing that. If you're not doing that you're sort of just keeping yourself in the past really because this thing is a fully ratified standard now. We know this thing is definitely landing - all the browser makers are committed to bring this in. There isn't really a good reason to not be using this today. [00:03:19] Jon: I've looked at using Typescript for that kind of class support in the past. Is there any kind of downside to continuing with that or are they similar? Steve: No there's certainly no downside to that. If you're getting benefit out of Typescript then absolutely use it. Typescript in a way is a transpiler because it is taking some syntax that is a lot like ES 2015 - it just adds some additional features on top of that to do with strong typing. So if you're getting some benefit out of that strong typing then yeah definitely use Typescript. On the other hand if you don't want to use the strong typing then you'll find that something like Babel will do the compilation, like an order of magnitude, faster. [00:03:54] Jon: So that's kind of a no-brainer as far as a future to dig into. What else did you talk about that's more forward looking? Steve: I was also looking at web components which is sort of all tied up with ES 2015. It's kind of a part of this package of things arriving at the moment but unlike that making that work across all browsers is not quite as guaranteed today. So the best known polyfill for web components is polymer.js but in terms of IE that's only IE 11 onwards. But it's a really good feature. Web components is a way of combining together a bunch of scripts and markup and styles to make a reusable package of UI features that you can put in your application and you can assign them to a custom element name so you can have something like sales-chart as an element and when that goes into your application your custom sales chart appears and it has all the behaviors your want. And it can be, to some extend, encapsulated from the rest of your page as well. So this is a feature called Shadow DOM and it's a way of telling the browser that a certain element should be abstracted away as far the page that contains it is concerned. Code running outside it won't see the elements inside. If, for example, you were using jQuery and you were using a selector and it happened to match something inside that component it won't actually match it because it's considered to be like a separate document. So you don't get accidental leakages of behavior into your component or out of it - it just makes reuse easier. Jon: And the same for stylesheets as well? Steve: Yeah, that's right. If you bring a stylesheet into your web component and it's certainly going to apply inside that Shadow DOM root it won't apply outside it. [00:05:31] Jon: And I believe you mentioned polymer.js is the polyfill for that? Steve: Yeah, it's the best known polyfill but Polymer is only the way of doing something like web components. If you're going to use something like React or Knockout or Angular any of those kinds of things they've all got their own kind of concept of reusable components with custom elements so if you're using any of those things you probably can pretty much do this anyway in a fairly cross-browser way. [00:05:56] Jon: Right. Ok. So then what other features did you cover? Steve: I was interested in the upcoming await/async support. Jon: That's always been kind of a challenge in Javascript. Steve: It so is isn't it. Yeah. So Javascript for the long time was plagued by this everyone's got a slightly different way of doing callbacks thing which is quite troublesome and then it all got formalized around promises. Promises is a fantastically elegant concept that gives you a really clear way of working with callbacks and chaining them and combining them and so on. So promises are brilliant and they're now a native browser feature but there's still a lot of opportunity to get confused with promises because there's so many way you can chain them together and not necessarily even understand how success and error values are flowing through that chain that you can still get things wrong by mistake. I find this happens all the time in my work. Not me, of course, but other programmers get very confused. Jon: Right. [00:06:55] Steve: I might do sometimes. Whereas as any C# programmer knows with await and async keywords you can write your code as if it was synchronous. Jon: It's so obvious what's going to happen. Steve: You can't get that wrong really. That's part of the ES 2016 proposal and if you want to do that today you can either use Babel which will transpile async/await just directly or you can use the generators feature which is in ES 2015. Slightly different syntax but it gives you the ability to do something almost exactly the same. [00:07:30] Jon: Can you explain generators a bit? Steve: A generator for a C# programmer is exactly like the yield keyword that came in with C# 2. So you can have a function that returns an infinite number of values. Like every time that you ask it for the next value it will give you the next thing and it will never stop doing that. That's yield in C# and generators in ES 2015 do the same thing. So you can have a function and you put a little asterisk after the keyword function to say that it's a generator and then inside there you can have yield, return, whatever. You can do that inside a while(true) loop or something like that and then the thing that calls it will receive each of these values. [00:08:08] Jon: Do I just throw away promises now? Steve: No, you still need to use promises. The way you can use this to make promises feel synchronous is by having some other that invokes your generator that gets back the sequence of values. Each time it gets back a value it will say "well what kind of thing is this? If it's a promise then I'm going wait for that promise to complete before I ask you for the next value." And so, if you are yielding a series of promises in effect it's like your promises are being called sequentially one after the other. Which is why your code ends up looking synchronous. It's not very easy to understand verbally but when you see it written down it's quite straight-forward and nice. [00:08:53] Jon: So then there was Emscripten? Steve: Yeah, that's right. So just yesterday or the day before depending on timezones there was an announcement from Brendan Eich that there's going to be a new bytecode format coming to the web. So instead of Javascript just being expressed in plain text as it always has been it will be possible to describe your code in a binary format. The idea with that really is just to take all of the good work that's been done with Emscripten which compiles native code to Javascript and Asm.js which is a special subset of Javascript that can be optimized very well and say "Okay, we don't need to write out Asm.js as legal Javascript any more we can just write it out as binary code and that saves the browser a lot of work in terms of parsing." Asm.js is very fast at runtime but it still imposes a high parsing cost on the browser and that's particularly noticeable on mobiles where people complain that say a large game might take multiple seconds to start during which the browser CPU is just 100% parsing so it would be nice to eliminate that cost altogether. Also, you get smaller use of network traffic because it's very compact and also even though the semantics of web assembly are the same as asm.js initially they are open to adding additional web assembly only features in the future. So it might be possible to have new types of parallelism for example that's only possible in web assembly. If they decide that it would be inappropriate to have it in Javascript it might still be appropriate for there to be a low-level feature that other languages can compile down to. Jon: Ok. [00:10:39] Steve: So yeah, that's all about performance really. And you can kind of do it today you know. We've got Emscripten today, you can compile pretty much arbitrary C code. You can get your asm.js - it will be very very fast in Firefox - the only browser that supports it today but other browser makers have committed to implementing that to. I know IE certainly has, I don't know about all of them. I'm pretty sure they don't really have a lot of choice these days. [00:11:04] Jon: Yeah. Steve: That's useful for a lot of things but one thing that you can't really do very well with that today, but it's kind of promised in the future, is compile some other language, that's not C or C++, into Javascript. So theoretically you could do it because Emscripten takes LLVM bytecode and turns that into Javascript. So in theory anything that compiles to LLVM bytecode can be translated into Javascript but in practice it's much more complicated than that. So if you take a Swift application for instance, and that uses the whole LLVM toolchain, it will produce LLVM bytecode and you might be able to get Emscripten to produce Javascript but it's not going to run because you don't have the Swift runtime there in Javascript. And it's the same with Go and Rust and so…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
