Why i'm leaving ember

I’m not sure I see how cramming all of your code into one file is better than using a tool that runs on the command line. Even if you were using grunt or something to compile, you’d still presumably being it with a CLI. You don’t even need to use the commands that much if you don’t want to (even though they’re faster than any UI could be). If you all you use is ember new and ember s, you get all the structure, live reload, and compilation benefits without having to use any of the commands. I was a little resistant to it at first as well, but I couldn’t imagine trading CLI for an IDE now.

All the code in one file is BAD, and I wouldn’t do it if there was a good example of how not to. The examples on the website (video, starter kit, etc) show it all in one file. But the issue of separating files is not CLI or not. In my Java, and C# apps every class is in it’s own file and I don’t use CLI. An IDE does separate files just fine.

And I, like many or all developers, hate throwing away code. In teaching myself Ember I got stuff running in the Three File Model (HTML, js, css) and I’m more interested in getting the application logic worked out than restructuring my code in separate files. Project 2 (if there is one) would probably start with Unit tests because I really like TDD design (yes I used the old way of saying TFD, but to me TDD includes BDD and TFD all in one), and separation of files.

What I’m really pointing to is a GUI can teach new users about what they are doing more than any commandline application can. An application can be a tutorial where a command line cannot. Further, it can show you the hidden parts far beyond “/?” or “/help” ever will. And I’m also not talking about an Eclipse or Sublime or Visual Studio style IDE either. Think UML Communication diagram linked to the code so you see where all the communication is going even when the objects are automatically created by the Ember framework.

I believe that’s why the Ember inspector was mentioned above is because it shows you, your paths through the application. What I don’t think it does is link to the source code, and I don’t know how many of the hidden objects it shows you.

As someone who used to manage a 200,000-line C++ code base before getting into Javascript, I have to agree that the Ember learning curve is pretty steep even for me!

I recently evaluated and discarded React and Angular for a new project, picking Ember. With the other two, I could easily understand what’s under the hood – the architecture. With Ember, I forced myself to read the documentation top-to-bottom (including doing the todomvc app), but I still don’t have a good mental model of Ember’s architecture. And without that understanding, I have to memorize the steps, which I don’t believe in doing.

I think the problem is not the framework. It’s not even that the documentation is not detailed (it’s very detailed, in my opinion). But it is encyclopedic. I’m thinking of doing a diagram that explains the whole thing to my team (who are new to JS frameworks). Perhaps I will post it here first, to check if I’ve got things right?

10 Likes

Actually you are saying that documentation should focus on what is in the code and how to read it. Programming documentation used to be that way. If not that strict, documentation may focus more on what is actually done by Ember, not on simplified usage samples. The first thing one mentions while using Ember is that classes appear where objects used to be. If the imminent Why??? is not answered, people will continue to be confused. Similarly, things like enifed and dependency6 should be explained on page 1.

Yes indeed, there should be a good overview diagram including flow charts and method hooks.

2 Likes

I have worked with AngularJS for a year now and I didn’t have any real problems with it. It has its issues (mainly the implementation of Directives) but the rest is very straightforward.

The reason I am looking at other frameworks right now is that AngularJS 2.0 will be very different from 1.X. I am learning emberJS now and almost ready to dump it in favour of Angular. The documentation outside of Ember.js Guides - Guides and Tutorials - Ember Guides is non-existent and there does not seem to be any development pattern explained anywhere. :confused:

Before you give up, first have a look here for some better guidance.

https://github.com/foraker/ember-reading-group

2 Likes

I have the same problems as described by the others. I think figuring out how Ember works is very hard. And it’s not because I’m a lame developer. I have over 10 years experience, a master degree in computer science and worked with many different frameworks. But working with Ember feels so unproductive to me. And links like the following Ember Reading group aren’t motivating. 7 weeks?? When do I have time to learn a framework for almost 2 month before I can get started?

Because many are comparing Ember with Angular. My experiences with Angular are much better than with Ember. It took me just 3 days to get started and then I was really productive. Because I’m forced to work with Ember right now I can’t switch and have to stick with it. But still after 2 month of working I’m not as productive as with Angular after the first week. And sadly I don’t have the time to read hundreds of pages, tutorials, blog posts, etc. My feeling is, that the Ember universe is so huge and it is so hard to get the concepts. There is so much magic going on and for me it’s not obvious how the architecture behind these magical things works. I really feel lost and find myself often fighting with Ember. I also think that the super-restrictive view isn’t helping at all. Yeah, but this seems to be a core concept of Ember. I don’t know…

Maybe Ember isn’t the right tool for me and I should stick with some framework which favours configuration over convention. Haha… but right now I don’t have the choice :smile:

3 Likes

I totally agree to your post. “Encyclopedic” really expresses my feelings about Ember. Maybe someday I know the whole encyclopedia :smiley:

1 Like

