How do we beat AngularJS in the developers mindset?

1

Hello everyone,

How are we able to win against AngularJS when it comes to winning developers over to use Ember.js in their projects? Everywhere I go, there seems to be this AngularJS bias, and its nearly impossible to get a developer to try out Ember.js instead. At least this is the situation in my country, Norway.

I mean, filling a room with 100 to 300 people at a conference seems to be no issue, but at the end of the day the developers choose AngularJS when they are starting projects.

I’m not sure why that is. It’s hard to beat that “Backed by Google” marketing that AngularJS has going for them. I also think that a lot of the developers are coming from a server-side heavy background with HTML-ish templating libraries on the server side. I think this is in favor of AngularJS, as it looks like the server-side templating libraries that we’ve had for languages like .NET and Java. And it does seem like developers within these two languages (they both have a huge amount of developers) both choose to go with AngularJS, even when the find it feature in-complete.

I’m curious how we can make improvements in this area - Getting developers to invest enough time in learning Ember.js properly; enough that they get to see the value of using it.

I’ve tried to start out a local Ember.js meetup here in Oslo, Norway, I’m organizing Ember Fest (Munich last year and Barcelona this year) and I’m writing Ember.js in Action. And while I do see traction for these, selling in Ember.js to companies is extremely hard work, and requires a significant investment (time wise) in order to get them to make the tiniest investment in return (also talking about investing their time here, not financial investment).

I do think Ember.js is moving in the right direction, but I also think we’re moving a lot slower than AngularJS is (market share wise, not technology wise).

The market might be different across the Atlantic, but wherever I go in Europe, this seems to be the case.

Any ideas from the community?

17 Likes
2

In my opinion, it comes down to 4 things.

  1. As you said, Angular.js is backed by Google. Everybody loves drinking the Google Kool-Aid, and there’s really nothing we can do about that.

  2. Angular.js is older. Factor that in with #1 and you have a ton of people using it before Ember.js even appears on the radar. And then, when it comes time for recommendations, there’s more for Angular.js because of it’s larger user base.

  3. Ember.js was in beta until recently (about 5 months now). It’s hard to use a framework for real development when it’s API is changing and it’s likely to have bugs. Plus, Ember-Data is still in beta. While Ember-Data isn’t necessary for Ember.js, everybody needs a persistence layer, and most people aren’t going to find out about ED alternatives unless they’re already using Ember.js.

  4. Ember.js was a super steep learning curve, much steeper than Angular.js. Ember.js makes it very easy to get something up and running, if your use case is normal and nothing goes wrong. The second that you need something special, or something breaks, it requires several hours of digging through documentation to figure out. (And let’s remember that 90% of developers nowadays are too lazy to search through documentation.) I would say that there’s a high number of developers that start with Ember.js and give up shortly after running into issues.

I think the only thing we can do is continue to spread the word and make Ember.js better. As client-side web applications continue to grow, people will realize that Angular.js just isn’t ready to scale as large as Ember.js yet.

4 Likes
3

One approach is to explain that they are two different tools. Angular’s creator describes it as a metaframework - a framework for creating your application’s framework. Thus, if you get two different Angular apps, their internals will look completely different.

This is not the approach Ember takes, where you buy in to the framework’s conventions. So, one could argue that once you learn the conventions, you’ll spend much less time on boilerplate writing a new Ember app than a new Angular app. This doctrine also belongs to Rails, and it’s worked out pretty well for them.

10 Likes
4

One way is to resurrect Embercasts. Remember what envycasts and railscasts did for Rails? If we keep pumping out high-quality video tutorials, and make it so that they stay ever-green, that is always up-to-speed with the framework, then we have a real competitive advantage. “Here is the canonical video tutorial for making an ember blog in 15 minutes. This tutorial will keep up with the framework so feel free to bookmark it and refer to it whenever you want to.”

