How do we beat AngularJS in the developers mindset?

We will have one of the biggest ember implementations in the UK in enterprise. We found it very good for our purposes.

2 Likes

@Nikos thats great. It will really good if you good publish somewhere about ur teams experience using ember and the points that led you to decide going with it.

Take a look at this list. There are plenty of enterprise users in there. To highlight a few: Yahoo, Zendesk, and Groupon.

1 Like

AngularJS 2.0 is making a lot of people look for other frameworks, which is the reason I am exploring emberJS now. This is an opportunity for emberJS to shine but I feel this will be a missed opportunity, at least for me.

I am struggling a lot to find up to date documentation, I don’t even know if I should stay with my ember-rails gem or move to ember-cli… one thing I do know is that my editor does not understand ES6 syntax yet.

I think every section of the documentation should show working examples of code (or links to jsfiddle) and expand a lot more on the non trivial stuff. People usually don’t struggle to write hello world in a template (even though I did… :p), they’re trying to understand design patterns, how they should refactor the code when they get large controllers (are fat controllers a design pattern in emberJS??), how to debug when they get stuck, which blogs/youtube channels have the most up to date tutorials, etc.

When I google for specific questions about emberJS, I usually end up on a ‘emberJS vs angular’ blog post or a ‘why emberJS is awesome/sucks/etc’. I don’t think that s very helpful.

@alexcppns I also think that Ember.js loses the opportunity to shine right now. And I’m afraid that this is the last opportunity.

I’m coming from Angular to Ember mostly because I have to use it at my new job. I really don’t want to complain about Ember, because I think it is maybe an awesome framework. But I don’t get the “aha” moment.

I setup the project with ember-cli and everything was up and running fast. But during daily work I often found myself wondering why certain things don’t work as expected. If I then google about this problem I often find the answer that this is not the way Ember wants you to develop. I really feel like a douchebag when developing with Ember. I think the biggest problem here is that there is no comprehensive explanation of the concepts. Ember is opinionated. That’s totally ok but I want to know about this opinions and I want to understand why some of these decisions were made.

Just to compare the conceptional guide of Angular and Ember:

http://emberjs.com/guides/concepts/core-concepts/

The Ember guide is really lame here. The explanations are so shallow that I’ve got the same information as when I read about the MVC-pattern in some design patterns book. Especially an opinionated framework should outline their decisions and opinions in all details. I think this is a main pain point for people starting with Ember.

Other things which are hard for me:

  • Testing: it’s really not so prominent as it should be. This is totally different in Angular. I think there should be much more focus on testing

  • Controll-Flow: from which point I have access to which functionality. This means basically what methods are attached to the this-pointer. In Angular it is very clear where I have access to what. Ether it is injected (this is very explicit because of the constructor function) or it is on the scope inheritance (which is very similar to prototypal inheritance of JS)

  • Where to place functionality: should I place it into the initializer, beforeModel-hook, model-hook, setupController-hook or init-controller-hook? It is even more confusing with actions. Should I place actions on the view, the route or the controller?

  • How to architecture the app: should I use components, views, controllers? When to use what?

  • super turbo restrictive view: I agree that there shouldn’t be logic in the view but my feelings are that it is too restrictive. Maybe I’ll grasp the concepts once and then find myself comfortable with it. But right now it just feels painful to write computed properties all over the place.

And after all one big question remains: “Why is Ember better for large scale?” I think this is a very important question to answer. Only because it favors convention over configuration? This can not be the only argument. I think it is totally feasible to write bad code in both frameworks and I don’t see where Ember guides developers better. I even think that I can achieve the same thing in Angular with less code than in Ember. Less code means less space for bugs and less time developing. So there is more time to spend for testing and refactoring. My opinion is that testing and refactoring are the most important things for large scale apps. Also the size of the community is bigger in Angular. Angular provides a impressive testing environment. Furthermore Angular has acceptable performance even if it does dirty checking. Just after my first days of Ember I found the limitations of Ember. I wanted to display a long list of items. No chance. With Angular I never run into performance issues since almost two years now. I just don’t see why it is better for large scale. But maybe this is due to my lack of understanding the core concepts. And this brings me back to the beginning of my post. I hope to find some good explanation of the core concepts, maybe some charts and diagrams, so I can remember them better (and look them up later). I hope I’ll get the “aha”-moment very soon but right now Ember leaves me like I’m a fool.

