9 ms·

Advice On & Instruction in The Use of Ember.js

127 points by tomdale 14y ago

leepfrog 14y ago
fantastic article!
- blktiger 14y ago
  +1
railsjedi 14y ago
Perfect article and explanation. After having bought into Ember a couple months ago and using it heavily, it's been really hard to express to others why it feels so revolutionary. Ember really changes JS development in ways that the other frameworks don't even attempt. And in a way this hurts it in the perception of developers, since it more often than not is just tagged as "too complicated" or "too much to learn". The more great articles like this, and I think there'll be a solid chance Ember catches on in a big way the same way Rails did. With 1.0rc, the tech seems to be solid enough now and it just needs a push on the other stuff (education, marketing, etc). And most importantly: some more successful Ember apps out in the wild (I'm working on that one).
- MatthewPhillips 14y ago
  But Rails was built for a different world, so trying to recreate what made Rails nice in the browser feels like an answer searching for a problem. Client-side JavaScript frameworks should be compared to UIKit and the Android SDK, not to Rails, which was only interested in routing, fetching, and rendering. Giving me code organization without giving me structure is only helping with a tiny sliver of the problem.
  - railsjedi 14y ago
    Sorry, I just meant compared to Rails in terms of impact. Ember is nothing like Rails architecturally. There's a good comparison here: http://emberjs.com/guides/ember_mvc/ http://emberjs.com/guides/ember_mvc/ So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).
    - MatthewPhillips 14y ago
      Those are implementations details, to the developer they serve a similar purpose. This is my problem with it, a web framework that gives equal weight to M, V, and C is missing the point; in the client the View is fucking everything. It is where any developer will spend the vast majority of their time; not in code organization. The frameworks and I mean this plurally, that win will be those that give structure to applications. Here's how the Android SDK provides structure to applications: http://developer.android.com/design/patterns/app-structure.html http://developer.android.com/design/patterns/app-structure.h.... Web frameworks need the same thing. They should ship with HTML, JS, and CSS.
      - erikbryn 14y ago
        Perhaps you'd be a fan of SproutCore?
      - wycats 14y ago
        Just because a framework has models, views and controllers does not mean it gives them "equal weight".
      - wycats 14y ago
        Just because a framework has models, views and controllers does not mean it gives them "equal weight".
      - jguimont 14y ago
        Then you do not understand what M and C does. It might be called a client but it is a stateful client. Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app).
        MatthewPhillips 14y ago
        > Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app). That's because we're not writing good reusable views. We're writing one-off views that corresponding to the current needs of the current application we're working on. Here's a good view: http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UITabBar_Class/Reference/Reference.html#//apple_ref/doc/c_ref/UITabBar http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/... It was created 5 years ago and I'm pretty sure it's got a lot of life left in it still.
fusiongyro 14y ago
Here's my petition for the site to join the contrast rebellion: http://contrastrebellion.com/ http://contrastrebellion.com/ The page is basically unreadable in FF 7.0.1 on RHEL 5.3. I realize light grey on white with a really thin font is dead sexy on your Mac (probably looks great on my home computer as well) but it's useless to me at work.
- arnarbi 14y ago
  I'm on a pretty nice mac, and it is basically unreadable without either zooming a lot or using some css switcher.
- majormajor 14y ago
  IME light-gray on white actually tends to be more readable on PCs than Macs due to the still-rather-different default gamma setup/color profiles. Cheaper PC screens especially often default to darker, bluer shifts. I normally hate comments that simply criticize something not related to the content of the article, but in this case I found the lack of contrast made the article basically unreadable (on a MBP, using either the internal screen or a nice external display).
- natrius 14y ago
  Readability link: http://www.readability.com/articles/3eiyua1p http://www.readability.com/articles/3eiyua1p
- trek 14y ago
  I agree. You should take this up with the Github page folks, specifically https://github.com/orderedlist https://github.com/orderedlist. It's his template.
  - fusiongyro 14y ago
    Thanks for changing this. You didn't have to, but it really helps, and I'm looking forward to really giving it the close read it deserves tomorrow.
