Hacker News Reader

Comment by brownBananas | Hacker News Reader

I am sorry, you make a good point, but it's for "better way of doing things". Such comment is so far deep into the common sense territory that there is hardly any reason to mention it explicitly. This discussion is happening with exactly that in mind.

Other folks here have mention the separation of concerns. Is there something that you can say related to that? Loved your summary of benefits and trade-offs, but can you please address MarkHarmon's comments? Thanks.

View on HN

Separation of concerns is increased with OJ: Your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html(template) & js. This will significantly reduce complexity in larger apps.

How is that different than another framework such as Angular JS, or something like web components perhaps? Each view, or directory or component can have it's own CSS file with existing solutions too.

What we are seeing here is an attempt to solve the same problem, but by doing all the work by using JavaScript. Cool. But not impressed.

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?

"Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply."

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.

OJ actually supports the ability to Theme objects which makes it much simpler to create design abstractions like you're talking about. It was inspired by the Bootstrap approach for customizing the look of different elements. The basic notion is OJ creates a CSS class that you can add and remove from an object to change its look. This can be done in a separate file (or even plugin) for designers to configure separately.

Here is a JSFiddle I made to demonstrate. This isn't even in the docs yet, so I made this just for you=).

http://jsfiddle.net/evanmoran/RmM96/

Reply on news.ycombinator.com