Why i'm leaving ember

I think Ben’s experience has been repeated by quite a number of folks. I remember having quite a few false and frustrating starts with EmberJS myself.

Too many times I think new folks unfamiliar to the framework are prematurely dismissed as not having enough rudimentary skills, lacking basic programming experience, and sometimes treated with an undercurrent that they’re not smart enough to get it.

Usually by the time someone has opted to jump into Ember, they’ve done enough roll-your-own work to appreciate what Ember brings to the table. Embrace these folks as future contributors and tutors for those that follow.

The fact that one can go over to Meteor and “get it” doing pretty much of the same concepts, suggests the problem is somewhere between the communication of ideas between framework designers and the target audience. But we’ll explore that in a moment.

Frameworks are supposed to not only remove the tedious work, do the heavy lifting, but also be approachable. Given that many of the folks having problems do have experience with advanced JavaScript, functional design patterns, other web frameworks, something is amiss. A close look at EmberJS shows that it has elegance, so it’s hard to blame the framework itself. Something else is going on.

@thatandyrose nailed it. It’s the documentation.

Ember’s documentation is beautiful looking, and that’s deceptive, because its polish conveys a degree of comprehensiveness and completeness that actually isn’t present.

When I dug my heels in to learn Ember, I took a bunch of notes, with the thought that perhaps a book would roll out. At the time of writing this, I have literally 72 separate concepts in my outline that are prerequisites for learning Ember from scratch. Somewhere between five and seven are what I’d consider the crucial concepts for groking EmberJS, but because Ember unifies these together so tightly, it seems there’s a chicken and egg problem buried in there somewhere.

Aside from outright problems and inconsistencies, which the community accepts from version drift, the documentation appears to be written in the form of a reference guide aimed at someone who already knows Ember. It’s not readable sequentially, as it makes forward references to unintroduced concepts. Consequently, at a minimum it takes multiple readings. Thank God it’s beautifully hyperlinked …with a tiny number of links to chapters that don’t appear in the outline.

As a development resource, it’s great. As a user’s guide, it does very little to let us into the mindset and design decisions that were made and how the framework designers expected it to be used. Explain by example doesn’t always convey why.

To be quite fair, this is a common problem for opinionated frameworks. Conventions are more than just naming conventions.

Suppose you want to something slightly more advanced than just displaying a form with reactive values in a template: store something trivial and do it the Ember way.

That means learning ember-data; one can surmise that it does ORM stuff, and maybe you’ve got years of Hibernate (or something similar) under your belt already – you’re not dumb. Click on ember-data in the documentation, you get a list of classes …but what are they for, what do they do, which ones are internal, which doe you extend through subclassing, which hooks do you override, which must you, and which can you?

Click a class, and you get a list of methods, but not the order they should be called in or used (alphabetical isn’t helpful); which ones are common, what’s the design pattern this is a part of, what are the ranges for the parameter values, where are the examples? How do these relate to other classes?

Terminology could be better. Oh, store as in data store, not as in a verb such as to store(). Can I use just a model, or do I need a store? What responsibilities does the class pick up? Which am I responsible for? Is the adapter thingy for the store, the model, or the application? Why do I need one?

If you’re familiar with Ember you may know the answers, having discovered for yourself, but the new person is going to be faced with hundreds of these kinds of questions. What seems silly or even nonsensical to you now is a legitimate question for the uninitiated.

Documentation’s purpose is to solve this problem. Right now, in its current state, it isn’t. Some day it will, Ben. Some day.

The documentation isn’t quite clear either with its examples. Again, it’s not the what or how, but the why. Take a simple example:

MyApp.Store = DS.Store.extend();
store.find("person", 123).then(....)

Is the .Store in MyApp.Store just a name I made up, or is it somehow wired where Ember by convention expects to see it? Why are we subclassing if we’re not adding anything to it? Why is DS not in Ember’s name space? When did the store instance get made? How did it get into scope? What naming conventions do I need to know? What is “person” the find is looking for? Does it do pluralization? Does that map to “People” somewhere else that I need to be concerned with? If a Person class expect a JSON object with “person”, why did REST becoming /people. Maybe .fmt() is guessable as format, but .loc(), what’s that – location? an offest? or localization?

Note the set of novice question has nothing to with things like “what’s a Promise?” You’d figure that’d be the hard part. If they can get what that’s doing, then what they’re really asking is a better understanding of how Ember is put together.

Yes, the answers are out there – spread all over like a massive Google treasure hunt.