3 Likes

I used emberjs one year.

My boss always ask me, why we use emberjs?

Because in the SOA architecture, most of the third party service provider angular SDK not ember SDK.

Ex: LoopBack or Clouddinay.

So I need coding by myself.

I think this is a very important issue for businesses.

Emberjs is best, but I am unable to refute my boss.

@speed1speed1: I really think this is a huge issue. Today the same happened to us. We are currently trying out some application performance tool and they provide deep integration into different JavaScript frameworks but EmberJS (more infos see here) is not mentioned.

It’s sad to see that the response to EmberJS is way less than to Angular. But maybe it is due to the many issues which are already addressed in this thread. Also for me it wasn’t easy (and still isn’t easy) to speed up development with EmberJS. Compared to Angular I think I get less done and need more time therefore. I hope this time invest will payback in the future.

@tschoartschi You rock!!

1 Like

It may be as simple as building some very beautiful looking/animating SPA sites with Ember and highlighting the fact they are built using Ember. I have witnessed fickle users/customers/product owners, people see something that looks impressive and they want their product to look/function that way - at the moment there are lot of impressive looking Angular applications that I feel ‘woo’ people into wanting it.

@loque Honest question: What are the “woo” impressive looking Angular apps?

From Square Cash to the Heroku Dashboard, Intercom.io and Billy’s Billing, or Let’s Make Some Great Art I can name a number of these for Ember.

But I don’t know what is touted as an Angular app today. Very curious to learn what you’ve seen.

I think the question “How do we beat AngularJS in the developers mindset?” will be a hard battle. Especially now, when the Angular team announced that version 2 will be built on Typescript. More infos here at the msdn blog. Google & Microsoft and also special thanks to Yehuda Katz! This sounds epic. I think it will be hard to “beat” Angular…

Hey guys,

I noticed your mentioning of ruxit. I’d like to elaborate on that a bit: ruxit’s deep Javascript support for Angular.js (among other frameworks) is just referencing to XHR requests. All other JS monitoring is total generic and not in any way different between the frameworks.

I’m with ruxit, that’s why I ask: does ember.js contain any dedicated XHR code? We checked this page http://emberjs.com/api/ and didn’t find anything to that respect. So, if someone of you wants to take a look at ruxit’s ember.js monitoring and can give us feedback and suggestions for improvement, we’re more than happy to implement dedicated ember.js monitoring features.

Really? Does anyone actually care that Angular is going to be built using TypeScript?

MS like this path because it takes NodeJS out of the equation and they can manage the build env etc without it. Lots of enterprise are in no shape to bring on Node and are a long long long way off from even considering it - this just keeps the MS stack shops happy - it’ll end in tears IMO

I think the real threat is React

I’m clearly missing something- isn’t React just a view layer? Does it have any mechanism for routing requests, manipulating state, managing data, etc.? I haven’t really spent any mind on it, but it seems to be just a UI builder, not an application framework. I hear a lot of talk about how it’s going to displace Angular and Ember, but wouldn’t it more likely take on the role of Bootstrap and Foundation?

If Microsoft manages to integrate Angular into their MVC workflow MS shops (which there are more than you think) will flock to the framework by the thousands. Do not underestimate how many people will be willing to default to angular simply because it has good Visual Studio(type checking, intellisense, etc…) support.

As someone in a VS shop it is HUGE plus for them.

EDIT: Quite frankly i think its a little arrogant the way these frameworks seem to push the UI language tendencies towards the server end but seem to balk at accepting some of the server side language conventions on the client end.

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

2 Likes

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 Loopback.io 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.

13 Likes

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

2 Likes