How do we beat AngularJS in the developers mindset?

React is no longer a threat now that Ember will have Glimmer soon.


It is huge but it is also not the right way to go and the more they patch VS to keep up with modern web dev the more it will show.

Take for instance NuGet - it’s a mess. Why didn’t they just hook into an existing package infrastructure?

@MartinGoodwell right now we are testing ruxit and we just have it on our dev servers. So we don’t have any special demands right now. I’m sure we will discover our special needs while testing your product. We use Ember-Cli and for XHR they use ic-ajax [1] which is basically a wrapper of jQuery XHR. So as ruxit has jQuery support this should be fine for us.

Just to clearify, it is not that ruxit lacks Ember.js support. I wanted to point out that Angular is omnipresent and Ember.js gets less attention. There are plenty of example where Angular support is promoted and Ember is not mentioned. Ruxit was just the most recent example I stumbled upon. Another example could be with it’s AngularSDK.

I think this issue could distract business from choosing Ember. It’s not an issue with the products, companies which promote Angular support, it’s more an issue with Ember-marketing

After few weeks of work on my first Ember.js app, I think I am ready to chime in.

One thing I am sure is Ember.js isn’t losing to Angular in advertising. It has its “cool factor”, there are guys out there who are spreading the word. If somebody asks about client side JS, the “also give Ember.js a look” guy is always here.

So, where you lose?

Coming from my own observations and what fellow devs who tried to get into Ember but eventually were bounced off and found promised land in Angular.js have told me, I have concluded following:

As a project intented to be a tool for developers to build with, Ember.js tells too much about how it achieves its ambitiousness, but too little about how I can use this ambitiousness in my project.

Let me use hammer methaphor to better explain my point:

I have two wood planks that I have to put together. I have asked around and from what I understand now, the tying them together with string is just so past decade. Everybody uses hammers for that now.

With my interest piqued by word of this new unheard of tool, I go to store where there are two boxes claiming to “just what you need”: Angular and Ember. I buy Ember hammer, because it has amusing rodent on box and memories of having pet hamsters made me warm and fuzzyinside. I take it home and sit down to my project.

I unbox Ember hammer. Inside I find tool with some nails and booklet that tells me following:

Confused, I take my box to town elder and ask “Oh The Allknowing Elder Google, What Is This Sorcery?”, to which elder answers:

This is the Ember Hammer. The Gods of the Hammering have used it to Hammer works that have impressed all, and they have found it good tool.

Confused by such non-answer, I return to store, where I pick that other hammer, the Angular one.

I bring it home, unbox it and inside I find booklet, hammer and some nails.

I sit by my planks, open booklet and start reading.

This is amazing. I now have two planks connected! But I also have composite blank I would like to hammer to those wooden planks. So I go to the Elder and ask: “Oh The Allknowing Elder Google, How Do I hammer composite plank to wooden plank with Angular Hammer?”, to which Elder answers:

Page 67 of the booklet, Son.

When I ask people why they dropped Ember.js for Angular.js, I always hear this answer:

Because I tried to do XYZ for four days, but couldn’t find any documentation, tutorial, example or StackOverflow Q&A on how to do it, or what I found was about something completely different. Then I tried it for Angular.js and had code snippet I just copypasted into my project in 10 seconds.

Ember.js docs (and community!) fail to accumulate and convey answers for those questions.

For example, if you pull Django documentation, its NOT written to teach you how to Django. Its written to teach you how to do good webdevelopment using Django.

Ember Guide needs to stop being about Ember. It needs to start being about achieving all those ambitious things I see in internets that make me say “me too!”. It needs to understand that Ember isn’t a goal, only one of tools in large toolkit used for achieving something greater.

It needs to show me how to use Bootstrap Tooltips on my pages, how to make automagically updating dates via Moment.js, how to do RPC for those little things that don’t make sense in REST, how to change page title when user transitions into a route, what design patterns are popular for handling forms in components/controllers, how to use my CSRF cookie in my adapter, how to lazily load heavy 3rd party libs like zxcvb.js or use google CAPTCHA.