And this is the point where things get snotty, and the community says “go read the code.”

The code, frankly, is pretty brilliant. And that’s turns out to be a problem, too.

Library authors are super-talented coders, using advanced constructs and techniques, and are focused on concerns like size, performance, and reusability, taking advantage of state that’s not transparent in the higher level abstraction. Sometimes the implementation of simple API magic is some hardcore under the hood stuff that requires detailed knowledge of other system internals, like how the browser really manages the DOM. A novice might not get it, the same way as someone learning C might not get clarity by reading how the compiler emits assembly code while mixing concerns with instruction timing optimizations.

More over, if the novice is only familiar with JavaScript from a web-client perspective, an excursion into NodeJS, Ruby, compilation tool chains, package managers, dynamic loaders, and ES6 transpires are most likely things they’ve never encountered before. Let’s be fair when we dole out that advice. EmberJS should be for the masses, it doesn’t need to be the framework of the elite as it’s sometimes treated.

One of the things that I really respect about Meteor is that it doesn’t just throw an API at you. It’s documentation explains the foundational concepts first, building them up with trivial JavaScript code, and when you see how it goes about doing it, it then says something along the lines of Meteor saves you from doing all this with the xyzzy() function, but the actual implementation takes into account a number of additional edge cases you don’t need to worry over. The actual code is far more impressive, but you’ve got a metal model that’s usable immediately. I think that’s how Meteor gets an accelerated head start over Ember, even though it’s doing both the front end and the back end.

That said, in using Meteor, there’s a lot of freedom it gives that makes me long for how EmberJS opts to do and organize things.

So Ben, you’re not alone. And I’d encourage you not to give up on EmberJS entirely, but consider taking a break from Ember for a bit.

If the concepts are tripping you up, go read Meteor’s introductory materials, it will turn the light on for you – and you’ll see the parallels, at least conceptually, that Ember is also doing. Then come back to Ember, and I think you’ll like the way Ember has carved up the problem space and where responsibilities lie once you start using it.

If the convention is tripping you up, welcome to the club; working example projects are probably going to give you better insight than the documentation for now. Where Meteor has what appears to be a lot of stuff floating around globally, EmberJS has things nicely packaged into a namespace. Although, you’ll often be left wondering if you’re just using the name space as a registry or actually plugging into something by convention hidden in an implementation class – for now a lot of reading of the documents will help, but I’d rely on asking the community to get clarity.

In the end, I think you’ll really enjoy using Ember.

21 Likes

It would be brilliant to see you put in your experience / notes to www.howistart.org

I think one of the things that lack documentation is the container.

The guide mentioned it as part of dependency injection, but the class is not documented as part of the API. EmberJS’s core team also had been saying that the container is an internal class that the public should not concern with. But I think it’s actually pretty core to understanding how Ember does its magic.

4 Likes

Except for .get and .set central, that is atrocious, was atrocious and will continue to be atrocious until it eventually dies and becomes an old battle story we tell Ember newbies in a few years time.

2 Likes

Feeling stuck here too. Ember is cool, and I almost get it. I am trying to add an object that has not yet existed yet was data bound to the HTML controls so I don’t have to “save” and I just can’t make it work. So I have been coding since I was 14 and am 47, I’ve used lots of languages and frameworks. I switched to Java eight years ago from C# and am switching to Unity today, but I have this pet side project I want to do in HTML/JavaScript with HTML5 storage on the client side.

So I’ll hangout a bit, post some specific examples and see if I can break through my barrier. Have horrific thoughts of this project dying if I can’t find a way through…

Here here! To what @ef4 and @abuiles are saying about more experienced ember users offering their time to beginners. Paying it forward can be a great way to increase one’s own chops and help others along the learning journey.

I know when I was first starting out with ember the moments where someone came forward to answer my basic, basic, very baaaasic questions were really appreciated. A little bit of direct help goes a long way and I encourage anybody offering help try to get it down in easy to digest units perhaps using something like JSBin.

As a beginner I have found trawling through JSBins of other people’s posted examples to be really helpful.

Also, I think more sharing of concrete examples and github repos is always good. I often learn best by seeing other peoples code. And simple git repo with focused ember cli based example is always instructive.

I think if collectively we can figure out how to turn more tutorial examples into polished pieces of didactic illustration of “how to” the ember documentation story will get better over time.

The reality is there are a million different ways to do various things in ember even with all the conventions. And so concrete examples/tutorials are always good.

