O'Reilly Fluent 2016 – impressions and trends

team-badger-golden-bridge-600
team-badger-golden-bridge-600

Roman and Kadi and I are back from San Francisco and Fluent conference. A week-long escape into the rains and floods of California, with an extra flavour of JavaScript. This was my second Fluent conf, and it’s time to share some takeaways.

For now this is the last Fluent event in San Francisco. It was announced that next year will be in San Jose, and there is also one more Fluent this fall coming up in Amsterdam.

Worthy talks available to watch

All keynotes from day 1 and 2 are available online. To save your time, here’s my favourites:

  1. How NPM split a monolith and lived to tell the tale. Laurie Voss on making large breaking changes without anyone noticing.
  2. Quality, equality, and accessibility - Laura Palmaro on the current state of web accessibility (which has become cutely named 'a11y' because it takes too long to type).
  3. Complex responsive SVG animations by Sarah Drasner.

Douglas Crockford from PayPal also did an intro on The Seif project - PayPal’s own reinvention of the Internet. They are pretty early stage, and their vision is debatable to say the least. They do have good intentions.

General trends and feelings

Last year React / Node combo was something of a novelty, a curious thing to learn. Netflix was doing introductory level talks on React and why they chose it. This year React / Redux / Babel / Node is the default. Dan Abramov's name was mentioned in every other talk. Interestingly, Facebook was pretty much absent from this conf - which is understandable since they are busy having their own React-dedicated events. Notable cool guys on the ground included Google, Netflix, New Relic, Uber, and Léonie Watson doing an epic talk on a11y.

heroku-socks-600
heroku-socks-600

Notable conference swag included Heroku socks

A lot of talks were about interesting ideas or wishful thinking, less of production-ready reality. I suppose this is what webdev is about - there is no platform really, more like a herd of clients and engines somewhat held together by loose rules and standards.

Meanwhile, Brendan Eich was pushing for service workers, WebAssembly and class decorators. He was surprisingly quiet on the sensitive topic of his new browser Brave, which blocks bunches of JavaScript by default.

Two days of talks

The keynotes were followed by five tracks of talks to choose from. Sometimes it was hard. These talks are not available online and will be later published and sold by O’Reilly. I’m going to handpick some quick takeaways from the sessions I attended.

design-process-600
design-process-600

Design process in a nutshell

Accessibility

disability-600
disability-600

Accessibility is still very important. There are lots of different disabilities, and addressing such users is more important than addressing old browsers. Different OS platforms contain different a11y APIs, but with regard to the Web, semantic HTML combined with basic ARIA markup gives a huge heads up for a11y tools to read through your page correctly.

Few personal takeaways:

  • Browser in addition to DOM tree creates separate a11y element tree based on your markup
  • aria-live=“polite” element creates live region on the page, when action on one element affect content of other element. Every time content of live region is affected, screen reader would announce that as soon as it changes. Generally screenreader is unable to jump around the page, and cannot be in two places at once.
  • role="complimentary” when content is incidental but related to the content on page (similar to aside HTML tag)
  • Use tabindex=“0” to allow keyboard focusing on otherwise unfocusable elements

Léonie Watson did a highly practical talk on semantic HTML and ARIA roles. Her screenreader for some reason failed to function when connected to the projector, and so she did the whole talk from memory, without being able to see any slides.

There was also an announcement of the upcoming Web A11y free course on Udacity.

Progressive webapps

Google did a presentation on their vision of web apps and software delivery to the end user. In a way from the user’s perspective there is no difference between web apps and native apps, as long as they behave in exactly the same way. There’s also a negative trend regarding users buying new apps from App Stores, and in general they use only three native apps 80% of the time. Google wants to address issues with web apps lagging behind native apps in terms of offline availability, home screen shortcuts, direct to full screen launching and push notifications. Some of that stuff is already solved. The biggest missing piece is probably offline access, which they claim can be resolved with service workers and an extra layer that intercepts all requests and behaves according to the network availability.

All these ideas have a common name and a site - Google’s Progressive Web Apps initiative.

NPM lifehacks

As an avid npm user I spend a good chunk of time every day typing npm into console. There was a talk with various hints and hidden features that might be pretty useful.

  • npm install when you are offline - npm contains a (huge) library of modules on your machine and can install the relevant module even when you’re offline from the local cache. To do so run npm install --cache-min 999999.
  • npm version [major, minor, patch] will bump version of your npm package and save it in package.json file. You can even auto-commit this with npm version major -m "bump to version %s”
  • npm prune - get rid of all packages in your local node_modules folder that are not explicitly specified in the package.json
  • npm outdated - quickly check for old and outdated packages in your app
  • https://tonicdev.com/ - Node sandbox that lets you require npm packages in the browser
  • NSP is great for maintaining 3rd party security in your Node app (although it is known to be down from time to time).

