No more CSS and HTML, just JS • Hacker News Board

Re: No more CSS and HTML, just JS

#31

Post by ceedan » Fri, Sep 13, 2013, 7:59 PM UTC

MarkHarmon wrote: post #25

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…

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

Re: No more CSS and HTML, just JS

#32

Post by [deleted] » Fri, Sep 13, 2013, 8:00 PM UTC

ceedan wrote: post #31

MarkHarmon wrote: post #25

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…

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

[deleted]

Re: No more CSS and HTML, just JS

#33

Post by thibpat » Fri, Sep 13, 2013, 8:00 PM UTC

Why would you remove HTML, it's the easiest way to create a UI ? Also this introduce a lot of coupling between the style, the structure and the logic.

Re: No more CSS and HTML, just JS

#34

Post by namanyayg » Fri, Sep 13, 2013, 8:00 PM UTC

CWIZO wrote: post #28

Umm ... why? (sorry, that's the most constructive I can get with this)

I was thinking the exact same thing while scrolling through the docs.

Re: No more CSS and HTML, just JS

#35

Post by gisenberg » Fri, Sep 13, 2013, 8:01 PM UTC

ceedan wrote: post #31

MarkHarmon wrote: post #25

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…

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.

Re: No more CSS and HTML, just JS

#36

Post by thibpat » Fri, Sep 13, 2013, 8:02 PM UTC

evanmoran wrote: post #14

balloot wrote: post #10

Uhhh...shouldn't the site itself be built using the framework it advertises? Because the page structure and styling is all there even with JS turned off.

The site definitely was written entirely in OJ=). What you are seeing is that OJ, since it is just JS, can be run server side as well as client side. Server side it generates HTML/CSS (so it renders with JS turned off), but client side it renders directly to the DOM for faster templating, and automatic event binding. The tool for server side static site generation is available in node npm. You can install it with `np…

This server side execution is a good idea ! I think this is an important/valuable point of your idea.

Re: No more CSS and HTML, just JS

#37

Post by tretarok » Fri, Sep 13, 2013, 8:03 PM UTC

Oh good, another abstraction around html and css. Please murder me and this project.

Re: No more CSS and HTML, just JS

#38

Post by diminish » Fri, Sep 13, 2013, 8:04 PM UTC

evanmoran wrote: post #30

mistermumble wrote: post #19

Earlier quoted context omitted.

Yes, it seems like added complexity and reduced performance for uncertain benefit. The whole point of HTML and CSS is to be declarative, non-procedural ways of specifying presentation and UX behavior. The rationale is that designers writing CSS rules is safer than developers writing Javascript code -- for those cases where the desired result can be achieved with either approach. So why turn back the clock and go back…

The goal for OJ is create reusable UI building blocks. So I agree completely that keeping sites simple and declarative is the way forward. I would argue though that if the abstraction well reasoned it doesn't matter if it is in HTML or in JS. It still simplifies things for the programmer and maintainer. Or another way to say it -- Imagine you can insert a YouTubeVideo as simply as you can insert a div. If that YouTub…

could be great if i could describe the reusable UI building blocks in a markup language, do their formatting separately with style sheet fragments and add a simple scripting language for actions and animations.

Re: No more CSS and HTML, just JS

#39

Post by vezzy-fnord » Fri, Sep 13, 2013, 8:05 PM UTC

I think I'll stick to markup.

Re: No more CSS and HTML, just JS

#40

Post by drcode » Fri, Sep 13, 2013, 8:06 PM UTC

MarkHarmon wrote: post #25

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…

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.