Slashdot Mirror

We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link.

Absolutely, this design style, called Unobtrusive JavaScript (for those reading and learning something new) seems to have become a recent push since the whole AJAX thing exploded. It's well covered by the gurus of the field Jeremy Keith (talks about it in his book Bulletproof AJAX) and Peter-Paul Koch (ppk) of QuicksMode. I've not read his book, "PPK on JavaScript" but if it's half has good as his website, it would be a standard buy for any web person.

Speaking of jQuery, Jeremy Keith also lists the following JavaScript Libraries/Frameworks/Toolkits...

• Prototype
• Scriptaculous
• Mochikit
• jQuery
• YUI (Yahoo! User Interface)

The only way someone would be screwed with this solution would be if [...] I am not aware of even a single example [of a browser that could screw this up]

Right, while not all objects/functions are supported cross-browser, they usually work the same when they are supported. There's only one real concern about the world of "AJAX" and "Web 2.0" that Jeremy Keith pointed out in Bulletproof AJAX: screen readers. Apparently Screen readers are far behind in detecting dynamically updated content via JavaScript. JavaScript "could" be turned on and the page properly updated but the Screen Reader won't understand this and this is a big problem for those sites concerned with accessibility. In short, those who require screen readers should turn off JavaScript and allow the site (if properly designed with unobtrusive JavaScript) fall back to the full page refresh updates. However, I don't know if there's a foolproof (or bulletproof) way of making sure screen readers turn off JavaScript and it could be bad to assume one would be turned off (if your sites traffic has high accessibility needs).

Cheers,
Fozzy

I think you are confusing to uses of the term Prototype:
1. There is prototype, the javascript library/framework, that makes it nicer to work in javascript. Rails utilizes the prototype library for their main javascript helpers.

2. Javascript uses a prototype based programming model versus a class based programming model.

Ruby most definitely uses a class based programming model.

What is interesting is that Prototype the library makes working in javascript more "class" like as people tend to prefer that way of working. Not to mention adding a ton of other useful methods.

There's a lot more to object orientation than simulating a vtable with an associative array. How can you have encapsulation without persistence or visibility modifiers?

Most of the dynamic language evangelists claim that the ability to add or modify methods at run time is a good thing. I believe this to be the part that takes getting used to. I can see the value of adding or modifying methods but feel that this should be done declaratively (e.g. Ruby or .NET 2) instead of by manipulating the associative array directly in code. I am okay with aspects and method interception even though some implementations use a dynamic approach. The developer experience is still declarative.

I agree that the DOM and browser disparities are an issue, however, those issues are mitigated by modern libraries such as prototype.

One big advantage to java scipt's associative array is an object approach is that is what allows JSON to work. JSON is a very easy way to serialize in arbitrarily complex object hierarchies into java script which is a good thing for complex AJAX apps. The down side to this approach is increased exposure to man-in-the-middle attacks that can run arbitrary code client side.

