Friday, September 17th, 2010

Progressive enhancement using nothing but JavaScript?

Category: Node, Yahoo!, YUI

Progressive enhancement is still a confusing matter for a lot of people who are very excited about the capabilities of JavaScript in modern browser environments. It can feel anachronistic to write your solutions for a non-JS environment and then once more enhances in JavaScript. I grew up like that so for me it is a simple matter of doing the right thing but with today’s world of JavaScript libraries and out-of-the-box widgets it can seem a drag.

Enter Dav Glass of the YUI team. He’s been turning the concept of progressive enhancement around in his head and as a JS lover and backend code “endurer” he set out to solve this issue once and for all in a pure JavaScript way.

Here’s the issue: you cannot assume JS to be available on the client side as your visitors might be on a slow mobile connection or are paranoid enough to turn off JS or actually have it turned off for them by company policy or many other cases.

So in order to use pure JavaScript to render a solution that works for everybody the natural thing was to move the JS solution to the server side and re-use it on the client when it is possible.

If you say server-side JavaScript you end up quickly talking about Node.js and so did Dav.

Check out the following demo:

Express.js, Node and YUI3 for progressive enhancement by photo

All of what you see is driven by JavaScript – there is no server-side PHP fallback. Yet if you turn off JavaScript in your browser, you get the same experience.

The reason is that Dav uses Express.js and Node to render the HTML of the application server-side with JavaScript and YUI3. The code is available on GitHub and a video of him giving a talk about this is available soon on the YUI blog.

This is an exciting concept as it means that we can build progressively enhancing solutions using any widget library if we just think of the server-side case, too. This can mean a lot less code and easier maintenance as the only skill needed to build bullet-proof solutions is JavaScript.

The missing piece to the puzzle though is a fully fledged DOM renderer on the server side. DOMJS works but a C++ version would be much better in terms of performance and have all the features of DOM-2.

Posted by Chris Heilmann at 1:06 pm

2.5 rating from 2 votes


Comments feed TrackBack URI

What about Aptana Jaxer? It’s got native DOM manipulation, I think it’s built on top of Firefox

Comment by tutini — September 18, 2010

Is your excitement because you haven’t read about Jaxer?

Comment by dotnetCarpenter — September 19, 2010


Unfortunately, Jaxer appears to be a dead project. There are some efforts to bring a DOM implementation to Node.js but there are competing implementations, none of which are really capable of all of the things a server-side browser environment like Jaxer can do.

jsdom () claims full support for DOM1 and browser augmentation, experimental support for live parsing of scripts in parsed documents, and in the source appears to have done some work on DOM2 and DOM3, including events. It doesn’t provide anything like Jaxer’s “runat” attribute, but I’m sure that could be either hacked in or worked around by playing with the “type” attribute (but this would require more work and attention from a developer).

I think ultimately Node.js will become what Jaxer could have been—a usable server-side Javascript environment—but pining for Jaxer now is probably wasted energy.

Comment by eyelidlessness — September 20, 2010

Er, I meant to include the jsdom github link:

Comment by eyelidlessness — September 20, 2010

I’m gonna say something that’s probably not going to be very popular, but we shouldn’t be coding and designing for outdated browsers, or systems, or whatnot. JavaScript has been around for more than a decade now.

“Here’s the issue: you cannot assume JS to be available on the client side as your visitors might be on a slow mobile connection or are paranoid enough to turn off JS or actually have it turned off for them by company policy or many other cases.”

That’s actually exactly what I always assume and will keep assuming. As far as mobiles – any modern smartphone does JS, and TBH I don’t care about users browsing on Razr.
“Company policy” and “paranoid users” I guess are legitimate reasons, at least in some cases. In general though a lot of JS functionality is superficial and not necessary to get at the actual content. In those cases that it is, the users, assuming they really need said content, will either disable the JS-blocking for the site, or if they’re being blocked by their IT department, they’ll just visit the site at home.

Btw, this isn’t a knock against this particular project as such. I just hate to see smart people spend time on figuring out ways around problems that shouldn’t exist. I think we, as developers, should be more aggressive about pushing the web forward and promoting new technologies, not spending hours trying to make sure our sites work in the year 1990.

/end rant;

Comment by iliad — September 20, 2010

This is one area where I think that e4x is really needed in the V8 engine… I think that with e4x, and with a DOM renderer there is a ton that can be done with node… short of both, XML/HTML manipulation becomes very cumbersome… I feel that Jaxer is/was a bit bloated, but very cool.

Comment by tracker1 — September 21, 2010

@iliad, I find the issue is more with visually impaired users more often than those with JS disabled out of paranoid habits. If a site doesn’t work without JS, depending on what the JS does and how it does it, not having clean markup, and actions without JS make it much harder for a blind person to use your site. If you’re a large commercial site with a few million users a month, you could be talking about hundreds of thousands a month in lost sales.

Comment by tracker1 — September 21, 2010


Comment by jlizarraga — September 23, 2010

Take a look to:

Basically ItsNat is a Java web browser in server, keeps a Java DOM tree in server and client is a sophisticated terminal of server (ever in sync with server by using AJAX converted to Java DOM Events).

With some work the same site AJAX intensive (Single Page Interface) can work with JavaScript disabled.

For instance try this demo, then disable JavaScript.

A tutorial (and online demo) about this is here.

Comment by jmarranz — September 29, 2010

Leave a comment

You must be logged in to post a comment.