Jump to content
  • Advertisement
Sign in to follow this  
Etnu

[web] How JavaScript became my best friend.

This topic is 4905 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I used to hate javascript 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 javascript. 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 one 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 on 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 javascript and xmlhttprequest, and, while I didn't find God in the process, I certainly have developed a new found appreciation for what I once 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 only 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 javascript in the first place. You know what i'm talking about - those days when every idiot had huge javascript menus on 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 javascript for anything presentational. Use it for what it's for - application logic. Use it to generate elements on the page dynamically, but don't use it to style them. Bad example:
var newElem = document.createElement("div");
newElem.style.color = "red";
newElem.style.backgroundColor = "white";
newElem.style.height = "500px";
newElem.style.width = "200px";
newElem.style.display = "block";
...

Good example
var newElem = document.createElement("div");
newElem.className = "some_class_name";

Now, javascript 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 on structural logic, usually in the form of templating systems) 2.) Client-side application logic (has heavy dependencies on server-side application logic and data transfer logic, low dependencies on 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 on it) 4.) Structural logic (small dependencies on presentational logic) 5.) Presentational logic (moderate dependencies on structural logic) Notice how nothing is actually dependent on 2 and 3 - and this is the critical part of making this viable. The page still needs to be useful if our lovely javascript isn't available. This might mean something as complex as generating frames on the fly or something as simple as falling back to a 'page by page' method. Now, javascript 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 javascript 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 javascript, but many of them will go away as CSS3 and XForms begin to take hold). javascript 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.

Share this post


Link to post
Share on other sites
Advertisement
Funny you should say this, because over the past week I've been experimenting with javascript RPC which kind-of works similar to the xmlhttprequest, and it's been incredibly interesting tinkering around with it :) The game I'm writing is a souped up browser-based game, with a DHTML gui with draggable DIVs posing as windows, tabbed dialog boxes, etcetc. Unfortunately I nearly had to book an appointment with a pyschotherapist after attempting to get IE to correctly display my DIVs, so I concluded that until IE7, only Gecko browsers work as intended.

The RPC layer dynamically creates IFRAMES requesting data from the server in the fashion:

http://localhost/server/rpc/<requesttype>.php

I was originally going to go with single entry point, but after a brief re-think, I opted for that style of request.

An example of how the RPC layer works:

1) Player enters login username and password
2) Player clicks 'Login' button
3) Click action creates an RPC request similar to:

function btnLogin_OnClick()
{
if (username == '') || (password == '')
return;
var rpc = new ZRPC('Login',[username,password]);
}

Sending this query to the server:

http://localhost/server/rpc/login.php?p0=zanthos&p1=letmein



The server can then validate if the user can log-in, and if successful, gets this reply:

RPCLogin_Success();
RPCMain_ShowWelcomeMessage('Welcome!');
RPCMain_Finish();


The RPCMain_Finish() call must be at the end of every response, it sets a timeout for 500ms or so, to delete the RPC IFRAME from the DOM.

Share this post


Link to post
Share on other sites
This is indeed good news that someone's finding a use for XMLHttpRequest (apart from Google :) )

Quote:

there is ZERO browser-specific logic in any of the javascript code that is needed to use this in practical terms.


Lucky you don't need to use events then.

Events are handled by IE in a way so totally different from any other browser, that you HAVE to write special code for them.

Basically, an event handler normally contains a parameter which is an event object containing the event properties.

This does not happen in IE. Instead, it writes the event into a window property called "event" (similarly to document, navigator etc).

So if you have a formal parameter in your event handler, nothing is passed through. This is a pain.

In practice the code required to work around this is small though. The event object itself has (somewhat) similar properties on.

The main case for this is in keyboard events. But there are other cases too.

A lot of the time people use events, they don't care about the parameters (like mybutton.onclick = function () { alert('hi'); } )

Mark

Share this post


Link to post
Share on other sites
A good post. XmlHttpRequest has been winding its way into my Web Development process a lot after I saw that article a few months ago. Even for simple things like populating a list box with values based on the contents of another the lack of a page reload can really add a lot to your application's usability. It's good because now you can focus individual sections of your site to do their thing and refresh them when needed; you no longer have to query the whole page, hitting the database multiple times to refresh the various sections of it. Now you can just refresh your 'Articles List' div and you're away. It really is sweet and I can see it paving the way to make purely web-based games (no flash) a bit more of a reality for people to make.

Share this post


Link to post
Share on other sites
Quite interesting... I'll have to look into this. I'm currently designing my own CMS loosely based on Oluseyi's non-hierarchical theories and this could prove useful.

As far as javascript is concerned, it is true that it has been horribly misused, especially during the DHTML era. It is perhaps one of the most dangerous technologies because if not used properly, the results can be disastrous. I do think, however, that using it to style pages can be considered fair use under certain circumstances. At least in the mean time, when certain things such as color-alternating table rows and the like are not feasible with the current support for CSS.

edit: A quite google of XMLHttpRequest yielded this seemingly extensive overview of the component and it's modern uses. Google searching also yielded a horrifyingly evil site based entirely upon XMLHttpRequest... one that broke all navigational functions of the browser, was extremely slow to load (no thanks to the author's "invention" of a poor attempt at hiding javascript to which the lag was credited), and was populated with mindless drivel! A very interesting technology we have here...

[Edited by - Fuzztrek on March 15, 2005 10:51:07 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!