Convention Over Incantation?
Conventions? Curations? Innovations?
Convention over Configuration is a "pull" – meaning that it's derived from practice. Conventions evolve and ultimately people agree on them… thus the term "convention".
Rails made use of this most profoundly when it was introduced. From Giles Bowkett:
When Rails first arrived, in many instances, it took the greatest ideas and most common use cases of Web development, streamlined them, simplified their developer interface, and repackaged them within cleaner APIs.
Rails also decided to innovate at the same time, and mixed together its conventions with its innovations. The results have been mixed (in my experience):
- The Asset Pipeline was an interesting solution to a problem that I'm not sure many people had. I spent more time trying to get the thing to work as expected – and then finally tossed it.
- I used CoffeeScript for a bit, but don't care much for it. This decreases the interest in the Asset Pipeline.
- I like RSpec. I like Factories vs. Fixtures. I tend to completely replace the entire testing experience Rails.
These aren't complaints, really. Every framework you use needs to be modified to a degree to fit how you work – but I do agree with Giles' assertion:
it is literally impossible to impose a convention on a community. It is a contradiction in terms, Orwellian doublespeak, and the human-language equivalent of a syntax error.
For all of the syntax niggling, Rails still lets me do what I want/need to do so I'm a happy camper. I also think the "conventions" it once imposed are being tweaked by innovation and becoming something else.
Giles calls it "Curation over Configuration" and I think I agree with him.
Put Your Left Foot Here, Touch Your Nose, And…
It seems that most frameworks (of any kind) are beginning to follow Rails' example by introducing some level of Convention over Configuration. This is a great timesaver, unless there are no conventions to adopt.
Which is something I've encountered with EmberJS. No, I'm not going to rant on Ember – I'm still pursuing Trek's prediction:
— Trek Glowacki (@trek) March 10, 2013
I haven't given up on Ember – even though I said as much in my last post. Well it's partly because of my last post that I can't give up – it wouldn't be fair of me would it :).
As I dive into Ember more, however, I've begun musing on "conventions" in general:
Ember.js uses naming conventions to wire up your objects without a lot of boilerplate. You will want to use the conventional names for your routes, controllers and templates.
By "convention" the team means "prescription". This is important because there is no convention when it comes to Single Page Applications in the traditional sense of the word "convention". Their naming guidelines are prescriptive – and something more.
A lot of frameworks do this kind of thing: Rails, Django, ASP.NET MVC (and I'm sure many others) expect certain files (views, for instance) to be in a particular place (which you can usually override). I like this – it promotes consistency.
Ember takes this to a different level, however. If you name things a certain way you can benefit from background code generation:
One of the ways that Ember.js helps to minimize the amount of code needed and handle things for you behind the scenes is through naming conventions. The way that you define and name your routes (and resources) impacts the naming of your controllers, models, views and templates
At what point do we call these "Incantations" instead of "Conventions"?
The Light Isn't Blinding Me Yet
Again – not here to pick on Ember. Strong naming has been around for a while (though I'm not sure I've seen it trigger code generation) and, far from condemning Ember – I applaud the team for taking a bold step.
I'll admit that it's not immediately sitting right with me, but I'm going to give it time to see how hard it will be for the incantations to work their way into daily memory. I'll keep travelling the road… until I'm blinded by the light or… get delirious from the heat.