How do we beat AngularJS in the developers mindset?

125

I agree with your frustration. A lot of people I work with froth at the mouth when they have to do something in one of our Ember projects because it seems so complicated to them. “I can do that in three lines with Angular” is usually the response I get.

I’ve found that one of the sources of frustration for me is also one of Ember’s strengths: Ember has a lot of built in “magic”. This “just happen”.

This is excellent when you’re in full development, but when you’re learning Ember or a new feature of Ember its maddening because so much is happening behind the scenes.

On the bright side, I think the Ember-CLI project will help address a lot of this. It makes a lot of things explicit. “You want a route? Well heres a route, controller, view, and template file for you.” Just my two cents.

126

IMO Learning Angular can be very quick at beginning. But when digging into a little it’s harder.

Recently I’m working on building a mobile app using Ionic which uses Angular as it’s MVC framework. When I want to build a component (directive) and set the element’s class name, I can not find a easy way. In my knowledge I have to like this:

// star-rating with Angular
directive('starRating', function() {
  return {
    restrict: 'E',
    scope: {
      star: '='
    },
    link: function(scope, element) {
      scope.$watch('star', function(newValue, oldValue) {
        element
          .removeClass('star-' + oldValue)
          .addClass('star-' + newValue)
      })
    }
  }
})

I need to handle detailed things (remove old class and add new one) which I don’t like. But by using Ember’s component I can easily do it with:

// star-rating with Ember
export default Em.Component.extend({
  classNameBindings: ['starCls'],

  star: 1,
  starCls: function() {
    return "star-" + this.get('star')
  }.property('star')
})

I think the latter one is more readable. Just my opinion.

127

I’ve never looked seriously at Ember before. I’ve used Knockout (with jQuery) for years successfully. Recently I tried to work with Angular in a very complex web site. I regret that decision. Ran into all sorts of issues, especially because their documentation conflicts with their actual code. Too many changes too fast, and you’re getting answers for past versions.

I think using Angular will make people look to Ember lol… Especially since with Version 2 they’ll be breaking convention again.

128

I think Ember shouldn’t compete against AngularJS. Not because it can’t but because Angular is not really a framework, I feel it’s like comparing oranges and onions… Yes, right, both have a similar shape but one it’s juicy and sweet and the other will just make you cry.

In my humble opinion, Ember’s learning curve is not that steep if you already know some JS basic patterns, my company is around 30 developers from senior to junior level, and for them it has been quite straight forward to understand Ember, even for the backend developers that come to give a hand sometimes.

I think that’s the key factor of Ember, it’s just plain JavaScript, the practices you learn are applicable to vanilla JS, I’ve seen myself using Ember’s concepts to organize Angular apps. If you learn Ember you’re learning JavaScript; If you learn Angular, well, you learn Angular.

Ember is really compliant with what is coming in ES6, and many of it’s features and syntax are almost the same, so by using it, basically you’re future proof.

To get to the point, I think Angular and Ember shouldn’t compete, I see Angular useful for public websites or even mobile, where you need some utilities here and there to speed up your development, Ember would be overkill for those cases. Ember is more for really structured apps, with strong conventions and practices, a really big application made by big teams with Angular would be just a mess because there’s just too much flexibility, hence, many ways to screw it up.

So instead of compete, I think Ember just needs to focus on its target: People who wants to build applications, not websites.

129

I’ve worked with angular for 8 months, just started a new contract with ember and much prefer its conventions and love the ember-cli.

130

One of the biggest companies in the UK in London is using ember, interested in a contract?

131

Point 5 is an important one for me. Looking forward a couple years, I do think that jQuery is on it’s way out, and I don’t want to have to use it if I to use Ember.

132

In five years Ember will not be reliant on jQuery. It probably won’t be reliant on jQuery in a year, two at the most.

133

I saw recently this article, not exactly defending Ember, but arguing against Angular. Very interesting.

134

It’s not a question of which one is better, although we all know that Ember.js wins hands-down :wink:

My two pet peeves would be:

  1. Steep learning curve and limited training for more advanced subjects (e.g. beyond the basics),
  2. Unclear how to glue the RESTAdapter to other slightly unorthodox server APIs.

(Would love to volunteer to help improve overall trainings and documentation)

1 Like
135

I think using Angular will make people look to Ember lol… Especially since with Version 2 they’ll be breaking convention again.

Exactly, that’s what happened to me. It was too painful/impossible to develop multi-view apps, so looked to Ember. However, I’m experiencing many of the Angular complaints with Ember. Poor, out-of-date documentation and examples.