adamnemecek 14y ago
Speaking of which, can anyone recommend good ember.js resources and/or open source projects? Something that is not a todo list would be great.
- railsjedi 14y ago
  pangratz has created an awesome example dashboard app (along with source) http://code418.com/ember.js-dashboard/ http://code418.com/ember.js-dashboard/. He also wrote up a dev blog series on it: http://code418.com/ http://code418.com/
- davemo 14y ago
  iWitness [1] is a great example of a non-trivial ember app. They released the source [2] as well. [1]: http://iwitness.adaptivepath.com http://iwitness.adaptivepath.com [2]: https://github.com/adaptivepath/iWitness https://github.com/adaptivepath/iWitness
shocks 14y ago
http://emberjs.com/ http://emberjs.com/ The font here really sucks, for me anyway. I cannot see the "cross" of the t. It just looks like an l. Anyone else see this?
inetsee 14y ago
Can anyone tell me whether a website built with Ember.js's default settings suffers from the same readability problems with font and contrast? If so, that tells me that I probably won't want to invest any time in learning to use Ember.js.
- tomdale 14y ago
  Is this a serious question, or just snark? Ember.js does not ship with a default stylesheet—it's up to you to style. It just generates plain HTML.
  - inetsee 14y ago
    This was a serious question. My vision is not what it was when I was younger. I am finding more and more websites are very difficult for me to read, and this one was unreadable for me without the help of Evernote's Clearly extension. I am a firm believer in the utility of web frameworks, and I'm always willing to look at new ones. I assumed that the tutorial website had been built using Ember.js, and my first impression was not favorable.
    - inafield 14y ago
      You may need to adjust your monitor settings or buy a new monitor. The difference between #232323 and #FBFAF7 should be enough contrast. The Trek logo is even higher contrast as #FFF and #171717.
      - mikejarema 14y ago
        I believe trek has updated the site's theme in the interim. I was also having some contrast and font size issues, and the new theme definitely addresses my complaints.
judofyr 14y ago
Let me tell you why I don't care about Ember.js at the moment: It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time. Of course, some parts might require more dynamicness than other, and in that case it's lovely to jump to client side MVC. But it doesn't seem that Ember.js wants to play this game. Every time I look at Ember it seems that it wants to define the architecture of my application. Thank you very much, I like my stateless-ness very much!
- erikbryn 14y ago
  There's nothing stopping you from having only certain parts of a page or application use Ember. Several people use this approach successfully. See the `rootElement` property of `Ember.Application`: http://docs.emberjs.com/#doc=Ember.Application&src=false http://docs.emberjs.com/#doc=Ember.Application&src=false
- wycats 14y ago
  > I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time I take it that all of your applications involve public content with minimal if any enhancements to logged in users?
  - judofyr 14y ago
    Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site. No silly "double loading"; easy to bookmark; links I can Cmd-Tab; the page doesn't magically fail when my internet connection is broken. I am aware of that most the issues with single-page applications comes from the applications themselves, not the architecture (i.e. is the developers', not the technology's fault) but there seems to be quite a lot of complexity with this architecture. I've seen very few applications that handles all of these issues.
    - 14y ago
tgriesser 14y ago
With regards to view cleanup code in Backbone - in the github develop branch [1], the view is now a little more active in its memory cleanup. A dispose() function was recently added which removes any handlers added in the view's 'events' object, as well as any collection or model listeners where the view is passed as the third argument (callback context). This function is also called by the view's .remove(), taking care of the majority of basic memory cleanup needs when the element is cleared from the screen. [1]: https://github.com/documentcloud/backbone/commit/3ae1af6df1b542bfb3e38f2fdfe7a471f2b830a0 https://github.com/documentcloud/backbone/commit/3ae1af6df1b...
- judofyr 14y ago
  You can also use Coccyx [1] which clears events on all objects (not just this.model and this.collection) and also adds recursive view disposal. [1]: https://github.com/onsi/coccyx https://github.com/onsi/coccyx