P.S. @ef4 your presentation at Ember Conf was inspiring. Many “aha” moments for me personally. Anybody else reading this check out his Ember Liquid Fire https://github.com/ef4/liquid-fire really really great stuff.

2 Likes

@ef4 Absolutely. Very wise words those.

@thatandyrose +1; TodoMVC is one of the dumbest apps ever imagined, but that is not it’s purpose, is it? I’ve always thought it to be just a baseline set of requirements so all the contributors had a common endpoint to build to using their particular library/framework. It certainly doesn’t demonstrate EmberJS very well, and the founding team has said that.

Maybe EmberJS is still new enough that the tutorials are yet to be created. Sounds like an opp for you!

for people finding it hard to grasp emberjs concepts check out this course from lynda.com

http://www.lynda.com/Emberjs-tutorials/Up-Running-Emberjs/178116-2.html

1 Like

I’ve been wanting to contribute back to Ember for some time. I dive in and try to answer questions here and there, I’ve been cleaning up a few nice libraries with the intention of pushing them out to the community, but really want I’d like to do is create a revamped “getting started” guide that explains many of the high level concepts Ember uses: stuff that experienced devs take for granted.

Some thoughts on that.

Most of the confusion I see comes from devs for whom this is either their first programming experience ever, or their first front-end framework. Even devs with experience in a solid backend MVC framework seem to get confused easily by Ember.

I feel some of this confusion is because Ember brings a lot to the table as a framework alone, and these devs are stepping into a framework encouraging an entire unfamiliar ecosystem of build tools and task runners. Getting up and running is overwhelming if all of these tools are as unfamiliar to you as the framework itself.

Imagine the self doubt: is the workflow broken? Or is it something in the app?

Get past the setup confusion and the initial “hello world”, and Ember assumes that devs know a lot of lingo and concepts that they likely don’t.

Ember makes the assumption you know what MVC is, and can understand why Ember’s MVC consists of model view template controller and route.

Ember assumes you know what a factory is, what an initializer is for, and what components are for. inheritance is awesome, and usually clear, but dependency injection is handled for you and prevalent all over but not mentioned often or explained.

There’s also consistent talk of Ember’s resolver, a magic black box that consistently seems confuse new Devs who don’t get how a controller is matched to a route and so on.

Not to mention the seeming inconsistencies in naming (largely cleaned up by ember-cli, if you are prepared to add that to the new tech stack being tackled) between

  • App.PostsNewRoute
  • this.resource('posts', function() { this.route('new'); });
  • the template posts/new
  • this.transitionTo('posts.new').

Or when to use camelCase vs CamelCase and so on.

Ember Data tends to assume you know what an adapter and serializer are for and how they are used. The best way to learn how to implement one remains reading the source of the default RESTAdapter and RESTSerializer.

In short, there’s a lot that Ember offers that isn’t well document or explained for anyone, but for beginners even the explanations that exist are too abstract or unrelatable, and the ones that are missing make the way Ember works seem like voodoo.

6 Likes

I don’t think that difficulties in learning the framework can be blamed solely on the documentation. Parts of the framework are difficult to learn, and even when explained well, are difficult to remember. Other features are difficult to explain, even when attempted by experts. These issues are indicative of poor design (that’s not to say that the whole framework is poorly designed!).

I’ve found that it is sometimes unclear what the “right” thing to do is, suggesting a lack of natural constraints. Some of the things I’ve found unclear include:

  • When to use hyphens, dots, slashes, colons, camelCase, PascalCase, or underscores?
  • When should I handle actions in the controller or a route?
  • How are component actions handled?
  • Should I nest within a route or resource?
  • Should I use a plural or singular resource name or both? (e.g. 'post' or 'posts'?)
  • Does this code belong in the posts route or the posts/index route?
  • Should I use a Component, View, or Handlebars helper?
  • class=foo or classNameBindings="foo"?

@alexspeller’s Ember Fest 2014 talk has more examples of this kind of thing.

There are also difficulties related to the state of the language and the stability of available tools. ember-cli is doing a tremendous job in this area, but given its pre-1.0 status, it brings with it the problems of pre-release software (breaking changes, out-of-date literature, etc). Its approach is at odds with that detailed in the official documentation (i.e. modules vs. globals), and much of the exciting stuff is going on with addons, which are not straightforward to integrate into non-ember-cli projects.

