No momento, um Ember.View está limitado às tags criadas para você pelo W3C. Mas se você deseja definir suas próprias tags HTML específicas do aplicativo e implementar o comportamento delas usando JavaScript? Na verdade, você não pode fazer isso com um Ember.View .
É exatamente isso que os componentes permitem que você faça. De fato, é uma idéia tão boa que o W3C esteja atualmente trabalhando na especificação de elementos personalizados .
A implementação de componentes da Ember tenta estar o mais próximo possível da especificação de componentes da Web. Uma vez que elementos personalizados estão amplamente disponíveis em navegadores, você deve ser capaz de migrar facilmente seus componentes Ember com o padrão W3C e tê-los ser usado por outras estruturas, bem que adotaram o novo padrão.
Isso é tão importante para nós que estamos trabalhando em estreita colaboração com os órgãos de padrões para garantir que nossa implementação de componentes corresponda ao roteiro da plataforma da web.
Também é importante notar que um Ember.Component é realmente um Ember.View (uma subclasse), mas que é completamente isolado . O acesso à propriedade em seus modelos vai para o objeto de exibição e as ações também são direcionadas ao objeto de exibição . Não há acesso ao ambiente contextexterno ou externo aonde controller todas as informações contextuais são passadas , o que não é o caso de um Ember.View que realmente tem acesso ao seu controlador circundante; por exemplo, dentro de um modo de exibição, você poderia fazer algo parecido com o this.get('controller')que controlador atualmente associado à visualização.
Então, qual é a principal diferença entre uma visão e um componente?
Portanto, a principal diferença além desses componentes permite criar suas próprias tags e, em algum momento no futuro, quando os elementos personalizados estiverem disponíveis, também migrar / usar esses componentes em outras estruturas que suportam elementos personalizados, é que, em algum momento, um componente de brasa tornará uma visão um pouco obsoleta, dependendo do caso de implementação específico.
E qual seria um exemplo comum em que eu preferiria usar uma exibição sobre um componente e vice-versa?
Seguindo o exposto, isso depende claramente de seus casos de uso. Mas, como regra geral, se você precisar acessar o controlador circundante, etc., use um Ember.View , mas se quiser isolar a visualização e passar apenas as informações necessárias para torná-la independente de contexto e muito mais reutilizável, use um Ember.Component .
Espero que ajude.
Atualizar
Com a publicação do Road to Ember 2.0, agora você é incentivado a usar componentes em vez de visualizações na maioria dos casos.