EmberCamp 2013 Recap

Despite having neither actual fires or actual camping, EmberCamp was rad. I
had a few thoughts, and then used some electrons and wafers of silicon to
transform those thoughts into words.

Ember is ready for production

Ember has been in alpha and beta for a while, with constant breaking API
changes and lots of rough edges. The highlight of the conference was the
1.0 release candidate announcement.
No more breaking changes! Ember apps that work with 1.0 will work without
modification until 2.0, which basically means you don’t have to be a
masochist/early adopter/hipster to use Ember in production.

Ember Data is not ready for production

If you use Rails, and use the ActiveModel::Serializers
gem, and don’t do anything crazy with your models, and are willing to spend
lots of time reading the source, then Ember Data might be a good fit for you.
The promise of having a single canonical representation for server-side data on
the client is seductive. Unfortunately it is seductive in a “sirens trying to
murder you by making you crash into rocks” way, not in a “delicious jelly
doughnut that you finally give in to devouring” way. The API is not stable or
locked down, and there are major conceptual problems that still need to be
thought through and implemented to make Ember Data robust enough for general
use.

The Ember team is aware of this, and I imagine Ember Data will receive a lot
more love after 1.0 is released, so expect it to improve.

Ember cares about the web

Yehuda Katz spent part of his talk speaking about the unique strengths of the
web. The Ember team wants to make it easy to build apps that are better than
desktop quality by combining the speed and interactivity of native apps with the
accessibility and openness of the web. This means embracing URLs for linking to
each state of your app. The Ember router is designed to give this to you by
default. It also means working with upcoming technologies like
Web Components
and upcoming JavaScript language features like
ES6 Proxies and
ES6 Object.observe to
make development easier and faster.

Also check out Trek Glowacki’s talk about genuinely reusable code
and UI elements. This is still a tough problem to solve, and it is encouraging
to see Ember core people concerned about making the web better.

The Ember Inspector is amazing and I want to subscribe to its newsletter

Yehuda showed off the Ember Inspector, a plugin for the Chrome developer tools
that makes debugging Ember and its abstractions much easier. You can inspect
controllers by clicking on UI elements that are rendered in their context,
easily check out models and their properties, and avoid the frustration of
endless chains of digging deep through the object graph of Ember internals. It
looks really useful and very impressive.

It is not scary to contribute to Ember

There are at least two core team members (Trek and Peter) who are responsible
for making Ember easier to understand and contribute to. Peter manages GitHub
issues and Trek is the documentation czar. If you find a bug, there are smart
people willing to help you track it down and fix it. If you find an area that
is hard to understand or poorly documented, there are also smart people willing
to help you make it better.

Concerns

Or, “Now, with the powers of constructive criticism, I summon people who know
lots about Ember to tell me why I am wrong!”

Ember <3 Rails

The RESTAdapter, the only production adapter that Ember Data ships with, is
optimized for Rails. One of the talks about Ember Data had about as much Ruby
code as JavaScript. Another talk was entitled “Client Side Validations for
Ember”, but the talk was about automatically turning Rails ActiveModel
validations in to JavaScript code.

edit: Tom Dale pointed out that Rails is an easily-targeted platform since
it can emit JSON in a standard format, while other platforms may not have common
conventions on data formatting.

Ember already has the reputation as the “Rails of the client MVC frameworks,”
and there is a real danger that Ember will become the “Rails client MVC
framework.” Why is this concerning? After all, the client has to get data from
somewhere, and Rails is a fine back end to get it from.

The web is amazing partly because it is a meta-platform. HTML, CSS and JS are
general enough that there are dozens or hundreds of different toolchains for
creating apps. This freedom fosters rapid innovation. Tying a client-side
framework like Ember to a server-side framework makes everyone who doesn’t use
that framework a second-class citizen and hurt its adoption.

I understand that by targeting some Ember Data features specifically at Rails,
Ember can appeal to a large exisiting community of developers who follow
a common set of conventions. I would love to see (and am working to produce)
more information on writing an Ember Data adapter if the RESTAdapter doesn’t
fit.

I would also love to see more examples of Ember applications built by tools
other than the Rails Asset Pipeline or Rack::Pipeline. Trek’s
example app
is a good start, as are efforts like Ryan Florence’s ember-tools.
I hope things continue to improve in this area.

Summary

Despite these concerns, EmberCamp was a great experience and I hope to be at the
next one. If you are on the fence about Ember, now is a great time to check it
out.

More Ember notes

Carlos Cardona took detailed notes about each
session if you want to relive the experience before the videos go up.

Acknowledgements

Jamison cares about family and programming and React Rally and Soft Skills Engineering and 🏋️ and 🏂 and computing and business and the Dunning-Kreuger effect. He is a real human bean who you can reach on Twitter.