To quote Don Norman in The Design of Everyday Things, “[w]hen we have standardization … then suddenly we will have a major breakthrough in usability”. So I think once there is a standard (stable) approach to building Ember apps, ease of learning will improve considerably.

10 Likes

I find this a fascinating discussion.

Having worked with Ember for around 2 years now, I’m astonished at amount of wrangling necessary when working with Angular.

I’ve recently joined a project that is using Angular and the build tooling is just infuriating. Minification breaks things frequently, particularly if you forget to stringify your dependencies for injection. Try running with a CI system and using protractor and selenium for running end to end tests and you’re in for a world of pain. Oh, you need a different test runner for you unit tests (Karma) too. Grunt, slow, slow, slow.

Try using SASS and you’ll need all kinds of external dependencies, which again break and slow builds. In Ember, just use the broccoli add-on and you’re all good, fast, dependable builds.

Angular’s structure, or lack thereof, is a nightmare when moving between projects. Where are models, what are the models? Are they factories, services, or should be attached to a controller?

The Ember team I have found to be amazingly committed to building around and toward the coming standards. Tried using ES6 syntax with Angular? (don’t).

I totally understand that there’s a learning curve with Ember and it’s kinda steep, but once over it’s just SO much more productive in my opinion.

7 Likes

I think that the Getting Started needs rewriting to make it more accessible to the community.

There are too many advanced concepts mixed in with the introductory stuff and should be moved to the end in a chapter dedicated to advanced level.

Also I find the whole discussion about routes (resources vs. routes) very confusing.

6 Likes

I completely agree, once familiar with Ember there is very little going back. I’ve needed to build some things in jQuery / raw javascript / angular since learning Ember and every time I find myself wishing I didn’t need to.

I feel that there are 2 separate issues here:

  1. difficulties learning the concepts of the framework
  2. difficulties with the accompanying tools e.g. ember-cli

The challenges of “just” using ember-cli should not be underestimated.

Whilst it has emerged as the front-runner for building Ember apps, it is not included with Ember (yet!). Not everyone is using it. It is pre-release software and is updated frequently—not always a bad thing—but updates often include breaking changes. It requires an approach that differs from the official Ember API documentation and guides: Node, NPM, Bower, Broccoli, and ES6 modules. So once you get over the initial learning curve of the framework, you’re then faced with another one which is a little unstable at present.

Unless you feel comfortable working with that technology stack, and are confident in dealing with breaking API changes and draft specs, the promise of “productivity bliss” may not be resolved (see what I did there! ;))

2 Likes

Yeah, I agree with your perspectives.

My major questions is what are the alternatives to Ember and Ember-CLI that provides an integrated workflow? I’m not trolling, but if the discussion is around the difficulties, what are the alternatives?

Patience!

Seriously, I’m not aware of any alternatives, although I pretty much jumped from Backbone to Ember, and that was that! Your experience with Angular suggests that the current situation on that side is not good!

I’m not sure if we need to look for alternatives, but rather recognise the current issues in usability, try to solve them, and prevent similar issues from appearing in future versions.

I started using ember since RC2, and sometimes I guess the difficulties is how to abstract yourself to see from a new user’s shoe. It is a matter i think about abit. Did rails ever had the same problem? As part of the rails framework they had scaffold tooling in place (then official docs against those artifacts)… maybe ember should take ember-cli in sooner rather then later :wink: or is it client side dev just not used that much layering in their architecture so the curve is even steeper?

There is alot going on in Ember and Ember-cli and alot of the explanation on the web is very detail (out dated), it is a sophisticated framework and everyone involve are PhDs in the matter. With a huge amount of enthusiasm we all just want to blurb all the detail out at once! The problem with PhDs is that they always have difficulty explaining how things work to a undergrad. ‘Everything is related where do you start’. Then the learner’s thinking ‘wow there are all this cool stuff out there i want them all at once.’ So to help we could:

  • Somehow demote older content. Maybe there should be a bot that index ember comments around the internet and tag them to 3 status (out-dated, current, future) – view them in a centralised site, user can vote on the level (beginner, inter, advance)
  • Vote to get Ember-cli be part of ember as soon as possible. Get the docs in Emberjs.com to mimic rails guides. So new users are not confuse what they should start… not sure what the reservations for getting ember-cli offically part of ember @stefan can you elaborate?

Maybe this is a bit over simplify - but for ember starters simple is good!

2 Likes

EmberJS is initially hard to learn but easy to master.

Once it hits stability this will happen. Some of the early doc work has already been started by @tomdale

3 Likes