skilesare 14y ago
I've now shipped an Ember.js application and a knockout.js application. I enjoyed ember quite a bit but feel that knockout gives me all the magic with half the complexity. It is true as the author mentions that it doesn't aim to fix the UI/statefullness issue, but I slapped on Backbone Routing on to my knockout code and it made capturing 'state' and urls a breeze. The last time I used ember was 0.9.6 and I don't think this routing stuff was even in it so I was excited to see talk about it. Unfortunately it looks to be even more complicated then I expected it to. :( Knockout may be creating some massive memory footprint in the background that will bite me down the line, but I'm writing significantly less code than I was with Ember. For example, In ember you have to create view objects and if you want your view objects to sync data with your controller you have to explicitly define them: App.userController = Ember.Object.create({ content: Ember.Object.create({ firstName: "Albert", lastName: "Hofmann", posts: 25, hobbies: "Riding bicycles" }) }); App.UserView = Ember.View.extend({ templateName: 'user', firstNameBinding: 'App.userController.content.firstName', lastNameBinding: 'App.userController.content.lastName' }); Now I get to do my handlebars template <script> <div>{{firstName}}</div> </script> In knockout just have to do: App.UserController = { content = ko.observable(new content()); } ko.applyBindings(App.UserController); And now I get to do a knockout template inline with my html: <div data-bind="text: content.firstName"></div> It just seems like there are fewer steps with knockout and I'm getting more done. The html is a lot uglier, but it also clearer what is going on when I read it. The ember guys have come a long way on their doc and they should be commended on it. I like the patterns they are talking about I'm just not sold that it has to be done the way they are doing it. Thanks to the author for putting together such an in depth post to me in the right direction in getting back into Ember.
- benatkin 14y ago
  I posted it as a gist on github for better formatting. I hope you don't mind. :) https://gist.github.com/3517051 https://gist.github.com/3517051
  - benatkin 14y ago
    Note: the author of the article (trek) posted a comment on the gist, so it's worth a look even if you've already read skilesare's comment.
adolph 14y ago
This is such a timely article, thanks! I was just listening to the video on this week's JavaScript Weekly and considering where to start among the js application frameworks. It would be nice if the author expanded on the different categories of js app frameworks. Video: Beyond the DOM: Sane Structure for JS Apps: http://www.youtube.com/watch?v=cd7HHN6IkrU http://www.youtube.com/watch?v=cd7HHN6IkrU
drek 14y ago
Does anyone else thing that the documentation for ember.js is really lacking? Some of the classes it has aren't even documented (ContollerMixin comes to mind) and others are lacking in the documentation depratment. Also, I don't seem to be able to find a full listing of instance methods for a class, I have to climb up the inheritance tree in the docs class by class.
- Vekz 14y ago
  I have to agree. I found my self reading the source a lot while working with ember. That lead to discovering said hidden classes like ControllerMixin.
programminggeek 14y ago
Ember looks cool, but knockout lets me ship fast and it's less "magic". Also, I think single page apps have a place as part of a greater architecture, but not as the entire app. If I wanted an entire app everything to be JS, fine, use Ember or something like it, but most parts of the web don't need this and single page apps make the web a bit worse if not done correctly. Single page apps are the new hotness, but once the fad is over and the newness wears off, they'll be fit into their proper place over time and won't take over the entire app.
- wycats 14y ago
  > Ember looks cool, but knockout lets me ship fast and it's less "magic". I'd appreciate it if you could quantify what you mean exactly by "magic". For example, one key difference between Ember and Knockout is that Ember's binding system automatically avoids triggering the same side-effect from multiple pieces of code. For example, if you had a piece of the DOM that was calculated from several observables (the stupid example is a full name calculated from a salutation, first name and last name), and made changes to all three of those in separate lines of code (possibly in different areas of your codebase), Ember would ensure that the DOM only updated a single time, not three times. This is true no matter where the three lines of code are, without you needing to take any special action to coalesce the changes. This aspect of Ember's codebase adds some magic, in that it introduces a higher-level abstraction that knows about computed properties and their side-effects (the "run loop"), but the end result is more predictable propagation of side-effects in an Ember application. Ember applications don't need to know about the specific mechanism that makes this work, but good Ember developers are aware that many side-effects happen asynchronously in an Ember application. The browser does something similar when you make changes to DOM structures: it only updates the rendered version of the DOM once all of the JavaScript code handling an event has completed. I would agree that something simpler would probably be a better fit for simple "islands of richness" on an existing application, but there are definitely a large number of applications with significant amounts of logic happening on the client side, even if those applications run inside of an area of a larger traditional page. In general, I would say that Ember is a good fit for applications that will end up with more than 100k of application code. That sounds like a lot of code, but it's really only a lot of code for islands of richness. Applications like rdio, documentcloud, soundcloud and other popular Backbone applications can easily reach 500k or even a megabytes or two of code.
