eat some code

Django to Ember #1

Convention over configuration

August 2016 #Ember  #Django to Ember  #Django  #Magic  #Convention over configuration 

If you know Django and want to learn Ember (or vice-versa), this guide is for you. To get started, let's see what happens when a user opens the `/contact` page in both frameworks.


Let's imagine, you want to edit the address in the /contact page of a website built by someone else (with no CMS).

If that website were built in Django, you would look at, find the corresponding URL Pattern there which indicates the path and which view is used. In the view, you'll find what template is used. You can open the template and edit it.

If that website were built in Ember, you would look at router.js, find the corresponding route which indicates the path and which route handler is used. The route name is enough to find the template.

  • In Django: /some-path => => URL Pattern => view => template
  • In Ember: /some-path => router.js => route => route handler & template

Django - "Explicit is better than implicit"

In Django, the view explicitly defines which template is used, what information is passed to it and how this information is named. For example:

# under
urlpatterns += [
    url(r'^contact', cms_views.contact_us, name="contact-us")

# under
def contact_us(request):
    return render(request, 'page/contact.html', {
        'phone_number': "+123456789"

By looking at the code, we know that the template is 'page/contact.html' and that we can show 'phone_number' in it. Also the view took an HTTP request as a parameter and returns an HTTP response via the function render. It cannot be more explicit.

Ember - "Convention over configuration"

Ember uses a different approach. In Ember, the template and the variable name passed to it are defined by convention. For example (pseudo-code below):

// under app/router.js {

// under app/routes/contact-us.js
export default Ember.Route.extend({
  model(params) {
    return "+123456789";

The template name and path depend on the route: it's going to be templates/contact-us.hbs and the telephone number is going to be passed to the template as "model".

In practice, you don't need to remember all the conventions since you can use commands to generate new routes, components, tests etc. You could also overwrite the default values but probably shouldn't !

With this approach you need less code to get things working and all projects are organised the same way. On the other hand, the code is a lot harder to follow. In our example, the "model(...)" function is magically called somewhere. You also have to keep in mind that everything is setup this way. If you face a weird bug, double check that you've respected the Ember conventions. For example, "badly" naming new routes will cause issues.


Ember is really opinionated:

  • that means less code
  • that also means some "magic" is involved
  • use the command lines to generate new routes, components, etc.
  • embrace the conventions: follow the "Ember way" to stay out of trouble
  • ask questions: Stackoverflow and Discourse