Why i'm leaving ember

I’m gonna shill my tutorial for beginners here :sunglasses: , https://medium.com/@ulisesrmzroche/lets-build-jwt-backed-authentication-with-ember-and-express-5425a1977d23.

It’s a “Lets Code!” rolling out our own authentication mechanism for an Ember App using JSON Web Tokens and an ExpressJS API. I’ve gotten kinda busy recently, but it’s at the top of my list right now to finish out the next part.

@zcourts side-loading is for the case when you don’t want to spend another request to the server to get the associated record, it’s not a rails-specific thing, it’s actually quite widespread.

2 Likes

For those who are more advanced and running into roadbumps, check out @alexspeller talk on Ember Pitfalls. If you’re coming from Rails, check out Brandon Hayes’ Refactoring towards Ember https://www.youtube.com/watch?v=VMmaKj8hCR4 and Matt Jones’ Empty your Cup,

3 Likes

Its not the framework

I’m thinking of making the switch also, and here’s why, it’s not the framework per say.

Ember does have a steep learning curve, but once you get certain concepts, it’s like, boom, now I get it. And it’s great. But getting there is a nightmare.

It’s the documentation

The issue is, the documentation is just horrible horrible horrible. Meaning it’s horrendously over simplified.

I’ve been working on my first Ember app for two weeks, it’s a dynamic form type thing, think survey monkey, that kind of thing.

With all my stackoverflowing, googling, even BINGing it - that’s what it got to :slight_smile: - I have failed to find ONE updated end to end example of just an effing basic form in Ember, with text inputs, checkbox groups, radiobutton groups etc. As in, a basic form we’ve been dealing with for years.

The todoMVC app is all well and good but it’s such a weird specific app with a very specific workflow.

18 Likes

I had never used a Javascript framework before. I had never really written anything in javascript other than JQuery to do stuff with . I just graduated college and had only been programming during my 3 years of CS. I’d written one app in Django, and a few of my own projects in frameworkless MVC style in Java. And yet, I was able to feel extremely comfortable with Ember CLI over a weekend solely from reading the documentation. I have since written a decent sized application that would have been impossible without Ember or some other SPA framework. Note: I don’t use Ember Data.

Sure, parts of the docs are weak (I’m looking at you, pods docs), but it’s really easy to internalize whats going in Ember from the docs IMO. I think the docs explain how the framework works really well. The API is incredibly useful too.

Maybe I’ve never been part of a community that spoon feeds you examples all over the internet and have nothing better to compare these docs against. But I know these docs were a hell of a lot better than lex/yacc, Tomcat, or anything other tool I’ve used before. I guess my approach has always been: find some example that’s ballpark what I am trying to do, tinker with it for a while, figure out why it works, and then tailor it towards what I need. From my experience, its been really easy to find examples of form views such as select or input on the web.

I think Ember’s docs make the assumption that you are a web developer and feel the need to only show you how Ember’s infrastructure works. And that’s the most important part to building an Ember app. Internalizing where aspects of you application should go.

Whats the url? Put it in the router.js

Do I need a library? Make sure to import it after using a bower install in my brocfile.

Whats the model behind this page? Add it to the model hook.

Do I need more than one model? Use a promise hash

Do I want some data to load after? Put it in the setupController so it doesn’t block on promises.

Is my model an array of objects? Use an array controller else object controller.

Am I doing manual rerendering? Setup named outlets. Add renderTemplate hook. Add action to rerender

You get the picture. The beauty of what I just described is that Ember made these decisions for me. This is a beautiful thing because any other developer on my team knows exactly where to look.

3 Likes

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?