I’ve been reading Ember guides recently and they do a good job of laying out Ember’s basic technical concepts. However, there is not much said about its ideology and goals it pursues. Those things have been mentioned in interviews and articles, but I’d like to ask one specific question here that’s still unclear to me.
To add an action to an element that’s injected into DOM from a template, we need to specify it within the same template using
action and that’s only way to do it. Is that right?
This is both technical and ideological question, let me elaborate on that.
I’ve been comparing the source code of different implementations of TodoMVC. I’ve looked at Spine, Backbone, Ember, and Angular; specifically, their
index.html file. So far, only Backbone and Spine keep their HTML clean of any application logic. They have a bit of logic in their templates, but it’s not that significant.
Ember, on the other hand, mixes actions and value bindings into its templates. And Angular places all kind of knowledge about application into HTML. I believe these latter examples lead to a more difficult to maintain and keep sane code base.
I’m coming from a non-webdev background, but I’ve been following its evolution and I think one can pick out these stages from the history of using JS in browsers, in chronological order:
At first, we had to add event listeners to elements in HTML using
on*properties and implement the handling functions in a .js file. This was the way to go because in JS itself you could only easily query for elements with ids.
jQuery appears with its powerful selectors allowing for easy element access in JS. No need to hard-code event handlers in HTML any more. This proves to be a very useful thing: a web designer can work with HTML and CSS to provide the visual and structural foundation of the site while a separate JS programmer would code all of the interactive behavior.
The rise of templates and MVC frameworks. We go back to step 1 by mixing behavior and logic back into HTML and making it virtually impossible to have a separate person who has no JS or templating knowledge to work side by side with a JS programmer.
This is my impression of the way webdev evolves, correct me if I’m wrong.
I like Ember, it’s very clean and code efficient (as in “energy efficient”) and it sets good conventions of keeping things separate, i.e. there is usually only one good place to put a certain kind of state in: model, controller, route, or application. But the fact that it treats HTML as its building block and at the same time intertwines it with application logic seems like a move in the direction that leads to less flexibility in the long run.