Web Directions Code 2015: Conference Report

29 Jun 2015 Web Directions Code 2015: Conference Report

Web Directions’ Code is a front end engineering conference that’s been run in Melbourne, Australia since 2012. I was lucky enough to attend this year’s conference, held under the spire at the iconic Melbourne Arts Center.

It featured a number of expert speakers and aimed to provide a refresher on the state of the industry concerning both web development technologies and best practises. This post is a rundown of some of the things I learnt throughout this two day event as well as a detailed look at some of the presentations I found most engaging.

What Comes Next for the Web Platform? – Alex Russell
Widely regarded as one of the most prominent talks from day one was the keynote by Alex Russell. Alex is a software engineer working on Chrome at Google and is also part of the ECMAScript/JavaScript committee among other things, so you can imagine the buzz surrounding his talk.

Alex opened with the declaration that the mobile revolution has happened, an exciting prospect in itself and one that’s hard to deny given the unstoppable transition from desktops to mobiles that’s been happening for years. He went on to look into the problems we’re still having with delivering mobile content, including the cost involved in getting users to download and sign in to your app.

He gave some insightful analogies – referring to app stores as a “lottery” whereby a select few get hugely popular, while a vast majority become “zombie” apps with just a handful of downloads. This in turn leads to “developer poverty” where most app developers won’t make enough off these apps to even pay for their own tools.

His answer to this problem lies in the fact that users are far more willing to find and visit new websites than new apps, despite the fact that a mobile user’s time is skewed heavily towards app usage. He postulated that delivering web content in an app-like format means you can get to more users, with none of the bad experience, and went on to describe a few of the problems in achieving this perfect world:

• Over-reliance on a fast and permanent internet connection (a carryover from the old desktop world)
• Lack of push notifications from the web
• Lack of a pretty home screen icon like we get from apps

But the really compelling part was his solutions these problems:

• The Service Worker API allows developers to cache the contents of a web page for offline viewing (rather than showing a dinosaur, cute though he may be), similar to the app model of presenting “last known” data when there’s no internet connection and syncing to newer data whenever possible
• Chrome allows you to easily add a home screen icon for accessing a web site
• Chrome mobile supports the new W3C standard for push notifications from the web, possible even when the browser isn’t open

And yes, all of these features are available in Google Chrome right now and are on their way to the other browsers (forgive the guy for any bias towards Chrome – he helps develop it). This was a great insight into the future of mobile web both from a developmental and a user experience point of view.

The gap between apps and web may seem insurmountable at times, but the truth is that it’s getting smaller all the time and it’s great to see these features hitting browsers in the real world so quickly. Walking out of the talk many of us felt that putting convenient and accessible content on the web was the way of the future, and that with a little luck we can eradicate the travesty that is developer poverty for good.

Getting Offline with the Service Worker – Chris Roberts
Chris Roberts’ talk proved to be a great follow up. Where Alex’s talk mentioned the Service Worker as part of a multi-pronged approach to making the web behave more like native apps, we experienced a deep dive from Chris (of Expedia, situated in Brisbane, Australia) on how to use the Service Worker in Chrome to cache a webpage for offline use.

As someone who suffers an intermittent data connection on the train into the city every day, and who occasionally has to turn off data to protect their dwindling battery after hours of productive phone use (lets be honest – cat vids), I can relate to the noble goal of making the web accessible when a data connection is not. But these are far from being the best arguments for these features.

There are large parts of the world (particularly in Australia) that are without Internet access at all, affecting visitors and locals alike, and every year the spread of smartphones to third world countries (also with poor Internet availability) increases. The old desktop approach, whereby a failed data connection may be treated as an error, is truly antiquated – this is a situation the majority of users will experience at least some of the time.

Chris’s talk included a demo of how such changes could be implemented and, as in Alex’s talk, it was great to see such lofty goals realised before our humble eyes. I really feel like these sorts of accessibility fixes are going to improve all of our lives in some ways, even if we don’t quite realise it. They may have been spurred by the needs of the disadvantaged but, like more regular accessibility goals such as maintaining a clear layout, high contrast, and not saturating the page with flashing GIFs, the benefits should be realised by web users the world over.

Console Dot – Warwick Cox

One of the surprise hits of event for me was on using the Console API in JavaScript.

This isn’t some theoretical, experimental, new-age technology that we’ll be using in the year 2050. The Console API is something every JavaScript developer has used, but the more people I spoke to the more it became clear – very few developers (myself included) are aware of what it can do.

Far from my previous experience (which involved using console.log() on absolutely everything), the API can also be used to: clear the console of mess so your messages don’t get lost in clutter; time and profile pieces of code; display an HTML element’s DOM; print stack traces; display data structures as a table, and that’s not even all.

It may still be a primitive way to debug your application, but it has its uses and I can’t wait to try some of this stuff out to make life a little easier, or at least to impress my colleagues. Note that there is no ECMA specification for this behaviour, though it seems like the big browsers have settled on a pretty consistent set of actions that can be used. For more detail, look up the documentation specific to your browser.

Current Best Practice in Front End Ops – Alex Sexton
Alex Sexton is a product engineer working at Stripe in Austin, Texas. His talk focused on a curious divide between front end and back end developers, given that the products and services they’re delivering have so many similarities.

While a good back end developer has careful monitoring and logging of errors, a bunch of automations in place to make deployment easier and a strong build process to help enforce quality, the same isn’t often true of the front end developer. Alex’s contention is that this need not be the case, that front end logic and code is not only important enough to warrant the same quality guarantees, but able to be covered to the same extent as well.

I think that this makes a lot of sense in today’s world, but perhaps it wasn’t always the case, and the support afforded to us by the technology we use has long reflected this dark past. Alex covered at a high level a number of tools that can help facilitate this including New Relic Browser for monitoring of performance, an NPM package called Critical which can show only structure-critical CSS for easy cruft removal, SuitCSS – a preprocessor which provides a naming convention to aid scoping, and a surprising mention of the Chrome Developer Tools.

It turns out that, much like the Console API, the DevTools console we know and love is full of advanced profiling and debugging techniques, from breakpoints to connection throttling to flame graphs which have some mind blowing 3D models to describe paint order and performance. These were amongst a number of other great tips, ultimately painting a complete picture of front end things that most of us could be doing, but aren’t.

Conclusion

These examples are far from telling the whole story. These are some of the stories that reached out to me, personally, but there were also fantastic talks on HTTP/2, the latest on animation and displaying videos on the web, some incredibly in-depth looks at the future of asynchronous programming and progressive single page apps, and much more. Finally, the organisers’ promise of “sensational coffee” (the key to a developer’s heart) was no lie.

I’m sure I speak for all attendees when I say I had a great time, learned a bunch and met a number of fantastic people. Can’t wait for next year!