This year I feel I’ve been more aware of web standards than any time before in my career as a developer. At conferences and in articles shared on the web, we’re starting to hear more about upcoming technologies and new tools we are soon to be able to use on the web. This year we’ve had things like Web Components, Service Workers and the rise of “Progressive Web Apps”, as well as new CSS features like CSS Grid and Custom Properties, finally start to make their way into browsers. With this in mind I thought a great way to kick off this year’s series of 12 Devs of Xmas would be to get a hold of representatives from some of the browsers vendors themselves and see what they thought of this feature packed year and what they’re looking forward to in 2017.

I posed five questions to five developer advocate’s from today’s top browsers:

• Ada Rose Edwards, developer advocate at Samsung Internet
• Jake Archibald, developer advocate for Google Chrome
• Martin Beeby, technical evangelist at Microsoft
• Soledad Penadés, Devevangineer at Mozilla, and
• Shwetank Dixit, who worked in the developer relations team at Opera for 9 years

I also spoke with an advocate to speak about Safari, however sadly they declined to participate. Hopefully next year.

Now, let’s dive into the questions!

To kick things off I wanted to ask what has been your the feature released this year that you feel is already making an impact on how we can build better experiences on the web?

For Jake he’s either been talking about Service Worker or streams lately, so I was not surprised by this answer:

I would say streams! – I don’t think they got as far as I thought they would in 2016, but they’ve showed that a progressive approach to content delivery is the fastest way.

Keeping along the lines of performance Soledad picks out two of her favourite features that will have a massive impact on performance:

Well, I’m torn between two things which are sort of complementary: Service Workers and Let’s Encrypt.

Pardon the terrible comparison, but Service Workers are like eating the mushroom in Super Mario Bros. Suddenly you get all these new cool things you can do, while still being a jumping plumber. But if you do not eat the mushroom you can still be a plumber. Service Workers are like that, if your browser supports them, your website gets lots of additional features that make it better for users, but if the browser doesn’t support them, users can still use the website.

Service Workers help developers take the network factor into account, and build websites that can work faster and more reliably by caching content for later access, amongst other great features. Users can trust the Web again, and developers do not need to write three or four different native wrappers around WebViews that access the same API end point. Happy users, happy developers!

It was really exciting to see websites take advantage of Service Workers soon after we shipped the feature in Firefox. One day we barely saw any registered worker in our developer tools, and the next week there were lots! (if you’re curious to see whether you’ve visited websites which use Service Workers, type about:debugging in Firefox’s URL bar, and go to the ‘Workers’ tab).

And Let’s Encrypt… granted, it was “launched” last year, but it was still in beta. This year has seen tremendous growth, and it is fantastic to see that. This service issues free SSL certificates, which makes delivering secure websites possible for everyone, and this is truly important because new features such as Service Workers only work when your code is delivered with https, for privacy reasons.

Developers had to spend money in a certificate in order to use https. And we want the Web to be secure, but we also do not want to limit access to the Web to just rich developers; that would be against the very principle of the Web! But Let’s Encrypt changes this. People can now get certificates for free, and they will work for everyone, without rightfully scary warnings from browsers.

I’m really pleased to see adoption going through the roof. It’s great!

The theme continues with Shwetank’s talking about what all these features allow us to do:

I think the whole progressive web apps movement got a serious boost this year. Granted that it’s not one single feature, but a set of features working together to create an enhanced experience. Some of these are web specs (like Service Workers, Push Notifications, Web Manifest) and some browser features (Like Add to Homescreen, for which web manifest is needed). Even though some of the work in this regard had been happening last year too, the majority of the improvement and polish in browsers like Chrome and Opera happened this year. This year we finally saw big businesses adopt PWAs as part of their corporate Internet strategy with sites like Flipkart, AliExpress, The Washington Post, Telegram, The Financial Times etc all coming on board. Many of those companies have blogged about how PWAs are already making a positive impact for them on key business metrics.

Me and a few friends from the former Opera Devrel team contribute and maintain a list of great PWAs – I’ll advise anyone getting in Progressive Web App development to go through those sites for inspiration and ideas.

I was starting to wonder if any of the interesting things would be CSS based, but fortunately Ada rescued me there:

CSS Grid – it’s coming out now, will go stable next year and will revolutionise the way we build websites. We can go back to building very semantic html, which renders in a beautiful Grid Layout, removing the need for DIVs for rows of content. It can be feature sniffed with @supports (diplay: grid) {}. This allows one to use it today where it is supported but fallback to something simpler in other cases. As grid support improves, users will get an enhanced experience without you needing to ship a single line of code.

And finally, Martin looks at one of the features that’s helping to improve developer productivity:

