Why i'm leaving ember

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

I think the docs need to be opinionated - just like the rest of the framework - they should assume the reader is using ember-cli because this is the best route to take - instead of showing inline scripts and all that jazz - that would take a lot of the parsing required by people coming on board - no one really writes code with inline scripts + templates anyway.

That way the docs would be in es6 syntax and actually be easily transferable to a real world app.

1 Like

Uh, I am.

I really struggle with not being negative about CLI. CLI stands for Command Line Interface. Why would I EVER want to create an app through a command line interface? I’m 47, have coded since I was 14. From 14-16 I worked on Trash-80s and main frames. Of course we coded every thing through the command line on the main frame. I worked for two large banks in their mainframe departments and was one of the chief engineers in porting those applications to the PC. But that is what the whole PC revolution was about. A UI that could teach me about the work I was doing and make me more efficient than typing.

Imagine if you had an Ember designer that showed you the structure of your application, each template, view, controller, and route and you could click on them and make the changes you wanted to. Not only the existing objects could it show you but all the auto-magically created ones as well, so when you did need to put logic in a view object, it is right their, in front of you, easy to access and you know why A) it was rendered for you and B) why you now need to override that auto-magic object and create your own.

Yeah, command line… so 30 years ago. Give me a good app anyday.

2 Likes

Let me introduce you to the ember inspector

1 Like

I use the Ember inspector, maybe not as much as I should. So far all I have needed is the console to debug the app - I presume the error messages are being thrown by the Ember framework, and they have been great (show me where the error is).