The challenge is that making a video project in such a way is challenging video engineering work. Even the normal way, having a weekly content schedule, and letting old content be archived, is hard work. Embercasts was abandoned due to lack of resources and Ryan Bates often burns out on Railscasts, even with a recurring revenue stream (railscasts pro).

17 Likes
5

This is the #1 problem that Ember needs to address. The others you mentioned really don’t matter in the long run, but this really does, and will hurt more and more as time goes on.

On the other hand, there aren’t so many full-JS-app frameworks out there, so even if Ember is always “second fiddle” to Angular it will still do well. What else are you going to use for a full-JS webapp? It’s not like there are dozens of framework choices, hell, there aren’t even six choices. So ending up as a perennial also-ran alternative may not be the end of the world for Ember.

12 Likes
6

Hi Joachim,

A caveat. Personally I’m not that interested in the goal. I assume that as a contractor in a small market I’m going to have ongoing projects in both dumped in my lap at some point from some larger market where they’ve gotten in over their heads and are just looking for folk to help out and are desperate enough to hire folk remotely. But I would rather Ember get it’s due.

Angular is a breath of fresh air in the web development world at least as much as Ember and I think that though my instinct is to go with Ember if I had the choice, either would be a huge improvement over what is typically done. I don’t understand why YUI or Ext don’t ever enter in the conversation, but I’ll leave that to someone else to provide insight on. I’m just thankful for some decent options.

My initial instinct on my own personal evaluation was that I would go with Ember if I had a choice and yet I’m finding myself focusing on learning Angular first over Ember in about a 70/30 ratio of my time because of the mindshare that you are mentioning, so I thought I’d offer what thoughts I have in case it helps as I think it should be more of a 1-1 ratio.

Still, it’s just an interesting question.

I think the most likely answer is that even really smart programmers have a limited budget of time (which is their capital) to spend on learning new things and most folk when given a choice, but with no data to make that choice on, will say “who is someone that is like me, but is either smarter or better informed or both” and they will throw the dice with that person.

Either that or the desire to follow google just because they are google are the main reasons in my mind for the mindshare. I’ve seen otherwise smart folk who have government clients that use IE 8 as their DEFAULT browsers sign on to angular this past year and I was not surprised to see angular throw IE 8 under the bus this month and for them to be (potentially) screwed by the move to do so. I don’t blame the angular guys for this, what they are trying to do doesn’t work that great in old browsers. That’s just the reality of it, But if you want to sell Ember over Angular, there is a clear hook. The Angular guys are shooting for the stars and the future. They have no reason to support compatability with your client’s legacy software that may use older browsers.

I don’t know if Ember has any problems with ie8, but I haven’t seen any. I do worry about both Ember and Angular’s use of bi-directional binding which I think can be a real performance problem with underpowered phones, but I think that Embers use of getters and setter and actual attention on the issue trumps Angular’s generic objects as a good control-enabling mechanism for this very large market, but that’s something that would take more time to go in to and will not be something that developers care that much about unless they have a lot of empathy for folk who use old devices, which is seldom the market that gets you the big bucks.

I’m just talking really and I’m running out of steam here, but I’ll just say that I’m going to keep looking at them both as well as others. I think your question is a good one for discussion but the real question is “what can we do to enable ember” and I think the answer to that is that we should all see if we can help out a bit with Ember Data, and training resources.

I suppose the proper response would be more along the lines of “what do you think the community could help you with in your book to best present the framework?” A book can be a powerful thing :D.

7

Hi,

I’m personally a core contributor of Zend Framework 2, a PHP framework. The same occurs in my community and AngularJS is mostly chosen (a big PHP project, Apigility, decided to use Angular as their admin).

I think this is in favor of AngularJS, as it looks like the server-side templating libraries that we’ve had for languages like .NET and Java.

Actually, among PHP developers (at least the one on IRC for ZF) are a bit reluctant to use Ember because they feel it’s too tied to Ruby. I know it’s silly, but most complex examples are using Rails backend, Ember-Data has native integration with ActiveModelSerializer… I really feel it this way, that EmberJS community is so tied to Rails community that PHP developers prefer to go with Angular. I may be wrong, though.

