Slashdot Mirror

There are other JavaScript frameworks, beside jQuery, that support CSS selectors. i.e. Prototype

System requirements! Browser-based computing eliminates most of this problem.

When degraded interface, latency of processing and (depending on who's deploying the servers) privacy aren't important... still often no. See the fine article for a counterexample.

Even if the programming language supports cross platform development, does that "cross platform" part include Linux? What about QNX? What about the iPad?

Linux - usually.

QNX - with this RTOS built for embedded apps you clutch at straws. But there's a desktop environment and QNX 6.4 included an albeit non-current Firefox 3, you'll say, then 6.4.1 decided to include a Webkit port last year, you'll point out. Well, yes - tell me, have you tested a modern web app on QNX? Now what about a Java app, or an OpenGL app?

iPad - Steve's a clever bastard, and has intentionally crippled this platform so you have the choice of either providing a degraded HTML/Javascript experience or developing for Apple's proprietary Cocoa framework. In this specific case, there's little developers can do except stop jumping on the shiny bandwagons Apple are driving toward the firing range.

Amiga - I'm including this one because I think you forgot it. A recently released Timberwolf alpha (Firefox port) for AmigaOS surely has to be an argument for web apps.

Environmental differences! Software that works well on computer A might not run at all on computer B despite them being very similar because B installed a shareware program that updated some DLL.

Oh Christ, the horror of checking a DLL/so version and/or providing my own in the app directory! You're thinking of problems with DLL sharing and system DLL overwriting which were largely eliminated by Windows 2000. FUD is bad, ok?

the browser discrepancies that exist when you don't write an app with a decent abstraction API (EG: Prototype)

This? It's a combined utility and occasional kludge layer, like padding for a kick in the balls. Compiling 160k of fixup source to visit a web page - that's what I want my CPU to waste time doing!

Data locality! So you are at work, you save your file, and then you leave.

Yeah, you'll have that file stored on a company network server somewhere which you can access securely from a remote location. You'll also have a locally cached copy. This will all be set up in a few minutes as part of the equipment deployment process in any competent IT department.

You might have trouble with Internet connectivity, but even in very rural areas this problem is disappearing rapidly.

Argh. Most of the world is a very rural area, and it's not disappearing rapidly because there is no profit in providing cheap connectivity to very rural areas. It's not as if you have to go to a third world country - just the most densely populated country in Europe. I'm not buying a satellite phone for your stupid web app, thanks.

Meanwhile, in the cities, (1) an business ISP can and will go down for a few hours (and routing be dodgy, and app servers have problems), and it'd be commercial suicide if your workforce suddenly couldn't do anything but twiddle its thumbs; (2) in general, disaster planning means you don't rely on global infrastructure and political stability except when you need to.

4) Cheap development! Web developers are easy to come by! The standards are open, the needs are many, and the work is easily commoditizable and thus hiring help isn't so difficult.

Ah, the "why choose Windows" argument. This isn't 1995. There are plenty of programmers available and proficient with common APIs beyond HTML/Javascript.

in IE 8, what's the recommended way to specify that a script shall run once the DOM content is ready? Or how do you attach multiple event handlers to an object, such as multiple things to run on load?

Exactly identical as in IE7, IE6, Firefox, Safari, Opera and Chrome. jQuery or Prototype.

You could make casual games about as easily with javascript libraries like jquery or prototype/script.aculo.us as you can with flash these days. Its probably preferable considering there is no need for proprietary tools or learning actionscript...

There is already plenty of Javascript in use with free licenses, such as GPL and MIT. The main practical advice from TFA is to make it easier for users to see which license Javascript code is under simply by putting the license terms in a comment, which sounds great to me. Are you saying more transparency is a bad thing?

jQuery is probably good starting point if you want to be able to do simple things very quickly and easily. If you are interested in actually learning the language itself as opposed to just how to do things in one particular library then I'd also recommend looking at Prototype. Prototype reveals a little more of the native DOM than perhaps jQuery allows so IM(NS)HO is a better primer for someone looking to grasp the fundamentals of the language, whereas jQuery is probably the best for actually "getting stuff done". I also cant recommend John Resig's book Pro Javascript Techniques enough, although it may be pitched slightly high for a beginner. Reading it seriously changed the way I thought about JS (and subsequently my entire career/life/destiny) so if you're an enthusiastic amateur looking to progress then I think it's perfect.

I can't help but think that all of these JavaScript/AJAX libraries keep reinventing the wheel over and over again. How many grid widgets written in JavaScript do we really need? How many toolkits for a progress bar or a div-based dialog box have to be developed? Is one of them really that compelling over the others. Consider:

