HTLM5 Developer Conference 2015

Last weekend I went to HTML5 Dev Conf here in San Francisco and wanted to share my experience.

Despite it’s name (and as you might expect), I don’t think there was a single talk that was truly about raw HTML, and as a sole human being, I didn’t get to sit in every talk I’d like. I did, however, get to hear from some smart folks who have been through large scaling initiatives recently inside companies like Yelp, Netflix, and Microsoft.

The Black and White

I sat in on a few talks from the Netflix folks — mostly regarding the tools they’re using to keep things moving as they continue to grow (Falcor, Node, React, etc.). Apparently their big task over the last year or so was decoupling their business logic from the clients consuming that data. This allowed a more uniform, client agnostic way to consume their back-end (whether it’s mobile native, web, or an ancient dvd player). They were able to use React to their benefit (describing UI vs. describing DOM), with a seemingly large amount of code reuse between clients. In addition, they talked about Node build tools, and how important fast builds and tests are for a scalable team.

‘Your build process is the foundation of your application — treat it accordingly.’ — A misquote from some dude from Netflix who possibly was quoting someone else

I heard someone from Yelp talk about their process of slowly decoupling from their monolithic structure. A true microservice structure didn’t seem to be efficient with a team of ~100 engineers, but splitting up their infrastructure into their traditional monolith (which served a core experience), and then another service (or set of services) which exposed data by other means allowed rapid production of new, domain specific pages. They claimed this gave developers more freedom to deploy things quickly, only requiring what they needed. They interestingly seem to keep all of their CSS/JS/partials in an entirely different repo, stored as isolated components that should work independently from the main app.

I saw a talk on browser normalization which I didn’t find particularly useful, but the person doing the talk was from Microsoft and they were showing off how you can emulate older versions of IE inside Edge, which seemed cool.

The Gray

The trend from these growing products seemed to be the conscious separation from the business logic and their front-end. They wanted to give developers access to the data they needed (in a uniform way) to quickly make unique experiences, without being reliant on the baggage of their back-end. Componentize everything — make data fetching easy and UIs easy to build. To many companies, this seemed to be their answer to keeping velocity high during the process of scaling a team.

This seems to be a continuing trend now that nearly every product is consumed by more than one client — and if this is the state of the future, I don’t know where that leaves the monolithic architectures of yesteryear. I tend to think that the hype often far exceeds the reality of the industry, but it’s always interesting to observe nonetheless.

The Abyss

As a relatively new developer, I don’t have a lot of historical context, but the state of front-end tooling is seemingly in a state of chaos, with frameworks, ideals, and convention all up in the air, competing for dominance in the mind of developers.

Amidst the chaos, one thing that just about everyone could agree on was the imminent domination of ES6 over the Javascript landscape. It’s at a point right now where browser adoption is around the corner and things like Babel are making it possible to use today.

For me though, far and away the most interesting thing was what I continued to hear from attendees when we really would get down into the weeds.

I haven’t even tried X yet — I need to catch up.

Whether it was Node, React, Meteor,, Falcor, Firebase, Gulp, Angular, ES6, Sass, everyone seemed to feel like they behind — like they were missing out on a secret that everybody else knew. The truth was that nearly everybody I met had dealt with a some of these new tools, but because there are so many at our disposal, the majority were often left unexplored.

I am of the personal opinion that some tools might be better than others for some applications, but that great creators will make great things despite the tools they’re given. I will admit, however, that when you’re trying to scale an engineering team at breakneck speeds and sell new hires on the fact that you’re using the latest and greatest technology, maybe that sentiment is not enough. Maybe we will all forever be infinitely behind, and just need to choose our battles a wisely.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.