Live data from Hacker News

No more CSS and HTML, just JS

ojjs.org

91–100 of 191 posts

Re: No more CSS and HTML, just JS

#91

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

Just to clarify -- The only dependency of oj.js is jQuery. Clearly if you want to use Backbone for model binding it has an Underscore dependency and if you want to use the AceEditor plugin then you will need Ace. So don't think you need all of these files to use OJ!

Also just for those who didn't realize, this is the initial release of OJ and was written by just one dude. As people start using it and a people give feedback it is just going to get faster, smaller, and better. Let me assure you perf and filesize are big priorities, as is better Express and Node templating integration.

Re: No more CSS and HTML, just JS

#92

Earlier quoted context omitted.

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.

Sounds like the Custom Element standard that's coming soon. http://www.polymer-project.org/ makes polyfills to use it today.

Re: No more CSS and HTML, just JS

#94
post #26

This feels like it is trying to reinvent the wheel. Is there something wrong with using HTML and CSS?

This is a good question. I think when writing websites you will always need to know how HTML, CSS work. It is just part of job=). What OJ is trying to do differently is make parts of your website self contained into objects.

So think more, what if I could bundle a part of my website into ShoppingCartView, or HeaderBarWithLoginView? It doesn't remove the HTML and CSS it just simplifies how it is created because OJ Objects create themselves, and once created they modify themselves. Clearly to write these objects you will still need to use and know HTML and CSS, but this provides a different way of encapsulating things.

Re: No more CSS and HTML, just JS

#95
post #79

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 th…

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?

it's neither new nor a better way of developing apps.That's the issue here. And it is certainly not "best practice".

Re: No more CSS and HTML, just JS

#96

Earlier quoted context omitted.

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.

There's actually a lot of weirdness with certain bits of DOM events and screenreaders, with some portions updating more often than others. You'll run into situations where some updates will fire, and others won't unless your careful, and use ARIA tagging properly.

That's very strange. I wonder what the technical reason for doing it that way is.

Re: No more CSS and HTML, just JS

#97

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…

Web Components are already here and they're part of HTML5 itself. What does this do to differentiate itself? To me, at first glance, it looks like a dead project already.

Re: No more CSS and HTML, just JS

#98
post #62

This post is getting a lot of flack from people who haven't given it more than a glance. -------Benefits 1. SEO is not a problem. Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem. 2. Current code-size can be ignored in the long run. This code doesn't have to be sent to the client (since it can run on the server), could possibly b…

Agreed, this is a good summary. My first initial reaction was one of slight skepticism, but one can reason pretty easily the output can be done on the server. When you work back on logic that way, what about having your site pre-built sitting on the server with only oj.s on your dev machines? As evan mentioned re-usable components that are easily dropped in to create faster website builds. Seems like an interesting concept to me.

Re: No more CSS and HTML, just JS

#99
post #79

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 th…

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?

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.

Re: No more CSS and HTML, just JS

#100

Good idea, I am currently working on something very similar, but built on Scala/Scala.js. Javascript is just not the right language for this, just as Java (GWT) wasn't.

First off Scala is amazing -- I'm using it for API servers -- so I'm very curious how your framework turns out=).

As you might imagine I would disagree that JS is the wrong language simply because it _is_ the web. Clearly abstracting JS to other languages can be quite useful (CoffeeScript), but by making your building blocks in JS every developer, library, or framework can use them. They become universal. If OJ can add YouTubeVideos, anyone can. It would be harder to do this if it was written in another language.

Post reply on HN