Monitoring

There were two somewhat orthogonal talks on aspects of monitoring your production apps.

New Relic did a presentation on NR Browser, which is a handy way of getting data about how your users actually perceive the app. It gathers everything that a normal browser would, including JS errors, and time to load pages to the client based in various locations. Server side pages usually load 10-20x faster than client side. There are also a number of most strange JS related errors that can be experienced by users and their (derelict) browsers. You can also detect bad deployments by monitoring spikes of client errors.

Shape Security did a talk on dark traffic. According to them, 92% of the global web traffic belongs to non-humans, which is sort of a pity because you still get all the monitoring alerts, but none of your human users are actually affected. Here lies an interesting question of traffic origin detection. You are likely to only care about human users, but they are a minority nowadays. Most of the bots will also try and pretend to be real humans the best they can. Bots will try to authenticate with real usernames / passwords, which are quite openly available on sites like Reddit/r/pwned, or less openly traded for money on the dark net. Since most users are using the same password everywhere, bots will often succeed in signing in, then will crawl everything they can, and move on to the next site.

Falcor by Netflix

Falcor deserves a dedicated blog post. It is Netflix’s answer to GraphQL and Relay by Facebook - central store and dynamic data fetching combined with request optimisation. Its implementation however is distinctively different from both GraphQL and Relay.

@jhusain did an impressive job to a full house explaining Falcor while live coding an app and getting things to work. We are using GraphQL in our production apps, so my angle was obviously on how Falcor is compared to what we already have. Here are a few takeouts:

  • GraphQL is a query language that allows you to request any amount of resources. With Falcor you request either a single resource or a known range. There is no way in Falcor to ask something like “give me all you have”.
  • JSONGraph for data
  • There is no schema in Falcor - as opposed to GraphQL where you must specify types. This works for Netflix since their production app has something like 6 types of resources.
  • Falcor might be more lightwave and easy to start
  • Current implementations of Falcor are in Node and Java. There is internal implementation for iOS which is not released yet.
relevant-swag-600
relevant-swag-600

I shall come back to this topic and write a more comprehensive blog.Other relevant swag

Workshops day

We also attended a full day of workshops. The first half of the day was about implementing desktop apps with Electron, then we did a session on writing your first language compiler, and finally real time drawing on HTML canvas. Electron was probably most notable out of the bunch - in about three hours we ended up implementing two functional desktop apps from scratch. Roman is going to write more on this topic.

Electron provides you with tools to make native OSX / Windows / Linux desktop apps while using the familiar stack of Node and React. But unlike conventional web apps, you also get full access to the filesystem, no CORS restrictions and the ability to integrate into the system menu. If you always wanted to get your app behind the system tray icon, with Electron you finally can.

Extra activities

job-board-600
job-board-600

Red Badger is hiring and we have an #officedog

The general format over the conf was 30 min talks followed by 15 min breaks. After two or three talks there would be 30 min break. In the middle of the day there was an hour lunch break. Everything started at 9am and finished around 6pm.

Breaks were filled with extra activities you could choose to attend. The main attraction and largest source of swag was the exhibition hall, filled with companies presenting their products and giving out freebies. During the last two days the organisers also moved coffee and snacks to the middle of the exhibition hall.

I should probably mention - we were fed pretty well, considering the scale of the operation.

In the main foyer they also tried to get introverted software devs to talk to each other by having topical meetups, speed networking and lightning talks.

exhibition-oreilly-600
exhibition-oreilly-600
vr-signed-book-600
vr-signed-book-600

Being primarily a book publisher, O'Reilly brought a bunch of authors signing and giving away free books. I got a couple too.

Trip

This trip was possible thanks to Red Badger’s training budget programme. Me, Roman and Kadi had an amazing time, despite the daily dosage of rain. This time I also did daily video log episodes covering our full journey outside of the conference. Yes, we had some fun.

team-badgers-600
team-badgers-600

Team Badgers

I enjoy Fluent mostly because of the variety of topics covered. Writing compilers, programming GPU, WebVR, fending off the evil bots, deploying clusters of containers, debugging performance - there’s something for everyone. So, thanks O’Reilly for making this a reality once again!

If you like the idea of an annual training budget, trips to conferences like this and a big focus on learning, Red Badger could be the place for you. Check out of current vacancies here.