I have one word for all of you: "prototype.js" ( http://prototype.conio.net/ ). The day I discovered prototype.js I stopped hating javascript. It also made me appretiate the really cool ways javascript lets you do inheritance etc + reading the prototype.js code really gets you learning.

If you also use Firebug (make sure you get the latest beta) for debugging then programming web and javascript becomes fun!

With prototype.js the javascript code becomes probably 30-70% smaller. No self respecting javascript programmer should be without prototype.js. It rocks!

someObject.onclick = function(){ myFunction( this.someAttribute ) }

someObject.onclick = (function(){ myFunction( this.someAttribute ) }).bind(this);

for( i=0 ; i<10 ; i++ )
{
  someObject[i] = new SomeObject();
  someObject[i].onclick = function(){ myFunction( i ) }
}

This doesn't have a neat solution. However, there are various ways to get around the problem you descript. For instance, under prototype, one could write:

someObject = $R(0, 10).collect(function(i) {
  return Object.extend(new SomeObject(), { onclick: function() { myFunction(i); } });
});

I know there are a million ways to go, but I've had really good luck doing ajaxy things with the prototype library and custom taglibs. If your interface is off the beaten path, jsps w/ custom tags give you a ton of control and are great for div loading - meaning they help you keep things on the server side as much as possible, which is always a good thing when dealing with javascript.

Doug

1. Snippets - Enhancing existing web applications (Slashdot; other tech site that I shall not mention)
2. Widgets - Snippets + UI Components such as Tree & Grid (IBM Online Help; Yahoo UI Widgets; Backbase)
3. Specialized Framework - Single purpose, mostly client-side logic (Gmail; Google Maps; Yahoo Mail, Tibco GI)
4. RIA Framework - General purpose, tightly coupled client & server side architecture (ThinWire http://www.thinwire.com/, Echo2)

• ThinWire Playground Demo http://207.200.22.70:8086/playground/
• ThinWire FormCreator Early Access http://207.200.22.70:8086/fc_beta/
• ThinWire Mail http://207.200.22.70:8086/mail/

<button dojoType="Button" widgetId="helloButton">Hello World!</button>

The Prototype script library provides an excellent base for AJAX (as well as other dynamic Javascript effects). I like to use that since it's very hard to make AJAX cross-browser compatible as it seems that every browser has a different way it would like the XMLHHTP to be formatted . . . I prefer to work off of what has already been tried and true.

Moo.ajax.js also provides an easy (and light) way to do AJAX very easily (using a "lite" version of prototype as a building block). In fact, moo.fx.js (another lightweight script library from the same folks) is used on this very site to accomplish the collapsible menu on the left.

Have a look at Prototype, in particular Form.serialize().
Oh, and Ruby on Rails has helpers for this too, of course.

Yes, this functionality is part of the Prototype library:

http://prototype.conio.net/

Nobody calls XmlHttpRequest() directly anymore. It's too much work, and there are slight differences between browser implementations. Nowadays everyone is using a wrapper library. Prototype is a very common one (it's certainly my favorite) -- abstracts everything into a nice set of functions for you -- you just specify the HTTP call you want to make, and the function you want it to call when the data comes back (because, in case you're not already aware, XmlHttpRequest() returns its data asynchronously).

The other nice thing you can do with Prototype is to avoid XML parsing altogether by saying "ok, here's the URL I want you to call; it's going to return pre-rendered HTML, and when it does, I want you to stick it in this DIV over here; don't bother me about it" and you can do things like automatically update portions of your page without reloading. You can even have an automatically recurring update, which is very cool for things like tickers, clocks, etc. We used it in our AJAX webmail/calendar system and it really worked well.

<script type="text/javascript" src="prototype.js"></script>
<script type="text/javascript" src="insertConceptHere.js"></script>

The Prototype JavaScript library.

From a web developer point of view, and as the article states several times, the Google Web Toolkit uses an approach similar to Swing, code written for GWT feels like GUI code more than web code, while I don't have anything against this and I believe it does have audience, I think many would prefer a more web-like approach such as Prototype or the Yahoo UI library.

I wonder how difficult it will be to write degradable applications with this toolkit. The demo applications I played with do nothing at all with javascript disabled... they're just a script tag in a body tag, so they make no attempt to render the application using plain HTML. I know they're just demos, but it won't save any time if you have to develop the non-js version separately... which is a problem particularly for those of us who have to develop to accessibility standards.

Also, this is coming right on the heels of the buzz about Oracle's AJAX Framework... and of course there's the Eclipse AJAX Toolkit Framework, which uses Dojo, Zimbra, and OpenRico (which in turn uses prototype)... others have mentioned Yahoo!'s toolkit and Atlas, as well, not to mention Rails... My point is that there are suddenly a ton of frameworks that all have slightly different approaches to the whole AJAX idea. Some are higher-level, some lower; some target a specific server backend; some offer UI libraries... Any or all of these might merge or die off or be made irrelevant at any time. It's almost harder to develop AJAXy applications now than back when you had to write your own HTTP request code... sure, you can knock one out in ten minutes now, but you spend the time you saved choosing the toolset beforehand.

I think I'll wait a bit... we've put the scorpions in the box and shaken it, so let's see who survives.

JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.

Prototype:
http://prototype.conio.net/

It's developed for ruby on rails, but can be used with any cgi language I guess.

Who's using Rails? Check out the Rails wiki site for hundreds of example sites

And if you want a free cPanel/SSH account to download the new Rails version in to see what the craziness is all about - check out www.HostingRails.com

I think its safe to say that Ruby on Rails is the fastest growing Web 2.0-friendly framework - and for good reason. I mean c'mon - the average developer can pick up a few Rails tutorials and have a working demo app (w/ CRUD scaffold action and such) on their local box in a few minutes. Throw in some easily-incorporated Prototype and Scriptaculous effects, and this developer is the new cool kid on the block.

Crazy

~JoeRails

I think you're a little confused about what AJAX technologies are and where they run.

AJAX is a presentation philosophy (AKA: a client-side issue). It runs independent of the server technology used. On various projects, I have implemented AJAX on servers running PHP, ColdFusion, and static HTML. AJAX is server platform independent.

As for the particulars of IE7, I can say that using script.aculo.us and Prototype libraries run the same if not improved on IE7 in comparison to IE6. The fact that the libraries themselves are actively being tested for IE7 as new beta comes out means that I don't have to do anything extra for the changes; It just works.

I understand the initial concern for IE7/IE6 compatibility, but sticking with a popular library solve this problem and make the concern a non-issue.

As for the server-side of AJAX, what you'll be coding are pages that output either HTML, XML, or JSON. Any server platform can create this kind of output, so questions of server compatibility are moot.

But my word of cation is this: Know why you are changing a component to an AJAX philosophy and how best to implement it. There are good reasons to use AJAX as there are bad ones. Please proceed with cation and purpose.

There's this: http://openrico.org/rico/home.page and this: http://script.aculo.us/ which are based on this: http://prototype.conio.net/. Neat stuff and easy to use..

Prototype is a de-facto standard set of extensions for JavaScript and DHTML. MochiKit is another powerful library. Projects like Dojo, Rico and Script.aculo.us build on top of those libraries to privide UI functionality like non-HTML widgets, grag/drop and animations.

There is very little real value in the code Yahoo! just offered, unless you want another library to do the same things. This is nothing more than a publicity stint.

There are some good snippets in there though, and Yahoo has done a good job of introducing code and web services to the developer community, much much more that Google has.

The design patterns are a very very good thing to expose. Although many of us might have been using similar standards, it sort of brings a number of them under one umbrella and into one place.

but when is cross-browser javascript ever elegant?

When you use Prototype to its full capability. Yes it requires a 'modern' browser, but your page should work without Javascript anyway. If you're going to use Javascript you may as well use it to its full extent. Prototype bridges an awful lot of gaps... I daresay more than 99% of JS developers could ever manage on their own, and it does it with style.

On some level this is cool. Good for them. But as an active web developer, this makes absolutely no difference in my daily life. (Virtually) Everyone who's using AJAX is doing so through the use of some toolkit or framework that abstracts out the browser-specific implementations.

Someone will update my OSS toolkit of choice, in this case Prototype, and life will continue without me even noticing.

If anyone wants a lightweight, simple, cross-platform AJAX objects they should check this out: http://prototype.conio.net/ The well-written javascript (prototype.js) library is the basis for many innovative opensource AJAX frameworks/libraries including: - Ruby on Rails (built-in support) - http://script.aculo.us/ - http://openrico.org/ - http://bennolan.com/behaviour/

I guess you can use JSON, and XML data formats with prototype, but I just use plain old text to accomplish whatever I want.

Prototype is also used in Ruby on Rails and its PHP analogue CAKE, and also the excellent perl framework Catalyst

Having learned the things I'm about to list in a less-preferred order, I recommend learning in this order. Some may overlap a bit.

First, learn a lot more about HTML than you know. Learn how to create the correct structure in your sites, and try to avoid excessive tags such as tables and divs. Use page headers (h1, h2,...) and paragraph (p) tags and avoid line breaks (br) unless you're actually attempting to do a line break and not just creating space. Here's a good article to read: http://brainstormsandraves.com/articles/semantics/ structure/.

Learn XHTML, and while you're at it, learn a little bit about basic XML and how it works. W3Schools has a good introduction. XHTML, XML. Don't go too far just yet with XML.

While you're learning XHTML, you'll inevitably encounter CSS. The W3C has plenty of links to articles. Make absolutely sure that you learn CSS, it is the pivot point of learning truly professional looking web development (even if you don't want to do it professionally).

Eventually, you'll need to either build your own system for a blog (as you mentioned you'd like to do), or use a blog management system such as Wordpress. If you choose to do it yourself, you need to learn 2 things. SQL and PHP. I recommend using MySQL (an implementation of SQL) because it's free. Most webhosts will support PHP and MySQL as well, so it's more widespread. W3Schools has the easiest introduction to SQL that I've seen. PHP.net has a complete PHP reference. Make sure to check out the mysql section, because that's what you'll be using most.

Scripting comes next. DevGuru has a pretty good, although incomplete reference for basic JavaScript. Basically, just do a search on Google for Javascript reference and you'll pretty much be able to find anything you want. As you get more advanced, try to understand more complex JavaScript such as the Prototype library, among others.

At this point, you'll have a firm grip on web development. Go back and refresh your skills with XHTML and CSS and you'll find out how much you still have left to learn.

There are many other things to learn about web development, specifically if you want to do web programming and application development. That's a whole other can of worms though.

I dare say it's the sexiest thing I've seen yet. If they ever release a version 2 that allows for simple Javascript on the client for AJAX interfaces, there will be only 1 game in town for web development!

Ruby on Rails 1.0 already has extensive AJAX support. It uses the Prototype library and the Scriptaculous library (which builds on top of Prototype). Thomas Fuchs, the creater of Scriptaculous is a core Rails contributor.

I'd recomend checking out the Prototype Framework. It make all of this transparent.

I've just done a site in Ruby on Rails, which includes nice javascript libraries for AJAX stuff (I think it's from here), and you can use the AJAX stuff without using Rails.

"...oh, I see, its just some stupid acronaming.

This is the sort of thing that I despise. I wish I could hit that guy over the head with a brick."

Since we're on the topic of "start" pages, I thought I would mention my own project, fyuze.com, which was mentioned here on slashdot some time ago. It started out as an RSS aggregator, but in it's latest incarnation is an API aggregator. What does that mean? Well, it means that in addition to pulling RSS/Atom feeds it will also run queries against web-services such as Flickr, Amazon, Technorati, Upcoming.org, and Yahoo (with more to come). It also allows you to post good links directly to your del.icio.us account (hit the settings page).

It doesn't yet sport the nifty Ajax effects of Google and Microsoft, but with prototype and Rico, it is only a matter of time. Anyway, we're trying to push the idea of an aggregator beyond just RSS headlines and weather. So, if you're interested, we'd appreciate it if you gave it try and told us what you thought.

I'm not sure that Sun plug-in is general purpose enough to be included in a book like this. There's a lot of us not using JSF for the view layer of our Java applications and even more people out there using PHP, Perl, ASP and other technologies. Since Ajax techniques execute in the client environment, each platform will need their own library.

However one thing that could have been mentioned to help simplify this type of web interface is a library like Prototype. The fact that it can be used by everyone who wants to use these new techniques make it, IMHO, a more useful library and something that should have been talked about in the book.

Since all these effects are built on top of the Prototype javascript library, you can use them standalone or with any server side language. Just download the effects and the Prototype library (be sure to get the pre-release version) and you should be good to go. Nothing Ruby or Rails specific, but Rails does have some predefined helper functions to make it easier to use the AJAX effects.

there are a lot of them...

Sarissa - http://sarissa.sourceforge.net/doc/
Prototype - http://prototype.conio.net/
Dojo - http://dojotoolkit.org/
SAJAX - http://absinth.modernmethod.com/sajax/
DWR - http://www.getahead.ltd.uk/dwr/
JSON-RPC-Java - http://oss.metaparadigm.com/jsonrpc/

They use the exact same Javascript library that is used in Rails as well: Prototype.

Rails is pretty decent. I guess the only issue is performance... you pretty much have to count out your typical web hosting account and have your own server. Mod_ruby pretty much takes care of the performance issues and it installed without incident in my Apache 2.xx web server with PHP 5.

Like many other people here, I realized that the whole Rails paradigm is great for new schemas and sites and will not fit well into my old crufty database schemas.

Would anyone care to post their experiences with any of the libraries - DWR, Prototype, Sajax, and Ajax.NET (i'm not interested in this one at all, but to be fair...) - mentioned in TFA?

The thing your missing is Prototype - a Javascript library which attempts (most successfully) to provide cross-platform objects to access common issues.

It's worth the price just for the $() function, which does a document.getElementById() on the argument ;)

One way is AJAX. To make it work well, you essentially have to write a version of the page for each major browser - which is a lot of work. Of course, there are development tools that make this substantially easier.

but is less suited than Flash or Java for real applications

- like a game or any other datadriven mouse-interactive thing. I don't believe there is no OOP Javascript in a browser.

Both are false. JavaScript is a prototype-based language, which means it's as OO as a langugae can get. JavaScript is as OO as Smalltalk, Self, and Ruby, and moreso than Python, Java or C++. OOP is a sound technique for developing data-driven designs and for developing games. Don't believe me? Check out the game code for any modern game, especially around the physics and rules enginers. Objects everywhere.

It's called Prototype, and it's available right here.

It's very well written, gets a lot of maintenance, and even has some eye candy as a bonus.