<< Back Home
JAVASCRIPT IS EVIL!!!: AJAX AND ATLAS Are Horrible Web Technologies. I Don't Recommend them, Ever! Why???
or "Use Style Sheets and XHTML Solutions Instead of Client-Side Scripts in Every Case Possible in your Websites!", 11/17/05
Why AJAX and JavaScripted Web Pages are So Bad for the Web?
Back in 1999 when Microsoft was battling Netscape for browser supremacy, the web development community began a period of suffering. Why? We were suffering from the fact that we had to design around two very different browsers who interpreted our html and javascript very differently. This was a real thorn in our sides because part of the excitement that Netscape had created in the mid-nineties was the "promise" of client-side scripting. I mean, if I had the chance to dress up my web pages with circus-tricks, like button rollovers, and popup windows, then man, my websites could "out-shine" my competitor's. People early on became enamored of JavaScript, as it was dubbed, by Netscape. I mean, you could send someone's browser a small piece of script and BOOM....cool visual effects would start unfolding. I think many designers latched onto this concept of
letting the user's browser and its scripting abilities determine the look-and-feel of their web pages and so began developing complex scripts in their pages to do just that. It was not long before Internet Explorer came up with their own version of client-side scripting (JScript) which did "some" of the same things, but often, did its own proprietary tricks in the browser, usually in support of some side-product Microsoft was pushing on its customers. The same generally occurred with HTML between these two companies, so that it quickly became very difficult to design cross-browser websites with all the latest tricks, and that worked in both of the major browsers and their various versions. That was the central problem with JavaScript early on and why many chose to avoid the technology as it developed. Back in 2000 as Netcsape 4 was dying and being replaced by a better Netscape and IE dominance took hold, some took the "dark side" and ran with developing more advanced JavaScripting tricks, while many who believed in the fact that designing for the now dominant IE browser was good enough for their audience requirements and simply designed around Internet Explorer only. Microsoft after 2000 also realized this fact and so began designing tools and websites around their browsers very proprietary html markup and JScript requirements and tried to sell us all on how to use JavaScripting, DHTML and other client-side tricks to make what they considered "better" web design. Sorry....it wasnt! Its now taken the Web Standards groups and the W3C to teach the open soyrce community the evil designs behind building web page dependencies on both JavaScripting, client-side technologies, and the XHTML and CSS flaws built into Internet Explorer and its doctype switching, the past 5 years. Many got spoiled by designing JUST around one or two browsers, like IE, so have failed to realize the error of their ways. Its the Web Standards groups pushing XHTML-driven CSS-based websites, free of most scripting tricks and free of table-based layouts that have freed us today from the "old ways" of table-based layouts we have seen in so many Microsoft products and tools, and the scripting still found in many products designed for Internet Explorer only.
But going back to 1999, the important thing to remember is that's where this evoltion away from Javascript started, for those smart enough to see that it wasnt going to work out so well...this client-side world. Unless we were going to live in a Communist World where everyone was forced to use the same browser, it just wasnt going to a good solution. It wasn't always going to always be a client-side, Internet Explorer world, either. When Netscape and IE started to part ways in implmentations, it really was the beginning of how web designers approached flawed technologies like JavaScript and cross-browser issues....and that was, "very carefully"! Not long after 1999, most realized despite IE's dominance, we would always have more than one type of interpretation of how web pages would be parsed, AND in the case of JavaScript, how limiting client-side scripting would be in trying to pull off some of the same functionality in both browsers. I for one forced my developers under me to always test in old Netscape 4 and today I still do, and its an important lesson to always focus on inclusion and your users, despite theri dwindling influence. (Microsoft would argue against that fact!) Despite this fact...people kept on developing solutions for scripting in web pages after 1999, but their numbers dwindled in comparison to those who learned to use the web's more reliable technology, called "HTML". The more mature development teams learned to use HTML tricks (or even Flash...a very reliable multimedia plugin for the browser) rather than JavaScript to solve most web front-end solutions, primarily because JavaScript was generally considered to be "risky" and more prone to errors. Most of the experiments I did using JavaScript for client didnt result in the cross-browser consistency needed, and it turned out over time, as more and more clients reported JavaScripted inaccessibility issues, that the time and money involved in adressing them just wasn't worth the solutions proposed. Today we find many tools that still grind out JavaScript and drop them into developers sites, often, unknowingly (ie Microsoft's Visual Studio 2003 and "autopostbacks"). Its bad and I simply go in and turn off those features and GUT them from my web projects and they work better, faster and are far less error prone. (Unfortunately, most young deveopers or guys new to ASP.NET development dont see the problem and accept the mess that falls into their websites.
I will skip over the complete history of JavaScript, Netscape,the W3C and its recommendation, and Internet Explorer and move on to the subject of the article now. But my point of showing you this little bit of history is to begin my telling you that early on, people were developing allot of the things people seem to just now in 2005 have begun to "discover" with AJAX, including folks at Google, and now with Microsoft's ATLAS technology. Nothing "new" here.....in fact, if you have some history developing websites that goes back to the 1990's, then you know EXACTLY what Im saying when I talk about the "problems" with JavaScript and client-side scripting in general. Its nothing new, allot of the stuff found in AJAX and now ATLAS....its actually just another pretty wrapper around a very old problem that people solved long ago in the nineties....a solution that involves, in most cases, using JavaScript carefully or NOT AT ALL, and finding ALTERNATIVE solutions. (Thats EXACTLY what I propose and will be as you read this article!). Its just that allot of young, unititiated kids on the web now have "discovered" the "promise" of client-side scripting without going back and reading the "problems" with this technology allot of us old-timers already solved long ago. Thats the real reason we have AJAX....the unititated in the web dev world simply have forgotten the lessons of the past!
When I say "solve", I mean most seasoned web developers know now that JavaScript is EVIL...and try and avoid all solutions that are "dependent" on that technology. The reason we do, is because of all the problems we had trying to achieve cross-browser support for thetechnology. I mean, in IE 4 and Netscape 4, we had MAJOR issues with how the Document Object Model in the browsers were interpreted. It made any type of client-side scripting very vulnerable to errors. JavaScripting, on top of that, proved to be very PICKY....I mean, you leave out one dot or semi-colon in an expression or function, and BOOOOM....your pretty web page will go bye-bye. Whats worse, clients now get a nasty error page or dialog box popup telling them in some C-coders language some object broke (which is BAD usability for public viewing...I mean, who cares about objects breaking in your page...just sell me your widgets!). Whats even worse, we had cases where one browser demographic got a beautiful web page and a whole range of lesser agents got crap!
How is any form of JavaScripting a good technology in those scenarios???
The web is about
inclusion, right???? Not exclusion...and thats what Client-side Scripting like JavaScript does.
Now, back in those days, we had spenbt ALLOT of money and time developing and cutting and pasting scripts that had all sorts of complex tricks to prevent those problems. You could eventually, by 2000, get some scripts that worked in a large range of browsers, and if they didnt, would kinda degrade gracefully, as they say, so everyone coule see your site, and the people with the newest and greatest versions of the browsers that fully supported JavaScript and all the newest tricks, could get your fancy menus and popups, etc. Ok, you say, cool, so game over on the JavaSCript issue, right???
No so fast...even though its true the the major browsers (Interent Explorer, Mozilla, Opera, and Safari) seem to have come allot closer in terms of what they support in terms of JavaScript, what you find now is alarger range of user types, and diversity of lesser browsers, that DONT support scripting. What has happened is that all the problems solved, also, hasnt made JavaScripting anymore viable as a multimedia solution for websites. What I mean is the promise that you could stick JavaScript in your pages like HTML markup, and your users would all see the same experience, has not changed or improved, especially in terms of reaching the goal that you could immulate a full multimedia interactive experience, like what
Macromedia Flash creates. In fact, JavaScript remains, it seems, despite the imporved and more reliable DOM in the major browsers, in the never-never land, or twilight forest of half-light, where you can "kinda" do cool things like send xml down, display maps, and move objects around in your web page, but then, you cant pull up interactive movies and animations, or create Windows on the browser. Some say thats where Active X and Flash come in, but I argue, whats the point of taking me "half the way"? Why has JavaScripting remained both such a pain to develop and pain to implement, and pain in the you-know-what to develop cross-browser, and still create those nasty error boxes when it fails? Why is it still so picky in terms of scripting, and why does it remain an option for so many young developers?
Reasons why NOT to use AJAX and JavaScript
Here are the facts....if you use AJAX and ATLAS, you need to know that other than a few XML objects that Microsoft and Mozilla has added to their browsers which support cool data downloads via JavaSCripting and client-side code, JavaScript is still bad, old evil JavaScript!!! It still is NOT supported by a whole host of browsers and agents and more to come. For example, most MOBILE BROWSERS DONT SUPPORT JAVASCRIPT, so your fancy scripts will flat out fail in those agents. That demographis is growing fast! JavaScript also has NOT solved the original problem...how to have your users do all kinds of "cool" things in their browsers, like button rollovers and dragable objects, and DHTML menus, without the HUGE risk of that breaking when the user has JavaScript turned off, is blocked by the security software, or is flat out not supported by their version of browser. What happens when your visitors see that ugly Client script dialog box that reports a scripting error, because one of your developers mistyped a semi-colon in your functions? Other issues...
What about when Nortons or other virus software blocks a malicious script that affects your DHTML menu? If they cant see it or navigate it, their user experience is destroyed!
What happens when a new browser come out that doenst support your scripting?
What happens when a mobile user cant see your navigation because its scripted or get your xml data because thats the ONLY way your side exchanges data?
What happens for screen-readers, Lynx or text-readers, the blind, or disabled? Can they use all your fancy scripts?
What happens when a dialup user cant down load the 500 kilobytes of extra scripts you are forcing your uisers to download just to be able to see a rollover menu change color? They may give up and leave....is it worth it?
You see, this is just a FRACTION of the problems we saw with JavaScript and STILL SEE! Am I saying NEVER use AJAX or JavaScripting! Hell no! Im saying, do what we do....use it very sparingly. I like to think of my web page markup as the flour in a large "cake", my style sheets the eggs and cream, and JavaScript as the "icing on my web cake". I mean, if I HAVE TOO...my users CAN eat cake without icing!!! But they cant eat icing without cake, can they! Yuck! So, you will see in my web pages, I will put small snippets of Javascript in my header and use it for small things like browser refreshing, or button rollovers, or an occassional trick like pulling stock data using XMLHTTPResponse, or menus, or image replacements without a server call back....but....I avoid it at ALL COSTS...and use it as EXTRA FLUFF....not the total DEPENDENCY that Google and Microsoft want to cram down your throat. Let me say this, I LOVE Google Earth as its a desktop install and app that connects to the web and gets data for you. Good design and desktop software should work like that....but not the web! I know they are sending my TONS of extra junk to my browser just to pull of that cool online maps feature....but thats because they worked very hard sniffing for all sorts of browsers, to make sure I wasnt an agent that could read their scripts necessary to may thier map feature work. Their desktop version....no problem. But the web page, its bad!
Use Style Sheets and XHTML and Flash instead of Unreliable JavaSCript and AJAX. AJAX Sucks!!!
I'll end by saying that there is a BETTER WAY to deal with browser clicks and events and menus and other features that young guys are using with JavaSCript instead now. Dont get me wrong, there are time when you HAVE to try client-side scripting. But I'm a firm believer that the level of scripting Microsoft's products and now Google's use is plain out foolish and lazy and ignorant of the history of Javascript. Sure, they are banking on the fact you all have broadband access and their latest browsers installed. But thats poor design and certainly ignorance of the power of the web as an "inclusive" vehicle. Just becuase your server logs say 90% of your visitors (and the improtant ones with deep pockets) have JavaSCripting capabilities in their browsers, and WANT that fancy DHTML menu doesnt mean its necessary! In fact, I say its not only an undue download and browser security risk (despite the sandbox) and headache to program and cross-browser problem, but its poor usability. Why?
Because it doesnt support the NEW model that XHTML promises. With XHTML and CSS style sheets you now have the ability to AVOID JavaScripting (or ECMAScript, as they call it now) and use the native markup and style to do some of the same tricks! There are NO security risk, very little cross-browser issues, and you have 1/10 the code needed to pull off the saem thing. Here is an example:
Instead of doing some complex rollover and DOM JavaScript to create, say, a box that pops up when say a link is clicked, you can simply do the same thing using the psuedo-class of an anchor tag like so:
NON-JAVASCRIPTED CONTEXT BOX (XHTML web code)
<style type="text/css" media="screen">
/*
<![CDATA[*/
.admin_help1 {
width:0;
height:0;
line-height:0;
display:none;
}
a#test:hover {
display:inline;
position:relative;
top:0;
left:0;
}
a#test:hover .admin_help1 {
display:block;
width:68px;
height:68px;
line-height:0;
background-image: url(icon_help.gif);
z-index:100;
position:absolute;
top:-50px;
left:50px;
}
/*]]>*/
</style>
<!--ADD THIS XHTML LINK OR TAG INTO YOUR PAGE. IT TRIGGERS THE "FOCUS" or "HOVER" EVENT USING STYLE SHEETS!-->
<a href="#" id="test">ROLLOVER ME!!!
<div class="admin_help1">
<!-- -->
</div>
</a>
ROLLOVER ME!!!
What this example creates is a simple link in your page. When the link is "hovered" over with the cursor, it pops up an image using simple stylesheets. Its says "JavaScript Sucks!!!" (which is the case). You can have this code display floating text in a box that sits on top of your web page, as well. This would be useful for say a menu system or rollover help function applied to text or buttons, context menu, etc. Normally it would take a huge amount of Javascript to show this in all types of browsers. Why go through hell my friend!
What's even better, the W3C.org is pushing XHTML version 2 now, that when implemented in browsers will allow any element to have the psuedo-classes applied above. Any tag can also be an image, so using style sheets, you can imagine the possibilities! DONT USE AJAX, USE XHTML AND CSS. Its the FUTURe...its better! And its more accessible in all types of browsers and users!!!
I say to all your web developers....go back and try and learn about the pitfalls of JavaScript before you choose to implement it, especially via AJAX and ATLAS, which are bad technologies and bad solutions to any web project. I say use them as icing on your cake, but try and learn to use markup, XHTML, and CSS to do some of the same things. You will hit a MUCH wider userbase of support, avoid error pages, and support all kinds of browsers old and new, across a wide spectrum of user types. I say....go see what happened onlin in the year 1999 and try and build on what older developers have discovered about Javascripting...thats its not such a great technology as you might think!
- Mitchell Stokely, USA