However, I’m currently working on PHP with EmberJS, writing a lot of integration between Zend Framework and Ember-Data, and I plan to blog a lot in the future about integrating EmberJS within a PHP workflow, because I really love EmberJS and you guys did an amazing work on this thing!

13 Likes
8

I think you are hitting on something important.

EmberJS and AngularJS users come from server side dev background. There’s should be more guides on how to integrate ember with currently existing web frameworks.

9

I was talking about this a little bit with @ebryn the other day when he visited Apple. These were basically my exact comments to him.

Embrace and reach out to other communities besides Ruby - specifically the PHP community.

The PHP community is massive. I love Ruby but it represents a fraction of the developers out there. Some might try to pretend otherwise but the world is chock-full of PHP developers who have gotten pretty much zero love from the Ember.js project. Almost all of the tooling out there for working with Ember has been focused exclusively on Rails. (Ember rails, sprockets support, ember-gem, etc.). My PHP team has some good tools in place buts its been the effort of many, many months of manual effort and research.

Where is the out-of-the-box Symfony support? Laravel? Zend Framework? Code Igniter? These frameworks have massive communities and there aren’t any reliable examples of how to use Ember appropriately with them. Prior to EAK and grunt modules, there wasn’t a good way of integrating Ember into an app that wasn’t Rails (unless you wanted to include all your templates in a single HTML file, which is ridiculous).

Here are some concrete steps that could be taken with the PHP community, at the very least.

  • There’s an Ember gem - why isn’t there a PHP Composer manifest?
  • Better yet, get Ember into NPM. The best NPM repo for compiling Ember templates, ember-template-compiler, is manually modifying its vendor file with latest version of Ember. This is almost always out of date by several days. Grunt depends on this repo, and EAK depends on the Grunt repo. Yikes.
  • Even better yet, create subtree splits of the core Ember packages and put them individually into NPM. This way I can build tools that only depend on a slice of Ember as opposed to the entire project.
  • Build canonical examples of how to use Ember with other backend frameworks. Show them how to deliver the assets (no HBS templates in the HTML files!!!), hook up communication and authentication with their backends, and also how to create reliable deploys.

The sad truth is that the whole world isn’t going to suddenly up and decide to start using Rails and Node. If Ember wants global adoption its needs to go to them, not the other way around.

18 Likes
11

Don’t forget it took me NO TIME to get into AngularJS and to understand it :frowning:

I’m 1-2 weeks ahead with Ember and it’s still confusing, just a example here.

App.NotesShowRoute = Ember.Route.extend({
  model: function(params) {
    return this.store.find('note', params.note_id);
  }
})

App.NotesShowIndexRoute = App.NotesShowRoute

Why does this return two different objects? App.Note.Ember and DS.RecordArray.

I’ve used AngularJS, BackboneJS, and other javascript framework without any issues, even developed small applications, without asking for any help at all, but with Ember it is still confusing after 1-2 weeks, because things doesn’t work as they should, or maybe I just cannot understand it.

12

We used to call this the “learning cliff.” Of all the things for Ember to have inherited from Sproutcore…

Developers coming in to Ember from server-side development have to cope not just with learning (some new concepts, like really paying attention to state and/or treating the router as a proper statechart) but also re-conceiving architecture patterns in their mind: what a controller is for, the role of a View (it’s not just a template! it’s not even a template at all!), etc. The existing Guides are pretty cool but they don’t address these large patterns at all.

13

Embercasts isn’t dead, I plan on adding many new casts after HTMLBars is done.

10 Likes
14

Likely you have a case where params.note_id is undefined, which causes find to behave like “find all”.

15

It creates both the showRoute and showIndexRoute, and both get the note_id. So I still find it weird. :frowning:

this.resource('notes.show', {path: "/:note_id"})

This fixed the issue on showIndexRoute but still I don’t understand why the nested Route didn’t get the model from showRoute, now I just force it to do it.

