How do we beat AngularJS in the developers mindset?

On the opinionated point, I mentioned in a previous comment that I work with Grails, which borrowed a lot of its concepts from Rails. And for anybody who works with Grails or Rails, the nice thing (and esp when it comes to larger teams) is that I can open virtually any Grails project, and know exactly where to look for what.

I found this to be the same when I looked at Discourse, the flagship example app I think for Ember. I’m able to open the Discourse source code in my IDE and know exactly where to look for the routing of the app, and from there, where to look for the routes, the controllers, the views and the templates. I have a mental map of the structure of the app that is the same from one project to the next. To me this is a massive positive and was one that won me over to Ember when I got frustrated with $scope’s in Angular.

1 Like

I’ve tried both Angular and Ember, and they both have their strengths. Here are a few suggestions I have to improve Ember adoption. Some of these were already mentioned:

  1. Fix the learning curve problem. More tutorials and better organization of docs.
  2. Realize that not everyone is using a Rails back end. Most larger companies do not.
  3. Finish Ember Data, or at least provide some examples showing alternatives.
  4. Publicize the strengths of Ember, especially the Routing.
  5. Make it smaller. The codebase is huge. Perhaps break it into components, and remove the dependency on JQuery. (This will make Ember more mobile-friendly.)

Joachim, a friend of mine let me read some chapters from your MEAP book and I must say I started understanding something about Ember by reading your book AND this page:

One problem is the lack of basic resources and the fact that the docs are too “monolitic”: it would be interesting to create an online “permanent” cookbook containing solutions to common issues, from very basic to advanced. As far as I remember Adobe made something similar with AS3 or Flex years ago.

The adoption is not only a matter of quality but of “hype” too. Maybe a big player (Yahoo!? Facebook? … ?) should adopt Ember.js. The fact that Google is behind Angular makes the project popular but at the moment I still read job postings where you should be proficient in ONE between Backbone, Ember or Angular. So Angular is still not a standard.


I took the time to learn ember, but when you start to take into account the upcoming htmlbars, the steep learning curve for the rest of the team and the solid rails integration with very little to no .net support… The framework isn’t ready for a full on integration with our app. I’ve been watching for the last six months, waiting for the project to truly mature, once that happens I don’t think angular (or any of the other frameworks out there) have a chance.

Advances in tackling the learning curve have been made, but it is the central issue to broader Ember.js adoption, and the winning of hearts and minds. It absolutely does not help that every book rushed to print about Ember.js older than 6 months is now full of holes, but yet they now form the body of knowledge.

The well written TodoMVC example in the guides aside, I also think it’s an incredibly short sighted position to be charging $799 for the official Tilde video training. Don’t get me wrong, I think people are entitled to do whatever they want with their own stuff, but given that beginners have such a hard time coming to Ember, and that it is extremely easy to follow the Todo example and then still fall off the cliff if you then try to deviate even slightly, putting all of that training up on Youtube and making that the definitive go-to starting point could have a big impact.

But this could be a broader issue in differences in philosophy. Ember.js authors have historically largely taken a position of charging for books, videos etc from the outset, whereas it seems Angular spent years with nothing but community output before recently moving to charging for screencasts and such.

If we consider the recent achievemnt of the 1.0 Milestone as Year Zero, we should all be flooding the community with as much free information as possible to seed the future correctly. I don’t see this happening. I’ve only just come back to Ember after a 7 month hiatus, so I intend to start writing as much as a I can, for free.

There is a start of a cookbook in the official guides:

Yeah, I’ve been able to find zero official guidance on what the best practice is here either.

1 Like

Lots of great views and suggestions here! Thank you all for those!

I will try to respond to the ones that I feel most valuable in my view.

The fact that Ember.js was in beta untill about half a year ago, is definitely a factor! And I do think that this has improved the situation somewhat! I do agree that Ember.js do have a learning curve, and answering questions on the IRC channel makes this point very clear. But its not only that Ember.js has a steep learning curve, but also that developers are largely used to writing webapps by assembling a set of “widgets” and combining them to create something that feels like an app. This is made a LOT worse by the fact that the two largest enterprise serverside languages JEE and .NET Webforms largely do all that they can to hide HTML, JavaScript and CSS from the developer, while trying to deliver a stateful experience over the stateless HTTP protocol.

Crushing the misconceptions that HTTP is as stateful as TCP in developers minds is difficult and takes a lot of effort.

While Ember.js and AnuglarJS is different enough, I don’t think that most developers new to the JS webapp game look at them as “two different types of tools”. They are, in fact, both tools to write SPAs in the browser, andt they both claim to be backend agnostic. They are similar enough that most developers new to both these tools wont be able to tell where the difference is.