Until Ember gives those answers, people will keep turning to Angular instead. Eventually, some of them will start giving to Angular’s ecosystem, in turn attracting even more people to Angular in future.


I hadn’t thought of this before, but I think he’s on to something here.


I think rafalp is onto something. There’s room for both approaches: A lot of the “how to think in Ember” stuff is really important for allowing you to be creative in the framework, but some “Ember Legos” to build apps with would be a much friendlier place to start. I think that’s what the cookbook was supposed to be, but I don’t think it’s seen much action in a while. Maybe we should do a “call for recipes?”

@kylecoberly call for recipes sounds like a great idea. I’m starting a new thread.

I’m a technology agnostic who wants nothing other than to relieve the suffering of developers faced with choosing technologies.

So I made this:

I’m looking for ember and ember-cli experts who can help fill in a few unknowns about these things so that people can clearly see what the trade-offs are between ember and angular and everything else.

If you are able to help out to any extent (you don’t have to be an expert), please send me a private message and I will make you an editor of the document. Every little bit helps and all good reasons to use ember (worded in yes/no form) will be added to the list.

So some thoughts from an Ember beginner (as in: no “real” code written yet). Also, first post, so hi all.

We at my company need to select a SPA framework (or toolset, if we’re being strict about what is and is not a framework). I really want us to choose Ember. Or more accurately: I’m really hoping Ember is a good fit for our purpose so that we can choose it. The thing is, it is rather hard to understand how painful things would be with Ember.

For example, one of our primary needs is to have Ember run nicely on Android (and iOS and whatever the mobile Windows is called), probably both as a website and as a phonegap app. So then you start googling around to see if you can find blog posts or forum discussions about whether I’m going to have a bad or good time with Ember, given those and other requirements. Then you quickly stumble across some old discussions like these:

(and even recent rants like this: Reddit - Dive into anything)

You realise they’re old threads and stuff has probably improved (and might improve before your app is going into production). But the seeds of FUD have been planted. “Maybe we should choose angular since surely the massive user base will help / has already figured all the solutions to any problems we might have?”

Of course, you then would start to look for newer information: whether the pain points you’ve found are still relevant. The point is: this takes way much more effort than it needs to. I have been doing substantial digging to understand where things are going and what pain points are currently relevant, so I know that there’s a list of things for Ember 2.0 on Github somewhere, I know there’s a conference talk on youtube announcing the date for 2.0, there’s a website (and a thing on Github) tracking the progress of the Glimmer engine (also announced on the same conference talk)… none of which has been linked or announced on the site (excluding this discussion board).

This would be extremely easy to fix. Just make more blog posts. I’d think things like Glimmer, date for 2.0, Ember conf videos, all the nice stuff that is happening around things like the CLI and Ember inspector should be announced and talked about in the blog.

1 Like

+1. Even if they were just links to the external resources, I think having a much more active blog would help. You could have links to the conference videos, particularly good meetup presentations, hot forum threads, RFCs, and maybe a “this week in Ember Twitter” best-of. The width and depth of stuff out there is great, but it would be nice to some curation on the main site.

1 Like

I actually posted over here about how to improve the Docs, before I’d read this thread. So let me address my thoughts on this topic.

I’m exactly the target audience that would have used Angular instead of Ember. In fact, I’m about 4 weeks into Ember and very close to calling it quits and moving to Angular. I’ll start from the beginning.

I’d say I’m an expert in PHP, jQuery and WordPress. I work at a digital agency, and work on WordPress powered sites almost 6 days a week. I’m in charge of a team of 3, with a network of freelancers. I hate VIM, we use Coda, the GitHub App, and generally stay out of Terminal.

WordPress just rolled out a JSON API, so we are starting to move to using WordPress as an API to power an MVC frontend. I spent a few months going into Ember v. Angular v. Backbone v. Flatiron. I would have gone with Angualr, except they blew up v1 and I’d have to start again with v2 at the end of the year, so I figured I may as well learn Ember now, and then switch to Angualr 2 if need be later.

