While everyone is busy implementing AJAX on every webpage they administer, and while I do not deny the beautiful simplicity and aesthetic design of an AJAX powered page (just look at how nice Gmail is to use, with instant marking of read/unread messages; or how nice the IPB 2.1 registration page is..) everyone seems to have forgotten something about the original foundations of AJAX. What it is, how it works, why it is not necessarily the best of ideas... In short, why it is best left well enough alone.
I'm not going to chide over the usage of something that is only too clearly a 'fad' and 'destined to die out.' After all, the entire web-administration business is a tangled web of over-night changes to make your website look cool and 'in.'
AJAX stands for Asynchronous JavaScript and XML. There is nothing wrong with the first or last parts of this acronym.. The trouble lies in between.
JavaScript was supposed to die. I say it with complete faith and certainity, because JavaScript was supposed to be dead by now! Before Gmail, JavaScript was being slowly, reluctantly, but most certainly, being removed by webmasters. Script writers were trying to use newer (at any rate, faster and more reliable methods) to make do without JavaScript. JS is by nature an ugly, buggy, bulky language. I oftentimes speak my mind here, let my opinions flow, but I make it clear that it is all just an opinion. But now I am writing as an experienced webmaster, issuing a factual warning in hope that someone will heed it.
JavaScript is an ancient language. Technically that is not a problem, after all, C (and its variants) is ancient and yet still the most common and powerful language. But the thing is, desktop programming languages never went through the great wars of web languages. There never was a time when everyone was trying to pack as many useless and buggy features into every browser. C++ did not suffer the Netscape and IE wars of many long years ago. JS however, did.
In its attempt to become an all-emcompassing scripting language, capable of controling every feature of (any?) web-browser, it went from a convient way to making a website more presentable to a disease-ridden method that slowed down page loads, that made content not standards-compliant, and worst of all, that ruined the initial beautiful simplicity of web-programming.
JS by nature breaks the W3C CSS/XHML revolution. The entire W3C committee is now built upon the seperation of content from display. By contrast, JS at its heart is used to merge the two.
Most JavaScript commands never display the same across all the different browsers, and many times not even between the two most popular ones. JavaScript is responsible for most of the web-spread spyware and virus infections that are brought on by those ultra-annoying pop-up windows, it is the reason why your toolbars disappear, why your mouse freezes, why your status bar flashes rude messages at you, and why you are no longer in conttol of your PC.
Firefox is involved in the war against JS. It allows you to completely disable JS on the websites you visit. However, that may be fine and dandy for staying in control, but almost none of these AJAX-powered sites are capable of displaying correctly on a non-AJAX supporting browser. Gmail used to refuse to display except on Firefox and IE6 SP1. Even now, the display is terrible on 'standard' browsing mode with AJAX disabled. Microsoft Mail (aka Kahuna) only works on AJAX supporting browsers.
No matter what you do on your end as a client, nothing can be done without extreme help from the webmasters and big corporations. JavaScript must die.. Other languages do exist as a matter of fact. ASP.NET can accomplish much of what JS can do, but then again, JavaScript is a client-side language; meaning that no matter how hard any server-side language tries, it will be muhc harder to implement some things, and many more will be impossible.
But there is one more client-side lanuage that once upon a time had a user-base. VBScript is almost as powerful as JS, except it is a true programming language, and can be used successfully without bugs on the client side, and with minimal trouble on either end.
I'm a little confussed - how can you be critical of the fact that AJAX doesn't work on every browser while at the same time suggest VBScript - something that only works on even less browsers than AJAX - as a viable alternative to JavaScript?
Also, you do realize that AJAX can be done using VBScript, don't you? Here's an example:
Set http = createObject("microsoft.xmlhttp") http.open "GET","http://toolbarqueries.google.com/search?client=navclient-auto&ch=" & CalculateChecksum(URL) & "&iqrn=d-s&orig=0J&ie=UTF-8&oe=UTF-8&features=Rank&q=info:" & Escape(URL),false http.sendI will grant that the name AJAX may not be appropriate when VBScript is used, but then again, it isn't technically appropriate for what even gmail does, as the following quote (source) demonstrates:
Great post, really enjoyed the details yawnmoth...
I did not realize how Gmail's service worked; but at the same time I should have made myself clearer. VBScript is obviously not a universal solution (it is imuniversal? ununiversal??). I referred to it simply as an example of a less buggy scripting language. I like AJAX.... Just I dislike (quite intensely and with a burning passion) JavaScript. The fact that AJAX works on about 4 major browsers does not trouble me so much as the fact that it uses JavaScript.
As it is... Today I am planning on posting a "Part 2" for viable alternate technologies instead of JavaScript. Not so much an AJAX article, but a general article on how JS can be done without ;)
Looking foward to it! :)
I must have missed something. Are you trying to imply that you can implement a dynamic web application (not a static html content site) using nothing but markup (XHTML+CSS).
My understanding of web standards is that if you want to do anything dynamic (other than rollovers) on a web page you need to use the DOM and some sort of scripting language such as JavaScript or VBScript. By your own admition if you want to do anything cross browser vbscript is not even a consideration. All you have left from a DOM+Script perspective is JavaScript.
Another option is to use flash for a web application. I think you would find that this is more of what your looking for. The flash player is the same on all browsers as I understand it. So you get great cross browser support. But guess what. The wire up back to the server/web service will use your fav little language JavaScript.
If you decide to put all the logic on the server there will be alot of http network traffic for posting form variables and rebuilding entire web pages when only small portions of the display need to be updated. This has been proven over and over again to be VERY ineficient.
I think your mainly upset with the state of web application tech available to build cross browser "smart clients" or "thick clients".
I don't see this changing much in the near future. Cross browser will continue to be a least common denominator affair. Only in the past couple of years has XMLHTTP been supported cross browser. AJAX was born (or reborn) by XMLHTTP becoming least common denominator. Now that JavaScript and async XML communication with the server can be done in 99% of modern browsers AJAX has now become a viable consideration.
Microsoft is working to take this to the next level with tech like XAML and Atlas. XAML will be windows only clients and will be able to do rich UIs bound to web services. Atlas will be your dream because it will implement a crossbrowser library of javascript and a set of ASP.NET server controls that take advantage of that library.
It is the goal of Atlas to hide all the JavaScript from you. It could religate all the JavaScript coding to people who write Atlas server controls. This sounds like exactly what you are looking for. A cross browser API for building dynamic UIs without having to write alot of client side script.
I'll be interested to see what alternatives to AJAX can create the UI that google did for gmail with AJAX that is cross browser and does not use JavaScript. IMHO AJAX is not a fad and will continue to grow and be used in web applications.
Hey David... Did you read my post on JS Alternatives? Because I mentioned the use Flash and even Java as alternatives for providing the nice GUI of Gmail or something without the buggy/incompatible code. I have been trying my best to keep up with Atlas.. it sure does seem to be what we are all looking and praying so hard for; but at the same time, what does 'crossbrowser' mean? Technically JavaScript is already a crossbrowser implementation.. but it was badly implemented by web browser designers, badly used by website designers, and badly bloated by its authors...
I guess so long as Atlas authors quadruple check their JS side of things, and try their best to make it truly compatible it will be a much better world.. But I have now come to think (thanks to my friends at neowin) that JS needs to be either rewritten or standardized and de-bloated or replaced by a true OOP scripting language.. Especially since when you come down to it the succinctness of JavaScript and its 'universal' approach make it an excellent method of accomplishing things... More on this later (I hope :P)
Thanks for the info on Atlas.. I never knew that the JS in it was hidden from the end-user.. I never noticed it before, checking it out now :D
I think when you say:
"Technically JavaScript is already a crossbrowser implementation.. but it was badly implemented by web browser designers, badly used by website designers, and badly bloated by its authors?"
You mean that the browser itself badly implemented by web browser designers. It sure sounds like your issues are with the APIs/Libraries. The fact that you can't do document.all in mozilla for example is not a problem with javaScript.
It has been my experience that JavaScript as a programming language has been very stable and not buggy or bloated. The language itself is relatively small. In most cases (IE/Mozilla) it is not even the same developers/teams that worked on the browser and worked on JavaScript.
When DHTML came on the scene you could say that the browser wars bloated the DOM API. I would agree with that. But it hardly bloated the JavaScript language.
Did you know that you could write ASP 3.0 server side code in JavaScript? If you do this, the experience is quite different than client side code. In ASP 3.0 your most likely binding JavaScript to COM objects that you write in VB or C++. The quality of that API is up to you.
IE simply hosts an "ActiveScripting Engine" in the browser and exposes all the programmable parts of the browser to JavaScript (the DOM).You can host this scripting engine in your windows application and allow people to write add-ins/macros in any active scripting language (VBScript/JavaScript/Pearl/Python).
I think your overall point is that JavaScript has been missused in the past. I'll admit that there is plenty of WTF code out there on the web. Just because you can do something doesn't mean you should. Programming is what you make of it. Anyone can write bad code in any language. Also, anyone can write good code in any language.
The reason that I like JavaScript is that it brings together many concepts from many differnt programming models. If you like to program procedural code its great at just slinging out global variables and a ton of functions. If your an OO guy and you like to write objects and use encapsulation and polymorphism, JavaScript can do that to. If you like functional programming with lamdas and closures and such, JavaScript excells at that.
Maybe thats part of its problem too. It's difficult to get a grasp all the faces that JavaScript can have. This by no means that it is bloated. The designers managed to enable all these programming models with a small lightweight language. Just go get a syntax hilighting JS editor and notice how few words are hilighted as keywords.
The fact that the foundation of Atlas can be cast in JavaScript is a testiment to its power. Check out http://www.nikhilk.net/ for some pretty impressive info on Atlas.
Oh, and JavaScript has been standardised. It's called ECMAScript and is supported by both mozilla and IE. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
In summary, I think you are venting alot of your frustration on JavaScript instead of web browsers. All the problems and issues you have are with incomplete implementations of HTML/XHTML/CSS and DOM not JavaScript. Writing client side browser code is a pain in the rear but not because of JavaScript. JavaScript is typically the tool that you use to overcome those frustrations when you have to make something work.
I think you are badly mistaken the DOM and JavaScript the language. The problems you seem to be trying to convey all seem to be pointing towards the difference in browser DOMs. It's the implementation of JavaScript code that handles manipulation of these different DOMs that you want to say is buggy/incompatible code.
Blame the DOMs, not the language!
Thanks for helping me out guys... I definitely understand your points much more clearly now ;) I guess the DOM is the guilty party afterall... But buggy code should not compile in the first place, and IMO it is the "language's duty" to ensure the availability of proper APIs and plugins, at least for the major languages... Thanks for all the help David.. Those links are invaluable... especially the PDF file, it seems to be exactly what I am looking for!
"But buggy code should not compile in the first place"
Ahh, now you are hitting on something. This is actually a subject of much debate in programming language circles. Currently there is alot of debate over static types vs dynamic types.
If you really want to geek out over programming languages checkout http://lambda-the-ultimate.org Most of the time the discussions there just go right over the top of my head. But sometimes there are some real gems. Like this one: http://lambda-the-ultimate.org/node/view/100#comment-1194 scroll down to Johnny Come Lately's post. He does a great job of pointing out the relitive merits of compiled vs script languages. I especially like the cresent wrench analogy.
Also another great resource is http://www.testdriven.com/ Test driven development (TDD) can be used with both scripting and compiled languages. In script languages it can geatly reduce bugs. It is worth noting that MS has stated that they are using TDD on all the JavaScript code they are writing for Atlas.
I'm still trying to adapt to TDD as a methodolgy for developing code. It takes concious effort. But I'm getting better.
labda the ultimate is Nice!!! thanks!
TDD seems like a good idea, but I forsee a very long road trying to implement it for the masses :(
thanks for the links (again :D)
stupidist article I read in a long time.
Microsoft is supporting javascript and and generates it through ASP.net as the code generator.
Javascript is growing to be the universal language of the future because of AJAX and the MS version of AJAX called Atlas
This is hilarious. Then again, this is what blogging is all about: unknowledgeable windbags spewing misinformation for consumption by other unknowledgeable windbags.
Firefox is involved in the war against JS? Do you realize that most of Firefox's user interface is WRITTEN in JavaScript, and the entire Mozilla XUL project has JavaScript at its heart?
The language isn't "buggy." First of all, a language can't even BE buggy. The interpreter, compiler, runtime environment, or programs written in the language can be buggy, but it doesn't even make sense to describe the language itself as buggy.
It'd be nice if you didn't label yourself a "computer guru." The smartest guys out there don't call themselves "gurus." But hey, I guess it's a pretty good sign of whether you really know what you're talking about.
and more importantly, think!
I can't believe that there are still people who advocate VBScript, and over a perfectly well and nice language called JavaScript!
(Correct me if I'm wrong, but) I think all the problems you mention are in the implementations of the language, not in the language itself. Not even the in whole implementation, only in its relation to the DOM.
You can think whatever works for you, but it's bad programming that gives a language a bad reputation (except, Javascript doesn't have a bad reputation.) That is, it's "guru" web administrators like you that are responsible for writing correct code when given a sufficiently flexible and powerful language like JavaScript.
-yzt
Muaah! ah! ah ah!
YOU are implying that VBScript is a better language than JavaScript ? In what grounds ?
Exception handling, perhaps ?
Please, RTFM, before trying to appear the guru you aren't.
VBS FTW =)