Skip to content
This repository has been archived by the owner. It is now read-only.

Switch from Ember to Angular #7

Closed
rnicholus opened this issue Mar 20, 2014 · 7 comments
Closed

Switch from Ember to Angular #7

rnicholus opened this issue Mar 20, 2014 · 7 comments

Comments

@rnicholus
Copy link
Owner

@rnicholus rnicholus commented Mar 20, 2014

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:

  • It really is an opinionated framework. This is an commonly used adjective when describing Ember. Ember data is one great example of this. Ember data seems really cool and powerful, but it's equally inflexible. I hoped to make use of ED early on, but had to drop it after I grew tired of wresting with Ember data due to its very strict rules for any REST API you intend to use it with.
  • The documentation is terrible. I found very little of the documentation on emberjs.com to be useful when attempting to learn ember. It also does not serve as a good reference. In most cases, I had to spend an inordinate amount of time googling for information about a convention, or an odd side-effect/rule. Stack Overflow and various independent blogs turned out to be a much better resources than emberjs.com. As someone who has the continuous task of keeping documentation up-to-date and useful a library, I can appreciate how difficult this is. However, angular has simply done a much better job than ember in this area.
  • There is no accepted/native support for services and providers. Dependency injection is somewhat possible, but it's extremely awkward and immature. Furthermore the documentation for DI in ember is only a few lines. The documentation for DI in angular spans an entire page. This is also another example of how much better the documentation is for angular. I really like how DI works in Angular, and codified acceptance of services and providers.
  • Don't want to use Ember Data? Good luck. The documentation on emberjs.com assumes you will be using Ember Data. You'll have to google around to find articles on using ember without ED.
  • Ember is confusing. I know I'm not the only one who has made this claim. Learning Angular was a bit of a chore, but it was manageable (and now I'll have to refresh my memory as I haven't done anything overly complex with Angular in a while). Ember's learning curve is much, much more steep. Even after working with it (in my free time) for a couple months, I still feel like I don't understand it very well. After some reflection over the last few days, I'm fairly sure that I have been using views, controllers, and routers in a non-ember way all along, but it's not clear to me exactly how I should be using each of these concepts in the context of an ember app.

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.

@ebryn

This comment has been minimized.

Copy link

@ebryn ebryn commented Mar 21, 2014

Just some quick replies re: your points above:

I grew tired of wresting with Ember data due to its very strict rules for any REST API you intend to use it with

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

The documentation is terrible

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.

There is no accepted/native support for services and providers

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 SessionService which will be useful for bookkeeping things like the current user information and any API tokens you might have.

Don't want to use Ember Data? Good luck.

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 ?

Ember is confusing

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.

@ebryn

This comment has been minimized.

Copy link

@ebryn ebryn commented Mar 21, 2014

All that said, I'd love to hear more specifics. I pretty much make my living teaching Ember to people and I would love to know what specific things tripped you up.

@rnicholus

This comment has been minimized.

Copy link
Owner Author

@rnicholus rnicholus commented Mar 21, 2014

Thanks very much for the time you have taken to comment on this. I really appreciate it.

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.

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 XMLHttpRequest directly, or via $.ajax. I realize ED is much more than just an XHR wrapper, but I had a feeling I would end up spending just as much time "configuring" ED as I would writing my own persistence/request mechanism for my particular use case.

The documentation is terrible

This is actually really shocking. I think this was true maybe a year and a half ago, but certainly not today.

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).

There is no accepted/native support for services and providers

...there's nothing stopping you from using these patterns in Ember yourself.

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).

Don't want to use Ember Data? Good luck.

I think the tl;dr of not using Ember Data is simple: just use what you know - $.ajax

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.

I think Ember is tough to learn and we're working on making is easier via better documentation.

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.

rnicholus pushed a commit that referenced this issue Mar 23, 2014
Setup tests, structure, build.  Next: start porting over app code.
rnicholus pushed a commit that referenced this issue Mar 23, 2014
@rnicholus

This comment has been minimized.

Copy link
Owner Author

@rnicholus rnicholus commented Mar 23, 2014

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).

rnicholus pushed a commit that referenced this issue Mar 23, 2014
rnicholus pushed a commit that referenced this issue Mar 26, 2014
rnicholus pushed a commit that referenced this issue Mar 27, 2014
TODO Unit tests for new controller(s)
rnicholus pushed a commit that referenced this issue Mar 31, 2014
Also run tests on travis
rnicholus pushed a commit that referenced this issue Mar 31, 2014
Ray Nicholus
rnicholus pushed a commit that referenced this issue Mar 31, 2014
rnicholus pushed a commit that referenced this issue Apr 3, 2014
rnicholus pushed a commit that referenced this issue Apr 3, 2014
Ray Nicholus
rnicholus pushed a commit that referenced this issue Apr 3, 2014
@rnicholus

This comment has been minimized.

Copy link
Owner Author

@rnicholus rnicholus commented Apr 3, 2014

Starting to port the center portion of the header next. First up: the repo chooser.

rnicholus pushed a commit that referenced this issue Apr 4, 2014
Ray Nicholus
I still need to pull the actual repos from the API, but everything else is functional here.

I also replaced redundant directives with ng-includes.
rnicholus pushed a commit that referenced this issue Apr 11, 2014
Ray Nicholus
- 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
rnicholus pushed a commit that referenced this issue Apr 11, 2014
rnicholus pushed a commit that referenced this issue Apr 12, 2014
rnicholus pushed a commit that referenced this issue Apr 12, 2014
rnicholus pushed a commit that referenced this issue Apr 12, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
- Will try to avoid pulling in jQuery
- Created a generic attr-level directive to use for sortable items

TODO:
- Support add, delete
- Update Github & UI on done
- tests
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
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
rnicholus pushed a commit that referenced this issue May 6, 2014
 Replaced by angular-ui-sortable.
rnicholus pushed a commit that referenced this issue May 6, 2014
Also, don't update columns if save failed.
@rnicholus rnicholus closed this in 9656a14 May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
rnicholus pushed a commit that referenced this issue May 6, 2014
@rnicholus

This comment has been minimized.

Copy link
Owner Author

@rnicholus rnicholus commented May 6, 2014

Finally! 👍 🍺

@rnicholus rnicholus mentioned this issue May 7, 2014
0 of 10 tasks complete
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants
You can’t perform that action at this time.