The Google thing was a non-factor, seems like Ember gets hung up on that.

So far, the major pain points for me trying to get into Ember have been Pre-compling templates, Authentication, Routes v. Controllers (they seem to do all the same things!), Views v. Components (all examples use Views, Ember teams says to use Components), and Animations (not mentioned in documentation at all). I’m also struggling to find a list of all the action hooks (I’m not even sure that’s the right name for them - beforeModel etc) and what sequence they get called in (would it be too much to see something like this).

The steep learning curve. No one above has touched on why this is so steep, but for me its easy to see why. Here is a list of technology you need to be very familiar with in order to build a simple signup/login/save-something app.

  • Node.js
  • Rails (so many examples say “Ruby gem” and it makes it seem like you need to know Ruby just to install something).
  • Grunt
  • Ember CLI or Ember Templates
  • Ember Data (the docs make it seem like ED is the best way to go, it’s not even at v1!)
  • Ember
  • jQuery RSVP promises
  • Setup a .htaccess (or equivalent) file to route everything to index.html
  • How to config CORS on your API server
  • jQuery
  • JavaScript

The above list is insane, you are not making it easy on people to get into Ember. Could you imagine a job posting asking for the above skill set? What would the salary be? Compare that to WordPress: PHP, HTML/CSS and maybe jQuery.

Now, it seems to me the best thing Ember could do is start figuring out ways to cross things off that list. Here are my suggestions:

Improve/Remove Pre-Compiling

Give up on the “everything in index.html” examples. They are disingenuous and not helping your cause. Having templates in separate .hbs files are the proper way to do things, so start owning up to that. I know the Ember core team are very adamant on how build tools are such common place these days, but the simple fact is they aren’t. If you’ve come out of PHP, then you’ve never used them. If you improved the build process, you’d cross 3 things off that list right away. My wish: Build a simple plugin to Coda that compiles templates on save. Now I don’t need Ember-CLI, Node or Grunt, and I can host everything on any Apache server.

Better “Ember Way” documentation/examples

The example app is way too simple for real life. No one is building a blogging app with no authentication. Authentication is a major pain point that you need to get over very early on in a build, and there is no clear indication from Ember about how best to do it.

@rafalp hit the nail on the head (see what I did there?). The docs don’t come at it from the right angle, help us build something useful, don’t show us all the fancy stuff Ember can do on Day 1. My wish: 2 or 3 simple apps well documented showing signup/login/save-something, each more feature complete than the next. They should show the current best practice on how to do things.

Then something like the WordPress CODEX. Start the docs from the point of view: "So you are looking to build something. When a user requests a Ember page, first this happens, then this, then this etc etc.).

See this for more details.

Don’t talk about Ember Data yet

It’s not ready for prime time, and it adds a whole other level of learning at an early stage of a persons Ember onboarding. You’d be way better off talking about simple ways to connect server side APIs manually. The concepts are easier to learn (it’s just AJAX returning a JSON object), and those lessons only make it easier for you to understand ED later when you are ready.

From what I understand so far, the same could be said for models. I got real hung up on defining models in Ember, when really if the server returns JSON objects formatted correctly, you don’t even need to define anything.


Angular makes a big deal out of this, because it’s what people in the real world want. The first thing anyone will want to do (even before authentication), is have a drop down menu or animation between routes. Ember makes a big deal out of being a “real world framework”, you need to give some official direction on how to do basic animations. My wish: Something way simpler than Liquid Fire, that allows me to slide in a menu, and animate between routes.

Stop talking about Rails/Ruby/Node

The PHP audience is massive, and the way WordPress is going will only encourage people to go the MVC way. But the more I see Ruby gem this, or Rails this or Node that, I just start thinking “wow, I have to learn so much just to use Ember!”. You should be server agnostic, and not require Node/NPM/Grunt to use something that is essentially a giant plugin to jQuery.

Get way into StackOverflow