I can relate to your feelings of frustration. Any powerful tool/framework just takes time to master. Seven weeks is a bit of an exaggeration, but indeed it took me more than a few days before I started to become productive. In retrospect, most people that in the end become experts wonder why the learning curve was so steep at the beginning. Perhaps we are still waiting for the right online video tutorial to come along and set us straight.

Have you seen http://www.ember-cli.com/ yet? This in my opinion helps with a lot of the issues that I had at the very beginning, such as folder structure, etc.

Here is a tutorial http://thetechcofounder.com/getting-started-with-ember-js-using-ember-cli, as well as an ebook: ember 101 by Adolfo Builes [Leanpub PDF/iPad/Kindle]

Hope that helps :smile:

2 Likes

I’ve been on the same project with ember for over 2 years and I would definitely not use ember again. I was all in at the start as I patched up the ember-data statemanager, waiting for the release that would fix it all. I blogged about all my experiences and while I felt things got better, I felt the core issues never got addressed. Here we are 2 years later and ember-data is still not out of beta. 2 way databinding was a pain from day one with ember-data models getting dirtied and then remaining in an invalid state unless you saved or rolled back the changes. I used the bufferedProxy and other hacks to get round this but the first year of the project was more about dealing with ember than shipping features.

You get pushed down the road of creating computed properties and observables all over the place but they are not practical for using large datasets. The first time you try and deal with a cp that is async then you know something is wrong, you get data observables and computed properties that are partially resolved triggering cascades down the line. I found the model broken, I found dealing with any sort of large dataset difficult and the framework just was not designed with this in mind. Things like the sort computed property macro etc. are all designed for everything being in memory but that is just not practical with a real world app. with real data.

The client side rendering is possibly the slowest of all the frameworks out there.

I like what I hear about ember 2.0 and data down actions up but I don’t feel it goes far enough. React seems to be all in with immutability and I like the unidirectional data flow of flux. I think if ember was to be a valid choice, then they would need to give this some thought. Dealing with immutable data structures opens up many doors and having a sea of mutation from template to cascading partial updates closes many.

All that said, we have shipped our product with a patched up version of ember-data and ember definitely got better but I feel the model of two way databinding, computed properties and observables make life very difficult and hard to reason about.

I realise I am bitching about something I got for free and I hope this feed back is constructive, on the plus side, I found the router something I really liked and the focus on components is making life easier although I would like to see some life cycle events in there apart from the view ones.

4 Likes

You raise valid points, but I think Ember’s newfound (or should I say: React-inspired) emphasis on one-way data binding will address these specific concerns in the future.

More info in this podcast interview: http://thechangelog.com/131/ relevant part starts at 44:00

I agree, data down and actions up is a good start but it does not go far enough. Why would I not just choose react? What does ember give me? I feel too much emphasis was given on demo apps where all data is in memory and I can use things like the sort macro which is no use to me with real data or creating nice widgets which is were I think ember does shine. I can’t remember the last time I downloaded a jquery plugin, I just write it in ember. But if I have a complex view with infinitely scrolled, sortable data where all data comes through asynchronous paged data sources and the horrors that can be caused through cascading computed properties updates and observables with partially resolved data then I don’t see the progression.

Ember needs a proper data flow story or the problems I faced will continue. I’m writing a blog about this as I write this, I’ll post the link when I am finished. I hope the ember team do look at flux or reflux.js for ways we can make this better.

1 Like

Agreed. While I do have confidence in Ember core supporting efficient data flows in the future, I’m not sure about Ember Data. The whole idea of keeping stateful models in memory may very well be outdated.

I blogged a about some of this here

3 Likes

Please do not stop trying. I can tell you emphatically from being a developer now for 8 years, that once you get to a certain point in Dev things get hard. Sometimes very hard. Keep trying. My advice… just back off the big stuff, and when you feel this way return to the roots.

Return to something simple in ember and increase your knowledge…then code something up…something simple. and build on your knowledge. It is just going to take time. You are dealing with a very robust framework here, not a language. There is a lot to learning a framework. It just takes time.

For instance… you can grasp the ins/outs of Objective-C pretty quickly… but try wrapping your head around the Cocoa/iOS framework in a month. It’s not possible. Try 2 years of constant work.

Just keep going my friend. You will struggle and then make a breakthrough…then struggle…then make a breakthrough… Don’t give up!!!

Seven weeks is no exaggeration.

3 Likes

Good writeup. Flux is the right idea, but the lack of an official, standard implementation makes me somewhat hesitant to consider it for a real project.

In case you haven’t already, you might also want to look into RX Observables for some thoughts on how to model data flow. RX Obervables are asynchronous collections of data, for example a stream of mouseover events, or a series of WebSocket notifications. Being observable (as in: the Observer design pattern) makes them conceptually compatible with Ember.Object (or more accurately: with Ember.Observable).

Asynchronous Programming at Netflix (excellent presentation on RX, the first 25:00 covers the essence)

https://github.com/blesh/RxEmber

For me observables in ember are a big part of the problem with ember. Having model state being mutated through observables or having data flow through observables has put me right off ember. The problem is that it is prominent throughout the framework.

1 Like