http://dojotoolkit.org/ - DoJo Toolkit
http://www.activewidgets.com/ - ActiveWidgets
http://www.prototypejs.org/ - Prototype
http://script.aculo.us/ - Scriptaculous
http://jquery.com/ - jQuery
http://extjs.com/ - Ext JS
http://developer.yahoo.com/yui/ - YUI
http://code.google.com/webtoolkit/ - Google Web Toolkit (GWT)
http://www.sproutcore.com/ - SproutCore

Those are just the ones I have used personally. It's getting ridiculous. Personally, I like the approach GWT has, but of course that's only relevant to the java developers of the world. I'd love to see all of these "widgets" be compatible with one another.

It doesn't play well with badly written Javascript that blindly use "for ... in ..." (not loops) in order to iterates over Objects and Arrays.

Have a look at why it's bad: http://www.prototypejs.org/api/array

Prototype doesn't do anything wrong here.

But Prototype can play very well with any other library and with badly written code, using Protosafe : http://code.google.com/p/protosafe/

Yes, and the most interesting thing about JavaScript is that it is arguably the most successful and widely deployed Lisp ever. Before you laugh, it has procedures as first class objects, can eval code, has lexical closures ... it's an absolutely rocking language if you want to do functional things. I love it for prototyping up algorithms.

Take a look at Functional JavaScript. Extensions for functional programming.

Or the great PrototypeLibrary. Note the functions like 'reduce' that can apply to array.

I used to believe this until I started the web2newsportal project whose client component is a pure AJAX web app. The prototype javascript library and getElementsByTagName does a lot to remove the clunkiness of XML. Also, I am uncomfortable with the script injection vulnerabilities of JSON.

http://prototypejs.org/

http://prototypejs.org/

If you run the MooTools Slickspeed tests in different browsers, you find something interesting:

• jQuery is the fastest JavaScript framework in IE6 and 7, and the slowest in FireFox, and middle-of-the-pack in Safari.
• MooTools is the fastest in Firefox and Safari, and slowest in IE.
• Prototype is generally slower than the others, particularly in Safari, and frequently doesn't perform the tests correctly.

jQuery also claims to be the most accurate, though who knows for sure.

I stopped worrying about that kind of stuff when I started using the prototype javascript library. It is easy to use and it Just Works. I've used it in a production environment for...I think ~2 years now. I normally detest using other peoples' third party javascript libraries. Prototype is a notable exception to my roll-your-own approach. I cannot say enough good things about it.

How well do you know javascript?

As someone else pointed out, XMLHTTPRequest is what makes AJAX tick. But without knowing Javascript, what are you gonna do with it?

Assuming you are very good with javascript, here are two resources for you. 1 will help you see what the XMLHTTPRequest object does. 2 will help you tame it a bit and abstract things.
[1]: http://w3schools.com/ajax/default.asp
[2]: http://www.prototypejs.org/learn

The thing is, the AJAX bit is a very small part of the total AJAX package. Then you'll need to learn JSON (a good data interexchange format) and how to use Javascript to create elements.

There, now that I have provided what you asked for and not just some smart alek remark about how you need to google it, this has to be said...If you seriously expect to master a useful skill in an afternoon, then you have some expectation issues. If there's one thing life has taught me, it's that something worth having doesn't come in a day, and if it does come in a day, it's probably not worth much. Did you learn to program in one day? No? Then why would you expect to learn a complex object and a totally new technique for making web applications on one day? But if you really want to learn then you'll thank me for those links later when your web development reaches the next level. If you are just bashing AJAX with a cudgel of ignorance, then you'll ignore those links and keep griping about AJAX being too hard. I guess time will tell.

Fair enough. I was awfully obnoxious, so I should make up for it with some actual information.

For a quick, but useful and accurate, starting point I like Mozilla's introduction.

Then I recommend downloading and trying prototype. It saves the mundane tasks, makes code a little easier to read, and is used by other popular frameworks.

Those cover the base scenarios. I haven't seen any good intermediate documentation. After the intros I suggest reading more reference documentation and just trying things out.

Just download a framework and be done with it. http://www.prototypejs.org/

It'll take about an afternoon to figure out the ins and outs and make it do what you want.

Ajax *is* mainstream - Google, Yahoo, Microsoft, Apple - all using ajax in one form or another in their web applications. Now - as to your other claim, that Ajax doesn't stand up to Silverlight or Flash; I say Flash!?! Have you every built an application in flash? It's a nightmare to maintain. I can't speak to Silverlight, as I've not yet played around with it. But the design theory of ajax combined with a good JS api (like prototype) Makes it a much more maintainable and IMHO a nice way to build interactive web apps.

