Tuesday, January 29th, 2008

You Used JavaScript to Write WHAT?

Category: Articles

<>p>

Michael Morrison, author of Head First JavaScript, has written a piece for CIO magazine titled You Used JavaScript to Write WHAT? which is part of a series of articles on when to use a particular language or platform.

It is always interesting to see what the CXO folks are reading wrt our beloved Web :)

The other side of the coin is the mentality of viewing a Web application as a program, as opposed to a page. In this scenario, the application is utterly dependent on the active functionality made possible by JavaScript, which means it’s okay to forego users who lack JavaScript support. Google has embraced this philosophy in several marquee products, two of which are extremely popular: Gmail and Google Maps. Both applications make extensive use of Ajax (JavaScript), and neither apologizes to users who can’t run them due to a lack of JavaScript. If this article had been written just a few short years ago, I might have used an e-mail application as the ridiculous example of when not to use JavaScript, instead of Halo. But Gmail has pushed through that barrier.

Even if JavaScript-powered, web-based e-mail ultimately takes hold, surely there are other stand-alone applications that will just never make sense in Web form. Two such applications that come to mind are video and photo editing. Similar to games, these are such media-intensive applications that they just can’t make sense in JavaScript, right? Yet Adobe has already released Premiere Express for online video editing and is putting the finishing touches on Photoshop Express for Web-based photo editing. What’s interesting about these applications is that they aren’t technically built in JavaScript; they’re built in ActionScript, a close cousin of JavaScript used in Adobe’s Flex development environment. But the ActionScript in these applications is compiled, so the net effect is more akin to a native application. Adobe may be foreshadowing the future of Web scripting to some degree, at least in terms of building more feature-rich applications. And in doing so, they’re forcing us to rethink just what is possible with scripting languages.

Related Content:

9 Comments »

Comments feed TrackBack URI

Funny… my Gmail has a “basic HTML” link at the bottom. I wonder which Gmail he’s using?

Comment by RichieHindle — January 29, 2008

And Google Maps works on my phone just fine with standard HTML movement arrow links.

Comment by David Carrington — January 29, 2008

“It’s okay to forego users who lack JavaScript support. Google has embraced this philosophy in… Gmail”

Good job I didn’t know about this when I used Gmail in Lynx a couple of years ago; I wouldn’t have bothered. Oddly enough it seemed to work fine. It’s almost as though Michael didn’t finish his research. I was disappointed it didn’t support Google Maps, though.

Comment by jdbartlett — January 29, 2008

Ok, I finished reading the article now, and guess what: I was right, Michael didn’t finish his research. It’s complete tosh. He summarized the whole thing in this sentence: “The problem with casually injecting Ajax (JavaScript) into traditional Web applications that don’t desperately need it is that you run the risk of making the application dependent on JavaScript.”

Yeah, it’s a crying shame no one came up with a system whereby we could casually inject Ajax into traditional web applications without negatively affecting browsers that don’t support it. We could call it “degradable Ajax” and could write entire books about it.

Comment by jdbartlett — January 29, 2008

With AIR, XAML, etc. the “web app” side of things is coming closer to the desktop, and of course more desktop components support web-like functionality. So it seems futile to say that any given app will never be a web app.

I wish the article went into some more fundamental limits, i.e. we know that network latency limits mean that loops which have to run more than a few times a second will never be possible to implement in a client-server fashion. Therefore certain highly interactive features (say dragging and dropping) have to occur in the client, whether that be javascript or C++.

In other words maybe its not about which applications will become web apps, but about which layers and aspects of apps will occur on clients and which on servers.

Comment by K9 — January 29, 2008

“If this article had been written just a few short years ago, I might have used an e-mail application as the ridiculous example of when not to use JavaScript, instead of Halo. But Gmail has pushed through that barrier. ”

People tend to forget history. In 1999 Microsoft created the XMLHttpRequest object in Internet Explorer 5 and used it for the Outlook Web Access supplied with the Microsoft Exchange Server 2000.
That was the first e-mail application taking advantage of Ajax.

Comment by Mac — January 29, 2008

It’s absurd to say that media-intensive, or any other applications ‘don’t belong’ on the web. If your users are willing to install the Flash plugin, why not? Oh! the video editing doesn’t work in Lynx… how dare they?!

Comment by Bub — January 29, 2008

Bub: You are hilarious. ;) I completely agree with you. The line has to be drawn somewhere.

Comment by mjijackson — January 29, 2008

A few orders of magnitude better than the similar article he wrote on Perl a few days ago, but still not very insightful reading.

Comment by Patrick Donelan — January 29, 2008

Leave a comment

You must be logged in to post a comment.