JavaScript
Article

JavaScript Isn’t Evil

By Kevin Yank

The following is republished from the Tech Times #159.

Following my Avoiding Evil JavaScript editorial last issue, I got a great deal of contradictory feedback. It’s not surprising, given the strong opinions that people tend to have about accessibility and its importance on the Web.

Nevertheless, before I show you some easy and practical ways to write better JavaScript, I’d like to clear up one common misunderstanding that I found in some of that feedback.

JavaScript itself is not evil, nor are the web sites and applications that provide a slick, enhanced user experience using JavaScript. What I call “evil” is the use of JavaScript in such a way that it needlessly prevents some users from being able to access the site or application.

It’s usually not only possible but quite practical to build your slick, JavaScript-powered user experience on a foundation of standard HTML and CSS. This foundation enables you to deliver your site’s content not only to users browsing with JavaScript disabled, but also to automated systems like search engines.

With a little extra thought, you can even make your JavaScript functionality play nicely with assistive technologies, and work well for keyboard-only users.

But things start to fall apart when Ajax enters the picture, and users begin clamoring for the desktop-like applications that it makes possible. Often, static HTML/CSS is not up to the task of providing a useful foundation for these apps, and building a non-Ajax alternative would be a completely separate project — probably one that you can’t justify the cost of developing and maintaining. In extreme cases, it’s possible that what your application does simply doesn’t translate to the page-based model of plain HTML.

The solution to this dilemma, in my mind, is to separate these types of applications from the current, page-based Web, and move them to a “Web of Applications” that’s just as universally available as the Web is now, but which is designed from the ground up with applications in mind, and solves all the issues that are currently being caused by our attempts to shoehorn desktop-like applications into a system that was designed for serving pages of information.

