Slashdot Mirror

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...

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.

Javascript is truly complex when it comes to cross-browser compatibility and object management. The ambiguity of type in the syntax is also horrible, and the handful of built-in functions needed workarounds until recently (most notably date related functions).

For the web I would avoid javascript wherever possible. If you want to do anything serious on the client use FLASH. If you want to pickup AJAX tricks then buy a book on the topic, not on JavaScript.

If you feel the need to buy a book like this then you probably aren't getting the most out of google, or looked into server-side scripting yet. Which is a shame, because starting with js is definitely the wrong foot. You'll end up learning a ton of language specific quirks and hacks that are useless elsewhere, and will end up with the impression that half of everything is broken, or that they cannot be done. Try PHP. Java is even easier than JS.

Anyone with a clue knows that beyond simple mouse-overs, libraries like this are the way to go. Any book that states otherwise is FYE: For your entertainment only.

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

If we continue down that line of thought we end up at the point where we just go back to static pages with no scripting.

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

I made a simple search for "fade file:.js" in order to find a javascript function that would fade a div or table or anything really (I know scriptaculous offers this already, just curious as to what's out there). I found something but the header of the file read:

All Code herein is Copyright 2005 Match.com
Do not copy, reproduce, reuse or sell any code herein
without the express, written consent of Match.com.
For information contact webmaster@match.com.
All Rights Reserved.

Which is expected. However, that means this tool isn't useful for finding a method or function or class I can use and then using it ... it seems to be restricted to one of two uses. If I'm looking for code that does natural language parsing, I could hope a comment somewhere contains NLP as a description of what's going on. Or, I could look for libraries out there with methods and then search for those methods to see how other people used them to get an idea of how they work. The vast majority of this code seems to be just web development front-end code at least from the few searches I've done. Too bad, that's a very small part of programming.

It's not just an effect library (anymore?). Yes, it is built on top of prototype - in fact, scriptaculous has the only documentation I know of for Prototype. But that shouldn't it exclude it from a list of AJAX library comparisons. That's like saying "well, the GIMP uses libpng so we're not going to review it amongst photo editors."

Anti-disclaimer: I don't have anything to do with the script.aculo.us guys, but as a Ruby on Rails developer it has served my needs just fine.

It's not just an effect library (anymore?). Yes, it is built on top of prototype - in fact, scriptaculous has the only documentation I know of for Prototype. But that shouldn't it exclude it from a list of AJAX library comparisons. That's like saying "well, the GIMP uses libpng so we're not going to review it amongst photo editors."

Anti-disclaimer: I don't have anything to do with the script.aculo.us guys, but as a Ruby on Rails developer it has served my needs just fine.

There are two other, very active and famous scripts left behind:

1. script.aculo.us : That have many effects include in it and is used in Ruby

2. script.aculo.us : An active library to help for ajax development.

Why is that script.aculo.us is left out of these comparisons? script.aculo.us is behind the AJAX in most Ruby on Rails apps, but it can be used on its own. (As of Rails 1.1, Rails has special built-in support to make it even easier to use.)

My main problem with AJAX: submitting a form without reloading the page! Any easy way to do that?

If you're not opposed to using a framework, use Ajax.Updater from script.aculo.us

I have used RoR and am impressed with what it has to offer. Check back in a year and it might mature to the level for larger scale projects that aren't as vanilla boilerplate as is the case now. I have used Smalltalk as an OO language and am starting to teach myself Seaside since it looks to be a good fit for certain potential freelance work.

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..

http://script.aculo.us/ has some interesting scripts (like drag-n-drop)

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.

Have you seen prototype.js 's sister Visual Effects library?
Yahoo's stuff looks pretty weak in comparison... not to mention that VisualEffects uses much more clean implementation with prototype.js

My biggest complaint about prototype is the lack of clear documentation. I have the same problem with script.aculo.us, which has a wiki that is often useless to me.

For a really lightweight effects library, check out moo.fx.

createNode and attachNode just like the old days :)

So what's the accepted DOM function that, given a string of markup, parses the markup to give me one or more nodes that I can attach?

