[web] How JavaScript became my best friend.

I used to hate &#106avascript with a passion, and as such, never used it. In the last 7 years of doing software development (my God, has it been that long?), I've written millions of lines in C++, millions in PHP, and millions in FoxPro, VB, and all the rest. But I'd probably, in my entire life, never really written more than a few simple, basic things in &#106avascript. Then, about 2 weeks ago, I discovered the beauty of xmlhttp request. Now, until Microsoft wises up and implements this sucker natively (no ActiveX, thanks!), it's kind of hard to use for anything critical (personally, I think it's the ideal solution for ad delivery -- especially as a replacement for google adsense, which simply doesn't work in xml). Suddenly, seemingly counter intuitive and useless functionality becomes a work of art. I'm in the process (about 75% done now, but I program rather quickly and I don't have much of a social life...) of completely rewriting our CMS at work to take advantage of this. Users can now manage a database of hundreds of thousands of articles through instant-update drag and drop. Searching through articles can be done with instant feedback via a google suggest-like interface. One of the biggest issues that we were facing recently was a content acuisition that would result in more than 40 times the current data being pushed into the system. There weren't any real database issues to be concerned with, as mysql can easily handle hundreds of thousands (if not millions) of records without really running into problems. The problem fell back to a simple matter of time: doing everything &#111;ne page at a time (and reloading constantly...) ultimately stuck us with a simple logistics problem: a single person who spends as little as 1 minute per article to review it and assign it to an appropriate topic would require 417 days (working non-stop - using a 40-hour work week it would take 1250 days...) of work. A team of 4-5 people (which is closer to what we really have working &#111;n it) could get the project done in a year or so). Obviously, the page-by-page approach wouldn't cut it. So I started toying around with &#106avascript and xmlhttprequest, and, while I didn't find God in the process, I certainly have developed a new found appreciation for what I &#111;nce called 'the stupidest, most aggrivating piece of web technology i've ever seen'. The great thing, though, is that this is being used strictly by our employees, we can simply mandate that a relatively recent browser is being used -- which means I don't have to really make any consolation for anything, it is very much true that most of the techniques I used would work perfectly fine in any version of IE later than 5.5 (~89%),Mozilla 1.4 (I think?) or later (~6%),Safari 1.0 (1%?), and some others. Unfortunately, it doesn't work with any current versions of Opera, although I've tested the 7.6 beta and it works perfectly there. Basically, ActiveX aside, if you're already designing pages around these browsers (i.e. you're using standards based design, and you love css with your whole body), you can use these same techniques. I'd have to say that this is the future of web applications. No bulky java, no bloated flash, and certainly no .net components can compare to clean, standards-based xhtml married to css (especially when css3 is done) and glued together with this beautiful language. My &#111;nly real concerns at present are the "dHTML"-era garbage that flowed endlessly from web page to web page and gave rise to the violent hatred of &#106avascript in the first place. You know what i'm talking about - those days when every idiot had huge &#106avascript menus &#111;n their sites, annoying things that would follow your mouse cursor around, and other, arguably worse ideas. I think that we can avoid this by simply encouraging people to NOT use &#106avascript for anything presentational. Use it for what it's for - application logic. Use it to generate elements &#111;n the page dynamically, but don't use it to &#115;tyle them. Bad example: <!--STARTSCRIPT--><!--source lang="cpp"--><div class="source"><pre> var newElem = document.createElement(<span class="cpp-literal">"div"</span>); newElem.style.color = <span class="cpp-literal">"red"</span>; newElem.style.backgroundColor = <span class="cpp-literal">"white"</span>; newElem.style.height = <span class="cpp-literal">"500px"</span>; newElem.style.width = <span class="cpp-literal">"200px"</span>; newElem.style.display = <span class="cpp-literal">"block"</span>; ... </pre></div><!--ENDSCRIPT--> Good example <!--STARTSCRIPT--><!--source lang="cpp"--><div class="source"><pre> var newElem = document.createElement(<span class="cpp-literal">"div"</span>); newElem.className = <span class="cpp-literal">"some_class_name"</span>; </pre></div><!--ENDSCRIPT--> Now, &#106avascript doesn't exactly have a unique role; server-side code (php, asp, whatever) will still make up the bulk of your application logic, xhtml will make up your structural decisions, and css will continue to define the presentation model. With those things defined, it seems kind of like you've already got all your bases covered, but you'd be wrong if you thought that way. This sticks these things together so nicely that it's hard to not wonder why everyone isn't doing it. Basically, you have 5 layers in any application: 1.) Server-side application logic (small dependencies &#111;n structural logic, usually in the form of templating systems) 2.) Client-side application logic (has heavy dependencies &#111;n server-side application logic and data transfer logic, low dependencies &#111;n presentational & structural logic -- mostly for things like getElementById and className attributes). 3.) Data transfer logic - xml formatting (no dependencies, since it doesn't "do" anything, but others depend &#111;n it) 4.) Structural logic (small dependencies &#111;n presentational logic) 5.) Presentational logic (moderate dependencies &#111;n structural logic) Notice how nothing is actually dependent &#111;n 2 and 3 - and this is the critical part of making this viable. The page still needs to be useful if our lovely &#106avascript isn't available. This might mean something as complex as generating frames &#111;n the fly or something as simple as falling back to a 'page by page' method. Now, &#106avascript has surprised me in how far it's come with regards to getting some kind of standardization going. With the exception of a 'special case' handler for the activex vs. native XmlHttpRequest implementation, there is ZERO browser-specific logic in any of the &#106avascript code that is needed to use this in practical terms. In all honesty, just the functionality of the most basic DOM attributes and methods is more than sufficient to do what you need - honestly, I'd rather keep it that way. Leave the logic to the server. The bulk of the javascipt code consists of: 1.) Doing some minor validation for obvious things that it'd be pointless to communicate with the server for (valid input and the like). 2.) Sending the request to the server 3.) Checking for a response message 4.) Processing the results (if successful) --- a.) Appending / removing / modifying values of nodes (actually this probably makes up the majority of the code) based upon responses --- b.) Displaying any appropriate response message And very little else (some things are still necessary to do via &#106avascript, but many of them will go away as CSS3 and XForms begin to take hold). &#106avascript very much CAN be light weight, it CAN be powerful, and - and this is important - it can be useful. More importantly, it can be your best friend.