Why we're moving away from Ember.js

How are ya'll caching your stuff? Sounds like all that is doing is just making fresh requests for every route.

We've been using Ember in our production environment for nearly a year now. There are lots of plus' and some minus', but I'd like to take a few minutes to share our experience.

We picked up Ember 0.8 in March of last year. Having some prior SproutCore experience it was a pretty easy thing to get going with. Back in those days, Ember was pretty nonconventional, there was a right way and a wrong way to do things, but the framework didn't really enforce a strong point of view. This was really good and really bad at the exact same time. The good was there was a much lower learning curve. The bad was it was so easy to head down the wrong path and shoot yourself in the foot.

I think in the summer of last year, just after Ember 0.9.8 was released, many of the core team members started to explore some the criticism and problems with the framework at the time. The end conclusion, from my view, was to restructure the architecture of the framework. The pieces were the same, but they fit together differently. The biggest of these changes was with the introduction of the strong router conventions. In addition, there we're major changes to the default template context, view hierarchy, runtime and metal, among others. IMHO this was the first time Ember really expressed a strongly enforced convention through the framework.

Fast forwarding to today. Ember has a lot of concepts that people have spent months and months working on. I can sit here and endlessly explain why how the router's pattern makes your application more flexible, or how the template patterns make for easy reuse, etc etc etc. But the truth is you won't really appreciate them until you've given Ember a fair shake.

EDIT: A fair shake doesn't mean picking it up on a weekend. A fair shake means trying to build a reasonable size application with it. Spending a two or three weeks. It has a big learning curve, but that doesn't mean it isn't valuable.

Your comment history indicates that this is a troll account, but I'll reply in case a bystander takes your post seriously:

Ember is actually composed of many smaller, independent packages. For example, we built four microlibraries for use in Ember that you can use totally independently: router.js, route-recognizer.js, rsvp.js and metamorph.js.

Additionally, many people use other great projects from the JavaScript ecosystem to do Ember development, like D3, Crossfilter, mocha, Jasmine, etc. Your assertion that it does not work together or integrate with other tools is 100% false.

We use a local storage method in browser and app data when running in phone gap

I've played around with Bootstrap and didn't like the idea of trying to replicate MVC on the client. Like the article said, I'm not yet ready to move away from server side frameworks for the most part. However, I like the data binding style of programming a rich client UI and I've actually found that Knockout.js is really nice for just doing that part. Does this seem reasonable? Would I gain anything by moving to Ember to do the same thing?