3 ms·

Please do not use something like this if you're building your next project. NOTHING is wrong with using mustache or so for templating, but this is just plain wr

Please do not use something like this if you're building your next project. NOTHING is wrong with using mustache or so for templating, but this is just plain wrong. You will know how much it costs to use something like this if you have a project that you've worked on for weeks or months and need to hand it over to another developer. Or actually any other interaction with a third party like a designer or frontender that's used to just juggling around some tags for preference or layout optimisation.

_lex 13y ago
Sorry, but there will always be new tools and newer, better ways of doing things: best-practices will aways change, and people will always need to be re-educated. This is even more true in this industry than anywhere else, and I've noticed that the rate of this change has been dramatically increasing (which is why there's such framework fatigue in this thread). Do you have any other reason why we shouldn't use OJ?
- camus 13y ago
  it's neither new nor a better way of developing apps.That's the issue here. And it is certainly not "best practice".
- brownBananas 13y ago
  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.
  - _lex 13y ago
    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.
    - brownBananas 13y ago
      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.
      - _lex 13y ago
        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?
        hrjet 13y ago
        "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.

_lex 13y ago

Sorry, but there will always be new tools and newer, better ways of doing things: best-practices will aways change, and people will always need to be re-educated. This is even more true in this industry than anywhere else, and I've noticed that the rate of this change has been dramatically increasing (which is why there's such framework fatigue in this thread). Do you have any other reason why we shouldn't use OJ?

camus 13y ago
it's neither new nor a better way of developing apps.That's the issue here. And it is certainly not "best practice".
brownBananas 13y ago
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.
- _lex 13y ago
  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.
  - brownBananas 13y ago
    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.
    - _lex 13y ago
      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?
      - hrjet 13y ago
        "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.