deleted 14y ago
[deleted]
richardjordan 14y ago
I've been looking for a decent tutorial on EMBER as someone who's of merely limited programming talents and abilities. I love what I've picked up so far, and I'm going to work through this tutorial now. Thanks OP for the work put in on this.
aidos 14y ago
For anyone trying to follow along with the tutorial beware that there's a typo the whole way through the code that stops it from running. connnect -> connect
Vekz 14y ago
Glad to see this article. The recent buzz around convention and best practices in Backbone.js has been frustrating. A lot of the recent Backbone discussion are issues that have been thoughtfully addressed in Ember.js. I feel that Backbone.js was first on the scene and hence has found its way into the current developer lexicon and toolset, leaving Ember.js unfairly looked over.
KaoruAoiShiho 14y ago
As I said in another thread, despite hilarious disagreement by jashkenas, http://news.ycombinator.com/item?id=4427974 http://news.ycombinator.com/item?id=4427974 that Backbone is perfect for big projects so long as you build on top of it with other libraries. Ember.js is just too opinionated for its own good.
robotmay 14y ago
Do any of these JavaScript frameworks have decent documentation yet? API docs are all well and good, but I'd really like some examples other than to-do applications. All they really need is an equivalent to the Rails guides at http://guides.rubyonrails.org http://guides.rubyonrails.org, which are ample. Frankly I'd take any example application over a to-do app at this point. As an aside, I've been using Sammy.js (http://sammyjs.org http://sammyjs.org) more than most of these other frameworks lately, as the effort involved is disproportionate to the rewards unless you're building the entire frontend in JavaScript. For any less-than-enormous project, you really don't need all that complexity.
- te_chris 14y ago
  Ember's getting there. Check out the "Guides" section on emberjs.com
- bertomartin 14y ago
  Heard about sammy, but never looked into it until now. It looks really interesting. I've been looking at emberjs for the past couple of days and I do like what I see, but I always felt it was a little too heavy for what I really wanted. I'm just not ready to make my app just an api enpoint...it's just too much abstraction. Regardless, I'll continue to follow emberjs.
tberman 14y ago
As the guy who wrote the first bits of the Rdio code in question, it seems worth mentioning that the part in question has nothing to do with Backbone, or Ember, or anything else. That code is a cleanup function on an object that helps to abstract HTML5 <audio> vs our Flash fallback. No matter what framework you are using, if you are solving the problems that we are solving, you are going to end up with that code. Now, that said, I agree that learning all of the frameworks out there is advantageous, but you can't assume that the code in the blog post is indicative of anything having to do with Backbone or any other framework.
- marcelvr 14y ago
  Thanks for the comment. Before reading it, I admit to being lured into thinking the code in TFA was there to clean up after Backbone. Sneaky bit of writing...
- trek 14y ago
  Is this entirely true? Clearly cleanup of event names like "loadedmetadata" is related to the audio element but '_bubbleProfilingEvent', '_logEvent', and general .unbind calls are on backbone-related objects, yeah?
  - jmtulloss 14y ago
    The only backbone related code in that snippet is the .unbind() call and the .trigger call. This is needed because this is our wrapper around the media element; it is an event emitter. If you're going to make something emit custom events, you'll need code to emit them and clean them up when you're done. One area where backbone is lacking is lifecycle management. You do sometimes have to unbind things in order to prevent leaks. Backbone is very minimal in this regard. At Rdio, we've built our own tools on top of Backbone to abstract lifecycle away from the developer as much as possible. That being said, that weakness isn't illustrated in the code example picked by the blog post.
throwa 14y ago
Emberjs in production: https://github.com/emberjs/ember.js/wiki/Production-Deployments-Page https://github.com/emberjs/ember.js/wiki/Production-Deployme...