Forget about IRC, your only helping nerds :stuck_out_tongue_closed_eyes: . StackOverflow posts last forever, and serve as a stop gap for incomplete documentation. The voting nature of it also makes me feel confident that something is best practice, more so than a blog from a year ago.

And having read the above thread, I’d urge you not to get hung up producing video tutorials. That’s such a frontend developer mentality (the days of Flash are over!). Clear direction on best practice from the core team, solid StackOverflow presence, solid example apps, and great supporting documentation is more than enough. WordPress got massive doing just that, can’t remember ever seeing a WordPress tutorial video.


Although I do not share your feelings here, I am actually absolutely on-board with fleshing out ember-cli / (editor|IDE) integrations. I believe this would really be nice. At some-point this is totally something worth pursuing.

This is actually one of the motivations of ember-cli, it aims to handle all these details for you. No need to learn how to compile templates, grunt, how to get tests running. Additionally, it aids community wide conventions, that make it easy to share add-ons (like wordpress) and also makes it easy for one ember developer to easily migrate to another ember project.

I am uncertain about the “its not ready for primetime” statement. I have seen and continue to see it used with success. Although it may not handle all use-cases, the ever growing set it does, work quite well.

Some pretty fun public examples that really show-case the flexibility of ember-data.

In reality, you do not need to use ember-data in ember, you can simply return ajax requests and ignore the ember-data even exists. It many of my apps, i really do use both.

When building an app with raw ajax requests everywhere, I quickly run into duplication of data serialization and API level concerns. Once i hit that pain, I start utilizing ember-data’s conventions to manage this complexity.

  1. adapters → API / Ajax level concerns (and honestly, just normal $.ajax in the adapters)
  2. serializers → data transform needs

What this means is, you can choose to use as little or as much of ember-data as your comfort level allows. As one gets more comfortable with it, you realize how it helps manage complexity.

if we look at ad the hn-reader, we can see that @chancancode uses the adapter to encapsulate the raw XMLHTTPRequest (this could easily just be $.ajax as well)

Now that enables him, to use'article', <article-id>) throughout his code-base, without leaking the details as to how.

This I also have to agree with. I in-frequently venture to StackOverflow to answer questions, this is largely do to personal time constraints, but I suspect making this a habit would actually go a long way.

1 Like

The above list is insane

Yes. Welcome to 2015. I realize that lots of web developers pine for the good old days when they were writing simple web pages. Those days are ending. Knowing just PHP, HTML, CSS, and jQuery is not nearly good enough to write the kind of ambitious applications that lead their industries today.

This isn’t an Ember-specific issue, this is the difference between web pages and complete in-browser applications. Asking how Ember compares to jQuery is not the relevant comparison. It’s more appropriate to ask how Ember compares to writing a native iOS or Android app (and I for one will take ember-cli over XCode any day).

The key tool that solves your pain points is ember-cli, and ember-cli hasn’t had a stable 1.0 release yet (coming in June). That means we’re still in early-adopter territory. Being an early adopter isn’t for everyone. It means you won’t always have clear instructions, and it means you will hit bugs. If you aren’t OK with that, then don’t be an early adopter.

We care strongly about creating a welcoming and accessible community. We want to help everybody who wants to learn Ember to learn it with the minimal necessary effort. But we are not miracle workers. Being an early adopter always comes with a certain amount of struggle. The early adopters do a lot of work that paves an easy path for everybody else to follow behind later. We are getting there.


As someone who just started a project for the first time this crystallizes my exact sentiments. Explaining how things work is an important first step. Explaining how things work in the context of getting **** done is the next.

[quote=“ef4, post:172, topic:3948, full:true”] Yes. Welcome to 2015.

The key tool that solves your pain points is ember-cli…[/quote]

I wanted to say “you’ve got to be joking”, so maybe I’d say it this way. If you knew PHP, HTML, CSS, and jQuery you’d know enough to learn any framework or coding paradigm. Then again I am a dinosaur and started coding in the early '80s, learning and adapting for 30 years can train you to always be adapting.

