- URL routing
- Rendering views
- Read/write data from/to the backend server
Conventions are good when they offer an easy mental model. For example using the following router mapping:
1 2 3
it would match
favorites with a
App.FavoritesRoute 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:
1 2 3 4 5 6
My mental model is challenged in a few ways here:
- Route has a
modelhook - which, by conventional usage, I can’t seem to recognize as a pattern.
Ember.ArrayController, one provided by the framework. Here, a router is producing a
Controllerin disguise from the
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:
1 2 3 4 5
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.