This “Web of Applications” could be as simple as a new URL protocol (hatp:// for HyperApplication Transfer Protocol?) or MIME type that would be recognized by browsers, and in fact a number of vendors have attempted (or are planning to attempt) exactly this:

Meanwhile, the W3C is also working on this problem through the Web Application Formats Working Group.

So far, every one of these initiatives has failed to attract widespread adoption because it required the installation of some specific piece of software in addition to a web browser (in the case of XUL, it required a specific web browser). Unless they can achieve the same ubiquity as HTML, CSS, and JavaScript, desktop-like applications masquerading as web pages will remain the more popular—and problematic—choice.

So, in the absence of a suitably ubiquitous platform for desktop-like applications, do Ajax-powered desktop-like web applications fall under the umbrella of “Evil JavaScript?” Personally I think they do, but depending on your particular situation, they might be a necessary evil.

The evolution of web technology marches on, but as developers we need to do the best we can with the technology and resources at our disposal today. The most important thing, in my books, is that you make sure you’re well informed before you make a decision that might prevent some users from accessing your site.

Free Guide:

7 Habits of Successful CTOs

"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.

  • MikeSchinkel

    I think this concept of a “Web of Applications” would be really harmful to the web. It is in many ways like the WhizBang visual features Flash offers that completely bastardizes that which makes the web work so well and be so scalable. Study the REST architecture style, which is essentially a codification of best practices on the web and you’ll find the web works best when web sites, and web applications, are architectured as a series of state transfers using a stateless protocol. This “web of applications” you speak of would require significant client side state and would by its very nature encourage developers to create highly coupled systems that would not scale.

    What’s more, these “web of applications”, like Flash, would almost certainly encapsulate and make opaque the URLs that identify state, if not eliminate them for some less universal linking mechanism. That would make it impossible for people to use URLs to link to those states, having search engines index those states, having users tag and Digg those states, and so on. In other words, this “web of applications” concept could quickly eliminate this network effect and send us in a direction opposite of all the power unleashed by the web and its RESTful architecture.

    In addition Flash, and potentially also this “web of applications” eliminates the “view source effect” which has been one of the strongest drivers for allowing people to learn how to implement things on the web.

    >> “So, in the absence of a suitably ubiquitous platform for desktop-like applications, do Ajax-powered desktop-like web applications fall under the umbrella of “Evil JavaScript?” Personally I think they do, but depending on your particular situation, they might be a necessary evil.”

    I think the real answer is both “Yes” and “No.” People who use AJAX to build “one page applications” (shudder) are at the height of evil. But those who use it for field validation (i.e. is that username been taken yet?) and other UI streamlining functionality are doing good, not evil.

    So I think it is incumbent upon people like you to educate web developers *how* to create non-evil AJAX-based web applications. And to me that means respecting the web and it’s page metaphor while incorporating functionality that still improves the user interface.

    Though it is difficult to give clear and objective guidelines, we can follow the US Supreme court’s approach when defining pornography (they “Know it when they see it!”) If the user clicks the back button and doesn’t get what he expects, the interface is evil. If the user cannot bookmarket a state that they should reasonably be able to bookmark, then again the use of AJAX is evil. For examples of both these types of evil, go no further than http://www.hostingrails.com/forums and try searching for something. While their search interface is “cool”, it creates tons of problems. The same *benefits* could have been delivered via a different implementation if they had considered all of the issues I mentioned when they were designing this page.

  • http://www.sitepoint.com/ Kevin Yank

    Mike,

    I agree with everything you’ve said, except that I believe it means the “web of applications” is a good idea, not a bad one.

    As you say, the web is not architected to support the statefulness that desktop-like applications require. So remove these applications from the Web, and let them run where they belong—on the desktop.

    The hard part is making these applications launchable on any Internet-connected desktop (and, over time, other devices) as easily as it is to walk into an Internet café and log into Gmail today.

  • MikeSchinkel

    >> I agree with everything you’ve said, except that I believe it means the “web of applications” is a good idea, not a bad one.

    Well I’m glad you agree with part of it. :-) But I still think a separate space for applictions outside for the web, but launchable by the web, is inherently a bad idea. Just like Tim Berners-Lee makes the point that there needs to be one and only one web (i.e. one DNS and one global namespace), there ideally shouldn’t be a set of apps that are not reachable by URL.

    BTW, myself (I an in the US) and a parter from the UK have been working on an open-source project whose underlying goals are to foster the creation of infrastructure for significantly improving the web. Mind you it is a lofty goal, but if we don’t reach for the stars, we’ll certainly never make it. :) Although it is a bit premature, I have actually been planning to recruit your feedback and recommendations on the project because I believe it will address many of the goals you write so passionately about. I was inspired to reply to this post in general and not because of the project, but since we’d started a dialog I’m going to use the opportunity to ask you to look at it, and ideally, sign up for the mailing list (there is almost no traffic on the list, at the moment.)

    But before I point you in the direction of the project, your first impressions will almost certainly mislead you. To understand our demo really requires you to understand our goals, which we’ve written about somewhat on the site, but we expect once deployed on websites it will look much different than our demo which is just a proof-of-Javascript-concept.

    Check it out at http://t.oolicio.us. If you have questions *please* ask them, and do so either on our mailing list or on our posts. We *need* questions so we can understand what we need to write an FAQ.

    BTW, our Toolicious logo is from a SitePoint contest. ;-)

    P.S. I sure wish your comment system thing had a preview mode…

  • momos

    Your javascripts for t.oolicio.us are not XHTML compliant yet. (document.write)

  • MikeSchinkel

    momos: Thanks. My partner wrote the Javascript, I don’t even known Javascript that well (I’m a ASP/VBScript/SQL developer learning Python at the moment…) But I would love it if you could join our mailing list and give my partner some more details on how they are not XHTML compliant, as well as any other concerns you might have.

  • AN

    I can’t say I really understand why it is that you think that you get to decide what the web should be and what it shouldn’t be.

    The reason it’s been tough for most of the other technologies you list to get traction is that the vast majority of both users and developers are okay with ajax technologies as a platform for web applications, so few people choose to use separate technologies that are less-widely supported.

    Information should be freely available for anyone to access — this is the premise behind the fight for web standards and accessibility, and it’s a good goal. Sites whose purpose is the public access of information should indeed try to make their sites as accessible as possible.

    You’ve already acknowledged that (at least some) web applications are different. But why does that mean they need to go live in the applications ghetto if the existing technologies work for application development? Because you say so?

Recommended
Sponsors
Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in JavaScript, once a week, for free.