33 Great Resources to Get Started with Ember.js

EmberJS logo

I mentioned yesterday that I have been exploring various JavaScript MVC frameworks for both client and internal projects.  Ember.js is one of those frameworks.

As part of my exploration, I have collected various resources on Ember.js and thought I’d share.  This list is by no means exhaustive and I’m sure there are loads of other resources that I haven’t discovered, add them to the comments and I will update this post.

Getting Started with Ember.js

Blogs with Ember.js Focus

Presentations

Twitter Users to Follow

Books

Miscellaneous

I hope these resources are valuable to those exploring Ember.js or just want to find out what it’s all about.  Please add any resources you might also find valuable in the comments and I will update this post.

And the Winner is…Ember.js

Logo

It seems the ability to escape the use of rich client-side JavaScript is virtually impossible because users expect desktop-like application experiences.  JavaScript began as a much different language with much different uses as it is today.

I have been spending a lot of time investigating various JavaScript frameworks over the past few weeks in the hopes to choose one for client work and for a couple company projects.  There are quite a few really good choices.

The frameworks differ in various ways, some are opinionated while others give a few key parts that you have to spend more time architecting and piecing together.  

It came to my attention that Jeff Atwood recently announced the project he’s been working on over the past few months after leaving StackOverflow; Discourse, which is a new approach to forum software.

It turns out Discourse is based on a Ruby on Rails backend (API) and an Ember.js front end.  Ember.js happens to be one of the client frameworks on my radar for our company products.  One of the Discourse co-founders, Robin Ward, recently wrote about why Ember.js was chosen over other JavaScript MVC frameworks.  

I love to see articles released like this from Robin where the aspects of the decision are compared and contrasted with other frameworks.   One aspect of using a MVC framework in particular which was eye-opening is comparing a task in jQuery with the Ember.js way of doing things:

For example, on the bottom of every discourse post there is a button a user can click to like a post. When clicked, it vanishes and adds a footer below the post saying you liked it.

If you implementing this in jQuery, you might add a data-post-id to the post. Then you’d bind a click event on your button element to a function that would make the AJAX call to the server. However, the click function passes a reference to the button, not the post. So you then have to traverse the DOM upwards to find the post the button belongs to and grab the id from there. Once you have it, you can make your XHR request. If the XHR succeeds, you then have to traverse the DOM downward from the post to the footer, and add in the text.

At this point it works, but you’ve tied your implementation of the button click to a particular DOM structure. If you ever want to change your HTML around, you might have to adjust all the jQuery methods that accessed it.

If this example seems simple – consider that in the footer we offer you a link to undo your like. When clicked, the footer text vanishes and the button appears again. Now you’re implementing the opposite operation against the DOM, only in reverse of what you did before.

Discourse even takes it a step further – we know that 99% of the time when you click the like button the request is going to work, so we hide the button and show the footer text right away, even before waiting for the server to reply. In the infrequent event that request fails, we’ll show an error message and pop the UI back to the state it was in before. If we were doing that in jQuery, we’d have to have a callback on our AJAX request that knew how to put the UI back into the state it was in before.

A prudent programmer might say, okay, well I’ll have a render function that can rebuild the DOM to the current UI state of whether the post is liked or not. Then both ‘undo’ and ‘like’ can call it. If ‘like’ fails it can call it again. Oh, and we have to store the current state of whether the post is liked somewhere. So maybe we add another data-liked=”true” attribute. ACK! Just typing this all out is giving me a headache!.

Congratulations, your code is now spaghetti, your data is strewn out in the DOM and your logic is tied to a particular layout of HTML elements.

One of advantage of a rich client interface like this is the API you create is a separate entity from your user interface and well-tested, as pointed out in the article:  

One amazing side effect of a rich client side app is you end up with a battle tested API. Our app has consumed our own API since day one, so we know it works.

Note: We haven’t documented it yet because we plan on major changes over the next few months, but after things stabilize we certainly will provide a more rigid interface.

If we want to create a native client for Android or iOS, it would be a lot easier because we already speak JSON fluently. If people want to build services that use Discourse, they won’t have to result to screen scraping. It’s a huge win for us and the developers that use our platform.

 I cannot agree more.

