Chris J. Lee

Dallas Drupal Developer

You are here

Cursory novice observations of ember vs. angular debate

So it's been a couple months from just learning ember.js: took a workshop, tinkering with a semi-built application, etc.

I admit i haven't used this in practice into a large scale or even a small application. So my opinion may change when i get asked to build a full fledged angular or emberjs application I've grown to like ember.js a lot more over angular.js. Here are generic viagra suppliers some reasons why so far:

  • Handlebars
  • Applications should have a URL
  • Innovation
  • The non-Google community

First, Handlebars Handlebars seems like a natural fit for me. The declarative attr-itis nature of angular seems a bit too odd for me. It is really nice to use filters in angular; but i think its better to seperate them and place them inside the actual moustache / handlebars template.

Seems like the issue with handlebars at the moment is that it's slow. Seems like the ember community, at the time of this writing, is now addressing it with the whole idea of a virtual dom using simple-dom, now known as Fast-boot; as well as changing the rendering to include the HTMLbars which got introduced into ember 1.8 beta. At this time of writing, it seems very promising but experimental. It does raise some interesting questions and a new fresh perspective on how the internet is being rendered.

Second, Applications should have a URL Design-wise and structurally, i whole-heartedly agree that SPA's and applications should use a URL; as in every state of an application should have a url. With that ember provides routing for each state of the application. When the state of the application changes it's accessible by URL: state can be described by GET URL parameters.

Third, Innovation Innovation. I'm very impressed by the speed of innovation that the ember community provides. They've tackled many interesting problems with new techniques and are often the first to adopt new better ideas into the framework: Glimmer as their new rendering engine, ES6 usage, traceur compilation, making routes in application state, data marshalling and demarshalling built in, etc.

Fourth At first, it seems nice to have your open source project backed by a large company by google. However, it seems that angular has too much authority over what the community wants. Having a multilateral corporate leadership is helpful in spurring different ideas. E.g. If Google decides to deprecate Angular it makes it very difficult to continue to do the work; not one company spearheads the development and growth of this framework. A recent example of this is the sharp departure of syntax in Angular 2.0

Fifth, tooling Tooling. The tooling seems like it is very helpful. Ember-cli seems like a great time saver. Creating routes and such make it easier with ember-cli

Downsides I've been able to see some issues with ember.js. Ember is highly invested in web components. If web components do fail; the direction of the project is entrenched in it. Additionally, i'm not a fan of broccoli. Broccoli has been in my opinion hard to wrap my head around it. i'm not a Ruby developer at all. So the idea of broccoli is esoteric and strange to me. I was looking for more of a package manager that i could just start and not worry about trees, and such.

Footprint. Footprint is another issue with ember. It is probably the larger javascript MVC framework that is currently out there. Airpair provides a good comparison. I've attached the image as the chart. Airpair recently provided a good comparison of MVC javascript frameworks. The inspiration for this of this article was based on the latter article. I thought i'd want to publish my 2 cents.

Your thoughts?

Am I totally wrong? Probably. I'm still learning more about ember.js on my free time. In which lately, i haven't had much time. I hope to post updates later in the year to provide retrospectives on this later on and document my findings. We'll see maybe another framework emerge here in the near future!

© 2017 Chris J. Lee