Live data from Hacker News

No more CSS and HTML, just JS

ojjs.org

181–190 of 191 posts

Re: No more CSS and HTML, just JS

#181

Earlier quoted context omitted.

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

I agree with you that JS has more wide-spread appeal. But it just is not the right tool for the job. Obviously, I have to be clear about the job. The job is writing a web application that lets gmail look like a school project.

but contrary to what people believe you dont create such apps with a big monolitic framework , but by using a lot of little modular libs. Gmail is build on google closure lib which is exactly that.

Re: No more CSS and HTML, just JS

#183
post #179
post #164

Earlier quoted context omitted.

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

"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 a…

OJ actually supports the ability to Theme objects which makes it much simpler to create design abstractions like you're talking about. It was inspired by the Bootstrap approach for customizing the look of different elements. The basic notion is OJ creates a CSS class that you can add and remove from an object to change its look. This can be done in a separate file (or even plugin) for designers to configure separately.

Here is a JSFiddle I made to demonstrate. This isn't even in the docs yet, so I made this just for you=).

http://jsfiddle.net/evanmoran/RmM96/

Re: No more CSS and HTML, just JS

#184

Earlier quoted context omitted.

Great feedback, thank you! If you don't want a jQuery dependency then you probably don't want OJ =). As for the CSS support it is actually quite elegant. Maybe 100 lines with full support for '&:nested' selectors, and nestable '@media' query support. One thing that I've been considering is right now 40-50% of the oj.js filesize is support for the Form Elements (TextBox, ListBox, CheckBox,Button) and the "collection"…

You might look at Zepto.js for a "lightweight" jQuery if it still does what you need for OJ.

Zepto would definitely work. Just using event binding and selectors.

Re: No more CSS and HTML, just JS

#185

Earlier quoted context omitted.

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

> 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 ;)

Re: No more CSS and HTML, just JS

#186
post #90

Earlier quoted context omitted.

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…

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.

Re: No more CSS and HTML, just JS

#187
post #178
post #161

Earlier quoted context omitted.

Except CSS sucks for styling. You can't even make a "scroll to top button" disappear with CSS because it doesn't know if the document is at the top. CSS is missing a ton of things.

One could argue if that is "style" or "behaviour".

I mean I want that button to disappear when the page is already scrolled to the top. The scrolling up part I'm fine with making with JS. I just don't feel right about attaching a scroll handler to have a very unoptimized implementation of such a thing since that scroll handler will fire EVERY SINGLE SCROLL. But the browser could optimize away "is document at the top" CSS calls by knowing we scrolled down (and by definition we can't be at the top then).

Re: No more CSS and HTML, just JS

#188

Earlier quoted context omitted.

Not true. Google runs javascript code before scraping.

No, AFAIK, Google does not run Javascript code first without special accommodations. See https://developers.google.com/webmasters/ajax-crawling/ . There's a fundamental disjunction between today's search crawlers and these kind of dynamic Javascript apps that's just going to become even worse. If anything, I think libraries like OJ point out the disjunction and therefore encourage discussion of what the future should…

I'm sorry, but you are incorrect. It may not be officially supported, but they are doing it.

https://www.google.com/search?q=uiji.js

Check out the results for the 1st link (aakilfernandes.com/uiji.html) and then check the source code. You'll see that the entire body of the page is written with javascript.

Re: No more CSS and HTML, just JS

#189

Earlier quoted context omitted.

No, AFAIK, Google does not run Javascript code first without special accommodations. See https://developers.google.com/webmasters/ajax-crawling/ . There's a fundamental disjunction between today's search crawlers and these kind of dynamic Javascript apps that's just going to become even worse. If anything, I think libraries like OJ point out the disjunction and therefore encourage discussion of what the future should…

I'm sorry, but you are incorrect. It may not be officially supported, but they are doing it. https://www.google.com/search?q=uiji.js Check out the results for the 1st link (aakilfernandes.com/uiji.html) and then check the source code. You'll see that the entire body of the page is written with javascript.

I stand corrected - sort of - a bit more research shows the reality is "some dynamic/Ajax content" is indexed by Google, and not all search engines (i.e. Bing) are doing it yet.

For example, same search on Bing - http://www.bing.com/search?q=uiji.js

References: - https://twitter.com/mattcutts/status/131425949597179904 - http://www.biznology.com/2012/01/no-more-seo-worries-for-dyn...

Re: No more CSS and HTML, just JS

#190
post #181

Earlier quoted context omitted.

I agree with you that JS has more wide-spread appeal. But it just is not the right tool for the job. Obviously, I have to be clear about the job. The job is writing a web application that lets gmail look like a school project.

but contrary to what people believe you dont create such apps with a big monolitic framework , but by using a lot of little modular libs. Gmail is build on google closure lib which is exactly that.

Well, Scala is more modular than google closure lib can ever hope to be. By the way, Scala.js builds on top of google closure.
Post reply on HN