127 points by tomdale 14y ago

leepfrog 14y ago

fantastic article!

blktiger 14y ago
+1

railsjedi 14y ago

Perfect article and explanation. After having bought into Ember a couple months ago and using it heavily, it's been really hard to express to others why it feels so revolutionary. Ember really changes JS development in ways that the other frameworks don't even attempt. And in a way this hurts it in the perception of developers, since it more often than not is just tagged as "too complicated" or "too much to learn". The more great articles like this, and I think there'll be a solid chance Ember catches on in a big way the same way Rails did. With 1.0rc, the tech seems to be solid enough now and it just needs a push on the other stuff (education, marketing, etc). And most importantly: some more successful Ember apps out in the wild (I'm working on that one).

MatthewPhillips 14y ago
But Rails was built for a different world, so trying to recreate what made Rails nice in the browser feels like an answer searching for a problem. Client-side JavaScript frameworks should be compared to UIKit and the Android SDK, not to Rails, which was only interested in routing, fetching, and rendering. Giving me code organization without giving me structure is only helping with a tiny sliver of the problem.
- railsjedi 14y ago
  Sorry, I just meant compared to Rails in terms of impact. Ember is nothing like Rails architecturally. There's a good comparison here: http://emberjs.com/guides/ember_mvc/ http://emberjs.com/guides/ember_mvc/ So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).
  - MatthewPhillips 14y ago
    Those are implementations details, to the developer they serve a similar purpose. This is my problem with it, a web framework that gives equal weight to M, V, and C is missing the point; in the client the View is fucking everything. It is where any developer will spend the vast majority of their time; not in code organization. The frameworks and I mean this plurally, that win will be those that give structure to applications. Here's how the Android SDK provides structure to applications: http://developer.android.com/design/patterns/app-structure.html http://developer.android.com/design/patterns/app-structure.h.... Web frameworks need the same thing. They should ship with HTML, JS, and CSS.
    - erikbryn 14y ago
      Perhaps you'd be a fan of SproutCore?
    - wycats 14y ago
      Just because a framework has models, views and controllers does not mean it gives them "equal weight".
    - wycats 14y ago
      Just because a framework has models, views and controllers does not mean it gives them "equal weight".
    - jguimont 14y ago
      Then you do not understand what M and C does. It might be called a client but it is a stateful client. Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app).
      - MatthewPhillips 14y ago
        > Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app). That's because we're not writing good reusable views. We're writing one-off views that corresponding to the current needs of the current application we're working on. Here's a good view: http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UITabBar_Class/Reference/Reference.html#//apple_ref/doc/c_ref/UITabBar http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/... It was created 5 years ago and I'm pretty sure it's got a lot of life left in it still.

fusiongyro 14y ago

Here's my petition for the site to join the contrast rebellion: http://contrastrebellion.com/ http://contrastrebellion.com/ The page is basically unreadable in FF 7.0.1 on RHEL 5.3. I realize light grey on white with a really thin font is dead sexy on your Mac (probably looks great on my home computer as well) but it's useless to me at work.

arnarbi 14y ago
I'm on a pretty nice mac, and it is basically unreadable without either zooming a lot or using some css switcher.
majormajor 14y ago
IME light-gray on white actually tends to be more readable on PCs than Macs due to the still-rather-different default gamma setup/color profiles. Cheaper PC screens especially often default to darker, bluer shifts. I normally hate comments that simply criticize something not related to the content of the article, but in this case I found the lack of contrast made the article basically unreadable (on a MBP, using either the internal screen or a nice external display).
natrius 14y ago
Readability link: http://www.readability.com/articles/3eiyua1p http://www.readability.com/articles/3eiyua1p
trek 14y ago
I agree. You should take this up with the Github page folks, specifically https://github.com/orderedlist https://github.com/orderedlist. It's his template.
- fusiongyro 14y ago
  Thanks for changing this. You didn't have to, but it really helps, and I'm looking forward to really giving it the close read it deserves tomorrow.

adamnemecek 14y ago

Speaking of which, can anyone recommend good ember.js resources and/or open source projects? Something that is not a todo list would be great.