Embercasts is a great idea, along with well written tutorials and books. Depending on who creates them, it might not be feasible in the long run for these to be made free of charge though. Creating good content takes a lot of work, and for most people that is time spent away from generating income. I definitely fall into the category of creating content for money with Ember.js in Action, and even though I’ve yet to actually make any income with that book, it will, once its published hopefully generate enough income in order to free up time to create more content. I think many are in the same position as me though, wanting to create good content, but finding that its hard to find enough time to do that properly on top of work and family.

Generating income from content vs creating content for free is also a chicken-and-egg kind of issue. You can’t make any income from a market until it grows large enough to support enough people willing to pay for good content. This means that increasing the market needs to initially start out with lots of free content.

I also agree that there is very little non-rails-centric Ember.js content out there. Rails and Node.js is the “cool” solutions to build stuff on these days, and thus this is where the content writers go to when writing their content. Having well written content that targets Java, .NET and PHP is critical in order to win over those developers. And those three market segments in the web-application scene are absolutely huge!

We also need to showcase what large webapps written with Ember.js is doing in order to keep their development smooth and on track. Show and explain why learning and adopting the strict MVC patterns is going to pay off in dividends once your app grows.

I think, that the fact that you MUST use MVC to the full extend even for small apps is both a strenght and a weakness with Ember.js. En even though the learning curve have gotten a lot less steep with Ember.js now automatically generating routes, controllers and views, the developer still needs to know that theory are in fact there.

Also a great visual prototyping tool is a good idea, but it is also a LOT of work. Look at the Cappuccino group. They used to have an awesome webapp that let you assemble apps, but now they use an XCode plugin and use Interface Builder instead. I don’t see that building such a tool is possible without some serious financial backing.

Also, the fact that some Ember.js books are resources is out of date is sad, but understandable. I’m glad I’ve held off with Ember.js in Action until Ember.js was stable. It wont come out until March, as Manning will spend a lot of time in production, getting everyting into the “Manning” style. That is the advantage of self publishing, you can publish early and often, where the advantage of going with a publisher is that the content will need to be properly proofed, as thousands of printed book will be printed and shipped to customers and bookstores (there’s no re-doing the print :slight_smile: )

I am hopeful for the future. And as someone mentioned, Ember.js doesn’t really have to compete with Angular. The real competitors are JavaServer Faces, .NET Webforms and the various PHP server-side frameworks. This is truly where Ember.js’ market is, and we need to do out part to grab it!

That was my loooong resonse to all of your great commetns and suggestions :slight_smile: As you can see, I like to write :wink:


A brief weigh-in here, as an interested observer. I’m currently using AngularJS on the project I started work on a few months ago, but am fairly neutral on the two frameworks - both are great, and I’m sure I’ll use EmberJS in the future.

Angular has been easier to get started in, but at the same time it seems a lot easier to write really bad code in angular - $scope pollution means I have fewer troubles getting actions attached to controllers, but at the same time it’s a lot harder to keep things clean. I’d say for a small- to mid-sized webapp and me personally, it was considerably easier to jump into angular. Again, though, this was in July-August of last year, when Ember was still quite young. Testing was also a lot easier to handle in AngularJS, although I hear there’s improvement on that front in emberjs as well.

Ember Data was the other area of frustration for me. Persistence layers in general can be frustrating, and I have high hopes that ED will someday provide the magic pixie dust I need. At the time I was testing Angular, neither the pre-release-but-stable version nor the canary build of Ember Data would work for me - both had subtle bugs that made it really hard to resolve nested and side-loaded resources; I’m sure those bugs are fixed now, though.

I’m actually planning a new week-long survey of the landscape in February where I see where everything has landed. For me, the big issue has come down to DRYing up my persistence layer. I’d love a simple way to cover these really basic CRUD actions synchronized between my API backend and the SPA frontend. Even with angular’s $resource or $http services to handle communication, there’s a lot of boilerplate-y code that seems prone to user error. A bulletproof persistence layer would really do the trick for me. Well, that and realtime two-way binding without needing to use firebase.

Joachim has a really good perspective on this discussion. Notably:

I think many are in the same position as me though, wanting to create good content, but finding that it’s hard to find enough time to do that properly on top of work and family.

I feel like the silver lining of this problem is that it can have a decentralized solution. Single writeups for a cookbook, single blog posts on individual blogs (we don’t need to commit to writing all-Ember-all-the-time), nibbles like that all contribute to a changing this sort of situation.

