How do we beat AngularJS in the developers mindset?

Hi folks, first post after many moons spent lurking. Bless you all for your knowledge and insights. I thought I’d throw in my $0.02CAD ($0.015USD).

When you read articles on Angular vs Ember, one of the most common pros for Ember is “Convention Over Configuration.” Cliche but true. And personally, coming from a Rails background, that’s a big win for me. I love how opinionated Ember is (or could be, rather) as a framework.

The reason I say could be, is because I feel that there are still some vagaries in the framework, which trickle down into unsure documentation. This leaves developers unsure of just what Ember’s opinion actually is on some key principles.

The latest and very clear example of this is this thread here where folks are discussing where to put their actions: controllers or routes. In an opinionated framework with a strict way of doing things, this should be answerable with one of the following one liners:

Put actions in the controller.

or

Put actions in the route.

Honestly, I can’t imagine a simpler question. Yet the responses are all over the place, with no clear answer. And the question concerns a fundamental aspect of development, not an esoteric edge case. I know folks don’t like the idea of Ember “being like Rails”, but the Rails guides IMO are an amazing work of guidance, convention, and opinion, that should be emulated in the Ember guides.

So coming back to developer mindset, once Ember’s opinion becomes clear and articulate, I think you’ll see a lot more folks agreeing with it.

Thanks for listening. Cheers.

2 Likes

I’m in London moving to contract and it’s annoying that basically everyone here is using AngularJS, even startups backed by Rails. For me the shocking part is when I ask why they are using it is that nobody can give me one clear answer, it looks like people are just choosing AngularJS because is “popular”.

As someone using Ember for the past 8 weeks I have a few thoughts:

  • I agree with @jatwood regarding the learning curve. I’m currently using Ember in my first real project here, and for the first time in years I had to email someone from the community (big thanks to @ebryn) asking for help.

  • Sometimes you don’t have a clear answer of what is the best design practice. I have plenty of questions regarding communication between controllers and multiple views where I couldn’t find a clear answer

  • Is not many projects that are one single page application, I’d like to see more things with components. I can see space where people would use Ember Components in parts of their current application

  • I’m using currently using Django and the fact that sometimes Ember is so tied to Rails you kinda scary programmers from other languages. We need more tutorials and examples that are not tied to Rails and also be aware of the fact that many Front-end developers only do lightweight server-side

  • Training – Recently, I asked to the London Meetup where I could go for a training and it looks like we don’t have anything happening here right now. This got me thinking, this city is huge

Funny you should mention that. I’ve just started looking into potentially doing our Advanced Ember.js training class in London. Would love it if you could have folks in London and anyone willing to travel to London register their interest here: Learn Ember.js: Ember.js Training, Consulting, Contracting, and Development - Erik Bryn

@ebryn that would be awesome! I have a few friends in mind that could be interested.

The best thing that could be done for Ember.js is to teach you all AngularJS :wink:

the main reason angualr is more popular despite being, in my opinion, harder to use and all together less good, is that it is being developed faster. It came out faster in a stable and mature form, packing many features and it impressed many people and since then they have released version 2.0. Meanwhile Ember only became decently usable around this winter and ember-data is still in beta. Ember doesn’t have solutions yet for some fundamental web development needs like query params and radio buttons or file uploads

Ember has strengths over angular - it’s nicer to use, more organized, better documented, more up to web standards etc. If Ember was being made faster it would catch up I think.

I have no idea where the main creators find themselves in their lives and careers, they have already done an amazing job and given us a great gift, but you would think at this time they have enough momentum to seek funding and become full-time occupied with making Ember if they wished.

2 Likes

you are quite right I think about Ember being so tied to rails. I’m trying to make a push so that Node.js devs choose Ember as a client framework and released a full stack js boilerplate and blog about it. It’s had quite positive result - 150k hits on the blog in 4 months and 170ish stars on the boiler in less than 2 weeks. The funny part is, I have found the actual Ember community to be not so receptive to it, because it’s node and not rails haha

The steep learning curves is enhanced by some of the unclear instructions of where to put given ember doc examples into my own project.

Here is one example where I have created a handlebar helper but the ember documents do not say where it should be inserted other than just inserting it into my ‘javascript’. I have +100 javascript files in my project and this statement doesn’t help me narrow down my options.

I’m putting feelers out to create some high quality videos for absolute beginners…

Please “like” if you’re interested…

When learning a new framework, it’s impossible to absorb every detail. If I can get going using patterns which I’ll understand later as the fundamentals sink in, that makes me more productive and eager to continue. When there are countless rules you need to know to get anything done, it can be daunting.