For me the biggest change in my own development has been the new features of JavaScript. I’ve adopted a number of the new features and am now using them day in and day out. In some instances I’m using TypeScript to convert the syntax into something that can be deployed to the web, but since most of my work is demoware and Proof of concept I’m often free to use it in it’s pure form.

Whilst you could argue that the syntax I use doesn’t have an impact on the end user experience of what we are creating I would argue that These new features in JavaScript are giving me better productivity and help me avoid simple bugs and so give me more time to add value into my apps rather than writing thousands of lines (or importing libraries) just to implement a specific design pattern.

My absolute favourite feature is Async/Await which reduces the headache of writing complex Promise or Asynchronous code. In this Gist I have added the same function call using plain promises and then in the 2nd example using Async/Await. It ultimately tells the JavaScript engine to do exactly the same thing but the 2nd version is so much cleaner to read particularly if you have lots of nested Async calls.

At 12 Devs we always like to hear about the things that people are interested and excited about, with that in mind, what new feature has you excited about the web and why?

Speaking from recent experience Martin looks at some of the things he’s been building with lately:

I’m building lots of bots recently for Facebook Messenger and Skype using the Microsoft Bot Framework. One of the more common requests we are getting is once the messenger bots are established they want to then have the bot be available through their website too.

This is perfectly possible using the framework and one of the things I have been doing frequently to not only have the bots respond using text but also, via the browsers baked in Speech Synthesis, have the bot speak to the user. You can find an example of the Speech Synthesis over here and a basic implementation example in this Gist. For browsers that Don’t have Speech Synthesis features I’m falling back to cloud based Text to Speech APIs.

Shwetank and Jake continue their theme’s from the previous question as well. First Shwetank:

Going with the progressive web app theme, it is possible that PWAs might be able to be installed as an actual APK soon, like like any other Android app. This has potential to be huge, as this means web apps could be side-loaded into phones and it can appear not just on the Homescreen, but also in the android apps list, along with all other native apps.

Henrik Joreteg has written a nice post about it which should check out.

And Jake:

I’m still excited about streams! Especially what we’ll be able to do with transform streams in 2017. Also, I really hope we can deliver a streaming html fragment.

I’ve seen Ada getting really excited about WebVR in a couple of talks lately, so it’s no surprise to see her answer:

WebVR: since I was child Cyberpunk novels promised this idea of a shared virtual reality that would grow out of the internet!! It’s happening!! It’s still very early days; currently it needs WebGL, but tools like A-Frame allow scenes to be written up in HTML!!

The abilities of the web for authoring content, delivering media and making complex APIs accessible to even the newest developer for free, cross platform, is incredible. This makes it the perfect platform for even novice developers to get stuck in and start building web sites. All you need to get started is a .html file and text editor.

If we can bring this level of accessibility to 3D and Virtual Reality then the cyberpunk utopian future of the web in which we share in experiences made by our own communities will really come true!!

And Soledad goes a bit meta, talking about a whole new browser engine:

Well, it is not strictly a new feature, but a new browser engine: Servo! It is written in Rust, a new programming language, which has modern computing platforms in mind, and takes advantage of all the hardware in nowadays devices in the most efficient way: using multicores, using GPUs, parallelising as much as possible. This is great for speed, and also for energy consumption: using more cores but at slower speeds results in less consumption than one core at top speed. Energy is a huge factor for success in mobile platforms, and the future is mobile.

Unlike older browser engines, Servo is modular by design, which means that parts can be plugged in and out, and even reused elsewhere. This benefits the ecosystem way more than if you have a huge “Browser Monolith repo” where all sources go to die: if you like one of these modules, you’re free to use it. And Servo might even consume modules from the ecosystem as well, even if they have not been specifically written with a browser in mind. It’s a more modern way to develop.

We don’t want to wait until Servo is a feature complete browser, so we are taking parts of Servo and bringing them into Firefox already. We call this Quantum: https://wiki.mozilla.org/Quantum – if you downloaded Firefox sometime after August this year, you have already been running bits of Servo/Rust code in your machine, and there will be more of this in 2017.

I’m very proud that we’ve invested time and resources in building this solid foundation for the future. Even if the results have not been immediately visible, it makes existing websites more performant, enables new use cases, and helps us ensure the Web continues to be a successful platform, ready for all upcoming challenges.

Is there any more obscure feature you’ve stumbled upon by accident that others might not be aware of?

I thought this question might turn up some interesting answers, and I wasn’t disappointed. First Soledad:

I’m always stumbling upon things and going all “WHOAAAA, I didn’t know this existed”!!!

One of the latest is the currentColor keyword – it is similar to a CSS variable in which you can use it wherever you would use a value. This is very helpful if you want to write modular CSS. I wrote a little post and demo about this feature.

