A Look Back at O’Reilly Fluent Conference

O'Reilly Fluent ConferenceLast week I attended the O’Reilly Fluent conference on behalf of New Relic. It was both fascinating and completely exhausting. I’ll be wading through the huge pile of information I accumulated there for weeks. And even if only a couple of the tips I picked up pan out, it will have been more than worth my time!

This was O’Reilly’s first stab at a conference focused on JavaScript. Based on the energy level at the show, their timing was impeccable. Almost all of the presentations in the Node.js track were fully attended. There was spontaneous applause in many of the presentations on how to do clever things in the browser and it seemed like everyone was thinking about the challenges of using JavaScript in mobile applications.

Here are a few of the larger themes of the show that struck me:

Node.js Was Everywhere
Given that there still aren’t a lot of venues for Node.js developers to congregate at and that an entire track of the conference was dedicated to it, it wasn’t a surprise to hear a lot of people talking about Node.js. (Speaking of which, I’m super psyched to be attending NodeConf in the beginning of July — find me and say “Hi” if you’re there!) What did surprise me was learning how many people use Node.js in production and in how many different ways. There were even a few presentations (including Dave Pacheco’s mind-bending presentation on postmortem debugging of Node.js apps) that made a convincing case for using JavaScript as a systems programming tool. Node.js isn’t a panacea — there are at least as many situations in which it’s just the wrong tool for the job as there are use cases for it — but it’s encouraging to see all the different uses people are finding for it.

Yet Another Death for the Client-Server Model
Hypermedia APIs with HTML5 & NodeWay over on the other end of the spectrum, some of the most interesting presentations were from teams who have built single-page apps with minimal backend support. (Lea Verou’s keynote took this trend to its ultimate conclusion, showing how to make apps “infinitely scalable” by using no server APIs at all!) SoundCloud demonstrated the new version of their frontend, which is a total rewrite of the user experience, but required almost no changes to the backend API. It’s interesting both as a real-world demonstration of the value of RESTful API design and of the increasing power available to in-browser app developers.

At the same time, one of the strengths of JavaScript is that it’s now possible to run the same language in the browser and the server. As with most things at Fluent, people had a lot of different opinions about this. On the one hand, a framework like Meteor offers the promise of building a single code base and abstracting away having to worry about where, exactly, the code will be running. On the other hand, browsers and server-side environments like Node.js or Meteor are very different, so it pays to design your applications in such a way that you can take advantage of the strengths of both, while attempting to minimize confusion.

Many sessions demonstrated tactical ways to bridge the gap and roll your own packaging systems and asset pipelines to deal with a world where you have as many as a million lines of client-side code.

Drinking From the Firehose
Drinking Our of the FirehoseA thread that wound through the entire conference is that there is just a lot going on. I lost count of how many presenters were asked about a specific tool only to reply, “I don’t know, I haven’t heard of that one.” While there are attempts to tame the complexity of welding together a bunch of client libraries, LESS templates, Backbone models, and the like, it feels premature. There just hasn’t been enough time for the conventions to establish themselves, and JavaScript is so malleable (and GitHub makes it so easy to start and share simple little projects) that it’s possible for people to scratch their own itches with a degree of speed and precision that feels unprecedented.

This is great, but also a little troubling. One of the great strengths of the last wave of web frameworks was how large communities coalesced around them and built a huge, solid framework that everyone could use. (By which I mostly mean Rails and Django. Make no mistake, almost everything discussed at Fluent owes a lot to either them or jQuery, even if removed by a few degrees of inspiration.) Some (including me, most of the time) would argue that one of the strengths of new-school web development is that it offers the ability for you to only pick what you need and keep things lightweight and minimal. It’s not like the other frameworks are going away (some of them have even been undergoing a bit of a renaissance lately.) However, it’s hard to stay on top of things, there are an awful lot of half-finished “good enough” projects out there.

Exciting Progress in Client-Side Development
Overall though, there was a lot of incredibly creative problem-solving on display. Kent Brewster gave a tour de force presentation on writing embedded HTML5 widgets. That was followed the next morning by Gary Flake giving an amazing demonstration of the technology underpinning his newly-live web clipping service. Between them, their presentations advanced the state of the art by several years. I look forward to the knowledge they shared disseminating out into the wider community. Applications like Cloud9’s browser-based IDE and the new SoundCloud are excellent examples of rich media web apps that match (or, in SoundCloud’s case exceed) the capabilities of traditional desktop applications.

I’d be a pretty poor member of the New Relic team if it hadn’t occurred to me that this new school of app development presents significant challenges when it comes to performance monitoring. When New Relic talks about performance monitoring, what it’s really talking about is giving you, as application developers, the confidence that your customers are getting the quality user experiences that will make them enjoy (and keep using) your applications and services. Going forward, one of our challenges will be to figure out how to give you more insight about what’s happening in your users’ browsers, because having a fluent, responsive user experience is at least as important as having a snappy request-response cycle to the web server. Seeing all of the slick, polished work everybody had on display (along with Paul Irish’s great, nerdy talk on the JavaScript Development Workflow of 2013) really brought that home. I left the conference feeling both bone-tired and deeply inspired. There’s a ton of work to be done for New Relic to help you all with these new challenges, and I’m excited to keep doing it!


View posts by .

Interested in writing for New Relic Blog? Send us a pitch!