railsjedi 14y ago
pangratz has created an awesome example dashboard app (along with source) http://code418.com/ember.js-dashboard/ http://code418.com/ember.js-dashboard/. He also wrote up a dev blog series on it: http://code418.com/ http://code418.com/
davemo 14y ago
iWitness [1] is a great example of a non-trivial ember app. They released the source [2] as well. [1]: http://iwitness.adaptivepath.com http://iwitness.adaptivepath.com [2]: https://github.com/adaptivepath/iWitness https://github.com/adaptivepath/iWitness

shocks 14y ago

http://emberjs.com/ http://emberjs.com/ The font here really sucks, for me anyway. I cannot see the "cross" of the t. It just looks like an l. Anyone else see this?

inetsee 14y ago

Can anyone tell me whether a website built with Ember.js's default settings suffers from the same readability problems with font and contrast? If so, that tells me that I probably won't want to invest any time in learning to use Ember.js.

tomdale 14y ago
Is this a serious question, or just snark? Ember.js does not ship with a default stylesheet—it's up to you to style. It just generates plain HTML.
- inetsee 14y ago
  This was a serious question. My vision is not what it was when I was younger. I am finding more and more websites are very difficult for me to read, and this one was unreadable for me without the help of Evernote's Clearly extension. I am a firm believer in the utility of web frameworks, and I'm always willing to look at new ones. I assumed that the tutorial website had been built using Ember.js, and my first impression was not favorable.
  - inafield 14y ago
    You may need to adjust your monitor settings or buy a new monitor. The difference between #232323 and #FBFAF7 should be enough contrast. The Trek logo is even higher contrast as #FFF and #171717.
    - mikejarema 14y ago
      I believe trek has updated the site's theme in the interim. I was also having some contrast and font size issues, and the new theme definitely addresses my complaints.

judofyr 14y ago

Let me tell you why I don't care about Ember.js at the moment: It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time. Of course, some parts might require more dynamicness than other, and in that case it's lovely to jump to client side MVC. But it doesn't seem that Ember.js wants to play this game. Every time I look at Ember it seems that it wants to define the architecture of my application. Thank you very much, I like my stateless-ness very much!

erikbryn 14y ago
There's nothing stopping you from having only certain parts of a page or application use Ember. Several people use this approach successfully. See the `rootElement` property of `Ember.Application`: http://docs.emberjs.com/#doc=Ember.Application&src=false http://docs.emberjs.com/#doc=Ember.Application&src=false
wycats 14y ago
> I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time I take it that all of your applications involve public content with minimal if any enhancements to logged in users?
- judofyr 14y ago
  Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site. No silly "double loading"; easy to bookmark; links I can Cmd-Tab; the page doesn't magically fail when my internet connection is broken. I am aware of that most the issues with single-page applications comes from the applications themselves, not the architecture (i.e. is the developers', not the technology's fault) but there seems to be quite a lot of complexity with this architecture. I've seen very few applications that handles all of these issues.
  - 14y ago

tgriesser 14y ago

With regards to view cleanup code in Backbone - in the github develop branch [1], the view is now a little more active in its memory cleanup. A dispose() function was recently added which removes any handlers added in the view's 'events' object, as well as any collection or model listeners where the view is passed as the third argument (callback context). This function is also called by the view's .remove(), taking care of the majority of basic memory cleanup needs when the element is cleared from the screen. [1]: https://github.com/documentcloud/backbone/commit/3ae1af6df1b542bfb3e38f2fdfe7a471f2b830a0 https://github.com/documentcloud/backbone/commit/3ae1af6df1b...

judofyr 14y ago
You can also use Coccyx [1] which clears events on all objects (not just this.model and this.collection) and also adds recursive view disposal. [1]: https://github.com/onsi/coccyx https://github.com/onsi/coccyx

skilesare 14y ago

