The island that I live on has a year-round population of around 3,000 folks. It’s a pretty tight knit community. We have our own special online forum, looking like it’s been running since the Internet began, where Islanders will post useful information, community updates, garage sales announcements and the like. However, it’s very much a case of being in the right place at the right time. If you don’t log on to the island forum for a couple of days, you could easily miss that the local Cafe is holding a free all-day pie tasting. And that’s a total bummer.
The Ember community is still a bit like this. You have to be in the right place at the right time to receive some new wisdom about how things work. This is especially true for the shift that happened with Views and Components.
Views vs Components
When I first started getting involved with Ember on a regular basis, Views were the only option. Components weren’t even a twinkle in Tomhuda Katzdale’s eye. So, you wrote lots of Views. The thing about Views is that they have implicit access to the current context, so you can easily reference properties on your Controller. When Components came along, I thought ‘great!’ and agreed it was a fabulous way to write re-usable, self contained components in your app, but noted that Components are completely isolated from the current context – you have to pass everything in that you might need. So far, so good.
Somewhere along the way, I noticed that the community had gone HAM on using Components all the time, in almost every circumstance. To me this seemed crazy! Views have their place, Components have their place. I was curious as to how this shift had come about.
Digging up the truth
Googling, I found this StackOverflow question on the difference between Components and Views, and when to use each. One answer in particular was advocating basically forgetting about Views and that Tomhuda Katzdale had officially advocated this position:
According to a training video that was recorded on August 2013, Yehuda Kats and Tom Dale (Ember Core Team Members) told the audience to not use views unless you’re a framework developer. They’ve made lots of enhancements to Handlebars and introduced Components, so views are no longer necessary. Views are used internally to power things like and .
And yet the official Guides still had references like:
Views in Ember.js are typically only created for the following reasons:
- When you need sophisticated handling of user events
- When you want to create a re-usable component
So I decided to do some investigation. The StackOverflow user mentioned ‘video training’ – the only video training I was aware of was the official Tilde introductory course for sale at Gaslight. As it would happen, I had bought this previously and hadn’t had time to get through it fully. I did some digging.
Eventually I found the section in the Gaslight video training: 10.2 Components Q&A @ 26:15 mark
Tom Dale: There was a general question about Handlebars, and probably some of you have gone through older Ember app examples and probably seen a lot of View classes. Basically don’t use Views is my answer. Since those examples were written we’ve added a lot more features to Handlerbars [..] we’ve added Components, [..] in general I would say Views are not something that we would expect most developers to be writing… they’re more of an internal book-keeping object at this point. You should use Components.
Then at 30m:
Yehuda Katz: View is basically an internal implementation detail that is the root class of things like #if, outlets, components…you could use a View but then you’re a Framework developer. You should instead use one of the things that we have built for you that uses View and the thing that is closest to View but still has better semantics is Component.
So you see, you had to be in the right place, at the right time. I can’t find this positioning reflected anywhere in the Guides (please let me know if you can!).
Incidentally, here’s a handy table that Yehuda drew in the video:
Yehuda and Tom seemed to have given out a very vital piece of information in the training video, that’s gotten lost. This happens from time to time: I just discovered that the way I’ve been defining Fixtures in Ember Data is a lie thanks to a Ember Zone reader’s comment on the previous post, where the real definition is covered in a Github Issue.
I also think a lot of developers are favouring Components because it’s Ember’s reflection of the new hot thing – Web Components – but without fully understanding the tradeoffs involved.
Personally, I think unless the answer to ‘Am I going to re-use this elsewhere in my App’ is yes, I’ll still use a View purely to avoid the unnecessary ceremony involved in setting up everything a Component might need. I also think it’s still semantically clearer.
Here’s what I say:
- Views – use ‘em when the thing isn’t going to be re-used elsewhere, and avoid un-necessary setup ceremony.
- Components – use ‘em when the thing is truly re-useable.
Perhaps one side benefit of ‘everything is a Component’ is easier testing as the Component testing story is very good in Ember now, but I haven’t delved deep enough into this yet to be able to say for sure. That might be one reason to always use Components.