controller.set('model', this.modelFor('notes.show'))
17

I think you’re expecting this proposed behavior: Core f2f proposal: unspecified this.route() models default to parent resource

1 Like
18

I think Ember is more geared towards large scale single page applications. It is easy to get started with Angular by converting a few components into client side rendered, but for a large scale project, Angular still needs a lot more support.

Two ideas for more Ember adoption,

  • Improve Component so that it could be plugged into the page without the support of application/route. The duo of “Ember Component” + “Ember Data” could help people to see the benefit easily and immediately.

  • Have a definitive answer as to the responsibility division among “route”, “view” and “controller”. I feel like there are too many layers here and it is confusing for new developers to figure out what should go into what. Component is the right direction to go. It is easy to understand because the js controller code is analogous to view controller in cocoa, to code behind in ASP.net, directive in Angular and etc…

On the other hand, I think Ember has great potential in fulfilling its mission of “building ambitious web apps” and should stick to this mission rather than trying to become a ubiquitous js framework.

6 Likes
19

I’m fairly new to Ember, and came to it after getting frustrated with Angular.

I agree with a previous commenter, that Ember suits large-scale apps more than Angular does. I first went with Angular for a SPA I’m developing because of all the reasons the OP indicated. That “backed by Google” sponsorship is powerful! And yes, I did hit the ground running with Angular, but once I’d gotten past a very basic implementation of the app I’m developing, things like $scope soon started to trip me up, and I found that the myriad ways to accomplish something were very confusing, and frustrating.

That’s when I took a look at Ember, and loved the opinionated nature of it. Furthermore, it was familiar to me coming from a Grails (Groovy+Java) background. I guess this is due to Grails’ common semantics with Rails. I’ve been using Ember since then, and while I do agree, the learning curve is steeper, knowing that my MaintenanceVehicleRoute will need a MaintenanceVehicleController and a MaintenanceVehicleView is really convenient. After all I want to focus on the business need I’m solving, not on the technology as much.

The place where I find Ember confusing is as a previous commenter hinted at - how the Route and Controller and View link to each other. Actions can be defined in a view, or a controller, or a route. I’m not sure this is helpful in the long run. The guides are great, but I find myself doing a lot of additional Googling for the edge case type of stuff. Having the Discourse app to refer to is great, although it is quite overwhelming to a newbie. It does however lend weight to the fact that Ember can be used for large-scale SPA’s. This is a good thing.

Just on the issue of preference for Rails. That may be true but as a Java/Grails developer, I’m finding Grails to be an excellent back-end for my Ember app. Grails has an Ember templates plugin, which together with the resources plugin for Grails, make a perfect means of compiling your templates and JS files into single downloads. Grails REST support also means I can create Grails controllers that extend the Grails RestfulController and all the code inherited from RestfulController is immediately available to me. I don’t have to write anything to be able to GET/PUT/POST/DELETE to my hearts content. So for any Grails developers out there, Grails works really nicely with Ember in that regard.

One caveat is that I backed off of using ember-data. As it says on the tin, it isn’t production ready yet. I also found the fact that createRecord() immediately created a record in my store quite confusing. In Grails nomenclature, when you create a domain object, it’s only “in the store” when you save it. Until then it’s kinda like any other POGO, just with some extra convenience methods tacked on for CRUD operations. That’s an anecdotal example, but that, together with it’s bleeding edge disclaimers was enough to scare me away. I’m currently finding the best experience with ember-restless.

How to make Ember better? Somehow the learning curve has to be shortened and flattened out. Clearly the Ember guys have put a lot of effort into the guides and the API, but they’re just not as complete yet. Unfortunately I can’t comment on how best to improve on that. I’ll probably have a better idea once I understand Ember more fully.

5 Likes
20

So after some thought, I’ll offer a simple answer that is probably unrealistic, and which some folk will scoff at or make fun of me for, but here it is anyway because I’m happy to stoke the fires for progress in this regard, and I KNOW that I’m right.