...or going to compatibility libraries (which is insane...

1. They trivialize tasks that developers use on a day-in day-out basis (hopefully to improve usability and accessibility).
2. They are (generally) well tested and have active support groups.
3. Less code!
4. In general easier to debug and/or maintain (in part due to reason above)

How does JQuery compare with Prototype? I'm trying to decide on which one to use.

The great irony is that all the things that made LISP useful in the 50's now make it a near perfect language for today. Great abstraction, objects, super efficient compiled code, libraries. And yet ...

And yet ... a large chunk of those benefits are available in languages with a syntax much closer to C, and those languages are cleaning up. Ruby, Python, Javascript. Personally though, I'm starting to build programs in Javascript that coincidentally have a web-UI, simply because of tools like JSLint, and great libraries like Prototype (think doing Haskelly stuff in Javascript) and jQuery (think Web 2.0 without the pain).

It's not big, and it's not c++, but I think the prototype Javascript library is a pretty good example of where brevity, functionality and "prettyness" should meet in code .

http://www.prototypejs.org/assets/2007/6/20/protot ype.js

well, depends on how you define "optimize".

An experienced programmer will know what to do and what not to do inside a loop. You write optimal code, but you don't do "special" stuff unless you need to.

As a real life (for me) example of "special stuff", I have an javascript program that has a loop in it to build html elements based on data obtained from a JSON object. I have a function, prototype's $() function, if you know what that is. If you don't, it's a function that you pass an element's id to and it returns a fully qualified object var. Anyway, this function checks for legacy DOMs, accepts an array of element IDs, etc, and therefore does more than a simple document.getElementById() does. So, since I use my $ function everywhere in the program, I use it in the loop, right? Most people probably would, knowing that it's less efficient than getElementById, but for the sake of consistency, they'd do it. Consistency often = readability. But in some cases a large dataset could be returned, so you have to optimize but dropping the $ function and doing a getElementById so you don't call $ 1000 times. But you don't prematurely optimize, blindly using getElementById everywhere you think a problem might exist. That decreases readability and consistency.

Bottom line is, you write the best code you can, and then go back and start trimming things, consolidating statements, etc, only when you need to. Otherwise, you become one of those people who write a line of code that does like five things (like you can readily in languages like C, javascript, java, etc), which can be very confusing to read. I used to think that statement "Premature optimization is the root of all evil" was a bunch of crap. Then I kept living and coding and learned otherwise.

Hmm, can you describe the shared namespace thing in a bit more detail, preferably with a test case (two pages on different domains I can open in tabs to see the interaction)? My understanding was that each tab was basically its own content window, and are completely unrelated...

There was something about assigning extra things to prototypes, but that doesn't actually happen as far as I can tell - I've only seen it do that when using Firebug on a site with prototype (i.e. things leak into Firebug), and that'd be an (unconfirmed, since I didn't look very hard at it) Firebug bug, not a Web 2.0 one.

But we *really* need to see a good standards based framework on the browser side, that applications can be written against.

Prototype has an addClassName function, so you can also just do

$$('a').addClassName('test');
$$('a').show();

I don't think addClassName returns the element list, but I don't have an environment to test it in handy.

I disagree. If your goal is to write a website for mom, it is overkill to look at Prototype (maybe). However, anybody who is comparing frameworks is probably way beyond the simple stuff.

As for the bloat issue, this is where libraries like Scriptaculous are doing it right by keeping classes of components in separate libraries. Second, this is why browsers cache JS files. Third, if you want cool effects that are cross-browser compatible, you simply have to accept that such effects come with bloat. If bloat is a show stopper, then you probably shouldn't use fading transitions with scaling div boxes anyway.

And if the argument is that these add way too much *unused* bloat, this comes back to the "mom's website" argument I made above. If people want to use machine guns to hunt cockroaches, that's their call. Unlike with a machine gun, if Prototype is too much, you can always cut out the small pieces you need. That's right -- people seem to conveniently forget that if they only really need one small, tiny part of a much larger library, they're always free to simply cut and paste that component out (MIT license is a great thing, huh).

What? But you need the rest, just in case? Then don't complain about the bloat you are willfully accepting. But in all honesty, Prototype's foot print is tiny -- about the size of an extra image banner -- and it gets cached.