I learnt about it from Glenn Maddern’s talk at Cold Front last year in Copenhagen

Not sure if this counts as ‘by accident’, though…

As expected Jake has found so many things! He’s given us a great list to check out:

Ohh a few!

Moving elements out of an iframe while the parser is still writing to it.
The difference between audio decoders across platforms and browsers.
The inconsistencies between canvas+svg+media queries.
How CSS custom properties can be used to manage states
And createContextualFragment, and how it differs from innerHTML in terms of script execution

Next we have some great little features along with some code examples to get to grips with. Starting with Ada’s look at state selectors:

One thing I particularly like is using the checked pseudo selector in CSS to hide/show a subsequent element. This allows you to have dynamic elements powered only through CSS, allowing you to control the behaviour and style of a drop down menu in CSS and it breaks down really nicely in the case that the CSS file fails to load.
e.g.

<label for="toggle" aria-haspopup="true">Click me</label> 
<input type="checkbox" id="toggle"checked /> 
<div aria-label="submenu">Hide me, show me</div> 

input:checked + div {
    display: none;
}

Next Shwetank explores a handy API for working with URLs:

It wasn’t really accident, but in my experience, not a lot of people I talk to are aware of URLSearchParams Try a demo. It can come in pretty handy in certain situations.

Basically, this nifty little API makes dealing with url parameters very easy. Till now, if you wanted to parse, read or manipulate URL parameters, you needed to use regex, which isn’t really that fun. With URLSearchParams, we now have simple getters and setters etc to manipulate them. For example if you have a URL like:

const myURL = new URL('https://example.org/?firstName=Bruce&LastName=Wayne');

then to get the first name, all you need to do is

let fName = myURL.searchParams.get('firstName'); 
// will assign fName as 'Bruce'

Append to the URL with

myURL.searchParams.append('secretIdentity', 'Batman'); 
// value of 'myURL' is now 'https://example.org/?firstName=Bruce&LastName=Wayne&secretIdentity=Batman'

and change it with something like

myURL.searchParams.set('secretIdentity', 'The Dark Knight'); 
// value of 'myURL' is now 'https://example.org/?firstName=Bruce&LastName=Wayne&secretIdentity=The+Dark+Knight'

Eric Bidelman wrote a nice article on it which is worth checking out. Andrea Giammarchi wrote a polyfill for it too.

Finally, Martin has a play with the audio API:

Web Audio isn’t exactly obscure, but I think this use of it is.

If you pop the following code into your console you should hear a continuous tone. (GIST Here).

var context=  new (window.AudioContext || window.webkitAudioContext)();
var oscillator = context.createOscillator();
oscillator.frequency.value = 5000;
oscillator.start();
oscillator.connect(context.destination);

This starts with a tone with a frequency of 5000 which most people with hearing should be able to notice it.

If you create a tone with a frequency greater than 15000 only those under 40 will be able to hear it and a frequency above 17500 can be heard by only by those 18 and younger.

oscillator.frequency.value = 15000;
oscillator.frequency.value = 17500;

This festive season why not turn your speakers up high and use this method (starting at 17500 and then reducing by 1000 at a time) to figure out who is the youngest in your office.

If you want the sound to stop simple run this:

oscillator.stop();

If there was one feature that you think developers should know about or be working with in 2017, what would it be?

Again, Ada’s answer hit’s close to my heart talking about CSS layouts methods we should be using more now:

Flexbox: it is incredibly powerful and I fear not enough developers use it. What you learn in flexbox is applicable with CSS Grids and they can be used to do some marvellous layouts very simply with HTML that looks incredibly neat. BE CAREFUL though because they can be used to change the order of elements which may have bad consequences for people using a screen reader.

Soledad echoes this brilliantly too, it’s time to jump in with Flexbox!

I think it’s time for people to shake off their fears, and embrace Flexbox to build layouts. Support is exceptionally good across browsers, and if you are building a new website you probably have no excuse to not use it.

If you are not building a new website, but working on a existing codebase, use every opportunity to see if you can replace old style potentially problematic code with Flexbox instead. You know, those definitions where sizes are essentially a collection of “magic numbers”, like for example:

.terror {
  height: calc(100% - 195px - 0.7rem);
}

You can often avoid writing this kind of rules by using flex and flex-grow. It will be simpler, easier to read and debug, and more maintainable on the long run.

I like this guide from CSS Tricks on Flexbox – I use it all the time!

Martin takes on a look at something that will change the way we buy things on the web, which is really exciting:

