How do we beat AngularJS in the developers mindset?

I think charging $799 to learn Ember.js the official way is too much. Dial it down a little? I don’t mind paying some, but not that much I think. Hmms… $200 I think is a nice price to learn.

I’m making the Ember Sparks screencast series right now (‘EmberCasts’ was already taken) to fill part of that hole. However, the way I’m avoiding burnout is by limiting the scope to 1 ~5-minute video every week, so there’s plenty of room for others.

2 Likes

TIL how to use defineProperty

thanks!

1 Like

I have to agree on this one, I’ve been using ember for a few months now and feel pretty comfortable with it. I’ve had a couple of cracks at TDD (my workflow has been entirely BDD on the server side for about 5 years now) and I just haven’t been able to get a test to run. In part I think this is because I’m using ember-app-kit which adds an extra layer to understand. The transition to ember-cli hasn’t helped here. However, I am hopeful that once ember-cli gets going a good testing story will emerge there.

That is exactly what happend to me. I started with ember and invested a lot of time books and the very good video and landed at angular. The reason was that the abstraction of ember is very high. You are far away from html, what is ok when you are within the borders of the framework. I think angular simply has an other level of abstraction than ember.

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