- Service Workers add push notifications and offline capabilities to websites;
- Start thinking and building in components with Angular, React and Vue.js
Web apps closing in on native mobile apps
People turn to technologies that allow them to do things they want to do. Back in the days, we’ve all heard from single vendor solutions; Java, Flash, and Silverlight. These techniques were rising to fill the void that was left by the old web; to create richer web experiences. The current state of the open web was not able to deliver that rich experience to the user. The problem with these technologies was that it wasn’t an open standard. With technology becoming an important part of our lives, it’s becoming more important to have an open web that’s available for free. This problem was fixed by the introduction of HTML5; the same experiences, but with an open standard. Nolan Lawson, Web Platform Project Manager at Microsoft Edge, had an awesome talk about this at dotJS.
But looking at today’s situation, Nolan told us we see the same problem happening again; native apps. They introduced offline capabilities, push notifications and background syncing. Again, vendors locking you in. You need to have an iPhone or Android device in order to use most apps that have those features.
According to Nolan, Service Workers is the web’s answer to that threat.
In short: Service Workers add push notifications, offline capabilities and background syncing in your browser. Loving push notifications to stay updated of what’s happening on Facebook? We can now implement these features in websites we use every day, right in the browser. This opens up new possibilities to enhance the experience people have with your website.
When can we use this?
Browsers are experimenting with it. Chrome, Firefox and Opera seem to have already added most of the features. Safari is lagging behind. The irony of this all is that Microsoft Edge, speaker Nolan is part of that team, also seems to be lagging behind. Keep progressive enhancement in mind; Service Workers should be an added bonus.
The term ES6 seemed to be popping up everywhere around the beginning of 2015 and I couldn’t really find any good source of why I should be using this, since most of the features were not implemented yet in the browsers. Most of the features were hard core experimental at that time.
Why use some experimental features, right? This is where Christophe’s talk became interesting.
The thing with new ES features is; these new proposals go through stages in what’s called the TC39 process. This is a committee that is responsible for evolving the ECMAScript programming language and authoring the specification. But, in order to make it to the 4th mature stage — so actually becoming adopted by browsers — those features already have to be in use. Developers already have to work with the new features in order to go to the next stage.
And that’s where Babel jumps in the game.
With Babel you can experiment with those new ECMAScript features right now! Babel transpiles your written ES6 code into code current browsers understand. You write “new” ES6 code and let a task automator like Gulp or Grunt do the transpiling for you on the fly.
Once those ES6 features have reached maturity and are adopted in browsers, Babel automatically removes it from their transpilers, so the browsers read your ES6 code. It’s that simple. Babel actually is the new norm for frontend developers who want to stay on top of the technology and want to use these new features right now. Babel is here to stay because it’s needed to make the language go forward.
Components, components & components
Frameworks like Angular2, React, and Vue.js are based on this component-based architecture and virtual DOM’s to render a complete UI. My my colleague Thom Hos wrote a nice in-depth article about this, and will give a talk about it at TamTam very soon. So I won’t go into it too much in this article.
But, since this topic seemed really big at dotJS, i would like to say a few words about it.
The idea of these components is that you have a single file that contains everything that component needs. So a HTML-based template, logic and — in the case of Vue.js — even CSS inside that component. You can just drop that component in your page and it works. It makes more sense to do it this way, especially with state managers like Redux or Vuex, since this also allows you to share states between components and render the DOM — made of multiple components — according to that state.
Don’t think about the DOM to be a static document where you add logic upon, so the old jQuery way. But think about your DOM as a result of all those components working together and maintaining state.
Why should you use this?
Besides thinking in a component mindset and structuring your development workflow like that, the real benefit is you have an isolated component that renders it’s own piece of DOM. No seperate JS, SCSS and HTML files floating around and thinking about how to structure it all for your development workflow. Just think about a component structure and that’s it. Everything that component needs is already organized in that little file.