On your second point, if the future of Ember is cli, count me out. Coding from the command line is not mainstream and cannot have the reach needed to compete with frameworks that have more adoption and backing. I started on main frames, coding from the command line - it is not the future, it is very much the past.

Let me give you a little of my Ember experience. I started coding in Unity at about the same time as I started coding Ember for myself. By day and night I was a Unity game coder and at night I was teaching myself Ember writing my own animal husbandry site. In six weeks of being lead developer teaching the company how to write games in Unity (my first time) my boss said what I was doing he thought we wouldn’t be doing for six more months. In seven weeks of coding Ember I was ready to give up.

Now a few months later I’m back to try again, I’ve shown my Ember site to my friends and they had a much better idea on how to manage the data than I had. I’m willing to run through the gauntlet again and I have a better idea on how to pass data around within an Ember application which I hope to post in the future.

I am a talented developer and Ember is hard.

Coding from the command line is not mainstream and cannot have the reach needed to compete with frameworks that have more adoption and backing.

Here’s the thing: in web app development in 2015, there is no such framework. Not with the kind of flawlessly integrated IDE experience you want. But we are literally building the first layer that will make it possible. Other Javascript frameworks with much bigger backers (Angular), are starting to use ember-cli too because it solves this common need.

If you look under the hood in any IDE, there are lower level programmable primitives. More often than not they can be used directly from the shell. ember-cli is that primitive for this ecosystem. It’s a necessary step before you can do IDE integration.

Your comparison with Unity just reinforces my point. Unity is a much more mature product in a much more mature part of the wider programming universe. Browser apps are the wild west. If you want a curated experience like Unity, stay out of browser apps until the dust settles.

1 Like

Yes, I’ have had a really really hard time to learn ember, and I’m still confused. If someone rewrite the guides part, I’ll appreciate it really.

I agree with this one. It’s not that Ember Data isn’t ready, it’s that ember performs well with with POJOs and jQuery and that is simpler. For simplicity of learning I wish the Getting Started Guide didn’t mention Ember data at all. Then a “Take your Data Models to the Next Level with Ember Data” section

This page is a great introduction, and I wish that I had seen this page before I tried Ember Data while going through the Getting Started Guide

As a new user myself, this is the introduction I would have wanted:

Binding a model to your view is as simple as returning an object from your route’s model hook

App.PhotosRoute = Ember.Route.extend({
  model: function() {
    return [{
      title: "Tomster",
      url: ""
    }, {
      title: "Eiffel Tower",
      url: ""

Views will update automatically after async data arrives via simple ajax requests

App.PullRequestsRoute = Ember.Route.extend({
  model: function() {
    return Ember.$.getJSON('');

You can easily format and parse the data to meet your needs

App.PullRequestsRoute = Ember.Route.extend({
  model: function() {
    var url = '';
    return Ember.$.getJSON(url).then(function(data) {
      return data.splice(0, 3);

If you want to aggregate multiple async data sources, Ember’s got that built right in

App.IndexRoute = Ember.Route.extend({
  model: function() {
      return Ember.RSVP.hash({
          people: $.getJSON('https://some/api/people/'),
          companies: $.getJSON('https://some/api/companies/')

Ember Data has advanced features for maintaining relationships between models. Learn about Ember Data and the Data Store in Part 2 here


Then that is the most important piece of documentation that should be on the Ember site - THIS IS AN INCOMPLETE, PROTOTYPE FRAMEWORK.

You’re leading people on to believe this is ready for primetime.

This is just incorrect. I started on Visual Studio, then GUI text editors, and now vim- you’ll hear similar stories all over the place. Between that, npm, git, grunt/gulp/brunch/broccoli… the command line is very much the future. IDEs are terrific training wheels, but they’re terribly imprecise tools for serious work. It’s why Angular is doubling down on Yeoman (a CLI tool), and I’ve heard similar rumblings out of React. These are the tools for the job.

Calm down, this is a little much.