How to be a frontender in 2016

My name is Philip and this talk will be 40 to 45 minutes. It's going to be some trends, it's going to be some bleeding edge front end stuff. We'll do questions afterwards if we have time or you can come find me when we're all done and there's a new session in here. There's going to be a lot of resources in the slides, a lot of links, so I'll tweet out a link to the slides so you don't have to write them down or take pictures or whatever you would otherwise do. The topics we'll go through today is we'll talk about the web versus native, we'll talk about new language features in JavaScript, we'll talk a little bit about frameworks, we'll talk about what's new in styles, and then there's a little extra thing if we have time. So my name is Philip, I'm a front end developer slash manager at a company called Impact. We do large scale e-commerce on .Net, so I'm sure like you've heard at all sessions here, if you're looking for a job, come see me afterwards. We're looking for developers in our offices in Aarhus and Copenhagen. But enough about that. So over the past years, since the various apps have been launched, since the web app stores were launched, everybody wanted an app because apps have great stuff, they have great features. But the web also does. So I just thought I would just list them out. On the web we have just one target platform. It's a great feature of the web. We don't need to develop for specific platforms. There's just one that works everywhere. There's no gatekeepers, no Apple wanting to control what you give to your users. It's very easy to deploy. More or less just, if you're old school, you can just FTP your file up to your server and it's available for everybody. Everybody's on the newest version. There's a lot of good stuff. And there's the power of the link. If you build a web app, you can have any state of your application have a URL. And that URL can be shared or you can write it down and type it in on a different computer and it'll just work. There's a lot of power in the web. But native has traditionally had better performance. There's been better access to hardware. The opportunity to do offline stuff. And re-engaging your users when they're not using your application anymore. And I'll talk just quickly about how the web is trying to go into these points. So it'll take over the world. And in a couple of years, I think, we'll be mostly doing web apps. So the problems of performance. Last year, Google introduced this idea of rail for performance. I'll go into that in just a second. For hardware, it's not common knowledge. But actually, most hardware APIs are already available in JavaScript in most browsers today. So you can get access to how much battery is left on your device. Whether the device is in a very lit or in a very dark room. Or the location. You can get access to the camera. To all the stuff that you really want. You already have JavaScript APIs for these. So I don't think that's a problem anymore. For offline, we have Service Worker. I'll show a lot about how to work with Service Worker today. And recently, we also just landed push events and notifications in the browser. And I'll show some code on how to use that as well. So I think we're already... All these features work today in stable Chrome. That's more than 50% of the users today. And Google kind of coined this phrase. They call it progressive web apps. The idea is... It's so important to them that they put it in the name progressive. So the idea is you build a website. And you follow some best practices. And then the more your browser supports, you progressively enhance the experience. Just like we did with regular progressive enhancements over the years. So if your browser supports offline, you get to have an offline experience in your web app. Support is growing. And as I said, it's already above 50% of the users, of the browsers. And it's continuing to grow. More and more browsers are investing into this. So the idea of progressive web app is performance. It's a responsive design. It's secure by nature. So most of the APIs that are specific to progressive web apps only work on HTTPS. So if you're not already using it, you should. There's really no excuse. You should protect your users. Protect them. I mean, your search rankings will be boosted and stuff. All the hassle has already been taken care of. So it's pretty easy to use HTTPS. So start doing that today. And so this kind of rail. The idea is that we have response, animation, idle, and load. And for response, it's like when a user taps a button. And they expect to see something within 100 milliseconds. And if you can do that. Your app feels performant. And 100 milliseconds in human times is very short. But in computer times, it's actually quite a lot of time. So it gives you an advantage. So if you need to do some complex work. Like an animation or something. When a user taps a button or does something. The idea is that you actually get a lot of time up front. Where the user don't notice that you're spending time. So you can do all the complicated math. And all the measuring stuff in the DOM. You can do all that up front. And then you can have really performant animations. Because you're not doing it on every single frame. And that's the next point of animation. The browser refreshes the screen 60 frames a second. So you have around 15 milliseconds to do stuff on every frame. And you should think that the browser is probably going to take out about half of that. To do its own stuff. And to do garbage collection. And to actually paint stuff to the screen. But that still gives you 5 or 10 milliseconds to do stuff on every frame. So you can set styles. Or you can do basic math. You can do all that. But try to not change or read from the DOM in every frame. So do that up front in the response time. And then in your animation. Just set new styles. And it will give you really good performance. And talking about performance. When we're doing animation. You should try to only use transform and opacity. Because these are hardware accelerated. And I think a lot of us say. But I want to transition from blue to green. And that's not transform or opacity. But maybe you can put a green layer on top. And then transition the opacity from 0 to 100. And it will give you the same effect. And it will be way better supported. It will be way better performance. Because it's on the GPU. Also there's. This new CSS property. Or a kind of new CSS property. That's called will change. Where you can say. Where you can define that on this specific element. What will change is going to be transform or opacity. Or anything that you're going to be animating. And that way the browser will know. That you're intending to change this. And it will optimize it for you. So if you put will change transform on an element. And you animate it with transform. You'll get really solid performance. Then there's idle. So sometimes you have to do really complicated stuff. That takes a lot of time. And when do you want to do that? Of course you want to do that when the user doesn't know. Or when the user is not doing anything. And there's a new API for this. It's called request idle callback. And the idea is that you can request the browser to let you know. Or to give you a callback. Whenever the browser thinks that it's not doing anything. So if you have really complicated stuff. You should chunk it up into stuff that can. Fit within the 50 millisecond limit. And then just schedule a new idle callback after that. And do your queue like that. The reason behind the 50 milliseconds. Is that if we want to still hit the 100 milliseconds on response. And the user taps right when it started an idle callback. You'll still have 50 milliseconds to hit the response time. So chunk it up. And then the browser will take care of the rest for you. It's a really great way to do complicated stuff. Or really heavy stuff in the browser. And then there's load. Load time is if your user goes to your website. He needs to have something on his screen by one second. And this is really, really hard. Because we have network and everything that's going on. And maybe sometimes on a mobile phone it's going to be simply impossible. But you should aim for it. And a really popular trend these days. Is to have maybe a single page application. Or to have something where JavaScript actually renders your code. Or renders your content. And you should be able to serve at least the shell of your application. Or some initial content within the 1000 milliseconds or one second. And the powerful thing is that if you serve an app shell up front. Then you don't have to show. I mean the user will eventually get the content. Probably around the same time. But he'll see your branding while he's waiting. He'll see your spinner. Or whatever you choose to do. And this also works really, really well. With the next thing which we'll talk about. Which is offline. Because if you have this app shell. You can put it in the cache. And you can serve that even if there's no connection. And then you can throw them a custom no connection message. Or you can cache your data as well. So a new powerful thing that's landed in browsers is the service worker. How many in here have heard about the service worker? So that's about half probably. A worker in JavaScript. JavaScript is like a separate file. You register it. And it will run on a different thread. So it's not on the UI thread. It's not blocking animation. It's not handling. It's not doing anything while your code is running. So that's the regular web worker. And the service worker is a worker like that. But it doesn't die with your session. So whenever the browser is closed. Or the tab is closed or something. There's still this file from your domain. That's running in the background. And it can wake up whenever you want it to. So it's pretty powerful. I'll show some code in just a second. So for network. You can think of it kind of like a proxy. So you can intercept all HTTP requests. Or any requests that's going on from your website. Not only to your domain. But from your website. So even if you're linking to CDNs or third party scripts or whatever. You can handle all of these requests. And you can cache your code. You can control the cache. And you can do really, really powerful stuff. Then there's sync. I think sync is a horrible name. Because it's not really what it does. But the idea of sync is maybe. Think of it like a request online callback. So this is a feature intended for when you have really bad connectivity. Or no connectivity. So let's say you're writing an email in Gmail or wherever. And you go on the train. And you press send. So I think today Gmail is pretty smart. And it saves it in local storage or index DB or something. But you still have to go back to the website and hit send. So the idea of the sync event is that you can register for an event. And this event will wake up the service worker. Even if the browser is closed. Whenever there's a connection back. And it will do your stuff for you. So that way when there's a sync event. It will wake up. Take stuff from index DB. Or take stuff from local storage. Do a fetch request or push request to your server. And the user doesn't have to know that he was out of connection when he scheduled it. So it's a pretty cool feature. And then there's push. Push is what you expect. You can send a push message from your server to the client. And the client doesn't need to be awake. It doesn't need to be open. If it's offline it will just get it whenever he's online again. And then you can show notifications. And you can handle what happens when you click a notification. So let's see some code. So the service worker kind of works like this. So you register it. I'll show that in a little bit. But you register it. And it's a file. And you have this reference called self. Which is the service worker. And you put an event listener on it. And here I'm listening for the fetch event. Which will happen on. Which will fire on every network request. And then I'm just simply looking up. And there's a cache. I look up in the cache. I see if there's a response. Or if there's a match in the cache. If there is I'll just serve that. And if there's not I'll just put on or fire on the fetch event to the server. And do it like usually. And the idea is that the browser doesn't know. I mean so the window of your browser doesn't know what's going on. So it doesn't know where the file is coming from. So if you would put all your resources in this cache that you can manually control. You can have instantly loading pages as soon as any visitor has been here. And it's not like HTTP cache where sometimes the browser will just clear it out. Or you have to set times on it. And how long it lives and stuff. You can handle all of this programmatically. And it's very clear. The cache of course is also a new API. And currently it only works from the service worker. But they're actually talking about also putting it on the window object. So you can interfere with your cache from there. It's pretty cool stuff. And it works kind of the same for all the other events. So this is the sync event. Somebody sent an email and pressed a button and he was offline. So when he's online again the service worker will wake up. It will fire an event called sync. I'll see what's the tag or what's the name of the event. And this can be some arbitrary string that you get. And then you can just respond to that. And the idea here is that you see this funny wait until. And that's because of the nature of service worker where it lives in the background. It needs to know when it can go back to sleep. So it doesn't drain your battery by running all the time. So you say event wait until and you give that any kind of promise. And when that promise is done it will go back to sleep. So that's why you can't just do a fetch request. Because that way you won't be able to see if it's working. You'll have to see if it completes or anything. So here there's a request. And as soon as the request is, we have an okay back from the server. The service worker will close down and don't take any more battery out of your device. Same goes for the push event. There's event wait until again. We show a notification. We give it a title, a body, an icon, a tag. And then we have this thing called actions. Where you just feed it an array. And you can do custom actions as well. And I'll show in just a little bit how you can respond to these actions. And give it any title and it will show up in your browser. Or if it's on your phone or wherever you are. And the last thing is notification click. So whenever a notification is clicked the service worker will wake up again. It will see, I'll close the notification. I'll see what event was triggered or what action was triggered. And then we'll respond to that maybe by firing off a fetch request. Or by opening the window to the URL or whatever you want to do. This is really powerful stuff. And it's here and it's working today. It's cool stuff. Of course, this is kind of a low level API. So it's a little bit tricky to work with. And you have to do a lot of stuff manually. But already we're seeing libraries showing up. Trying to help you with this. A great example is service worker 2.0. It's on GitHub. There's a link here in the slides. And the idea is that you can kind of control caching of your assets in kind of by route. So you say anything that matches slash API slash something don't cache that. Anything that matches slash scripts cache that. But always try to see if it's also on the network. And only show the cache if the network fails. And there's different strategies for handling your cache. And you can do that on a route basis. It's pretty great stuff. So I think the web will win. I think for most purposes the web will win eventually. The biggest drawback now is that Apple don't support service worker. So you should all write an email to Tim Cook. I put his email address up here. So you should write him and tell him you want it. And you want it now. Officially it's the support of service worker is Firefox and Chrome today. Edge is coming there. It's currently in development is what they say. And Apple has got it in its five-year plan. So who knows what that means. Let's talk about new language features. I love JavaScript. But JavaScript is a pretty simple language. And it's evolving. It's getting new features. You guys probably also do some kind of .NET or some C Sharp or whatever. You're used to some of these language features. And now they're actually here. All these features are supported today in Chrome. And I think most of us could probably have a setup today where we're working in maybe some of this. And then we're transpiling all the time. And we're waiting for the browser to reload and the build and all that stuff. But maybe it's time to say. When I'm developing, I can just use the file that I'm working on. Because the browser already supports all this. And then just transpile for compatibility if you have to support older browsers. That might be a way to speed up your workflow today substantially. But let's see some code on that as well. So I thought I would write a push subscription manager. Because I just showed off how to work with push messages in service worker. So I wrote it as a class. Just to show you. Just to show off that you can do that now. So that's line three if you're following along. And if you take a look at line 11, that's where all the service worker stuff goes on. We're registering a service worker, giving it a path to a file. And it's all very promise based. So there's going to be a lot of thenning. Then we're waiting for it to be ready. Because there's an install step where you can actually also hook into the install step from your service worker. And then you can get resources or cache them or something. So there's a hook before the application even loads. And then you say, here I say, I get a subscription if there is one. And if there is one, I'll, you know, and there's some implementation details about updating a button and stuff. But that's not really important. But what you see here as well is a lot of, because it's object oriented programming. And traditionally it's been really weird with JavaScript because of all the this's. But here we do a lot of arrow functions. Or lambda functions. So that's where you see everywhere you see this pattern with a parenthesis and this weird arrow. So that's a function. Think of it like a function in JavaScript. But with this scope of outside of it. So when you're in a class like this, you can still reference this in an arrow function. It will actually be on the class instance. It's a pretty cool feature. It's pretty basic if you're used to any other programming language. But in JavaScript it's almost revolutionary. So did you see that? That was an animation. Also here just a couple of other features. If you take a look at line 44, there's an equals here. And that's a new feature where you can have default parameters on your functions. So you can say, so you can give it, you know, if you're passing in this takes a subscription and you need to have a subscription, you can have some kind of default. And this is actually kind of a nice little pattern where you handed a function instead. Handed an invocation of a function instead. And then I have a mandatory function at the very bottom that just throws an arrow if you call it without anything. So it's a nice little feature to actually have mandatory or required parameters in your code. But you could also just use it for default values. It's a cool little thing. And line 51 is we have square brackets or curly brackets inside of the parenthesis. That's called destructuring. And the idea of destructuring is that you can say I get a big object but I only care about this part of it. So traditionally you'd say, I mean, I'm sure we've all done this where you get a data, you get an HTTP request or an AJAX request back but you only really care about the data of it. You don't care about the headers and all that stuff. So traditionally you said response and then you said bar data equals response.data. And this is exactly the same just without the extra line. So here I could have just. I could have just said subscription and then said var endpoint equals subscription.endpoint. But this just takes it out of it for me. So it's pretty simple. There's a lot more features and I can't show them all. But there are a lot of new cool features coming to JavaScript. And of course, as I said, as a good citizen, this is progressively. So I'm checking if service worker is supported. I start all of this. If it's not, I don't. So the browser won't fail. So I'm checking if service worker is supported and the user won't see it. So a quick demo. We never know if demos work, especially on Wi-Fi. So you see my screen now, right? So this is the local host. This is the exact file you just saw running. There's a subscribe button. When I click it, it calls the unclick callback in my class. And it asks me. Do you want to show? Do you want to allow it to show notifications? And yes, I do. And for the purpose of this demo, I've prepared so it will actually just spit out the curl command I need to run. But it gives you the subscription and the endpoint. And you should send that to your server and store it that way. And then you get to just fire off more or less just a push request from your server or a post request from your server to the endpoint that the subscription will give you. And a push message will show up. So let's pray to the demo gods and see if this works. Are you ready? Woo! Oh, and my wife said something as well. So there's a brilliant talk now in the other room. You should go see that. No, stay here, please. So... Here. Where do we go? Yeah. So lots of cool ES6 here already. And all of this works today. As you can see, there's no transpilation going on. The class, the fat arrows, the destructuring, all of this works today. You should be working with this today and then maybe transpile for compatibility. And maybe also soon we'll have async functions. So the idea of async functions is that you can have... You can write code that looks kind of synchronous while it's actually being asynchronous. So in JavaScript until now, we were doing all this... Well, back in the old days, everything was callbacks. And now everything's promises more or less. But you still get the dot then, dot then, dot then, dot then. And it's not optimal. And it doesn't make your code very readable. And whenever something goes wrong, it's kind of hard to debug. Because there's a lot of anonymous functions within then callbacks. And you don't really understand what's going on. So async functions will let you write stuff like let response be... And then just a fetch request. And then you can just say... If you say let response equals await fetch request, that will hold execution of your code. It won't actually hold it because that would block everything else. But it'll stop the execution there. It'll wait for the response to come back. And then it'll continue on where you're at. And it'll return your code. So it'll let you write much more readable code. Decorators is also a new thing coming. It's kind of a... The idea is that you can attach metadata to functions or to classes or to anything really. It's being used a lot in some of the newer frameworks. Angular 2 is using this very much. And I think also the Ember guys are looking into this. And they're working together on actually making a specification and getting it standardized. So it'll work in all browsers. These things do not yet work. And then observables, of course. Observables is a new big thing. It's kind of like... Yeah, I have that on a new slide. So I'll talk about observables first. So we've seen two new patterns for handling data in your application. And there's the immutable pattern and then there's observables. And the idea is that observable is kind of like a... Like you can register on it and then you'll get notified whenever something changes. So think of your application or your application state somehow. Instead of checking, did you change, did you change, did you change? You can register for it and it'll call you back whenever it's changed and it'll give you... It works. I mean, if this was all it had, it's just pretty cool callbacks. But what it... The power of observables... The power of observables is that they're really composable. So you can have one observable, you can map it through, so you can do operators like you do on arrays. You can for each over them. You can map them, you can filter them, all that stuff. So you can say if you have an observable of mouse events, you could turn that into an observable of fetch requests. So if a mouse event triggers a fetch request, then you can just say mouse.subscribe and then... Put a... Or mouse.map and then you can get the actual fetch request when you move on with it. So it gives you a data flow... It makes your data flow a lot easier. It's a pretty cool thing. You should check it out. The best way to play with observables today is through the RxJS framework. It's built by some guys at Microsoft, I think, and Netflix and other large companies are investing heavily into it. And it's a really cool library that... It's a really cool library that's supported and very widely used. And then there's immutable data. This has been... Maybe last year, this was a really, really hot buzzword. And it came along with React, really. It's a cool feature. The idea is that... Just to be clear, it has nothing to do with the constant keyword. So it's not... You're not setting constants or anything. The idea is that whenever your state changes, it doesn't mutate the current state. It gives you back a new state. And what's the point of that? Well, the point is that what's hard for an MVC app or for any app framework that needs to do something in the view is knowing when stuff changed. And in the good old Angular 1, that was the problem Angular 1 had with performance because we need to check everything all the time to see if it's changed because everything can change anything. And that's kind of weird. And for me, it's weird. For performance, it stinks. But with the beautiful data, you can do a really, really simple, strictly quality check. So you can more or less just say if state equals equals equals new state, then don't do anything. And if it does... If it's not, then there has been a change and you should do your magic and update the view. It's a really, really cool feature. And it's coming to more and more frameworks. I think they're building it into Angular 2. So I think they're... It's a pretty good pattern. It's solid. And of course, because it actually... Because it actually gives you back a new object every time, it has some pretty powerful debugging opportunities because you can... I mean, when you're debugging and you don't care about memory, you could just store all the old states and you can go back and forth in time and see what did my app look like at this stage and this stage and this stage. And you can... It's really good for debugging. So frameworks, we've been seeing a lot of these two. So I won't talk about those, but I'll talk about these maybe. Angular 2, the logo is updated slightly, but it's more or less the same. The framework is really updated though. So they just... I think today or maybe last night, they released the second release candidate and it's close to a final version. Angular 2 is a lot of the great features from Angular 1 in a very... much more modern approach where they took care of all the weird stuff of Angular 1 and they were very heavily inspired by React and some of the other frameworks and it's a pretty cool framework. And there's Aurelia. Aurelia is made by Rob Eisenberg primarily. He used to be on the Angular team, but they had a disagreement over something. So he went out and built his own stuff and it borrows a lot of the concepts from Angular 2, but it is more clean and much more lightweight. And if you like really clean and pure code, you should check out Aurelia. It's cool. But since it is smaller and more clean, there is... well, there are some drawbacks you have to do, some stuff yourself that the framework doesn't handle for you. Then there's the weird Heptagon or whatever it's called. CycleJS. This is a framework built entirely on observables. So if you like observables, you should check it out or at least just for the fun. It's pretty cool. It's like even like if... when you're in React and you're reducers, you should just think of it like React where all the reducers are observables. So it's pretty cool. It's really performant and it's a nice refreshing approach. Then there's Polymer, Google's new framework that's really inspired by how web components work. So it's actually itself a pretty small library. It gives you a lot of cool features for working with web components, especially custom elements. But unfortunately, the entire spec isn't really supported yet. So you still need to ship a polyfill with it in order for it to work everywhere. But it is a pretty cool feature. It is a pretty cool framework and there's a lot of good stuff on it. And it's really easy to plug and play. You can just put in any kind of custom element and Polymer... or you can put in any kind of Polymer element and it's going to work out of the box and it's really, really easy. I see Polymer being the new... I don't know if I'm allowed to say this, but it's the new jQuery plug-in. So it's like whenever you need a date picker or any kind of weird thing that would traditionally go to jQuery to get or jQuery UI, I see in the future it's going to be Polymer elements or something like that. And then there's Meteor. Meteor is a framework. It could be a couple of others, but the idea of Meteor is that it runs not only in the client, but it also runs on the server. So it requires a node server. It runs on your server. It's pretty interesting because it kind of bends your mind about what's going on in the cloud or on the server and what goes on in the client and how they interact with each other. It's a lot of fun. I mean, I wouldn't use it in production, but it's kind of fun. It's pretty cool. You should check it out. Then there's Styling. Well, a couple of years ago, it was like styles hadn't changed for years. We started doing preprocessors like SAS and LESS and Stylus and all those preprocessors to be able to have variables and functions and all that stuff in our CSS and to be able to author in a better way. But the platform is actually coming up to date now. So now we have variables. It's called Custom Properties. And CSS is supported pretty good today. And it's actually way more powerful than SAS variables or something because it's scoped in the browser so you can change properties and say this variable is blue here and it's red over here and it'll actually do all the complicated stuff for you. So it's a pretty cool feature. And then we've gotten a lot of new layout opportunities like Flexbox. You should use that today. If you're not already, it's great to support it. Multi-column, the ability to do magazine kind of layouts where you can do automatic columns where they'll have the same height and you can put gutters and all that stuff. It's a pretty cool feature. And there's the grid. I hate the API, but it's kind of powerful. It gives you a lot of control over how your data, how your elements flow around. Unfortunately, the support for a grid is horrible. And then there's Houdini. Who in here has heard about Houdini? One. That's perfect. So the idea of Houdini is to expose the very low-level APIs that the browser is actually doing when it's rendering stuff. Expose that to the developers from JavaScript. And it's really, really cool. You should check out this. There's a fantastic talk at Google I.O. about Houdini. It goes into a lot of depth about how it works and why and all that stuff. You should check it out. But you know how we traditionally do a lot of this? So we want to set a transform and then we have to do weird string manipulations and put numbers in and strings and put, join weird strings and it's just weird. And then when you read it back, this is the same dom note. I just did this this morning. The same dom note. I just set translate on it. And then when I read it back, it's a matrix. Again, as a string, the parentheses. And it's just weird. You shouldn't have to do this. So Houdini is exposing or wants to expose stuff like this where there's instead of being a style attribute on the element, there's actually a style map where you can say set and then you set the height and then you can actually do numbers and units separately and not as a string. And the same goes for reading it. So this is the reading of height and you'll actually get the value and the unit as two different things. And if you do calculate stuff, you do calc stuff with CSS, you can actually get a map back that says, so it's 50 VHs and then minus 20 pixels. And you can actually read all of this programmatically. This is pretty cool. They built a custom build of Chrome that has this already, even though it's very experimental. But in this custom build, just by, just by looking at it, just by doing this when they read styles and write styles, they speed up the general animation by more than 50%. So just by not converting strings and numbers back and forth all the time, they can do way more frames per second than before. So it's pretty cool stuff. It also lets you register your own custom properties. So you can have properties in CSS that you decide what does and how it inherits and the initial value, especially if you're doing web component stuff, being able to set an initial value is pretty powerful. And the Houdini, it just goes on. It's crazier and crazier. So it'll actually let you do a composite worklet. So you can, again, it's a JavaScript worker, but it's a worklet because it's really, really small and really, really powerful. And this will actually run in sync with your animations. And traditionally, you didn't really want to run stuff synchronously in your animations because it messes with performance. But since this is on a different thread, it actually works really well. That makes you able to actually react to scrolling within the same frame because now the best thing we can do now is react to scrolling within one frame. So we have to wait for the frame to render and then we can measure it and move our frame up with the next frame or our element up. And the idea is that because worklets, they can't access the DOM, when you register your animator, you give it a proxy to especially, exactly the element and the properties you want to listen to or you want to be able to change. And that way, the browser can optimize exactly what goes on and what's allowed to be changed. And this is really, really powerful. And for performance, it's amazing. And it goes on and goes on. This is a function that lets you do a custom image kind of tech that will actually show a default image while it's loading and you can show an error image if it doesn't load and all that stuff. And you can do that. So you don't have to work with it any differently than any other image. So you can have really, really powerful stuff. And if you see, if you're used to working with Canvas, you can see it's kind of like the Canvas API. So you get a context and you can call draw image on it and it's really, really powerful. And the ideas of Service Worker and Houdini and these things is the extensible web. So the idea of the extensible web is that we expose very, very low level APIs. So we can show the APIs to developers to play around with. And to, well, it's not really expected that all of us are going to write stuff like this because it's complicated and it's really, really hard. But the opportunity that you can do it lets frameworks, authors, if you want to play around with some new CSS thing that you're making up in your head, you can actually program your own layout models that will work in CSS using Houdini kind of stuff. That's a fantastic way to work. And so if you're the really nerdy library kind of guy, check this out. Play with it. Start to do library stuff. If you're not, find the libraries that are already out there that works with this and play with it so we can get feedback, so we can have, tell the browsers what we want and how it's going to work. So we're about soon close to done. What else is hot these days on the web? Beacons are hot. So the idea of a beacon is, you know it from hardware, if you're using apps or something. In Apple's land it's called iBeacon, of course. But it's the same thing. The idea is that it gives you like a proximity thing so you can imagine you're at a museum and you walk up to a weird sculpture or something. And since there's a beacon here, your phone will wake up and say, oh, I know what this is. And now beacons can broadcast a URL so you can actually open up your progressive web app that works offline just on your phone. It's really, really cool stuff. And also web Bluetooth. Web Bluetooth just landed in Chrome. So you can actually play around with Bluetooth devices from your browser. It's really, really cool. And since beacons are also made with Bluetooth, there's actually, they're trying to turn it together so you can walk up to something and it'll immediately just give you control over the device since it's Bluetooth. Pretty cool stuff. Then there's instantly loading pages or really, really fast pages. Google calls it accelerated mobile pages. Facebook calls it instant articles, whatever. The idea is that they give you some kind of framework or some kind of tools to make really, really fast and performant pages. And then they'll reward you for it. So if you're looking through your Facebook on your phone, you'll see some articles has a little lightning on it. And if you click it, it'll load instantly. That's instant articles. And if you go on Google and you search for something that's kind of newsy, they'll probably, on your phone, they'll probably show up with instant, like a carousel of pages that shows something about news. And it's actually the real page being rendered. And it's really, really cool. And that's accelerated mobile pages. And then there's request payment API. Google just released this a couple of weeks ago. And the idea is that they're pushing for a standard for handling payments and checkout, really, in the browser. So because checkout on your phone is weird, if you have put stuff in your basket and you have to fill out a million forms and your credit card and all that stuff, this should just live in your browser. So the idea is that you can just call a simple API from the basket where it has all the basket lines. You just say checkout, and then the browser will prompt the user. It knows who the user is. It'll just say, do you want to use the same shipping address as you usually do and the same credit card as you usually do? And the user can just say, yep. And the payment will go through, or Google will hand a token back to you as the developer. And it's really, really powerful. I think this will standardize, and I think in a couple of years, this is going to be the way we do shopping online. The idea is that also with request payment API, you can have third-party applications that can hook into this. So you can have, if you're Danish, you should think of something like mobile pay doing an integration with this. So you can just put up your phone, or maybe you can even authenticate with your fingerprint scanner or something that's in your phone already. Really, really cool stuff. That's a lot of stuff. So the question is, how do we survive in this world where everything changes and everything is new and everything is weird and stuff? First of all, take a chill pill. Take it easy. You don't have to know everything. But you should embrace the extensible web. Try to play with new stuff. Go home and play with Service Worker. Download the Service Worker toolbox. It gives you a lot of stuff right out of the box, and it's progressive. So you can put it on your website, and it will work for users that support it, and users that don't, they shouldn't know the difference. And that might be actually the way that we convince Apple to put Service Worker in. If they can see that all pages load really much faster on Android, they'll eventually put this in so they can be as fast. And use all the new features in dev, like I said. So when you're writing your code today, write ES6, write your classes and all that stuff, and wait. Just compile in your build step when it goes on the server. Don't worry about that when you're developing. And then stay up to date. Read newsletters. Read people's blogs. Use Twitter. Go to conferences like this. Participate in local meetups. And an important point about this is you should also contribute to all of these. So go home, do a talk in your local user group, write on your blog, share whatever you know, even if it's not the coolest new thing. You should share it with people. It will be of help for someone. And when I say this, a lot of people usually say, but what newsletter should I get? So I put this list in here. You don't need to take pictures now. You can just go get the slides. So these are some of the blogs that I read, some of the Twitter profiles I follow, some of the newsletters I subscribe to. Go check that out if you want. So that's it for my talk. Thanks. That was like 46 minutes. I timed it perfectly. We have time for a couple of questions maybe. If anybody wants to ask. Maybe for the video. So do you have any experience in using custom properties in CSS? Not a lot. Not, you know, because you can't really use it in production. So it's more of a playing around so far. Yeah, I was also thinking more about we used to, we're used to concatenating files together and kind of defeat the purpose of not having a preprocessor. You have the, how do you say, you have the good parts of it is having a lot of small files using your CSS instead of having one large code base that you need to handle. Exactly. But I would say the same probably goes for, like with, in development, don't worry about it. So use a million files in development and then just compile it, transpile it all into one file whenever you're pushing it up to production. So you don't have to wait for the build every time. Anybody else? Okay then, come find me afterwards if you think of anything. Thanks.