An example with ember would be the various identifier syntax rules. Whether a rule, resolver pattern, or convention, use of camel case, dashes, underscores, dot/slash separators, can be very confusing. In development mode it would be helpful if there was more detection for the expected values to guide new users, or those of us making such mistakes. Also, arguments/bindings being quotes or not wasn’t trivial to grasp and still sometimes (embarrassingly enough) gets me.

3 Likes

Yup, we need a cheatsheet!

#cheatsheetorriot

1 Like

Yo, if anyone wants me to help out with whatever documentation projects, I’ve got some time right now.

Interesting thread.

I stumbled upon it searching for “why choose EmberJS?”

I’m one of those guys Ember is trying to attract/win over.

At a surface level I’m reading articles that come back from “AngularJS vs.” searches, and there are some great summaries out there. But one high level conclusion one draws from these is that they both have a learning curve issue and generally do the same thing. The only difference is one is more popular and has better documentation.

Additionally I’ll also see what the industry is looking for by way of hiring trends. And if you use the job trends feature of simplehired.com and indeed.com, there’s a sizable advantage in favor of Angular.

Which led me to the question - if Angular has such a clear edge, there has to be a reason why some people are choosing Ember instead (especially with the “steep learning curve”), and thus I ended up here.

So being an outsider, and having read this very informative thread, what would help Ember is to market its differentiating factors. So instead of being a “competitor” to Angular, and although both can be used to solve the same problems, position Ember as being optimal for very specific scenarios.

You might to address it head on put on the home page of emberjs.com a blurb with a link that leads to a page that discusses where and why Ember is a better choice.

Thanks guys.

1 Like

This is isn’t really TDD. This is just writing unit tests for your code. The fact that its youtube title starts with TDD is laughable. Not to mention the guys demoing this video had difficulties trying to get the tests to work properly.

I’m a web app developer with software architecture background. Now I’m learning modern SPA frameworks to decide whether a migration of my job’s large semi-SPA with own JS “framework” and PHP backend ( www.ivideon.com/my ) to one of them would be feasible and would not take much effort.

Sorry for too long answer, just sharing my own experience.


I studied both Angular and Ember theory thoroughly before making any decisions. I haven’t built anything with Ember yet and I’m trying to build a mid-complex pet app in Angular for a start.


Sidenote: Choosing Angular for a start does not look to me as the result of Google marketing. If a framework or a library is well-built and well-maintained (this is likely the result of good engineering team which Google has), and I like its core concepts (which are well-described), I would use it. If a small library is built good enough to start using it, I would try it and if something goes wrong, I would try to contribute back to some extent to fix the issues. If a large framework is built or maintained not well enough, or the core concepts don’t match mine, I won’t touch it and go find something else because I can’t contribute enough to change it, and I could come to misunderstanding of concepts with the owners.


The following things push me towards Angular after examining both source codes and docs:

  • Element-based templating, element-wise updates (vs String-based + Metamorph in Ember). Both have pros and cons, the newer Virtual DOM approach of React.js and friends is worth considering but also has issues.
  • Plain old HTML, extended with custom tags and attributes (vs Handlebars curly braces interleaved with HTML in Ember). Coming from PHP, interleaving is what I’d want to avoid in the apps of the future.
  • Highly-modular app architecture, Dependency Injection (vs Global object + conventional implicit naming in Ember)
  • Ability to control a part of the page, side-by-side with existing application, using only the necessary features.
  • As a JavaScript ninja, I simply liked reading Angular source. Ember is structured well enough but despite having a monolithic core, it does repeat itself a lot from level to level when declaring the framework building blocks.

What I’ve discovered while building my first and only, yet not a todo-list, Angular app:

  • Lots of useful directives and services out-of-the-box.
  • Lots of ready-to-use installable (via bower) and injectable (via DI) modules that do one thing good.
  • Good ready-to-use integration with modern theming (Bootstrap) and CSS animation (animate.css).
  • Easy creation of app UI components via all-in-one directives (vs required Model+View+Controller+Route boilerplate in Ember)
  • Built-in animation for DOM manipulation that syncs automagically (haven’t seen anything like that anywhere before).

What I liked in Ember (from the docs and tutorials):

  • Classes for app components (that is what I have in my app for view components, models, app-wide services etc.). Angular does not forbid classes but does not encourage use of them (a developer should have good software architecture background to architect Angular app the right way).
  • Statechart router (in my job’s app I felt the need for it and started using Abyssa.js which implements similar concept as a standalone module). For my Angular app I also start feeling the need but decided to find other independent implementations that would better integrate with Angular out-of-the-box (found yaptv/StateTree and burrows/statechart with burrows/angular-router ). This is very essential component for SPA that should be evangelized more.

