Wednesday, April 30, 2014

Embular Part 6 - Two Paths Up The Same Mountain

Years ago when I was learning kung fu, my Shifu would talk about kung fu and tai chi as "two paths up the same mountain". One path was external and physical. The other path was internal and introspective. That was to say that in both kung fu and tai chi you were starting from two difference places, but you were on a journey to the same point. When you reached that point, the only logical choice was to continue down the other path.

I feel that Angular and Ember are nearing this point. And I think they're reaching it at pretty much the same time. Simply cresting the mountain isn't enough; Now it's time for both frameworks to take a trip down the other side.

It seems to me that Angular's path has been primarily driven by a desire to create a highly extensible, clean, simple, concise API, to allow developers the power and freedom to accomplish their goals. They've certainly done that. In spades. But not without some pain to those developers. With freedom comes the ability to shoot yourself in the foot and enough rope to hang yourself with.

Ember, on the other hand, chose a path of guiding developers to create software easily and safely by providing a broad set of tools, structure and rules to follow. And they have definitely succeeded. But again, not without some pain for the developers. That broad set of tools, the expected structure and all of the rules that go with them must be learned in order to master the framework, and it’s perhaps too much for some to digest.

The Angular and Ember communities are the ones pushing the web forward

All of the new features available to us in modern browsers are powerful and amazing, but it’s these two frameworks that truly enable developers to create content that leverages that power in a way that’s pushing the web forward.

It is my hope that there will be increased cooperation between these two core teams, so that they can create something more perfect than they each already have. It certainly seems possible. There are a lot of future developments in this space that both frameworks have overlapping concerns with: Web Components, Shadow DOM, ECMAScript 6 (and beyond), even the future of HTML standards.

More importantly, I hope to see more interaction between the Angular and Ember communities (meaning you, dear reader) in general. Sharing techniques and strategies across frameworks only serves to give everyone a better understanding of web development and help these two frameworks evolve.

Maybe one day they will be one framework… Maybe one day we’ll all be Embular developers.

Links to the rest of this series:

