 I'm here in Melbourne for Web Directions Code, where we're going to hear from a bunch of hardcore front-end engineers about best practices and techniques in building web applications today. I'm Alex Danlow. I'm here with John Olsup, who runs the Web Directions series of conferences. Quite a while ago, you wrote a document called the DAO Web Design. How relevant is it to the web today? Well, I guess it's more relevant than I thought it would have been in the year 2000. It spoke a lot about the kind of things that became responsive web design as we now know it. I reread it the other day for the first time in a very long time, and to be honest, I was quite surprised actually by how really it did foresee some of the things that we're seeing even to this day. This conference we've brought in Alex Russell, who keynoted, and he also wrote an amazing document called the Extensible Web Manifesto. How do you relate to that document yourself? Really, where we saw the web driven for a long time, in terms of the development, was in two different ways. The underlying platform was being developed very much within the W3C, almost within hermetically sealed units of working groups and the like. But a lot of the innovation of the web was happening outside DAO, whether it was the likes of jQuery, whether it was the innovations around the use of CSS techniques. What I think that really did, that particular manifesto, was bring together those two groups, both working for the development of the web, and to basically say, well, we should be drawing from both those groups to drive the web forward. I think some of the great examples such as the Responsive Image Community Group, really developing Responsive Images, have been a great example of this kind of combination of the users of the web, as in the web developer community, combined with the browser developer community and the experts in the standards, working together to move the web forward. I've spent probably a decade in W3C working groups, working a lot with SVG, et cetera. Better man than me. Well, it's painful. One thing I do strike is that I'm always asked about web applications versus native applications. What's your take on the web versus native application thing? What should a developer do? I think that you approach this in various ways. One is purely from an economic perspective. On one level, we have to feed our families, we have to eat, and looking at that, really, what is the better bet in terms of utilizing your skills to generate revenue? I think Alex spoke really well of this this morning in his presentation to talk about how it's a really hit-driven business, the app business, where you have a small number of very successful financially apps and the cost of acquiring users and so on and being very high when it comes to the native app platforms. Whereas on the web, you're seeing an enormous amount of monetization around things like e-commerce, and ultimately, I guess, too, the opportunities to work for clients if you're in that client services business as well. Or I guess a lot of us, though, choose the web as a platform to work on because we believe in its values and we believe that it's an important platform in and of itself. And the fact that we can also create good businesses around it just multiplies that. One of the things I love about this conference series as well, I have to say, is that it brings together professional web developers. It's not academia. It's people actually building commercial sites, building the big sites. And so the group of speakers and delegates is quite amazing. How do you keep up the energy to do this every year? Yeah, look, it excites me. It interests me. I kind of use this analogy. I got this TRS-80 back when I was about 15, I guess. And when I see a picture of that TRS-80, which was a really early, kind of not even personal computer, when I see pictures of them, I feel that in Simon and enthusiasm, I had as a 15-year-old. And now, like more than 30 years later, I guess I still have that excitement and enthusiasm for the platform. I think partly because of the values, you know, that the web embodies and the positive things it does for the world kind of really helps. But, you know, it is hard work. And I guess sometimes I think, well, it's our job as in web directions. What we try to do is to keep up with a lot of these trends to help a lot of people out there who are also building sites and building apps and doing what they do, help them keep up. Because I don't know how people do that, to be quite honest, while they're holding down full-time development jobs and trying to keep on top of all the technologies and all the changes and all the innovations around the web. Exciting times, Henry. Thanks for speaking with me today, John, and I'll have to see if I can run down Alex and get some more insights. Alex Russell, you authored a document called the Extensible Web Manifesto. Could you summarize that in, like, 10 seconds? Browser vendors should attempt to give you more power, not less. Awesome. Between the Dowell Web Design and the Extensible Web Manifesto, do you think they're on the same path? Do you think the web has changed in that period of time? I think we're demanding more of the web. And as a result, the Extensible Web Manifesto kind of builds on that capability by asking browser vendors to return the power to kind of create the new things that we need to extend that path that we're already on to us. Browser vendors have a poor track record of inventing new stuff, and the community is really vibrant. And the more we enable the community to sort of figure out what that new future is and then let us sort of pave those cow paths after they've already been laid, I think the better we go, I think the better we do. Yeah, like, I've spent a lot of time in W3C working groups. And one of the things I find really difficult is answering the HTML versus native app question. I'm constantly asked at, like, what's your point of view? Users visit a lot of websites, even though websites are very difficult to use on mobile devices frequently. And as a result, it means that getting two websites has got to be much easier than getting to apps. And there's an opportunity there for us to try to make websites into apps, not by repackaging them, not by turning them into things that are listed in a store, but just sort of upgrading them where they lie. And I think that's a better way forward because it improves our ability to turn the web apps that we've already got into better things, as opposed to sort of contemplating some new architecture. And one of the things that I think is a really hugely positive thing that's come recently is service worker. So to the developers out there, could you summarize service worker? Sure, so service workers are kind of an extensible answer to what would it be like if you had the power to implement AppCache yourself, right? If we just gave you the pieces, the parts, and let you figure out how to handle the network layer on your own without our intervention, what would that look like? And that's what service worker is. It's an answer to that question. It's an attempt to give you the power that browsers have had and kept to themselves about mediating for the network. And they let you answer the question of how does my application work offline, not because they are designed to do offline per se, but because they just give you the tools that we already had in the browser for making things work when you're offline. And another thing I've also seen that a lot of people are really not aware of is things like the add to home screen, because now the mobile browsers let you add an icon to the home screen, let you do push notifications. For me, that blurs the line between native apps and web apps. And I'd like to just get your insight into where you think this is gonna go further on in the future, like what will happen from here on? We've sort of been calling these progressive apps. There are things that begin life in a tab and then they sort of escape the tab and they turn into real first-class applications inside the OS that you happen to be using. And I think progressive apps are a good response to the question of what should the web become? The web should become first-class everywhere that you want it to be. And today, that's been a difficult challenge to try to overcome because we've sort of always had to live life in the tab. And so these features are specifically designed to give good things that we know can be app-like, the treatment that you would expect of something that is an app, but only after you've engaged with it for a while or only after you've decided that it is really app-like and that you wanna keep it. The conference so far, what do you think? This is an amazing conference. I am astonished by the kind of lineup and the topics that John has gotten folks to speak on here. Everything I've seen today has been both straight up my alley and I think indicates a deep understanding of what it's going to take to build the next generation of web apps. Great talking to you, Alex. And it's Alex talking to Alex. So we're the two Alexes. We're done in an array of inexpensive Alexes. Yeah. I'm here with Jonathan Cronon from Atlassian. And of course, Atlassian's a great Australian company that's built some amazing web applications. And currently some of their production systems are actually using web components. So can I just ask you what made you choose web components? Web components are fantastic because what web components or specifically custom elements give us is a separation between interface and implementation in HTML in the DOM. So we can write a web component which just has like the semantic intent of a component like a header or a dropdown or a dialogue. Give that to people. It's very minimal. It's very easy to write. And then we'll, you know, explode the web component and render it. That's one of the things I found with web components versus something like, say, Angular. Because in Angular, your model for your application is in JavaScript. And then the browser is basically a slave. Whereas with web components and custom elements, you can keep the model in HTML and the normal DOM. And that, to me, is a very big difference. Have you found, like, say, for example, Angular, the one thing I've heard is debugging is really hard? Like, what's your experience? I think the first thing to get your head around is the fact that the structure is in the DOM. You know, when we first started doing this and talking about the APIs, people were kind of like, oh, what JavaScript methods I'm going to use to change the content here? And I was like, you know, no, it's the DOM. You're using markup here. Like, you might have a method which is on your custom element, right? But that method would be more something like, ah, what's a good example? Like, show, if you had a dialogue show is probably a good method, right? But you're not going to change the content of the dialogue via a method. That's why the DOM. It means that you can use a templating framework and you'll write your custom elements as part of your template. And then once that makes it into the DOM or into the document fragment or into the actual document, then at that point, the web component framework will take over and explode that custom element into, you know, the stuff the user actually sees. Got it. And so a lot of stuff with, like, the whole web components thing, I mean, there's Shadow DOM and, right, I understand you're not using Shadow DOM at the moment. I know that, you know, Chrome implements Shadow DOM but there's not great cross-browser support. The polyfills today have been very heavyweight. What do you see is the future of Shadow DOM as far as your applications or people out there that are building web apps? So in terms of what we're using, we're using not much, right? So the web component spec is, you know, custom elements, HTML imports, HTML templates and Shadow DOM. We're just using custom elements, right? So HTML imports. Don't even know if they'll make it in there. Hard to polyfill HTML templates, hard to polyfill. There will be a Shadow DOM but we don't know how it'll be expressed. We don't know if there'll be template elements, that kind of store content elements, sorry. We wanna start using it now. What's the shortest path to doing that? And so looking forward to the future, yes, at some point we'd use the Shadow DOM. I guess there's a couple of tough questions there. So the first is, would we use the Shadow DOM before it's available anywhere? Like, if you're using, you know, like Shadow DOM in Chrome but not using Shadow DOM in IE, then that kind of increases the scope of stuff that could go wrong between the different browsers and the scope of cross browser coverage. So, you know, that's a question we look to in the future when we can actually start using it in Chrome or something like that. Cool. Anyway, it's really great to see like these emerging standards being used in real production systems. So like, here's a perfect example of success with web components in general production things. So like, web developers out there, please use it. And of course, use all of that. Lassin's great stuff as well. Thanks for talking to us today. Cool, man. Appreciate it. Thank you. I ended up going from cartoons from making comics for teenage girls where I was very successful to getting into front end development around the time of the recession. And while I was in front end development, I just threw myself head first into learning JavaScript and fell in love with CSS. And many years later, I saw that you could do animations with CSS. And I started doing really cool things combining some of my skills from cartooning with CSS. And I realized that people just responded so much better to learning how to make a cat run across the screen than moving a box across the screen. So I ended up leaving my job as a front end developer to travel and teach people more about animation. Now in your talk, you spoke a bit about the cortex and the brain being like the GPU and the rest of the brain being like the main thread. Like what gave you that visual? I actually was just reading a research paper about how the human brain, the mental models work when on task and how dysfunctional it can be when trying to interpret this completely foreign interface. If you look at how old operating systems used to work, how things would just move from one place to another from screen to screen with no indication of where they were going, it looks very foreign compared to how things move in the natural world. So when I saw that and they were talking about how that kind of disjointed movement affected kept bouncing things off of the visual cortex onto the quote unquote main thread. I thought, oh, it's like a GPU. Oh, I get it. And I just decided I had to doodle it. Very cool. So as you know, I've been involved in W3C standards for a long time and been an editor on the web animation spec. So you've recently become an invited expert working directly with people like me. So like, how do you find going from the more creative side to these crazy standardistas? I'm still getting used to it. If you've ever seen a large dog being hugged by a small child, that's my face. It's like, what is this? It's very different. Participating in all these email chains, an awful lot of responsibility, but I'm happy to do it. Cool. Also, I just wanted to mention to anyone watching that you of course have started a web animations newsletter which is something that gets from people like us out to real developers in the front end. So like, would you just tell us what that's about and how you get onto it? Absolutely. So you can visit webanimationweekly.com and sign up. And every week I send you all the news that's fit for reading regarding web animations from case studies on big sites all the way down to little tutorials and more specifically, important browser upgrades and spec options. Awesome. So pleasure talking to you today. Let's make an animated world. Let's. I'm here with Dominic Denikola, and he's on the TC39 committee. So could you give me a rough overview of what that is? TC39 is the group responsible for evolving JavaScript, adding new features, tightening up the spec. We produce the spec basically. Awesome. And I understand that you are heavily involved in development of promises. And like, promises are now everywhere in the browser. Like, give me a quick summary of what a promise is. So a promise is a representation of a value that you might not actually have yet. So the value will maybe come later, or maybe it'll fail to come, and you'll get an exception, a rejected promise. So it's a primitive for programming asynchronously. And today you were talking about something that I thought was really interesting, which are cancelable promises. So like they're called tasks. Is that right? Yeah. So tasks is kind of the marketing name, and we're still figuring this out. But basically, the idea is to evolve promises so that not only do they represent the value, they can also represent the operation that produces the value. So then you could take that operation and cancel it if you needed to. And if you have multiple people who are looking at the operation, all of them kind of have to opt into cancellation. It should all work out. Anybody out there that's a web developer, definitely use promises. Because if you're using Service Worker, you have to. And Service Worker is awesome. The other thing that you talked about today, which I think is really exciting, are the streams, like the IO stream. So give me a quick rundown of those. Streams are basically solving this problem that we've had in the browser for a long time where you can't actually read a large HP request response without using up all your memory, all the memory that it takes to put that entire thing into a string. So with streams, which are shipping in Chrome 43 and Mozilla is going to ship them soon, what you can do is you can just read chunks at a time into memory and process those as you need, and then throw them away. And you'll only consume a maximum of however many 10 megabytes of memory or whatever, even if you're consuming a gigabyte file at a time. Awesome. So if you're doing anything with streaming data, like from, say, video streams or audio streams or anything like that, look at the streams API. It's definitely cool. And the thing that I thought was the best, like, I don't know if you agree, but it's a synchronous. Effectively, it runs on a separate thread to the main thread. So you don't get janked. So if you use streams, you can deal with tons of data coming to your browser without worrying about hitting the main thread and making your whole site janky. So anyway, thanks for talking with me today, Dominic. And I look forward to all the new APIs that are coming. Thank you. It's great coming home and being part of the next generation of the web. We've got progressive apps. Everything is going mobile. I can't wait to see where the web goes next.