Check out http://script.aculo.us/ for a javascript class called Builder, works well.

The page you linked does not contain the word "Builder", and neither does the Prototype library linked from there. If it's part of the script.aculo.us library, I'm not in a position to evaluate that library as I write this comment. Besides, would it run nearly as fast as the browser's built-in markup parser, which I assume is used for handling the innerHTML property?

What you are doing is inserting a character data node into the DOM not element nodes.

If I were inserting character data instead of markup to be converted to element nodes, then I would use the innerText property, not the innerHTML property.

createNode and attachNode just like the old days :)

Check out http://script.aculo.us/ for a javascript class called Builder, works well.

innerHTML isn't deprecated, it's just that it's in a grey area. What you are doing is inserting a character data node into the DOM not element nodes. So accessing the data again shouldn't be possible (although i imagine many browsers will fudge this for you just like the good old days)

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/

that you may as well go with a library like CPaint http://cpaint.booleansystems.com/ . It saves a lot of time, and the principle of AJAX is so simple anyway you aren't really missing out on any 'under the hood' shananigans. CPaint combined with some of the JavaScript from Scriptaculous http://script.aculo.us/ means you can quickly knock up something impressive and responsive with a pretty user interface that will let you extort as much money as you like from any Venture Capitalist you can garner an appointment with!

Thank you for the compliment, but I actually got it from script.aculo.us. Apparently to be truly Web 2.0 compliant you have to have a mind-numbingly stupid domain name, not an intuitive name like "Google" or "Slashdot." ;)

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.

This is actually a very good point that you raise about Ajax, that has less to do with the failings of the technologies than it does way some people employ them. Clicking an Ajax link won't cause the browser to refresh, and since most users look to the top-right corner of their browser, or their status bar, for visual feedback on the connection and retrieval status of the result of their mouse click, this can leave an Ajax-enabled site feeling broken.

The best solution is for web developers and designers to provide some simple feedback of their own that could be a simple small animated gif of some kind, perhaps with some text saying 'loading...' 'updating...' or 'sending...' nearby that is switched on when a link is clicked.

http://script.aculo.us/ has a JavaScript library that can be used with links to switch on or off content in <div> or <span> tags with mouse clicks, which works very well with an Ajax-enabled site.

There are some people out there who might have been led to believe that the fancy AJAX applications currently being built using Ruby on Rails actually require RoR for that degree of rich functionality. Fortunately, this is not true. The AJAX library is called script.aculo.us and it is available as a standalone JavaScript library.

It can be used in any language, or even from static web pages. Heck, I practice the unorthodox style of developing web apps in C and I'm using it too!

For some drag-and-drop resources check out http://script.aculo.us/ or http://tool-man.org/examples/. For an interesting practical application of drag-and-drop take a look at this bookmarklet/Greasemonkey script for Netflix: Netflix Queue Manager

So, I'm going to use a clunky piece of shit web app when I could be using a real binary, because there's this 1% of time that I need email from somewhere other than my own machines ...

Allow me to propose an alternate theory: I'll use a real binary until the corporations decide that they don't Trust my machine to run them, and use web based applications only when I'm actually away from machines that can support a real application.

It's not about trust though. It's about convenience for both user and developer. Anyone who uses gmail as their primary email will give you a laundry list of reasons why they like it more, and one of them that's always near the top of the list is that they have one email box and interface even when they're traveling. Plus, you never need to worry about updates or learning a new interface for the "(win|mac|linux) port" again. The idea of a machine specific binary goes away entirely, which means more people can use the app under more conditions. And, it means that developers can spend more time making their software great instead of wasting time porting.

I think that the future for things like email and other applications that are pretty unique per user (as in, I get no use from your email client) is portable applications, like portable thunderbird. USB keys are becoming cheaper, faster, and support more ubiquitous.

There's no need to deal with the slowness of a text dissemination system shoehorned to other duties when you really want an application that does something completely different.

Just because many webapps suck doesn't mean that they have to suck. Cross platform rich-client behavior is already becoming a reality on web browsers. There are still holdups, but at the rate their being surmounted, it's only a matter of time.

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.