I think the Payment Request API is really interesting. It’s basically the ability to allow the browser to manage the Payments part of an Ecommerce experience. It has a number of potential benefits for the user, in particular it will allow them to use their digital wallets to easily buy stuff on the web and to never have to enter a billing or shipping address ever again. This has the potential to be hugely important, it could even disrupt the dominance of larger Ecommerce sites as transacting with smaller companies will now have less friction. Of course it also has the potential to be a huge flop. Either way, I’m intrigued by the possibilities of it.

Shwetank looks at a spec for improved performance:

The Preload spec. This was implemented in Chromium earlier this year, and I hope in 2017 more browser engines support it.

Basically, by using you can tell the browser to preload some resources that you know will be needed later on for the current page. A common use case for it (though definitely not the only one) would be web fonts.

Right now, you often find web fonts taking time to load even though they are critical resources. This is because most browsers preloaders do a shallow parse of the JS and CSS, which means that Web Font declarations are often missed by them. So now using rel="preload" you can explicitly tell the browser to fetch the resource early because you know you’ll need it later in the page.

Yoav Weiss implemented the spec in chromium and wrote a great article on it over here.

Jake also backs up the focus on the performance aspect of the web too:

Ahh well I’m always going to say “service workers”. But really, anything that improves the performance of unpredictable network conditions.

Finally, looking ahead to 2017 there’s already a lot of exciting looking features that are starting to make their way into stable browsers, like CSS Grid and even WebVR for instance. What’s the next feature you’re excited about seeing begin development and testing in 2017?

In the final question I wanted to see what people thought about the future of the web and some future features we’ll be seeing talked about a lot next year.

Shwetank kicks off this final question with a look at something very interesting that could broaden the reach of the web in the new year:

I really find Web Bluetooth exciting. The ability of the web to talk to physical devices will be amazing. Instead of downloading and installing an app for each of your hardware devices, imagine just opening up your browser and going to a web page to control them. When you’re done, just close the tab. There are already demos involving controlling toys, drones, and other IoT devices. I wrote an article introducing the Web Bluetooth API over here.

Martin has another new one for me, which I’ll be interested in seeing develop next year as well:

I’m really excited by 360 Video. Not just the virtual reality experience of 360 video but even the regular 2D browser experience of it. Take for example this project built using Babylon.JS.

I love the way that they have 360 video and text working together and I suspect that lots of web designers and developers will be working on finding the patterns and practices that make experiences like this main stream.

Following Martin’s look at 360 video, Jake looks at another way we might be working with images on the web next year:

I guess I gave my streams answer earlier, but I’m also excited about createImageBitmap.

It has already landed in Chrome, but the missing bit is being able to rasterise SVG in a worker. Right now it’s difficult to hit 60fps when zooming SVG because it paints on every frame. createImageBitmap would let us do super-fast bitmap transforms while rasterizing shaper versions in a background thread.

Taking over Jake’s Service Worker baton for the final question, Ada looks at a new feature being implemented at the moment which might add another dimension to how we use Service Workers:

I’ve mentioned CSS Grid and WebVR already but another feature I think will be great is a new one for Service Workers: Cross Origin Service Workers and Foreign Fetch! It’s a bit of a mouthful but they will allow CDNs to setup their own service workers. When multiple sites are sharing the same Service Worker then it will greatly reduce the network load for commonly reused resources. Here are some example use cases:

• Large popular library, e.g. THREE.js
• CDN with browser specific libraries e.g. The Polyfill Service
• Large reusable 3D models, e.g. In WebVR it is common to include 3D models of the controller which is being used in Virtual Reality, these models could be downloaded once and used again and again across different domains.

The advantage of all of this is that if you use a popular library the user may already have it cached and ready to go!!

Finally, Soledad looks at one of the things I’m most excited about next year, CSS Grid:

Grid is certainly one of the next big things. Firefox and Chrome just turned it on in the nightly browsers, and we even have support for debugging Grid on developer tools – we’ve worked hard to make sure developers can debug and inspect Grid from the start! And the feature should become available to stable browsers some time next year. Here’s an article talking more about it

In the meantime, it’s a great opportunity to learn and embrace good mark-up practices and Web design, in the sense that designs that take into account the diversity of browser support for various features are great designs.

You can use feature queries and @supports to enable conflicting parts of your CSS stylesheet depending on browser support, so you serve the same mark up code (HTML) and a stylesheet with various @support sections and different browsers will render it differently depending on what they can do. Here’s an article explaining how to do this

And this is not a prediction, but a wish: I would really like to see Safari/iOS support Service Workers in 2017. This would be huge!

And finally we’ve reached the end of our mammoth tour around the top browsers, the new features they’re excited about, and some interesting things you might not have known.

A huge thank you to Ada, Jake, Shwetank, Soledad, and Martin for being involved.