The article goes on and talks about why Ember.js was chosen over other MVC frameworks.  I won’t bother to explain those here but feel free to give the article a read and see for yourself.  Some very good reasoning.

Sometimes making choices like this are the result of subtle differences in frameworks that favor the taste of the developer.  Ember.js is definitely a framework of opinions, not surprising since one of its creators is Yehuda Katz.  Yehuda was the lead architect on the Rails 3 rewrite and Rails is a very opinionated framework.

This is definitely worth a read if you are considering Ember.js.  Also, there are some gems in the comments worth taking a look.

JavaScript Has Its Place, But Not Every Place

No javascript

JavaScript is everywhere these days; more-so because legions of developers play follow technology leaders like the Pied Piper playing his flute. 

I’ve worked on many Rails projects over the years and the inevitable pain points usually turn out to be JavaScript. Whether it be mounds of jQuery selects, poor attempts at AJAX everywhere or lately, Backbone.js and some other MVC frameworks which virtually mirror much of the backend in the UI. Unless these technologies are implemented to perfection, it leaves evidence of attempts at “playing” with a new framework with artifacts left behind that last a lifetime.

Some issues I have with using large amounts JavaScript in your Rails (or any web framework for that matter):

  • Leads to lots of code in the browser – with tons of JavaScript, applications start to get slower. There’s only so much client-side code a brewer can expect to handle.
  • Leads to lots of code inherited that is hard to debug, hard to support and the client ultimately pays – this is probably my biggest pet peeve. It seems like every Rails project, there’s a different JavaScript framework used and it’s the first time the developer is using it. 
  • The examples of bad code are numerous and hard to fix. It is really hard to understand the intent and really hard to both support and enhance. In the end, the client pays the price from both a monetary perspective and a maintenance one.
  • Developers like to “play” with the new hotness leaving breadcrumbs of learning something new of a framework that gets dropped or at least minimally maintained.

I came across a great article published recently from the developers of Charm. One of the developers, Thomas Fuchs, who is previous Rails core member and a well-known member of the JavaScript community gives his thoughts on the heavy use of JavaScript in a web project.

Hi Sasmito, as for technical issues, we where plagued by various problems that are not related.

The app as it is, is using Backbone.js, Underscore.js and Zepto on the front-end, and Rails 2.3, Postgres, memcached, redis, resque, and for websockets Sinatra, and a few other things. The front-end is communicating with the back-end via a JSON API.

I’ve come to the realization that this much client-side processing and decoupling is detrimental to both the speed of development, and application performance (a ton of JavaScript has to be loaded and evaluated each time you fire up the app). It’s better to let the server handle HTML rendering and minimize the use of JavaScript on the client. You can still have fast and highly interactive applications, as the new Basecamp shows—letting the server handle most stuff doesn’t mean that you have to cut back on cool front-end features and user friendliness.

I’d argue that all these newfangled libraries are actually detrimental to the user experience in some ways, as they lock you into certain patterns (it’s hard do to things the authors didn’t anticipate) and if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same.

We’ve spend a lot of time getting Backbone to work properly, as the easy-of-use quickly deteriorates when your models get more complex. It’s a great choice for simple stuff, but email is far from simple. We also had to add yet an other extra layer of processing to generate “ViewModels” on the server because the normal Rails serialization of objects wouldn’t cut it.

What you end up with is building a layer cake that doesn’t add any value and slows down development. Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that. But… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you.

All in all, my current recommendation for SaaS-type web apps is: Rails 2.3 (or Rails 3.2 if you prefer), a Postgres database, as much HTML generation on the server as possible and augment that with RJS (Rails’ mechanism to push JavaScript snippets to the client that get eval’d). This allows for direct re-use of server-side templates, and it’s simple, and works well. As an added bonus, keeping things on the server allow for much better error and performance monitoring and thus quicker turnaround for fixes. There’s also a lot of great stuff in this direction coming up in Rails 4 (like Turbolinks).

Alas, keep it simple and don’t repeat yourself.

This is some of the most common sense advice I have read in a very long time.  Please read the comment and consider the advice before harsh comments here.  I know there are a lot of JavaScript developers out there but I ask those to use it with care.

A wise man once said, “Just because you can, doesn’t mean you should”.  No idea who said it but words to live by.  This applies to so many things, especially JavaScript.

