Archive | OpenSource

The Portsmouth Web Dev meetup is hosted at Alpha Loft in Portsmouth. This month there were two meetings: Ember on the 25th and Lightning talks on the 26th. On the 25th was the first, with Brian Cardarella of dockyard.com giving the main presentation on Ember.js.

Brian started with a bit of a history lesson. Ember spun off of SproutCore from Strobe. SproutCore 1.0 suffered from the slow (at the time) JavaScript runtimes and overly-complex UI widgets, resulting in a poor user experience. The 2.0 branch was started and Yehuda Katz (core contributor, Rails, jQuery and more) and Carl ??? and pushed off UI elements to focus on the core and on speed.

The run loop is the core event loop engine of Ember, and code in Ember can enqueue new items onto the loop, which continues to loop as long as there are items to be processed. There is great documentation in the Ember Guides, and a good video overview. Brian suggests that the Ember Starter Kit is just that, a good way to get started, but likely not appropriately robust for a professional application.

Enough background, we jumped into http://ember.jsbin.com/ and Brian commenced live coding in Ember to demonstrate how the Ember application essentially hooks into the body tag of the DOM and can read and write elements from there. He showed how actions could be triggered by observed changes, that setters and getters were required for property manipulation.

Ember has its own form of MVC (doesn’t everything?) where Models are business rules containers, and Controllers are contexts in which your interactions with models occurs, essentially acting as proxies. Views are nearly becoming deprecated as their functionality is being replaced with HTML5 Web Components (there’s currently a polyfill for these called polymer.) Routes are similar to Rails with nesting. URLs can be considered a state manager for an Ember app, so two users see the same thing at the same URL, unlike some other JS frameworks. There is an Ember Inspector for Chrome and FireFox that allows you to dive deep into the View Tree, Routes and Data for debugging. Excellent peer support is available on IRC at emberjs and emberjs-dev.

Brian and Dockyard have built Ember-AppKit-Rails as a gem to create a shared directory for an Ember app and its Rails backend. Note this is Very Beta, Somewhat Experimental and may be abandoned. You have been warned. Brian explained there are not yet any Best Practices worked out, so different attempts have been tried. Side-by-side projects where the two are separate may turn out to be a better design; Brian is looking at Ember AppKit [Update: Deprecated, but URL updated for reference]. Ember is designed to deal with different backends, depending on their API syntax. The one he was using was ActiveModelAdaptor, build to work with Rails.

An excellent question on “Where do you do validation?” And the answer: pretty much everywhere. Brian is the author of ClientSideValidations and has some experience with this. He tried something similar with Ember but points out that the context of the front end and backends can be so different that the validations aren’t necessarily the same.

Brian then proceeded to do a demonstration of an under-development project by Dockyard and even in its early stages, it appeared pretty promising.

Brian recommended downloading Ember, reading through the Guides, and taking some time to learn the components. Promises are a key element to the Ember framework and are worth reviewing; ECMAScript 6 will have promises built in. Handlebars, the templating language, is expected to be replaced by HTMLBars in the next major revision. Best practices and calling conventions (especially error/exception/validation handling) are still up in the air; check out JSONAPI.org for some work on this front.

So, we had an action-packed, fact-filled, acronym-filled session with a lot of good material and an excellent overview of the state of Ember and its promising future. Thanks for Brian for speaking and for Josh Cyr, Alpha Loft proprietor, for hosting!