I've now shipped an Ember.js application and a knockout.js application. I enjoyed ember quite a bit but feel that knockout gives me all the magic with half the complexity. It is true as the author mentions that it doesn't aim to fix the UI/statefullness issue, but I slapped on Backbone Routing on to my knockout code and it made capturing 'state' and urls a breeze. The last time I used ember was 0.9.6 and I don't think this routing stuff was even in it so I was excited to see talk about it. Unfortunately it looks to be even more complicated then I expected it to. :( Knockout may be creating some massive memory footprint in the background that will bite me down the line, but I'm writing significantly less code than I was with Ember. For example, In ember you have to create view objects and if you want your view objects to sync data with your controller you have to explicitly define them: App.userController = Ember.Object.create({ content: Ember.Object.create({ firstName: "Albert", lastName: "Hofmann", posts: 25, hobbies: "Riding bicycles" }) }); App.UserView = Ember.View.extend({ templateName: 'user', firstNameBinding: 'App.userController.content.firstName', lastNameBinding: 'App.userController.content.lastName' }); Now I get to do my handlebars template <script> <div>{{firstName}}</div> </script> In knockout just have to do: App.UserController = { content = ko.observable(new content()); } ko.applyBindings(App.UserController); And now I get to do a knockout template inline with my html: <div data-bind="text: content.firstName"></div> It just seems like there are fewer steps with knockout and I'm getting more done. The html is a lot uglier, but it also clearer what is going on when I read it. The ember guys have come a long way on their doc and they should be commended on it. I like the patterns they are talking about I'm just not sold that it has to be done the way they are doing it. Thanks to the author for putting together such an in depth post to me in the right direction in getting back into Ember.

benatkin 14y ago
I posted it as a gist on github for better formatting. I hope you don't mind. :) https://gist.github.com/3517051 https://gist.github.com/3517051
- benatkin 14y ago
  Note: the author of the article (trek) posted a comment on the gist, so it's worth a look even if you've already read skilesare's comment.

adolph 14y ago

This is such a timely article, thanks! I was just listening to the video on this week's JavaScript Weekly and considering where to start among the js application frameworks. It would be nice if the author expanded on the different categories of js app frameworks. Video: Beyond the DOM: Sane Structure for JS Apps: http://www.youtube.com/watch?v=cd7HHN6IkrU http://www.youtube.com/watch?v=cd7HHN6IkrU

drek 14y ago

Does anyone else thing that the documentation for ember.js is really lacking? Some of the classes it has aren't even documented (ContollerMixin comes to mind) and others are lacking in the documentation depratment. Also, I don't seem to be able to find a full listing of instance methods for a class, I have to climb up the inheritance tree in the docs class by class.

Vekz 14y ago
I have to agree. I found my self reading the source a lot while working with ember. That lead to discovering said hidden classes like ControllerMixin.

programminggeek 14y ago

Ember looks cool, but knockout lets me ship fast and it's less "magic". Also, I think single page apps have a place as part of a greater architecture, but not as the entire app. If I wanted an entire app everything to be JS, fine, use Ember or something like it, but most parts of the web don't need this and single page apps make the web a bit worse if not done correctly. Single page apps are the new hotness, but once the fad is over and the newness wears off, they'll be fit into their proper place over time and won't take over the entire app.

wycats 14y ago
> Ember looks cool, but knockout lets me ship fast and it's less "magic". I'd appreciate it if you could quantify what you mean exactly by "magic". For example, one key difference between Ember and Knockout is that Ember's binding system automatically avoids triggering the same side-effect from multiple pieces of code. For example, if you had a piece of the DOM that was calculated from several observables (the stupid example is a full name calculated from a salutation, first name and last name), and made changes to all three of those in separate lines of code (possibly in different areas of your codebase), Ember would ensure that the DOM only updated a single time, not three times. This is true no matter where the three lines of code are, without you needing to take any special action to coalesce the changes. This aspect of Ember's codebase adds some magic, in that it introduces a higher-level abstraction that knows about computed properties and their side-effects (the "run loop"), but the end result is more predictable propagation of side-effects in an Ember application. Ember applications don't need to know about the specific mechanism that makes this work, but good Ember developers are aware that many side-effects happen asynchronously in an Ember application. The browser does something similar when you make changes to DOM structures: it only updates the rendered version of the DOM once all of the JavaScript code handling an event has completed. I would agree that something simpler would probably be a better fit for simple "islands of richness" on an existing application, but there are definitely a large number of applications with significant amounts of logic happening on the client side, even if those applications run inside of an area of a larger traditional page. In general, I would say that Ember is a good fit for applications that will end up with more than 100k of application code. That sounds like a lot of code, but it's really only a lot of code for islands of richness. Applications like rdio, documentcloud, soundcloud and other popular Backbone applications can easily reach 500k or even a megabytes or two of code.

