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 know someone replied to your 'this' problem. You can also check out mochikit, they got a great bind() metoth which let's yuo 'set the this pointer, also, they got 'bindMethods()' which binds all methods of an object ao that objeect always is the this pointer, very neat. also other goodies like partial functions, map(), filter(), standardised event handleing over ie and ff (look a bit like Qt event handling) and more for you to play with - lovely stuff

What standard function should be used to turn a string of HTML into a tree of elements for insertion into a DOM tree?

var result_div =
Builder.node('div', {class: 'result', id: 'first_result'}, [
Builder.node('h3', {class: 'heading'}, [
Builder.node('a', {href: '#'}, "Heading")
]),
Builder.node('p', "Small description goes here")
]);

One way to reduce the challenges of using Javascript and AJAX across browsers is to use a library that abstracts away many of the differences from one browser to another. One such library is MochiKit, which provides AJAX / remote scripting support, functional language tools, portable DOM manipulation, and event signalling. It's even got some cool flashy visual effects.

Anyway, I'm not affiliated with the MochiKit at all; I'm just a very satisfied user and even use it on my own site.

...go for MochiKit, nuff said.

Maybe take a look at http://www.mochikit.com/. At 110 kilobytes, the full distribution isn't super small, but it includes quite a bit of stuff and can be used in a more modular fashion to save on size.

As someone who's evaluated various JavaScript frameworks, what do you think of "prototype.js", the AJAX library that Ruby uses?

Does the new version of Ruby continue to use "prototype.js" or has it switched to a better designed and documented JavaScript framework?

How is the documentation of "prototype.js"? Does it have a rigorous test suite? How does "prototype.js"'s documentation and test suite compare with, say, MochiKit?

Does "prototype.js" continue to define additional methods on Object.prototype? How does it deal with the issue that defining extra methods on Object.prototype causes "for (key in obj)" to return those method names for every object, totally breaking a fundamental JavaScript language construct, and making it extremely difficult to integrate other JavaScript libraries and code modules without suffering mysterious bugs and crashes?

A JavaScript framework should NEVER define methods on Object.prototype or Array.prototype, because doing that breaks all JavaScript code that iterates over the keys of objecs or arrays, which is certainly not very friendly nor modular. Why did Ruby choose to use an AJAX framework that makes such a huge mistake? Have the maintainers of "prototype.js" gotten around to cleaning up that mess, and why did they make such a horrible mistake in the first place? Weren't they aware of this horrible JavaScript quirk, and why didn't they work around it in the first place? Isn't that supposed to be why we use JavaScript frameworks: to avoid such problems?

-Don

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

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.

I mean, the first articles explaining how to create cross-browsers XMLHTTP requests ain't have more than a pair of years anyway...

Wouldn't it be slightly more interresting if Slashdot promoted useful stuff such as the Dojo or Mochikit Javascript libraries/toolkits (others exist btw, those are just fairly stable and advanced), which actually:

• Make that kind of stuff easier
• Make that kind of stuff more reliable
• Give great tools/shortcuts for working with javascript
• Actually work

Just wondering...

But it's unfortunate that the preferred Ruby AJAX design pattern still includes prototype.js, because that library as written is fundamentally dangerous. It's written in a fashion which demonstrates that the author is very adept with JavaScript and functional programming in general; but it also does some unpardonably cute tricks in extending core objects, thereby changing the overall JavaScript environment and making the core AJAX library not play nicely with others. (And if ever there was an environment where you need to have good manners and not piss in the pool, it's the browser + JavaScript environment.)

To me it seems like a silly exercise to replicate rails in python or what have you.

1. TurboGears is not a Rails clone.
2. Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
3. Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
4. MochiKit has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype.

Rails has taught us some important lessons, but they aren't really technical lessons:

1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
3. Things like screencasts are nice.

After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.

As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.