As far as competition is concerned, imo, it’s game over for Angular:

  • no migration path from 1.x to 2.0; no serious enterprise will adopt a new unproven framework
  • 1.x developers will be left with a bad taste in their mouths; they’ll be lost orphans and will have to re-tool

Supported/made by Google is a double-edged sword; look at the past apps and apis discontinued, and policy changes without much regard for users.

136

I was starting a new project about a month ago and I had to make a decision what to use. I decided to go with Ember, mostly due to couple of factors:

  1. Angular is being completely rewritten. The Angular team is making it sound like it’s a good thing. To me this is too big of an unknown. I expect many people in the following months choosing Ember over Angular for the same reason.
  2. Handlebars/HTMLbars templates. I really don’t want to pollute my templates with angular code.

I was starting from scratch and without any prior experience with any of the JS frameworks. I’ve built some front-end code with Knockout before, but never anything complex.

Here are some observations based on my experience:

  1. Ember-data will be great. I get it. But for me it’s an overkill. In the guides (Specifying a Route's Model - Routing - Ember Guides) you touch on using getJson to pull data, then you mention ember-data, and from that point onwards all examples use ember-data. I do not want to use Ember-data. Ember-data makes me feel like I should be using RoR on the backend and it’s not very clear how to design an app that doesn’t use it. It was only after I started digging through Discourse code, I finally understood how to use my own Ajax calls instead. I come from .NET background and this is what I’m going to be using. I don’t want to rely on a library that has been designed with RoR first mindset.

  2. Lack of clear instructions where to put what. Actions can go in routes and controllers, Model can be defined in a route but you can put additional properties in controllers. What do you put in views. It took me a while to understand what can go where and decide on one way of doing things, so I can be consistent throughout my app.

  3. Limited functionality in Handlebars templates. I would like to see some more helpers being included as standard. I ended up having to create a lot of controller properties so I can call the {{#if}} helper on Boolean property as I couldn’t get my custom conditional helper to work.

Just for clarity, I am using:

  • ASP.NET vNext
  • Ember
  • Visual Studio 2015 Preview
  • Grunt & Bower

Similar to @kgish I would be more than happy to volunteer my time to help with docs and tutorials, wherever I can actually contribute something useful.

I think I’ve also found a bug in Discourse as in the edit mode, my bullet points are in order.

137

No question, this is game over for Angular. Whatever “competition” there was, it is completely irrelevant now.

p.s. you had a weird leading space in your numbered list. That … didn’t work out for you.

138

It’s game over for me and Angular because of the re-write with 2.0. But I don’t know if it’s game over for enterprises and Angular.

I say that because I work at an enterprise company, and we just spent the last year transitioning all development to Angular. Hardly any developers have concerns about Angular 2.0 though. Most believe that the Angular team will come up with a migration plan from 1.x to 2.0 before its release, and everything will be fine.

No other developer than myself is concerned enough to look at frameworks other than Angular. And I’m afraid that mindset is common among many other enterprise companies that currently use Angular. They already made the big shift to Angular, and they don’t want to make another big shift.

And I don’t have the answer on how to change the mindset…

139

The decision will certainly become a bureaucratic one made by management folks who don’t care about the low-level details.

So if these so-called enterprise companies have to undergo a big change anyway, and they have to choose between something totally new (Ember) or something new but kind of related to a previous version (Angular), then the choice seems completely predictable though perhaps not the most logical.

Ember will have to appeal to the rest of the world, all those early adopters, starters, and other small to medium sized companies ready to make the transition and start with a clean slate.

140

But the shift to Angular 2.0 is a big shift. That’s the whole point. A shift so big, you might as well consider any change at that point…

141

I know. That’s why I’m shifting now.

It’s also going to be harder for enterprise developers to sell the idea of converting to Ember. Because to managers, converting to a whole other framework like Ember seems like a lot more work than just converting from Angular 1.x to 2.0

So it’s not only convincing Angular developers, it’s also empowering them to convince their managers for the need to jump ship off Angular.

142

Sorry that this got so long. In short: it is about the aspects that made me (a JS framework noob) decide to go with Ember, which I think might be interesting in the context of this question.

I am new to this forum (so hello world) and also quite new to Ember. I come from a backend stack for which I am still enthusiastic about. 2014 for me felt a a lot like finding some fat-client-framework in the JS world that I can imagine to build a similar level of trust in.

So I wrote little (as in between demos and live code, but far from enterprise) SPAs in Knockout, Knockback, Backbone (w/ Marionette), Dart (w/ Polymer), Angular and Ember. Their scope was usually a hand-full of routes as well as consuming and posting from/to REST-APIs.

Writing those small first apps has a lot to do with surfing the web and reading about the pros/cons. So what I often read is that Ember’s documentation wasn’t good. If this has been an issue before, I must say that I like the Guide and API section as well as the ember cli docs very much. In my opinion (and in those use cases I am learning about in my current state) they are superior to Angular’s.

On the other hand, Angular by having so many users, has many books (published and self-published) out there. E.g., I like Safari and Packt Publishing as online libraries and often look to Leanpub for what they have. There are so many publications about Angular, even whole books devoted to aspects of the framework (like directives, services). Getting a comparable amount of publications out there (including books/booklets about more specialized aspects of the framework) could help in building trust.

What pushed me as a noob towards Ember are these aspects:

1 core team solutions
2 ember cli
3 readability
4 community
5 roadmap

Core team solutions:
The most annoying fact experimenting with Angular was, that it made me – the noob – choose between a bunch of third-party components on the model layer as well as having a de-facto standard router from contrib-land. To be clear, choice is good (and Ember has alternatives form contrib as well), but having components for aspects like data, routing and more complex layouting needs directly planned and maintained by the core team seems like a must to me.

Ember CLI:
This is the biggest selling point in my opinion.

  • It makes it easy for new devs not to worry about whether their file layout follows best practices.
  • It comes with auto-configured dev server and lets you directly jump to the first line of code.
  • It has the build tools integrated.
  • It supports the POD structure (which I hope will become the default).
  • It comes with a free solution for app and environment configuration :thumbsup:.
  • It obviously has the potential to become a widely used package manager for contrib packages.
  • It delivers infrastructure for test scenarios.
  • It is obvious that its scaffolding can house larger projects.

Readability:
Not having to carry around all those arguments related to DI makes the code more readable and easier to write.

Community:
Angular is (enormously) huge, but this doesn’t mean that all the other frameworks are small. Ember (like backbone and co.) do have a very active community. Resources like this forum or SO show that you can get decent help rather quickly.

Roadmap:
Following some talks on Youtube and reading here, I notice that with HTMLBars there is a very concrete strategy to lift some of the currently weaker(?) parts like rendering speed or a more generalized approach to animation. That the people behind the framework actively address such issues (on a core level) instead of leaving it to third party and/or encouraging workarounds makes me confident that the project has a future.

Now, there are some concerns (most probably due to my lack of experience), like e.g. the file size of even a plain production build from ember cli (> 500kb?). But I guess a part of it is caused by transpiling ES6 to current-day JS(?), so this might eventually become less when delivered to ES6 browsers. For small addons to existing services plain jQuery (maybe supercharged with Backbone) will remain perfectly valid solutions.

But for a bigger web application context, because of all the reasons above (and some solely personal preferences like the framework’s interpretation of M/VT/RC :smile: ) I will go with Ember on apps that call for a big framework. And I am very curious how gaining experience will influence the initially very positive impression that I have.

3 Likes
143

One thing that I would really like to see are more concrete examples on how to do unit tests of core functionality. That’s something I really liked about the Angular documentation. Almost every API example also has an embedded test for it.

For example, I was struggling with how to test that my model was discarded if the model is unsaved when the routes deactivate method occurs. I have no clue how to unit test this and after an evening of googling and experimenting I eventually just gave up and don’t have a test for that.

4 Likes
144

I work for an enterprise company and one of out clients is asking us to select a frontend framework that they can use for a couple of their apps. They want to use it with mobile, desktop and hybrid(cordova). My companies normal suggestion is Angular. There really isnt any big reason. Its just that architects in my company see a Google logo and just go with it.

I would like to suggest Ember but I don’t see a lot of Ember adoption in the Enterprise. I may be wrong. There are a lot of good product companies using it but if you search the net there isn’t a lot of details of Ember being used in Enterprise. It would be great if people adopting Ember in enterprise would publicize it.

If you check the build with ember site, there is a lot of desktop sites but I couldn’t find many mobile sites.(I didnt check the whole list, just the first few entries)

ember-cli is awesome. But its not easy to get it to work when you’re behind a corporate proxy. ember-cli is a great point when considering ember but I couldn’t get it to work on my work computer. It would be great if some of the contributors could look into this.