Live data from Hacker News

No more CSS and HTML, just JS

ojjs.org

21–30 of 191 posts

Re: No more CSS and HTML, just JS

#21

Well, it's only 11 000 lines of js... Plus Backbone, plus jQuery, plus underscore, plus ace. Loading the source page takes about 15s on my computer... I'm not sure I would like my index.html to like this https://github.com/ojjs/ojjs.github.com/blob/master/index.ht...

When will we write a full browser in js and render to canvas?

Today if you feel like it: http://html2canvas.hertzen.com/

Re: No more CSS and HTML, just JS

#22
All benefits to having a CSS file are completely lost using this method, in addition to the aforementioned performance hits. Could be cool for creating widgets and forms on the fly, but would definitely not recommend creating an entire site, let alone a webapp of any size or scale, using this tool.

Re: No more CSS and HTML, just JS

#23
Not really sure what problem this is trying to solve. I am more enthused about the potential of Web Components, shadow-dom etc. [1] Take a look at Polymer [2]. By abstracting away the concept of the contrived set of HTML Elements we currently have we can create new 'complex' elements/components while retaining consistency with the rest of the DOM API.

[1]: http://www.w3.org/TR/2013/WD-components-intro-20130606/ [2]: http://www.polymer-project.org/

Re: No more CSS and HTML, just JS

#24

So, how well does this framework handle screen readers, like JAWS? All javascript, all the time is terrible from an accessibility standpoint.

My understanding is that screen readers read from the DOM and update their buffer regularly, so as long as you're doing your rendering via the DOM, and not by drawing to a canvas or something weird like that, it won't really matter.

Re: No more CSS and HTML, just JS

#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 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

Re: No more CSS and HTML, just JS

#27
I like the idea even though I am not a JavaScript developer per se. The examples are fun to play around with. It hides so much on the backend that I definitely would be worried about performance. Fun stuff.

Re: No more CSS and HTML, just JS

#29
The big issue I have with this approach is that you'll eventually need to do one of the following: hire a designer that can javascript (rare); hire a javascripter that can design (rare); sit and tediously convert your designer's static html and css line-by-line into javascript templates.

It's not impossible to be an expert graphic designer and web developer, but they are both extremely deep disciplines and people with the dedication, inclination, and aptitude for both are few and far between. Unicorns, etc...

This is fine for one-offs and side projects, but trying to build large project around this seems like an unnecessary extra layer of complexity (not that the current standard isn't complex, it's just relatively entrenched, for better or worse :)

Re: No more CSS and HTML, just JS

#30

Well, it's only 11 000 lines of js... Plus Backbone, plus jQuery, plus underscore, plus ace. Loading the source page takes about 15s on my computer... I'm not sure I would like my index.html to like this https://github.com/ojjs/ojjs.github.com/blob/master/index.ht...

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 YouTubeVideo component is well tested, then you are actually saving your self time and will make a more robust site.

Post reply on HN