"Getting started with Ember.Js is easy." - No it isn't

I tried Ember for over three weeks on an expected-to-be-large project in December/January. It seemed like a perfect fit - instead of using hackey URL/DOM-driven MVC framework on a complex project, Ember would absolve me of dealing with element IDs and $('#menu').bind(). I had done projects using Backbone but it seemed too simple for this project. I needed some structure and Ember would provide that.

I didn't give up in hours like the author and spent days reading through the tutorials on routings (which they changed), layouts (which got replaced), MVC, data-bindings, and everything that could make me proficient. After about 3 days of hacking, I managed to get ember to control a Bootstrap navmenu so that logged in users see something different from guests. I figured initially things would be slow but once I started thinking the 'Ember' way, my development speed would rise. It happened to me with OOP, functional programming, Java, Objective C, and RoR.

I continued working on the project using Ember and my productivity did not go through the roof. I was still trying to figure out the proper way to make Bootstrap Tabs work in Ember. It's views within a single view. Is that CollectionView? But I don't want to lose state when a tab changes. Should I hack my own TabView and TabViewController? I couldn't find others doing anything similar though lots of people were asking online about tabs in Ember. The tutorials were old and applied to deprecated Ember elements/concepts. I tried the Ember-Bootstrap library but it had problems too. There were sorta-ok answers on SO and Ember forums. It just didn't seem 'right'.

After three weeks of trying my best, I said 'ok, let me just try replacing it with Backbone and see how long that would take me.' Took under five hours to replace all of the Ember code with working Backbone code. Took another four hours to accomplish tabs, nested views, and data-bindings. I did more with Backbone in that one day than I could in Ember despite trying my best for 3 weeks. I'm not blaming the framework but I do realize it's not meant for me. I thought it was meant for exactly the kind of project I was working on but I couldn't make it work.

I did my best to grok the tutorials, the design patterns, and the Ember-way. But I still didn't "get" it. I do not understand why some things are Ember.X.create while others are Ember.X.extend. I liked the concept of Ember computed/aggregated properties but could never get them right and two-way data-binding was very difficult. So I switched to Backbone and haven't looked back. Maybe I'll try Ember again some day in the future when there is a single known way of dealing with basic things like TabViews.

This is all spot on. And despite the somewhat humorous, but not at all rude tone, this guy did some real leg-work to type this up. Documenting something in that much detail takes a lot of time (he went so far as to find the missing dependencies, and copied in the error messages at each step). Duck-debugging often works because you have to get specific, and logging issues is the same.

I've had this same experience with Node.js (http://nodejs.org/), whose homepage links to API Docs (not at all introductory or even linear). Granted, they don't say 'easy', but good documentation is still nice to have. Compare to Django documentation, which is expansive.

And I understand that these various frameworks are for seasoned developers who don't need HTML closing tags explained to them. But there are so many platforms and tools out there, and they so often take you from 'toy' to 'enterprise-scale' in this sparsely documented way.

True story.

I've seen 2 extremes in my career:

1. The "product makers" think they know everything and force the users to do it the way they want.

This often results in a bad to use product.

2. The "product makers" think the user knows best and do everything the users say.

This often results in a too specific/unflexible product.

This seems like a variant of PBSALTPH, a silly initialism I coined when I found myself ranting about product blogs that don't link to product home pages [1].

Generally speaking, any subdomain or isolated "region" of a product web site should always provide a prominent link back to the product's home page. A good option is to use the product's logo as that link. Using the logo to link to anything other than the product home page is a crime against the gods of user experience.

[1] http://tiamat.tsotech.com/pbsaltph

Yes, I agree. Just a couple of days ago I had a similar interaction with the mercurial folks, where I posted a (slightly overly annoyed) e-mail saying that their page about GUIs was awful.

In that case I got a nice reply, and they clearly took the suggestions on board and have massively improved the page. It gave me an excellent impression of the developers of mercurial.