Over a million developers have joined DZone.

Unconventional Conventions

DZone's Guide to

Unconventional Conventions

· Web Dev Zone ·
Free Resource

Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.

JavaScript has been reborn, thanks to jQuery to begin this epic and wonderful march. These days, we have a huge influx of micro to macro frameworks, all providing some well curated set of features. Every now and then I try to get a glimpse of the new and hot stuff so when time comes, I can make an informed decision on what to use and why.

This post is about my recent attempt at learning AngularJS and EmberJS. Client-side MVC and/or single page apps need some core features as follows:

  1. URL routing
  2. Rendering views
  3. Read/write data from/to the backend server

Both AngularJS and EmberJS offer these and some additional features, most notably, two-way data binding, so a change in the JavaScript object reflects on the rendered view and vice versa. But, to be honest, I think they overstretched the framework N miles to the north of where it should be. Let me explain with an example:

Conventions are good when they offer an easy mental model. For example using the following router mapping:

App.Router.map(function() {

based on the names. It’s an easy enough pattern to recognize and remember. However, I find it’s too far fetched in the following example:

App.FavoritesRoute = Ember.Route.extend({
  model: function() {
    // the model is an Array of all of the posts
    return App.Post.find();

My mental model is challenged in a few ways here:

  1. Route has a model hook - which, by conventional usage, I can’t seem to recognize as a pattern.
  2. App.Post.find() entails an Ember.ArrayController, one provided by the framework. Here, a router is producing a Controller in disguise from the model hook.

I’m sure with repeated usage, I’d be able to use these conventions without much of a problem. But on a pure API design/Architecture perspective, I think it’d make more sense to remove such unconventional conventions.

To be honest, I’ve attempted the EmberJS guides for the 3rd time now, in less than a month, and I feel lost in so many conventions. I have had similar experience with learning AngularJS as well.

With AngularJS, I was first a bit skeptical about all the custom tags that you’d introduce when using AngularJS. But after giving it a go, it sort of made sense as a trade-off between less code and manageable clutters. But I got really uncomfortable with the likes of the following:

<ul class="phones">
  <li ng-repeat="phone in phones | filter:query">


While it offers a snappy filtering experience and some declarative code, it feels too far stretched again. The convention around $scope, and a few other oddities as you’ll see in this EggHead.io $scope vs scope tutorial can be quite a stress on the brain.

To conclude, I personally like both frameworks and think they offer some great features over their counterparts, but it’d make sense in a later version to pick conventions where it’s truly conventional over an imposed one with lots of foreign concepts.

Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}