deleted 14y ago

[deleted]

richardjordan 14y ago

I've been looking for a decent tutorial on EMBER as someone who's of merely limited programming talents and abilities. I love what I've picked up so far, and I'm going to work through this tutorial now. Thanks OP for the work put in on this.

aidos 14y ago

For anyone trying to follow along with the tutorial beware that there's a typo the whole way through the code that stops it from running. connnect -> connect

Vekz 14y ago

Glad to see this article. The recent buzz around convention and best practices in Backbone.js has been frustrating. A lot of the recent Backbone discussion are issues that have been thoughtfully addressed in Ember.js. I feel that Backbone.js was first on the scene and hence has found its way into the current developer lexicon and toolset, leaving Ember.js unfairly looked over.

KaoruAoiShiho 14y ago

As I said in another thread, despite hilarious disagreement by jashkenas, http://news.ycombinator.com/item?id=4427974 http://news.ycombinator.com/item?id=4427974 that Backbone is perfect for big projects so long as you build on top of it with other libraries. Ember.js is just too opinionated for its own good.

robotmay 14y ago

Do any of these JavaScript frameworks have decent documentation yet? API docs are all well and good, but I'd really like some examples other than to-do applications. All they really need is an equivalent to the Rails guides at http://guides.rubyonrails.org http://guides.rubyonrails.org, which are ample. Frankly I'd take any example application over a to-do app at this point. As an aside, I've been using Sammy.js (http://sammyjs.org http://sammyjs.org) more than most of these other frameworks lately, as the effort involved is disproportionate to the rewards unless you're building the entire frontend in JavaScript. For any less-than-enormous project, you really don't need all that complexity.

te_chris 14y ago
Ember's getting there. Check out the "Guides" section on emberjs.com
bertomartin 14y ago
Heard about sammy, but never looked into it until now. It looks really interesting. I've been looking at emberjs for the past couple of days and I do like what I see, but I always felt it was a little too heavy for what I really wanted. I'm just not ready to make my app just an api enpoint...it's just too much abstraction. Regardless, I'll continue to follow emberjs.

tberman 14y ago

As the guy who wrote the first bits of the Rdio code in question, it seems worth mentioning that the part in question has nothing to do with Backbone, or Ember, or anything else. That code is a cleanup function on an object that helps to abstract HTML5 <audio> vs our Flash fallback. No matter what framework you are using, if you are solving the problems that we are solving, you are going to end up with that code. Now, that said, I agree that learning all of the frameworks out there is advantageous, but you can't assume that the code in the blog post is indicative of anything having to do with Backbone or any other framework.

marcelvr 14y ago
Thanks for the comment. Before reading it, I admit to being lured into thinking the code in TFA was there to clean up after Backbone. Sneaky bit of writing...
trek 14y ago
Is this entirely true? Clearly cleanup of event names like "loadedmetadata" is related to the audio element but '_bubbleProfilingEvent', '_logEvent', and general .unbind calls are on backbone-related objects, yeah?
- jmtulloss 14y ago
  The only backbone related code in that snippet is the .unbind() call and the .trigger call. This is needed because this is our wrapper around the media element; it is an event emitter. If you're going to make something emit custom events, you'll need code to emit them and clean them up when you're done. One area where backbone is lacking is lifecycle management. You do sometimes have to unbind things in order to prevent leaks. Backbone is very minimal in this regard. At Rdio, we've built our own tools on top of Backbone to abstract lifecycle away from the developer as much as possible. That being said, that weakness isn't illustrated in the code example picked by the blog post.

throwa 14y ago

Emberjs in production: https://github.com/emberjs/ember.js/wiki/Production-Deployments-Page https://github.com/emberjs/ember.js/wiki/Production-Deployme...