There are so many new frameworks popping up each day. We don’t need more frameworks, we need better ways to use them; such as standard and proven usage patterns, well-known interfaces and published best-practices.  It’s like the wild-west out there in JavaScript land and things are not better because of it.  

You are not doing anyone any favors using all of this JavaScript.  Use it sparingly, use it right and remember that JavaScript is not a silver bullet.

7 Resources Every JavaScript Developer Should Know

Lrg

A web developer today is expected to be an expert in every aspect of their craft and JavaScript is no exception.  Years ago JavaScript seemed to be more of an annoyance, producing those trailers at the bottom of the browser.  This has changed and JavaScript is a first-class citizen as a functional programming language and what seems like an unlimited number of resources covering the language.

I have been doing more and more JavaScript lately, both on the front-end and some node.js on the back end.  I wanted to share some great resources I use for what’s new with regards to JavaScript libraries, projects and general reference.

1. JavaScript Jabber

I am a fan of listening to good podcasts when I take a daily hike.  It gives me a chance to find information about new projects or libraries of code.  I ran into JavaScript Jabber by accident.

This podcast is put together by the same creator of Ruby Rogues, another great podcast but instead talking about Ruby.

Each episode covers a particular topic and goes into detail about the pros and cons of using the technology.  Recent episodes include Backbone.js (Jeremy Ashkenas) and co-hosted by Yehuda Katz (ember.js) and include some lively discussion between the two about Backbone.js vs. Ember.js and some design decisions made by the two frameworks.

Other episodes cover topics such as JavaScript Objects and Asynchronous Programming.  Every episode to date has been filled with great bits of information and a wealth of other things to checkout.  Be sure to check out the show notes from each show with links to things mentioned on the show.

2. The JavaScript Show

The JavaScript Show is a podcast which runs down the weekly happenings in the JavaScript community, similar to JavaScript Weekly but in obvious audio format.  Lots of news and opinion here from hosts Jason Seifer and Peter Cooper.

This show is varies from JavaScript Jabber as it focuses more on new projects, updates to existing projects and all-around what’s happening this week in JavaScript land.

If you want to get the “Nightly News” version of what’s happening with JavaScript, this is your source.

3. JavaScript Weekly

This is a weekly newsletter put out by Peter Cooper.  JavaScript Weekly is a nice collection of what is going on in the JavaScript community; new projects, updated projects, news, videos, podcasts and conference information.  It probably overlaps a bit with The JavaScript Show since Peter Cooper does both but probably enough different to make it worth it.  If you aren’t into podcasts then this one is definitely a good resource.

There is also a Twitter account where various other updates are published.

If you don’t have time to scour the web for JavaScript news, this weekly delivery to your inbox can help sort it out and keep you up-to-date.

4. Mozilla JavaScript Reference

Mozilla is THE place for information regarding JavaScript.   There is so much detail on the site it is easy to get overwhelmed, so #4 is really 4 picks in one.

Re-introduction to JavaScript is a resource for those developers who may have some exposure to the language but maybe where not steered down the right path or just don’t remember the basics.

The Mozilla master index of their JavaScript resources is a great place to bookmark and return to later.  This includes links to what is new in JavaScript versions, language guide, mailing lists and tools.

The master list includes the JavaScript Guide, which is a how-to manual about the JavaScript language itself.  Great for just starting out or referring back when you’re just not sure.

The AJAX Tutorial takes a look at how to get started with AJAX requests, what they are and the various places to use them.  This is one of the best introductions I have seen as it just refers to JavaScript and a bit of HTML with no other language mixed in to add to the confusion.

UPDATE: Reader Don Smith points out by including “mdn” (no quotes) when searching Google for JavaScript reference information, you will get the best results from the Mozilla resources.  I tried several searches and he is right, the good stuff comes to the top.  Also remember you can limit the searches to this site specifically by preceding searches with “mdn:”.

5. Douglas Crockford’s JavaScript Resources

When I think of JavaScript, Douglas Crockford is one the names that immediately comes to mind.  If you haven’t heard of him, you may have heard of his book – JavaScript : The Good Parts.   His web site dedicated to JavaScript is a nice list of resources to his work as well as others.

6. Advanced Topics in Web Development – Fall 2011

