FluentConf 2015 Review

IMG_3634Denver Code Club, the technical study group I help organize, is sponsored by O’Reilly Media, a technical publisher. Among many other community-oriented things, O’Reilly hosts several conferences throughout the year in several locations around the country. This week I had the privilege of traveling to San Francisco and attending FluentConf, their annual event primarily dedicated to JavaScript and front-end web development. As part of their sponsorship, O’Reilly provided me with a pass for two of the three days.


The conference started on Monday, which was a full day of workshops on various libraries and technologies. On Tuesday morning I made my way to the Marriott Marquis, the host hotel. Underestimating commute times during rush hour, I arrived around 9:10a and quickly registered, but sadly missed a few minutes of Paul Irish’s talk on web performance. We heard other talks on how to fine-tune our website page load times, about the JIT Coach feature in Firefox’s debug tools, and how PayPal completely (and successfully) revamped their development workflow. We watched a presenter have a conversation with a robot over a Siri-like web interface. I thoroughly enjoyed the rest of the speakers, especially Brandon Eich’s talk on the future of JavaScript and how Kathy Sierra avoids “death by a thousand cognitive micro-leaks.” The keynote was a great opener for the conference and I left the “salon” excited to learn more.

Over the course of the next two days, I got to hear some big names in the industry give talks, meet peers doing some amazing work, and have my interest in web development reinvigorated.


There were so many talks on great topics, and I couldn’t hear them all, but here are breakdowns of the ones I found most-interesting.

Reative, Composable UIs with React.js

Ben Anderson gave a great talk on Facebook’s React.js and how it’s simplifying the single-page app landscape by introducing the concept of virtual DOM diffs. Data is not 1:1, which helps to avoid “data flying in all directions.” Data goes down the DOM hierarchy, and events flow up.

React prefers code that is functional over object-oriented, clear instead of terse, and stateless over stateful. Ben recommends reading “Functional JavaScript”, by Michael Fogus, and giving the “Thinking In React”  blog post a read. I left excited to embrace simplicity by trying out React.

Automate Front-End Performance

Kitt Hodsden spent her talk teaching the audience about the benefits of performance budgets and how to get started. First, we have to determine key metrics, then establish baseline, (the folks at Etsy have some great examples.) When you make a change, make sure you measure the effects.  This is especially important when “40% of users will abandon a site that takes more than 3 seconds to load.”

We can do this by setting a performance budget, determining key metrics on a per-project basis, and establishing a baseline using the waterfall metric. Tools, like Grunt and Gulp, can help make this easier and Kitt lists out a handful of helpful packages:

  • Remove HTML comments: grunt-contrib-htmlmin
  • Concatenate/minify CSS files: grunt-contrib-cssmin
  • Remove duplicate CSS: grunt-csscss
  • Remove unused/broken CSS: grunt-uncss or grunt-cssstats
  • Generate a sprite: grunt-montage
  • Minimize images (removes metadata): grunt-contrib-imagemin
  • Clean up svg files: grunt-svgmin
  • Responsive images: grunt-responsive-images

She then goes into the benefits of using tools like webpagetest.org, where you can specify test locations around the world. You have the ability to set up your own instance of Webpagetest on your own server, where you aren’t limited to 200 page loads per day. Using this, combined with the grunt-perfbudget package, you can enforce your defined performance budget that can be integrated into CI builds. Additionally, you can track your performance over time using the Webpagetest Monitor and the grunt-wpt package.

Other tools included grunt-yslow, grunt-pagespeed, PSI, sitespeed.io. At the end, Kitt walked us through creating a private Webpagetest instance on Amazon EC2 and consequently blew our minds. This was probably the most eye-opening talk I saw at the conference.

Eliminate JavaScript Code Smells

Master JavaScripter, Elijah Manor, walked us through a handful of JavaScript anti-patterns that we’re all guilty of. More importantly, he explained why they were bad and how to fix them. The theme of the talk was to refactor code to keep things simple and allow for easy unit testing. He highly-encouraged using linting and getting on board with ES6 now. Elijah recommended tools, like jsinspect, to detect copy-pasted, structurally similar code, and that the audience study up on the Open/Closed Principle from Uncle Bob’s SOLID Principles.

My favorite example was the “this abyss,” where he walks through ways to avoid caching the this keyword. I’ll let the rest of his slides speak for themselves (they include more examples that we didn’t have time to get through), but I left the room enlightened and excited to implement what I had learned.

Custom Interfaces with HTML5, JavaScript, and ARIA

Leonie Watson, a usability engineer, walked us through WAI-ARIA, the set of attributes applied to markup that allows manipulation of information. While it doesn’t provide behavior (JavaScript cannot interact with accessibility APIs), it does provide semantics that the browser can use to convey our site’s message to those using assistive technologies (touch, speech, alternative keyboards, haptics). I had never heard of the Accessibility API before, which interacts with the assistive technologies in the browser and then the operating system. She applied everything to an example, which made ARIA far less scary than most of us think it is.


This Used To Be SimpleHenrik Joreteg gave an entertaining talk on the history of web sites and apps. He outlined a story that many of us could relate to and posed the question “What service are we providing?” He encouraged the audience to build modular systems that strive to be as simple as possible (easy to test!) and to optimize for change, as change is the only constant.

Divya Manian walked us through another consistent theme of the conference: how to bridge the gaps between designers and developers. She outlined a handful of things we should consider while designing:

  • Which web-safe font should be chosen
  • What if there’s a poor internet connection?
  • What if CSS3 is too slow?
  • Is the design possible to replicate?
    • Are there other resolutions we should consider?
  • Link Smart Objects
  • Utilize Photoshop CC grids
  • Collaborate on the same units (pixels, points, etc.)
  • Inventory features you will use
  • Use Responsive Frameworks
  • Rough prototype before design

She suggests using the features of design tools that make designing responsive websites easier and suggests leveraging html5please.com and caniuse.com.


O’Reilly puts on a great conference. There are few places I can wander around a complex full of people just as into web development as I am. Here are my high-level takeaways:

  • React.js is the new hotness
  • Learn ES6 today
  • Modular JavaScript is easier to test
  • Learn to how to test modular JavaScript

There were plenty of little things that made the experience so enjoyable. The job board was full of companies hiring and I got to talk shop with people at big-name companies in the halls and at lunch. I was so entrenched in conversation with a peer involved in a healthcare startup that I barely noticed Eric Meyer signing copies of his new book across the table from us.


O’Reilly even created a game to engage attendees with a prize of a FluentConf hoodie. They handed out different stickers at various talks/events. We had to collect all the stickers, which contained snippets of code, put the snippets in the proper order, and run the code on the FluentConf site to get back a number. At the designated time, we had to bring the stickers and the number to the O’Reilly booth to receive our prize. I made sure to introduce myself to the members of the O’Reilly Community Partners group who helped get me there, finally putting faces to names. I even found Denver Code Club on the community partners board!

I had a great time and I’ll be back next year.