Throne of JS Summary

Disclaimer

I could be misquoting or mischaracterizing things, sorry in advance.

Frameworks

Core developers from the following frameworks were at the conference:

Backbone.js
Ember
AngularJS
Meteor
Spine.js
Batman.js
CanJS

Role of REST / HTTP

Matt Debergalis, creator of Meteor (and founder of ActBlue) came out with a very provocative statement. He claims web is wearing out and HTTP and REST are terrible for the next generation of applications. He alluded to websocket/web stream and even said HTML isn't here to stay and might not be the best choice for app development. He also said Rails was on it's way out.

Others seem to be more pragmatic and for the current state of affairs, dealing with mainly REST (or local-then-REST) backends.

Role of Rails / Django

There was a lot of laughter around that DHH blog post where "n levels of complicated caching" is the answer to rich client-side apps (even Yehuda chuckled).

Tom Dale (from EmberJS) rejected the fact that javascript is appropriate for the server, "JavaScript ended up in the browser, but I want no part in propagating this happy accident to the server". Applause from most (like me), some boos.

But even the pro-Rails speakers feel Rails is becoming a tool for building REST APIs and dealing with asset packaging (and build/test environment).

Data Binding

Lots (and lots) of talk about implementing data binding to the DOM. Some had pretty simple "live" binding, which really looked slick.

Testing / Developer Tooling

During one of the panels, I asked about testing. The response I got was testing is hard, but the tools are coming. Tom Dale told me about the capybara driver with PhamtomJS. Batman.js seems to have the most framework test coverage.

AngularJS seems to have the best test story, with tools right out of the box ready to go. They also have a cool Chrome plugin that helps with development.

Templates vs. Templateless

One of the key differentiators across some of the frameworks is how they deal with view manifestations. Some take a DOM approach, injecting special attributes into the DOM (AngularJS example):

<ul>
  <li data-ng-repeat="person in people">
    Hello, <b>{{ person.fullName }}</b>!
  </li>
</ul>

While others use string templates, like mustache or handlebars.

<ul>
  {{#each peopleController}}
    <li>Hello, <b>{{fullName}}</b>!
  {{/each}}
</ul>

The advertised advantage of DOM/templateless is you can send it to the browser and have it render before getting data or running any JS. And the lure that designers can work with regular HTML and not learn a templating language.

The disadvantage of templateless, is even with fancy CSS, you can't have non-styled/ignored DOM elements, which can make some UI markup very difficult (tables were mentioned).

State

Very interesting conversation about state. Mainly between Yehuda and Jeremy Ashkenas (backbone.js). Jeremy didn't think trying to have application state tied to a URL was at all a good idea. He thinks your apps should be pure stateless. If you are on a tab in an app, data on the inactive tabs is still active, as all the data bindings would work. Yehuda (and Tom Dale) think for any significant application, this is not reasonable and oversimplified.

Data as Alex MacCaw (Spine.js) or Persistable State as Yehuda (Ember) called it, represents the information that gets stored on the server. This can include session data.

State or Transient State (I guess), is the things stored in JS variables that don't persist.

Some frameworks offer, or you can build, a local client storage -first model where that is the canonical storage for the app, which gets sync'd to the server. This seems obvious for apps wanting to work with imperfect network connections.

Conflicts

Dealing with short-term edits (i.e. update a form, but don't hit submit) was discussed.

Many had a pattern or built-in tools to allow you to "rollback" any edits before hitting submit. Ember has on the roadmap a 3-way merge, like git, to deal with the situation two people edit the same resource at the same time... this sounds awesome to me!

Prototype Lessons Learned

One of the guys from Angular (I think) asked about computed properties in Ember and how the implementation is following similar missteps of not using wrapper functions, like prototype.js.

Summary

Several of the frameworks were highly inspired by the conventions of Rails (batman.js and Ember, for instance). Some promote the use of CoffeeScript. Meteor, although a crowd favoriate, seems a bit too early / experimental to be taken seriously right now.

I will continue to invest in using these tools, and finding reusable patterns. Using backbone.js was a nice start and I would love to try our batman.js and Ember an a real app.

bkaney/tojs.md