The discussion in the last few posts has been about video training and screencasts; like Joachim’s book, a screencast is a pretty big undertaking. (Although a book is bigger.) I don’t really learn well from screencasts; I’d rather read something, so I can skim, skip around, and find it in a search engine. Blog posts don’t need to be so big; a paragraph to describe the problem (including the versions of your libraries!) and some code to describe the solution, along with another paragraph explaining the code, might be all you need.

1 Like

Thanks! Maybe this could be enhanced.

Not sure why the PHP frameworks would be considered competitors. At least, they aren’t anymore competitors than the various Ruby and Python frameworks. There isn’t any difference in who’s pushing JSON to Ember, whether its Symfony or Rails or Django.

As for the .NET and Java frameworks, start pushing example projects that show how to easily you can integrate Ember with .NET MVC and with Grails, Spring MVC, etc.

I think to be competitive against Angular, continue making the sorts of improvements that are already being made and at some point when it’s decided the project has enough polish, do some marketing. Here are some general high level suggestions since everybody else is making them.

Build Tools

We’re given the Starter Kit where the application is a single page. That’s cute, how do I write something in the real world, with multiple files, templates, concatenation, minification, coffeescript/typescript, modules, etc.


I don’t know what the status of this project is. But I think it would help with the ‘learning cliff’, and maybe speed up development for the rest of us, if we could generate the defaults.

Internals Docs

This is something that would be very helpful to me, personally. Visual diagrams of how the components fit together. A description of object lifecycle. Talk about the runloop (there was a video a few weeks ago, so that’s fine Ember.js SLC - YouTube). Doesn’t need to be very complete since someone digging that deep shouldn’t need much hand holding. But a map would help.

Libraries and Integration

There aren’t very many Ember specific libraries and in my experience it’s not very easy to integrate existing JS libraries. I think a good metric would be to look at something like Bootstrap and UIKit and consider how to integrate those and what could be done to make that process easier.


Would it be helpful provide a desktop GUI app for Ember development? I find setting up a new Ember application very cumbersome. Ember App Kit resolves some of the issues here but I still need to be in the command line to create new projects etc.

Maybe a nice polished GUI to create new EAK projects from templates, manage them, start servers, testing, building, generating would alleviate some of these problems. It could also help keeping the used Ember and EAK framework up to date. Or include a directory of Ember Libraries that can be integrated with the push of a button.

If anyone is interested in this maybe we could discuss what we could whip up.

Are you thinking of something like the Android Development kit GUI? That’s what came to my mind as soon as you said that.

If you haven’t used it before, it’s basically exactly what you described except for android projects.

I don’t really know the Android development Kit, but I think it’s something alike. Maybe something more like Xcode. A top to bottom integrated solution.

I think creating an application like this for multiple platforms would be time consuming though.

Ah, yes, something like that.

Here’s what the sdk manager looks like for android, dead simple:

If it were backend agnostic, it would be even more epic.

Probably with its own package system (for quickly installing bootstrap, nifty modules, components, etc), using Java or Mono for the GUI. You’d be responsible for installing your own backend handlebar compiler, api backend, etc. I personally hate ruby and refuse to even learn it (had an extremely bad experience with updating gems a few years ago on a production server that resulted in several days of downtime) … so I like backend agnostic since I’m a PHP, .NET guy.

Hey @bakura, I am also developing an api with zf2 and emberjs+ember-data as my front end. I didn’t use apigility due to lack of getting started tutorial which has one complete module. As of now it is great with zf2+ember, but the ember-data serialization which is tied to the rails api is kind of pain to support zf2 JsonModel. It is supposed to be backend agnostic but out of box it is planned to support rails active model serializer.
Feel free to correct me if I am wrong anywhere.


I’m currently using my own REST library for ZF2 (which is called ZfrRest - -). I have written my own resource renderer that uses ZF2 hydrators and outputs the data in a way that is readable by the default RESTAdapter of Ember-Data.

It’s a bit hacky for now and I didn’t open sourced the renderer yet. The problem is that I’m a bit lost between RESTAdapter and the ActiveModelAdapter. It seems that the two adapters are a bit different, but not so much (I’m not sure to understand why Ember-Data is bundled with those two)! I’ve heard that the RESTAdapter should be compliant to JSONApi, but it’s not yet. Once Ember-Data stabilizes towards a given format, it’ll be much more easier to start writing integrations with PHP frameworks.

Hi @bakura,

It would be great help to developers like me who are using ZF2, if you could just show a demo or better yet the unfinished renderer. Yeah, I am also still waiting for the RESTAdapter to be compliant to JSONApi.