I recently attended the very first JSConf.IS in Reykjavik. It was a great conference and one that I can highly recommend for next year. In this post I wanted to cover off some of my highlights from the conference. I’ve also published another blog post covering some of the evening activities.
The New Mobile Web: Service Worker, Push, and App Manifests
I’ve previously seen talks about service worker which convinced me that one day it was going to change everything. Dan’s talk could probably be summed up as: that day is now. The major features of service worker are now available in Chrome and Firefox, Edge is currently working on it and Safari is considering working on it. Even if those browsers take a while to get on board, service worker apps are fully backwards compatible so there’s nothing to stop adoption now.
If you’ve not come across service workers before you can think of them as
script tags for domains rather than pages. Whilst the web is ubiquitous, it can’t currently be considered resilient because it doesn’t work offline. Service workers can plug this gap by allowing a domain to take complete control over how its resources are cached.
However, they can be so much more than that. As well as offline support, they allow web technologies to deliver other experiences we’ve come to expect from native apps but which have previously required native wrappers to achieve. Examples include, push notifications even when the user isn’t using your site, chrome-less launching from home screen, geo-fenced events, etc..
Already libraries are starting to emerge which offer benefits for service worker supported browsers with little effort required from the developer. An example presented in the talk used a service worker to automatically send patches for updated assets to the client, whilst browsers lacking support continued to receive the original assets. I’m sure performance enhancements such as these will pile the pressure on the other browsers to support the standard.
Pivoting to React, at scale
Tilde talked us through Pintrest’s move to React covering some of the things they did well and things they’d do better next time. It’s worth noting that these are lessons that apply to very large code bases where big-bang migrations are not an option. It was an interesting talk with parallels to many projects Scott Logic has worked on.
My favourite piece of advice relates more to human psychology than anything particularly technical. The rule was very simple: most UIs are composed of nested trees of widgets, when transitioning from framework A to B allow teams to host type-B widgets within type-A widgets but not the other way around.
This rule forces teams to port over all components in a hierarchy and not skip over the “boring” components to play with the “exciting” ones. If you don’t have a rule like this it’s easy to end up stuck with a codebase based on both frameworks, for a very long time. On reflection, Tilde suggested that you might want to specify some top-level exceptions to this to maintain a level of pragmatism but these should be the exception.
Another interesting suggestion, although one that’s probably harder to pull off in real life, is to decouple framework changes from design changes. The rationale being that if you don’t there’s no way to decouple the effect of the changes on engagement metrics i.e. did a user stop using that feature because the design is now awkward or did we introduce a massive bug? I do like the idea but I can foresee a tricky budget conversation when you suggest reworking the same widget twice.
Also in my notes -
- When training up a team in a new framework produce a suggested learning order for the various technologies and sub-frameworks involved.
- If possible when moving between frameworks, you can try to iteratively update the semantics of framework A to be ever closer to framework B to ease the migration.
As if this wasn’t hard enough to wrap your head around, they realised that debugging on the watch was going to be incredibly painful due to the constrained resources available. Therefore, they also transpiled their firmware’s application layer using Emscripten so that they can offer as realistic as possible emulation of your app running on the phone… in your browser…
It was a thoroughly enjoyable talk and a very interesting conversation I had with Heiko afterwards. As someone who’s backed the last two Pebble campaigns it was reassuring to hear the rationale behind some of their decisions and hear a sneak preview of some very useful sounding, upcoming features.
- Make developing on Pebble with JS as simple as
npm install pebble-create-appin a similar way to react-create-app.
- Support hot module reloading. Ideally on the device but the browser-based emulator would be a good start.
- Support for some form of time-travel debugging. If there are the resources to spare, a functional UI approach would allow for rapidly testing e.g. the various edge-cases of watchfaces (midnight, midday, daylight savings, etc.).
I was also disappointed to discover that the latest firmware would remove the ability to navigate into the past (rendering my Mondo Timeline pins pretty useless) but apparently that feature was very rarely used…
Katrina talked us through creating apps with Electron with a demo which featured remote controlling a Sphero BB-8 Droid toy via Bluetooth, from a popup menu launched from the task tray on her laptop. It was a very entertaining demo which was very well received.
My favourite part of the demo was actually something that was very quickly glossed over. In order to allow the whole room to see the small droid do its thing, Katrina had quickly put together a (or possibly grabbed someone else’s) system tray launched chrome-less app, which showed the laptop’s webcam scaled to the size of the window. Despite being so simple, for me it demonstrated the real power of Electron: being able to achieve deep integration with an operating system very quickly and easily, in a very accessible way, all with web technologies.
If you’re interested in finding out more about the security side of using Electron, I’d recommend Dean’s posts on the subject. Or if you just fancy reading making something cool in Electron, check out William’s post.
And much more…
- This will flow your mind, Tryggvi Gylfason - A quick tour of Facebook’s TypeScript competitor. I was interested to find out about it’s unique approach to opting-in to type-checking per file to allow adoption in large projects. Also hat tip to pungenerator.org for its many pun-hit wonders!
- On How Your Brain is Conspiring Against You Making Good Software, Jenna Zeigen - An interesting talk covering an angle of development we talk very little about: we’re not designed for writing software. I particularly enjoyed the discussion of how bad we are at estimating tasks: more formally called the planning fallacy.
- There was also much talk of Guinea pigs, Babel/PostCSS, filthy dirty CSS, WebVR and so very, very, much React (so hot right now!).
Also, don’t forget about the evening’s activities.