For those who may want a bit more classroom type training but can’t get away, iTunes University has a free course covering lots of great stuff about advanced web development which equates to JavaScript.  It looks like there are 19 sessions up and possibly some more coming since #19 is jQuery, part 1.  Even if there are only the 19 episodes, there is lots of great content.

7. Essential JavaScript Design Patterns For Beginners

Essential JavaScript Design Patterns For Beginners is a book about JavaScript patterns, it has beginners in its title but most beginning developers don’t know what a pattern is.  Heck, most experienced developers haven’t studied them enough to be fluent in pattern speak.  This is a great book for anyone to better understand patterns and has the JavaScript twist to them.

Finally

I hope people find this list useful.  I tried to keep my narration to a minimum since you can go to the sites to read the real details.  I just wanted to share some useful links I use and found after filtering through tons of Google searches.

My Updated Developer Podcast List

My appetite for podcasts is always growing but my interests routinely change.  I don’t listen to many .NET-specific podcasts any longer, but more along the lines of software craftsmanship, Mac/iPhone, Python and Ruby development.  I hike about an hour a day to try to stay somewhat fit and always have my iPhone loaded up with podcasts to pass the time.

I am always searching for new podcasts and from time-to-time that I come across new ones I consider worth sharing. It has been a while since I have shared any, so now seems like as good a time as any.  My last update from a few years ago titled Software Development Podcast List has seen a few additions.

General Coding, Ruby on Rails, .NET

  • coderpath podcast with Miles Forrest and Curtis McHale – mainly interviews with Ruby on Rails community folks, great dialog.
  • Teach Me to Code podcast with Charles Max Wood – covers a wide variety of topics and interviews with community members from Agile to Ruby and everything in between.  Very good detailed discussions, highly recommended.
  • The Dev Show with Dan Benjamin and Jason Seifer – news covering JavaScript, Python, Ruby, Java, PHP and more.
  • The Ruby Show with Dan Benjamin and Jason Seifer – good review of the latest Ruby and Rails news, with a side of hate for MongoDB (just kidding).  Most episodes are 20-min or so in length.
  • The Changelog with Adam Stacoviak – very detailed interviews and discussions on more obscure subjects in Open Source including JavaScript, iPhone, Sinatra, node.js and others.  This podcast exposes listeners to subjects not really heard elsewhere.  Good stuff.
  • Herding Code Podcast with K. Scott Allen, Kevin Dente, Scott Koon and Jon Galloway – originally mainly a Microsoft-centric podcast, lately they have been expanding into many great areas such as iPhone development, Ruby, Ruby on Rails, jQuery and more.  Great interviews by people really focused on technology.
  • Startups for the Rest of Us with Rob Walling and Mike Taber – not a developer podcast per se but a podcast about going out on your own from two software developer.  Truly valuable episodes if you are thinking about starting a software company or even if you have an idea for a product and wonder what to do.
  • Ruby5 with Gregg Pollack and Nathaniel Bibler – great source of Ruby news in very short episodes (5-6 minutes).

Open Source

  • FLOSS Weekly with Randal Schwartz – interviews with leaders in open source.  Great insight into great projects.

Mac and iPhone/iPad

  • Core Intiution with Daniel Jalkut and Manton Reece – includes many aspects of Mac development.
  • The Mac Developer Network – covers a wide range of development topics for Mac, iPhone and iPad development.

Screencasts

Even though I don’t put screencasts on my iPhone, I do watch these in my free time on my Mac.  These are really good, so I wanted to share.  I didn’t really have enough to put in their own categories, so everything is just lumped together.

  • RailsCasts with Ryan Bates – short (6-15min) screencasts covering very specific topics of Ruby on Rails development.  This is great for beginners and experienced developers alike who want to come up-to-speed on new topics like Rails 3 (222 episodes as of the time of this writing).
  • web pulp tv with Josh Owens – very detailed interviews with many high-profile tech companies talking about how they approach a tech stack and make thing scale.
  • Teach Me to Code with Charles Max Wood – great how-to videos on various aspects of Rails, including Rails 3, RSpec and others.  These are very well done and worth watching for the latest.

I am always looking for any other podcasts or screencasts covering unique topics.  Please leave a comment here with some I may not be including here and may enjoy.  Thank you.