Part 1 - Comparing Ember and Angular
Part 2 - What's Great About Angular
Part 3 - What's Great About Ember
Part 4 - What Angular Could Learn From Ember
Part 5 - What Ember Could Learn From Angular
Part 6 - Two Paths Up The Same Mountain


  1. And then there's Facebook's React. I can't help wondering if frameworks like Angular and Ember aren't two mighty steeds running the wrong race.

    1. HTMLBars is basically an Ember version of React. React is just the view layer and nothing else which is fine if you don't want the full power of a framework but just want a view library.

    2. Except with React you render the whole view and let the diff engine figure out the changes

      I think that leads to a different architecture because it simplifies having to propagate and respond to events and determine subviews affected etc.. So I'm not sure its fair to just call it a view engine

  2. People claiming that framework size doesn't matter is a bit of a pet peeve for me: download size may not matter once the files are cached, but the uncompressed size still translates directly to how much code the browser needs to parse and execute on every page load, and may also negatively affect the weight of execution payloads across operations in your app.

    These costs are not as small as you might expect. The performance tests I put on the site for my framework Mithril ( ) illustrate this problem. I don't have Ember there, but if anyone more familiar with it would like to contribute (the rendering test is really simple), that would be most welcome.

    There's another independent test here ( ), which actually surprised me.

  3. At ng-conf the AngularJS team said that the will be doing a new router in the future and it would likely not be based upon the Angular UI router. So it might well be modeled upon Ember's.

    BTW, I really appreciate a sensible article written by someone without an axe to grind. I may be using AngularJS and not Ember but I'm still interested in it and what we can learn from it.

    1. "BTW, I really appreciate a sensible article written by someone without an axe to grind. I may be using AngularJS and not Ember but I'm still interested in it and what we can learn from it."

      My thoughts, exactly.

  4. Thanx a lot for your great write up.

  5. Ben, thank you for this post. Aside from being well-written and thought-out, it really highlights the pointlessness and counter-productivity of the Holy Wars which competing frameworks, languages, editors etc so often provoke (and I am as guilty as any of joining in).

  6. Great post, Ben. I work with Angular at work and play with Ember at home. I also found Ember's extend and property syntaxt to be a bit weird at first. After I used it a couple
    of times I found it to be just as easy to read. I kind of appreciate that the two frameworks don't have almost identical syntax otherwise I'd have a hard time playing with both on the same day.

    I really enjoyed the 4th paragraph. I hope it was an intentional play on words: "Ember...perhaps too much for some to digest."

  7. Not a single mention about mobile development and the deplorable performance you get by using either one. GPU for animations in JavaScript? Forget it - choppy as a sushi chef. An alternative to the scrub-and-replace templating system? Nope - paper plates and plastic sporks only. Unloading and GC'ing modules? Not a chance. Practice real DOM manipulation and JavaScript fundamentals? Shove it lamer! This seems like yet another fanboi blog post.

    1. Fanboy if which? Or do you mean a "fanboi" of frameworks in general? Because if you mean fanboy of frameworks... GUILTY! I love frameworks!

      (I feel gross typing "boi" for boy)

    2. Frameworks are like a welfare system: once you get on them, you loose the ability to function without them. Most devs "like" frameworks so much that the thought of a mobile project using pure JS with *zero* frameworks makes them have feelings of uncertainty, inadequacy and fear. They are utterly lost and have no idea how to begin a project so they push hard for the latest trendy framework (with IE9 support - which is completely unnecessary).
      So the project gets funded and 15 devs plug away at it, then during QAT, the dev leads are caught with their pants down trying to explain to business why performance sucks, memory warnings appear or the app crashes after the first few use cases. After tracking it down to framework overhead like Angular's dirty checking or Ember's view rendering, the solution is usually to *design them out* of the application and hope the app is still useful after the slaughter.
      Nevermind that innovation is constrained by the capabilities intrinsic to the framework and devs that use frameworks are more likely to suck in general. If you must use a framework (as a last resort on mobile projects), it should be the pepper on your salad, not the beef in your burger.

    3. Well, given what you're doing without a framework is essentially: Taking disparate pieces of the puzzle, either premade (like JQuery) or developed custom with vanilla JS, then piecing them together so you can develop an application in a consistent and unified structure. You're developing a custom framework for each application you make.

      If you're developing a large scale, single page application. You're going to need things like routing and the logic around that. Routing alone is a problem that I sincerely doubt even the people that wrote it originally would be able to solve well on their own "freestyle". Not to mention is a *lot* of work.

      The bonus to DIY frameworks: Maybe some "performance"... Maybe. That's all alleged, isn't it?

      The downside: You're taking the collective works of some of the best minds in the industry, all of the discoveries, optimizations, testing, and refinement... and you're throwing it out the window because you're betting that you're smarter and will write something better. Which is always possible.

      In the end, I guess we're all on welfare, because we're all slave to a framework. Either one of our own making, or one someone else made.

    4. I think you're confusing infrastructure with "framework". No, not all applications written in vanilla JS have a DIY framework. In fact, most do not. Instead, they have infrastructure that provides object coordination, integration with other tiers and communication with outside resources. It's possible that it performs a small and selective subset of work that would otherwise be provided by some kind of general framework but without golden hammer that comes free with most frameworks.

      When architected correctly, large scale, single page applications are composed of smaller, context independent sub-applications, re-usable widgets and services that are bootstrapped via a common shell that provides a limited degree of marshalling. Setting this up is remarkably simple and can be done with far less code you might think.

      Every line of code you write that depends on a framework is already legacy before it goes into production. Using vanilla JS buffers you from this because frameworks have never stood the test of time like the core language has. Besides, ES5 (and soon ES6), web components, Modules and the like will invalidate 99% of the frameworks out there which will leave a lot of devs grasping at straws.

    5. Very interesting. I think you should write a blog post about your ideas. I'd read it. I'd like to read how you do client side routing/push-state/etc, or how you avoid "frameworky" patterns like MVC. If you write the post please link it here.

    6. Echoing Justin's comments a bit: I see W3C Web Components as the technology that will allow his (i'm paraphrasing): "large scale, single page apps composed of smaller, context-independent sub-applications, re-usable widgets and services bootstrapped via a common shell....etc."

      Web Components and things like Polymer and x-tags (some call them frameworks, but they're not really; they are just tools for building web components) are exciting and promising to move the web into this domain that Justin is describing. I think app frameworks like Ember will continue to provide a lot of value in the years to come because they address higher-level issues with complex apps like routing and things. Frameworks and Web Components will co-exist nicely as the browsers evolve...

      +1 on a blog post talking about Justin's ideas.

    7. At this point it can be hard to distinguish "infrastructure" from "lightweight frameworks":

      dev1: I love frameworks!
      dev2: I hate them! Only idiots need frameworks!
      dev1: Wow. You are skilled. You write features A, B and C every time?
      dev2: No, of course not. I like to benefit from battle-tested code that's been used in thousands of implementations worldwide. That's why I use infrastructure code, duh.
      dev1: ...!

  8. Parabéns, sua explanação sobre as duas tecnologias foi imparcial. Gostei muito!

    1. Muito obrigado! (That's all the Portuguese I know)

  9. I have not used any of the JS MVC frameworks till date and want to make up my mind to start using them. How do these frameworks handle low-power mobile devices, screen-readers and what if JS is disabled on the browser?

    1. They should be fine on low-power mobile devices so long as those devices have modern browsers on them. The only thing you'd want to watch out for is anything where you had repeated calculation in some sort of a loop. Neither Angular's digest nor Ember's run loop is going to hurt a low-power mobile device on it's own. But if you did something with a lot of trancluded animation (D3 or jQuery animations) and you were doing that on a loop, you might have a bad time.

      In the event that JS is disabled, you're going to have to handle that with a noscript tag or the like. It's rare, but possible. Then again anyone with JS disabled is going to be pretty used to a horrible web browsing experience.

    2. Though I haven't any testing with this (I plan to), it might be worth checking out Jon Abrams "SynthJS", a backend frame-work that has the power to save 2 roundtrips that the server usually takes. In his test he shows that it saves 20% in performance. Though some won't care much about this, to me it is HUGE for mobile performance. It can be used with angular/ember also. Another thing worth mentioning is the Ionic Framework that's strictly built to work with angular to create advanced hybrid mobile apps that takes care of things like scrolling for example.. Again, frameworks and frameworks and more frameworks!,,, "perhaps, a LOT to digest"... Though, we can learn a lot from these ideas.

  10. I enjoyed your analysis and agree with just about everything. As someone that has been building high performance SPAs for about 5 years now both have severe performance issues and that will be their ultimate failure. Angular is not very modular, by that I cannot swap out parts that are not needed or are inefficient, like the compiler. Ember has the hard dependencies on Handlbars (a very fat templating engine) and jQuery. Both rely on a brittle routing system. Both utilize two-way binding which is rarely needed and the source of many memory leaks.
    I do like how you identified good and bad things about both. Maybe I will extend your analysis if I have some time in the next week or so.

    1. FWIW, you can definitely swap out Angular's compiler if you so chose. That's sort of the beauty of Angular's built in IOC container: myApp.provider('$compile', function() {}); ... That's going to break an *awful* lot of stuff, though... haha.

      Thus far, I haven't noticed any "brittleness" in either client-side router, however Ember's is definitely much more feature rich than the Angular offerings.

      On the modularity of routing in Angular: Version 1.2 and higher as no built-in routing, and you'd need to pull in the `ui-router` or `ngRoutes` module in order to gain that functionality. But from what I know, Angular 2.0 definitely promises to be even more "modular" as you would say.

      Both Ember and Angular have done a very good job managing memory leaks that could arise from setting up your own two way bindings. Both frameworks have teams of highly skilled developers working on both libraries have solved those problems for the average developer.


This form allows some basic HTML. It will only create links if you wrap the URL in an anchor tag (Sorry, it's the Blogger default)