Hacker News Reader

Comment by MarkHarmon | Hacker News Reader

What problem is ojjs solving and what are the trade-offs?

For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css person would have blurred lines separating their responsibilities. It is a cool project, but it seems like a step backwards to me. Maybe it's just a step sideways or a better way of doing things for a team consisting entirely of programmers.

https://en.wikipedia.org/wiki/Separation_of_concerns

View on HN

Author here=). OJ is trying to solve the View layer by creating objects that act like website building blocks. So you can insert a YouTubeVideo or a TwitterButton as easily as you add an img or a div. Check out the plugins: http://ojjs.org/plugins.html

But to your question should all CSS be in JS? I'd say no, that wouldn't make sense. Clearly site level CSS should remain in a file and can be just included in a link tag normally.

The CSS being moved into JavaScript would be just that CSS used by the objects. This is how OJ Objects have no dependencies. The CSS for the YouTubeVideo, or Tab control, or the TwitterButton is included in the objects themselves. So definitely imagine still using CSS as you do now, but pulling out only the css needed for the reusable components into OJ Objects.

This approach creates multiple sources of truth for how elements should look, and in general I would avoid it - in the same way that I avoid using the style attribute or <style> tags.

For structure (the meaning and content of each element), use HTML. For presentation (e.g. colors, fonts, transition appearance), stick to your linked stylesheet. If you need to modify behavior (e.g. what happens on a given event), do that in a Javascript include.

To be fair, so does Twitter Bootstrap, with its use of classes like "pagination-centered" - but even that's an antipattern. I tend to agree with etj's approach.

It really depends where you're coming from. For the kind of sites that prevailed maybe five years ago, you could separate HTML and CSS quite neatly and JS was a minor element used to add some effects. But these days you're starting to get web apps etc. with very rich interactivity; and once you're past a certain level of complexity it's inevitable that you'll end up modifying lots of HTML and CSS from JS. So if you reach that point then you can efficiently make JS your main (or even only) source of truth.

Ten years ago, we were all tempted to put <style> tags in the HTML "in order to have the entire website in one place." As site complexity grew, we realized we needed to start separating components that had distinct roles. If I'm changing a font site-wide, I don't want to scroll through lines of totally unrelated copy to get to my styles. I want completely separate files that only need to reference each other (via classes and ids).

I am a huge fan of AngularJS, because it's essentially following the same separation pattern. It uses references (like ng-model, ng-controller, etc.) to attach elements to associated interactive behavior, but doesn't actually interfere with the structure of the page.

Things like fonts can be defined at a high level by higher-level css tags or classes. I usually use less instead of direct css, so for me I'd just throw in an import in each view's less file to get the default styling applied, or I'd just have basic font styling done at a higher level in css so at the level closer to the actual class, I'd only need to apply tweaks as needed.

The solution is very similar to GWT, Google's ugly step child. Why ugly, because it uses Java... hiss! Boo! Yet it does make every optimization under the sun and boils it down to JS.

Using JS to insert CSS, DOM nodes, and more JS is becoming pretty standard now. ExtJS and GWT led the way seven years ago, and frameworks need only dumb it down more to gain popular acceptance. I've been on teams that made award winning sites with GWT, but you had a steep learning curve. Perhaps OJ can overcome that.

Have you ever used ExtJS? ...I have had the displeasure of developing with it at a large financial institution...it is madness...everything is a JSON object and what ends up happening is a mixing of concerns...putting logic, and layout in the same place.

ExtJS didn't lead shit...there is a reason hardly anyone uses it.

GWT I am not personally familiar with, but if it is at all like ExtJS I want to stay AWAY as much as possible.

> ExtJS didn't lead shit...there is a reason hardly anyone uses it.

One major reason is it's just so freaking large and unruly to do anything simple. It's one of the few frameworks I've used that even after moderate use, I still had to keep the docs open on one screen even during routine development. The error messages weren't very helpful, either.

I did use it for a large project over about 14 months. You do need those docs open and since Sencha's doc servers were always overwhelmed, they suggested you run your own locally ;)

Even so, the GWT creators ended up recognizing the value of presentation markup and introduced the UIBinder system (HTML markup + XML for custom widgets), which arguably made my life a whole lot easier when I was working on a moderate-sized GWT codebase. It's definitely better compared to mucking around with Swing-looking code soup.

GWT-P takes this a step further with completely isolated layers (MVP) so that you can easily make permutations of your app bound to a Tablet, Mobile, and Desktop set of Views very easily. I've been using it a year now and love it.

Why does everything have to necessarily solve something?

Just experimenting around it's pretty valid IMO.

You are right, it doesn't have to. But there are a lot of newcomers to front-end web app development (either moving from other technologies, or new to dev altogether) that might think this library is fit for all sorts of projects and businesses.

That being said, this library does try to solve a problem, it's not useless. In my opinion, it's just not the right tool.. yet.

The goal of these types of systems (react.js essentially does the same thing) is to fully abstract away the need for direct HTML/DOM manipulation.

Now it's possible that the layout of the current browser DOM represents ultimate perfection and we will never improve upon it. However, it is more likely that we will find some way to come up with a better design for the DOM in the future (i.e. new types of nodes, node attributes, member functions, or some sort of entirely new data structure) and these types of frameworks allow us to experiment with new DOM ideas. With oj.js or react.js you could write to this "new DOM" and the library will project changes back to the legacy DOM.

That level of separation exists in dream worlds. Have you ever seen a job application for an "HTML/CSS Expert"...

This isn't as uncommon as you might think.

Yes, definitely.

They are called "designers".

eh... YES

I hire them regularly.

One problem it solves: HTML templating without server code.

I think the only benefit that comes with this library is job security lol

How so?

Reply on news.ycombinator.com