Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Switch from Ember to Angular #7
The last couple of months have been a good learning experience. I had absolutely zero knowledge of Ember coming into this project, and decided it might be fun to use nimble as an excuse to learn Ember. There are definitely some things I like about Ember, such as the the mature routing ability, and the highly sophisticated property binding. However, there are far more things I do not like about Ember, and, as a result, I think it makes most sense to cut my loses and use Angular instead.
Some of the things I don't like about Ember:
There are other gripes, but I've outlined some of the big ones above.
P.S. This is not an "ember sucks" or "angular rulez" post. I'm not trying to rage against ember, just point out why I've decided on one over the other for my small and currently insignificant project. It's quite clear that a lot of time went into ember. Tom Dale and Yehuda Katz are two of the most brilliant developers around today, and I don't want my post to suggest anything to the contrary.
Just some quick replies re: your points above:
Did you check out the adapter/serializer APIs? ED comes with a built-in adapter/serializer, but they're totally customizable on an application or per-model basis. I think the inflexibility pain is likely due to a lack of understand how to customize ED, which is a documentation problem and we intend to have that fixed before ED goes 1.0. More details: http://emberjs.com/blog/2014/03/18/the-road-to-ember-data-1-0.html
This is actually really shocking. I think this was true maybe a year and a half ago, but certainly not today. I think the biggest gripe I have about our documentation is that there's too much now and it doesn't really interlink well and the navigation is cumbersome.
I'm not sure exactly what you're trying to achieve, but there's nothing stopping you from using these patterns in Ember yourself. Here's a great slide deck from @mixonic talking about the container/DI in Ember: http://www.slideshare.net/mixonic/ember-and-containers
Have you seen ember-app-kit? https://github.com/stefanpenner/ember-app-kit I think you'll like ES6 modules and the awesome test helpers that it has.
We are going to be adding the concept of services. The first one will be a
I think the tl;dr of not using Ember Data is simple: just use what you know - $.ajax. You can return a promise from the model hook in the router and Ember just does the right thing for you. Did you come across https://github.com/ebryn/ember-model ?
The author of the last post, recently did a 180: https://twitter.com/robconery/status/444287117909192704
I think Ember is tough to learn and we're working on making is easier via better documentation, but I truly believe that once learned, you will reach a new level of productivity that no other JS lib/toolkit/framework can compare to.
Thanks very much for the time you have taken to comment on this. I really appreciate it.
Yes, I read about these a bit early on in my exploration of ED. It seemed a bit confusing (to me) and I couldn't justify spending a lot of time trying to understand how to configure ED when I am very comfortable just making the ajax requests myself using
I think it's difficult to judge the quality of documentation from the perspective of a developer who works on the library/framework and really understands every single line of code, as well as the big picture. I say this as I've been given the same feedback on the documentation for Fine Uploader, a library I have been personally invested in since mid-2012. As you have said about Ember, very few people complain about Fine Uploader's documentation. In fact, we've received much praise, but a few have pointed out serious deficiencies in the docs. Historically, my answer to these people has been "are you serious?" (but not in those exact terms). It's always been hard for me to understand how the docs are lacking, since I really only need these docs as a reference for the API, events, and options. For that purpose, it is awesome (again, IMHO). However, for those who don't have the same intimate knowledge of the library, it likely needs a lot of improvement in the form of details and better examples. There are also likely important concepts and details that are not documented or glossed-over. This is my exact gripe with Ember's documentation. The examples are usually very trivial, and the concepts are not explained in great detail. The ember docs were always my first point of reference initially, but I found them to be of little use as my project progressed. I soon turned towards google to find the answers to most of my ember questions/problems. Whether you like Angular or not, I find their documentation to be superior. I think a lot of libraries could learn a lot from Angular's documentation site (as could Fine Uploader).
You are correct, but I very much like to avoid reinventing the wheel. I don't really want to worry about implementing DI, or services, or providers, I just want to develop my app. It's possible that this reflects poorly on me as a developer. With some more time and effort, I could perhaps have everything I need, but my time is limited, especially with projects such as this one, that I generally only work on late at night, outside of work. I'm taking up some of my employer's time to comment here as I think this is a good discussion relating to tools that we use here at Widen as well. (Please note that I speak for myself, and myself only, not for my employer in this context).
Agreed, and this is the route (no pun intended) that I chose early on. It bothered me a bit that the ember docs left out anything (that I could find) detailing best practices for a non-ED ember app.
That's great to hear. I certainly wouldn't rule out ember for a future project. I'm just not sure it fits with my current project, especially given the small amount of time I have to work on it, and my involvement in yet another (currently also irrelevant) library outside of business hours that is pulling on my off-hours time as well. Ember was especially tough for me to get started with. I worked with Angular before Ember, and while Angular had a learning curve, it was much more manageable (for me). This is a problem in itself. It's quite possible that Ember is simply a better all-around framework than Angular, but the time commitment required to get up and running is an obstacle that probably swings other developers towards Angular as well.
Again, thank you for taking the time to comment here. I really am in awe of you and the other Ember developers. I could never build such a complex framework myself, and I have a lot of appreciation for those who work on such things.
The switch to Angular is currently being staged in the angular branch. Once all current functionality has been converted, I'll merge the angular branch back into master. I would expect this to take a while, especially since I intend to do a better job of writing tests this time around (some tests vs. the current zero tests).
- Pulling all repos and populating the repo chooser modal. - Implemented paging of results in github API service - Need to implement conditional requests - Need to move some logic out of github service and into repo service? - More unit tests
I had to pull in angular-ui-sortable to handle the sorting, which also requires jQuery and a subset of jQuery UI. It's by far the easiest way to implement sorting that updates both the UI and the model. TODO: - Update GitHub on done - Update columns view on done