I have been using Prototype extensively lately, and I have found it as a major time saver. By using it, I don't have to remember the various undocumented "gotchas" across browers. I'd much rather deal with the well documented show/hide issue than trying to figure out how to make transparent text in all of the browsers. On that note, did you know Prototype tries to prevent the very "gotchas" you talk of? For example, stopping event propogation is the same method no matter what browser you are using, and the Element.setStyle/getStyle methods correctly convert the 'opacity' property depending on the browser being used. So for whatever "gotchas" you are using to discredit Prototype, I think you are conveniently ignoring the hundreds of others that Prototype strives to fix, silently, without the developer ever knowing.

And lastly, about the notion of writing your own custom library -- that's hardly an option for most people. First of all, most web developers are not JavaScript experts. In fact, I've almost never seen someone use exception handling in JavaScript, short of in libraries like these. More importantly, even if you were some kind of JavaScript guru, are you going to test all of your methods in all of the browsers out there? Can you guarantee your AJAX calls work the same in all browsers? What happens if I trigger a second one during the first one? Is your implementation really more efficient than Prototype's? How long is it going to take to design this custom library? Is it extensible? Does it respect the global namespace? Does it play nice with other JS files I include? Does it work in strict/quirks mode? Like I said, writing such a library isn't an option for most people. Prototype is as close as it gets to a "patch" library, which is why so many other frameworks are built on it. That, and it has been extensively tested, which is a requirement for most companies rolling out technologies like it.

I agree!! Most, if not all, of the tested frameworks were not current versions.

I'm currently doing development using Prototype. The new version works quite well.
I found the documentation here!

They must have been sitting on their results for the last 5 months or so!

Most of the projects mentioned are in a rapid state of development, so old news just won't cut it!!

Well, Fortify Software Security Research Group (which I am part of) has recently released a report ( http://it.slashdot.org/article.pl?sid=07/04/02/111 3242 ), where we discuss the new type of vulnerability we named JavaScript Hijacking.

We believe that JavaScript Hijacking is the only type of vulnerability found so far applicable only to Ajax applications. We've also analyzed 12 most widely used Ajax frameworks (DWR, GWT, Microsoft "Atlas", xajax, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit) and determined that all the frameworks that use JSON and/or JavaScript for transferring data (except for DWR 2.0 which was not released at the time) are vulnerable to JavaScript Hijacking.

To summarize, the vulnerability allows an unauthorized party to read confidential data contained in JavaScript messages. The attack works by using a tag to circumvent the Same Origin Policy enforced by Web browsers. Traditional Web applications are not vulnerable because they do not use JavaScript as a data transport mechanism.

Complete report is available here: http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf .

As a side note, DWR 2.0 ( http://getahead.org/dwr/ ) and Prototype 1.5.1 ( http://prototypejs.org/2007/5/1/prototype-1-5-1-re leased ) have been recently released, and do contain fixes that prevent JavaScript Hijacking.

What library is this?

I created it on my own for personal use (I don't like all of the things Prototype chose to do).

This is the original library.

OpenAjax Alliance.

That said, I have no idea why this alliance is needed, even after reading most of their site. We already have Prototype, MooTools, jQuery and other great libraries. I'd be perfectly happy if Microsoft could just make IE fully support CSS instead of joining this buzzword-masturbating alliance...

Yeah, that's the way it used to be. Prototype is what I use, because along with a very useful AJAX library it has several useful tools that totally abstract browser differences. For example, it has the $() function. Plug the id of an element in there like such: $('chewbacca'). Assign that to a var, and you have an object var that references the fully qualified element regardless of which browser you are in.

That's pretty simple actually. I used to have my own library that did that and more. But Prototype also does some totally awesome AJAX stuff, and adds useful functions that simulate methods that SHOULD exist (like document.getElementByClassName(), which does what its name implies.) You can get prototype here: http://www.prototypejs.org/download. There is even an (unofficial) reference here: http://www.sergiopereira.com/articles/prototype.js .html.

I use this all the time, and it is a fantastic library. I never have to worry about feature sniffing or *shudder* browser string sniffing.

If you are on an intranet and you don't have to worry about some schlub having netscape 1 or something, then you can really do some very cool stuff with javascript (like AJAX) that makes the user experience much much better. Just be subtle with it. Going over the top with javascript and AJAX just makes you look ridiculous. If you are on the internet, I am not sure how well prototype works with ancient browsers (IE 3, etc). But unless you are amazon.com, who the heck cares?

is this. Seriously.

Mod parent up. Given two application stacks of equal feature/functionality merit, choose the one with the least TCO. The more software dependencies, the more likely that there will be problems with the client side install, the higher the TCO.

I am not a big fan of Java Script and would prefer to code Java applets. However, the prototype library and the debugger mitigates most of my complaints.