What I did not like most in Ember or did not understand to an end:

  • Monolithic architecture of the core Ember (I cannot take e.g. StateManager and plug it in independently)
  • Lack of app modules and dependency injection (according to the most of the docs and examples, everything should be tied to the global App object).
  • Implicit creation of components. Convention is good when dealing with architecture patterns and configuration options, but having something that is not declared but “automatically created for you” got me confused.
  • Binding requires string-based absolute paths to globally available objects’ properties (e.g. “App.currentUser”), so I cannot bind to dynamically instantiated instances. In Angular, this is likely accomplished via $watch(function () { … }).

Summary: At first sight, neither Ember nor Angular are fully prepared to make partial migration possible (migrate a part of the app, then another part and so on). Angular is perfect for quick prototyping, and the prototype can grow into a well-architectured app that can be as maintainable as an Ember app, with benefits of modular structure and simplicity at its core.

1 Like

Have to disagree here. I’m a long time PHP developer, and have used both Ember and Angular, to me, Ember feels much more like a well structured backend PHP framework than Angular does, but then that depends what PHP frameworks one is used to using.

Rails is a very convention led highly opinionated framework, much like Ember. A lot of PHP frameworks are less convention led or opinionated, much like Angular, and thus the transition for PHP developers may be that it’s easier to pick up because it is looser in terms of structure, and you can do more things “your way”, rather than “their way”. Just my 2 cents.

Spot on. Unfortunately (and I may get some flack for this) a lot of developers are completely unaware of design patterns and how to design good software. When presented with a framework like Ember that makes strong use of design patterns and conventions, many developers simply give up because it’s too much effort to learn this stuff.

My mum could go and do a code academy class tomorrow and learn how to write a simple website with some JS and call herself a developer without really knowing anything about the complexities of these things that really define the craft. There are too many developers like this who are either ignorant and just don’t know about the importance of good design of their code, or just don’t care to know (much much worse).

The difficulty that Ember faces is to educate these people in an easy to understand way without scaring them off.

Funny to come across this post, as i was just about to start a similar discussion when i saw it …

I just spent the last several days attempting to learn ember again … I had given it a try about 8 months ago and gave up after loosing almost a week in productivity due to the, quite frankly, terrible and seemingly outdated documentation.

I was immediately extremely disappointed to find that the introductory video is still the same demo from long ago. It also seems as though the documentation is still in terrible shape albeit some improvement.

MY BIGGEST COMPLAINT WHY WHY OH WHY ARE ALL THE DEMOS I FIND USING INLINE JS TEMPLATES AS OPPOSED TO DIRS/FILES???

THE FIRST THING I HEAR/READ IN EVERY SINGLE ONE OF THE DEMOS I FIND, BE IT AN EMBER STAFF MEMBER OR OTHER DEVELOPER IS THAT THEY POINT OUT THE INLINE JS TEMPLATES ARE NOT THE WAY YOU WOULD DEVELOP IN A REAL-WORLD ENV — SO WHY DO IT IN THE FIRST PLACE??? ITS COMPLICATED ENOUGH WITHOUT HAVING TO THEN MOVE ONTO DEVELOPING A STRUCTURED SET OF DIRS / FILES and then decide on how to build it out.

AND ALSO — THERE IS ABSOLUTELY NO REAL WORLD HOW-TO EXAMPLES OF HOW TO DEPLOY AN EMBER APP.

The bottom line for me is this… I did the research and what is most frustrating for me is that i do feel like Ember is the right way to go, however there is no denying that Angular is MUCH more intuitive, extraordinarily easy to grasp and thus provides developers of all levels the confidence to dive right in.

I have to say, while Ember may be pursuing a path toward having a better framework, what good is it if it is far too difficult to learn and use. At least with Angular, even if it is not future proof and creates the possibility for a developer to fall into pitfalls that will require some modification to code in the future to account for new HTML specs like Components or the like, it DOES feel like i can be more productive today, RIGHT AWAY and hence maybe a better direction to take.

PLEASE convince me otherwise??

As I speak im in the middle of following along with yet another online tutorial … 2 minutes in … im hearing the same note about how you normally wouldnt use inline js templates in this way… UGH.

I held a talk at a conference in Denmark a few months ago, where I use Grunt and templates as .hbs file. Over the course of an hour or so, I am building up a small website.

The video is on YouTube if you are interested: Ember js - An Application Framework For The Future - YouTube

THANK YOU, im going to check it out IMMEDIATELY.

I HAVE seen a few demos that use template files, however, they are all different, there is just never any consistancy … currently ive installed the ember CLI — im exploring using that as a starting point … im hopeful to grasp this… im just running out of time … and considering Angular unfortunately. We have a large, rather ambitious project coming up that lends itself toward using a framework, everyone wants Angular, ive been trying to convince them otherwise … guess we will see. Wish me luck.