|
Currently, views are split into 3 places: html, css + js (for rendering updates - usually done with a template). The big difference here is saying that the view is actually all three things/ that it's made up of all three components, which is closer to the truth than other systems of thinking. Can HTML be the view without css and without js binding for events and updates? Not in a modern app! Can CSS be the view without HTML/JS? NO! Can JS alone be the view? Yes, but you'd have a lot of inline css and html - it'd be and a pain in the ass to maintain. So if you want a single, true View in your MVC, you'd need a view that has all three parts. Other frameworks like backbone try to do something similar - backbone allows you to let your view have a template, but backbone views rely on external css and often attach to dom elements that aren't even in the view's template. So what you have is a view that's only referring to/aware of a few of it's actual dependencies. That seems sloppy if you ask me. Also, if I had a TweetView that was a backbone view, and I wanted to move it to another person's system - maybe I created an awesome design and called it AwesomeTweet - other people who wanted to consume AwesomeTweet without OJ today would have to include a css file, some html (or a template) and some JS. Each presents a rich opportunity for namespace collisions, and for my bad documentation to make it difficult to import AwesomeTweet as a module. Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply. Does this explain the "why" better? |
Ah, but you are sacrificing uniformity of design there. What if I would like the style of the tweet to be consistent with the overall style of my app? And this style is managed by a separate designer not a programmer?
Modularity works fine for behaviour, because it is better to abstract and encapsulate behaviour. But modularity doesn't necessarily work great for looks and feels.