If someone really wants to take the prize here. Create a good visual prototying or development tool. Not a comprehensive development tool, just a good prototyping tool will be good enough for now.

In the late 90’s and early 2000’s I was a flash developer and the one thing that held flash back as a programmers tool was the timeline and embeded assets which they used for their ui components. The flash ui components were held back from an architectural standpoint from the fact that they wanted the components to be easily skinnable for graphic artists and so they used 9-slice embedded graphics instead of purely programmatic code for the imagery. That choice hampered their components but kept them going and being productive for a while.

Now Laszlo created their own ui components and object model that ran in the flash player and the language was brilliant. There isn’t anything in Ember or Angular that is all that better than Laszlo had in 2002, but their ui components had a smart but inelegant skinning mechanism and they had no visual development tool, an issue that would come up often for new devs and especially designers or interaction designers.

Today we have raphael for backwards compatability and svg for image representation, and good js libraries for extending svg in everything above ie8. There is no reason not to have a good set of svg/vml skinable programmatic components that tie to a development framework.

I just say this to throw out the challenge to anyone with some ducats and the desire to make a change… Adobe is a sluffer… They had a golden opportunity and great people who really know what they are doing when they bought macromedia and they are clearly just hampering these really talented folk.

There is a blind spot that many developers have.

And that is the understanding that ANY framework is an IDE without an interface.

The IDE is there to make learning the framework easy.

Create the IDE and the framework will thrive.

Create an ide with visual styling and it will dominate.

2 Likes
21

And I realize that I’ll probably get missunderstood here so I’ll add a few more notes.

  1. I’m not talking about representing the ast in memory ala webstorm, I’m talking aobut creating a datastructure middleman between your interface and the code generators and demarcating custom code from generating code. Let webstorm handle the ast of the javascript and focus on the framework rules in the ide, maintaining your own datastructures for your own rules.

  2. The goal of such an IDE is to identify the lists of operations at various levels of hierarchy and make them visually explicit and selectable rather than relying on knowledge and memory.

It’s a training tool for folk who are new to the thing and it doesn’t need to cover everything It just needs to demarcate generated from custom code.

  1. creating such a tool will inform the framework.
22

I don’t have one decisive argument in favor of Ember over Angular.js but have a couple of thoughts that can make a developer lean towards Ember. Take it with a pinch of salt since I have not built anything in Angular so my knowledge about it mostly comes from others’ experiences, reading about Angular and the famous cage match. So please correct me if I am wrong in the following:

  1. Ember might have a steeper learning curve but I think it pays off later.* That it because there is a very clear separation of concerns (one area where this might not be so is action handling) whereas in Angular this is less so and so bad developer practices rear their head up (putting everything on the global $scope object). Thus Ember code is more robust and maintainable (developers reading other developers’ work know where to look for a certain functionality), especially for large projects.
  2. Backed by Google sounds good but I think that having a lot of people be intimate with the code base is more of a guarantee for a project’s continued success. Now, it might be the case with Angular and I’m not sure how much that is the case with Ember exactly but I definitely see more people involved with Ember as just the core team. Opinions very welcome here. Google has pulled the plug on many services and while “this time it might be different”, “Backed by Google” is far from being a safe bet.
  3. The opinionated framework nature of Ember might actually be an advantage. I agree that this is not so when it comes to what the backend is built in or what languages are installed on the developer’s machine but it is generally a good thing when it comes to how to actually build a large-scale app. I -and I think many other- developers would much rather choose a framework where most things already have their place and role than to reinvent the wheel every time.
  4. I agree that the teaching material could still be improved (although I think Ember is the OS project with the best code comments I have seen), but I think there has been a huge improvement on this front, too, since 1.0 came out. The docs have gotten significantly better, there is now a cookbook and several screencasts. To tout my own horn, I also did a screencast series for total beginners in which I really focus on only one component (first routes, then controllers, etc.) per screencast which I think makes learning easier.

I would really like to hear other arguments in favor of Ember to use them when the topic comes up (and it does).

3 Likes