It’s something I always wanted to write about and also a response to Peter Cooper’s post on RubyFlow calling to write about tools that we use everyday to do Ruby on Rails development. I like the idea since there are a lot of options and finding right tool for the job is essential.

Let’s start:

Hardware

• MacBook Pro 15″ with Intel Core 2 Duo 2.40GHz and 2 gigs of RAM - absolutely enough. This is a decent laptop, the only thing which bothers me is its temperature, sometime it burns my hands, literally…
• Logitech VX Nano Cordless Notebook Mouse – the best notebook mouse ever, has the smaller receiver out there + I change batteries like twice a year, love it

Base software

• Arch Linux – it’s my 6 day with this distro actually, I’m a Gentoo fanatic but from time to time I try to use something different. I usually go back to Gentoo after a month or so. We’ll see how I’ll end up now. So far I really like Arch, it’s extremely lightweight, fast and stable. Software availability is as good as in Gentoo. It’s also easy to make your own packages which is crucial for Ruby developers since it happens that we need various non-standard stuff, like let’s say Nginx with Passenger support. I’ve got a feeling that this time I won’t go back to Gentoo

• KDE – it’s my desktop environment and one of the most important reasons why I’ve switched back from OSX to Linux. KDE’s window manager is highly configurable and gives you features like moving and resizing of windows via a special key + mouse move/click, custom settings per application / window class so for instance you can configure that console window will always appear on the third virtual desktop snapped to the upper-right corner of the screen, useful desktop effects ie “Present windows” which is something like Expose in OSX but you can filter out windows by typing key words, cool window transparency (you can alt+mouse scroll to change window’s opacity…it’s useful, believe me) and much, much more…I just can’t work without those things. Here are KDE’s apps that I use:
  • Konsole – terminal emulator, very powerful, has tabs, horizontal / vertical view splitting, bookmarks and fully customizable look’n'feel
  • KRunner – something like quicksilver for OSX
  • Dolphin – file manager, supports remote protocols, in my opinion the best file manager ever
  • KDiff3 – GUI for displaying diffs and merging, it’s my mergetool in Git
  • KColorEdit – color picker and editor
  • KRuler – on-screen ruler
  • KSnapshot – for doing screenshots
  • Klipper – a handy clipboard manager, supports custom actions
  • Amarok – music player

• NetBeans – I use this great IDE even for writing tiny scripts, for me it’s the best choice. I’ve tried many other IDEs/editors including Eclipse, JEdit, RubyMine, TextMate and others that I don’t remember now and NetBeans works best for me. Key features are powerful editor with macros and great shortcuts, ctrl+click navigation, fantastic JavaScript support, debugger, test/spec runner and…support for multiple projects in the same window, something that most of the IDEs don’t have and I really need it. I use following plugins:
  • Ruby and Rails – what a surprise
  • Database – to access databases via a GUI
  • OpenFileFast – written by my friend from LLP, Marcin Kulik. Works like the open file dialog in TextMate, highly recommended. You can read more here

• Firefox – I’ve switched from Opera a long time ago because of Firebug, now I’m about to try out Chromium for normal web browsing and use Firefox only for the development. Plugins that I find useful:
  • Firebug – must-have for every web-developer
  • Web Developer – easy access to things like clearing cache, disabling JavaScript etc.
  • Chat Zilla – IRC
  • Read it Later – I never have time to read interesting things from Google Reader in the moment I find them so…I read them later
  • Delicious – I still use it but rather for sharing bookmarks between work and home

Dev tools:

• GIT - probably the best SCM in the world
• QGit4 – sometimes I use this git gui to view history of a project
• ZSH with a pimped prompt for GIT
• Nginx with Passanger – better then script/server
• VirtualBox – I have 3 Windows virtual machines each with different version of Internet Explorer, only for testing of course

Communication:

• Skype – Linux version is very crappy, unfortunately I’m forced to use it
• PSI - great Jabber client
• TweetDeck – powerful Twitter client, Adobe AIR based

That would be it!

CodeRack is a coding contest dreamed up by a group of the Ruby programmers at Lunar Logic Polska who were excited about the possibilities of Rack middleware. The team wants to encourage Ruby developers to explore the possibilities and what better way than to hold a contest? The secondary goal of the contest is to generate a set of open source solutions that will solve real problems and inspire others. Every entry will be released under the MIT open source license.

Programmers are encouraged to submit contest entries that will be judged based on the cleverness of the application and the elegance of the code. Entries can be submitted at coderack.org until midnight EST November 15th. Finalists are scheduled to be announced on the 1st of December and public voting will run for one month. The final winners will be announced on the 5th of January.

The first round of the contest will be judged by an elite panel of judges including Ben Bangert of O’Reilly Media, Chris Wanstrath and PJ Hyett of GitHub, Joshua Peek of 37Signals, Yehuda Katz of Engine Yard and Rails core team member, Ryan Tomayko of Heroku, Core Rails team member Matt Aimonetti, and the Rails Envy team of Gregg Pollack and Jason Seifer.

Once the finalists have been selected by the panel, the public will vote for the top prize winners.

Prizes have been donated by Bytemark Hosting, GitHub, Jetbrains, Mindmeister, Freelance Total, Heroku, Rackspace Hosting, Peepcode, BDDCasts, and Zenbe Shareflow. The top prize includes a dedicated quad core server package and is valued at over $3000. Every entrant will receive a credit from bddcasts.com and $30 credit from Heroku. All finalists will receive a package including Zenbe Shareflow subscriptions, a RubyMine license from JetBrains, and five credits from bddcasts.com. Details of all of the prize packages will soon be available on the coderack.org website.

More information about the contest, including the contest rules, can be found at coderack.org.

ps. This post is a copy from Lunar Logic Polska blog

A while ago I have written a post about JavaScript helpers in Ruby on Rails and tried to explain why they are a bad idea. It’s hard to believe for me that it was almost 2 years ago! Since then so many things have happened in the Ruby world…Now Rails 3 is on its way and we already know what significant improvements and changes it will include. One of them is related to JavaScript helpers and the way how remote links and forms will be handled and I must admit that the new idea is absolutely great.

The new way is based on unobtrusive approach to JavaScript. This means that HTML code will be separated from JavaScript. I have checked out the latest sources of Ruby on Rails and found out that some of the work is already done. There is a new helper called AjaxHelper, it implements link_to_remote method which in the moment of writing this post looks like this:

def link_to_remote(name, url, options = {})
  html = options.delete(:html) || {}
 
  update = options.delete(:update)
  if update.is_a?(Hash)
    html["data-update-success"] = update[:success]
    html["data-update-failure"] = update[:failure]
  else
    html["data-update-success"] = update
  end
 
  html["data-update-position"] = options.delete(:position)
  html["data-method"]          = options.delete(:method)
  html["data-remote"]          = "true"
 
  html.merge!(options)
 
  url = url_for(url) if url.is_a?(Hash)
  link_to(name, url, html)
end

What you see here will generate a clean markup with HTML5-compliant attributes prefixed with a word “data-”. If you are not familiar with them you can checkout a nice article by John Resig HTML 5 data- Attributes. Those attributes will instruct the additional JavaScript code how it should handle the behavior. Basically all links, buttons and forms that have the special attribute “data-remote” set to “true” will issue an AJAX request. There has been a discussion on the Rails on Rails Core group about how to implement corresponding JavaScript code. People are worried about its performance since finding all elements with data-remote=true appears to be slow in case of Prototype and jQuery. Moreover there is a problem of new elements that may be dynamically inserted after the page was loaded and all the event listeners were attached. Fortunately there is no need to be worried as our situation is a perfect example where we should use Event Delegation. DHH has already showed in his Rails 3 and the Real Secret to High Productivity presentation how links and buttons can be handled by Prototype library and it looks absolutely reasonable to me.

I would like to focus on jQuery though as it’s getting more popular even in the Rails community. Great example is my job where we use jQuery in every of our new projects. So how can we handle new remote links and forms using this popular library? Actually it’s ridiculously easy. Thanks to jQuery.live function we can easily use Event Delegation to handle AJAX calls. Just take a look at this sample of a markup that new helpers in Rails 3 will generate:

<!-- the new link to remote -->
<a href="/users" data-remote="true">Users</a>
 
<!-- the new remote form -->
<form action="/users" method="post" data-remote="true">
  <input type="text" name="login"/>
  <input type="submit"/>
</form>

Pretty clean, I really like it! Now let’s see how we can implement jQuery handler that will send AJAX requests:

var request = function(options) {
  $.ajax($.extend({ url : options.url, type : 'get' }, options));
  return false;
};
 
// remote links handler
$('a[data-remote=true]').live('click', function() {
  return request({ url : this.href });
});
 
// remote forms handler
$('form[data-remote=true]').live('submit', function() {
  return request({ url : this.action, type : this.method, data : $(this).serialize() });
});

The above code will send an AJAX request when you click on a remote link or submit a remote form. Note that it will work also with new elements dynamically inserted to the DOM. The example JavaScript code is the bare minimum of course, we could have something much more sophisticated. We will be able to specify success and failure handlers and also elements that should be updated with an AJAX response text (and probably much more!), hence the JavaScript is going to be more complicated.

This is definitely a step into the right direction. I’m looking forward to Rails 3!

Wow, it’s been a while since I wrote last post. I guess I suck at writing posts on a regular basis. Hopefully I will be able to change that So…a lot has happened recently and I’ve been quite busy. First of all about 3 months ago I bought my very own apartment. The whole process of getting a bank credit took 2 months and it was sucking my energy without any mercy. But…I did it and I’m alive No more renting, I’ve got my own home. Me and the bank of course, haha.

Anyway now it’s time to get back to the Web and let people know what I’ve been working on.

Utype

At Lunar Logic Polska we’ve migrated our site to Utype which aims to be a modern, flexible, user and developer friendly CMS. It’s currently based on Merb and DataMapper. Our plan is to migrate it to Rails3 later this year. If you are interested in the development please have a look at the official GitHub repository

RubyTime

Again, at Lunar Logic Polska we’ve spent last couple of months working on a new version of our time tracking system. Version 3.1 will include some new features and many bug fixes. We should release it in July. You can see the progress at LightHouse site. The release will support external clients too – an iPhone app (by Kuba Suder) and a KDE4 plasmoid (by Marcin Kulik). RubyTime is an open source project, sources can be found at the official GitHub repository

DataMapper related goodies

That’s a fresh meat for me. I’ve resurrected a plugin that I’ve originally created to use with Utype and now after some hacking dm-is-configurable is compatible with DataMapper 0.10.0 RC1 and will be officially released whenever DataMapper 0.10 is finished, which should happen soon.

During my recent work for Ideeli I had to deal with Google Data API which I’ve found relatively simple to use via Ruby GData lib; however I would love to have even better way to access that API, hence I’ve created dm-gdata-adapters. The only thing that works there is loging in, but stay tuned! I’m going to write a wrapper around Spreadsheet API for a good start and hopefully I will find some people to help me with the rest of the APIs. If you are interested just drop me a line.

KDE4 related goodies

I’ve been experimenting with Plasma and trying to write a simple plasmoid (in Ruby or Python) which would replace Skype notifications. Current status is…double fail. I’m using an SVN snapshot of the upcoming KDE 4.3 and I’m having various issues with Ruby and Python bindings. pykde4 doesn’t work well with the Skype4Py library so I’m trying to use Ruby which seems to be unstable at the moment…oh well. We will see how it goes when KDE 4.3 RC1 is released (which will happen in a week ).

Me at Lunar Logic Polska

A couple of weeks ago I became responsible for implementing high standards of development at our company. We’ve created a list of various best practices that we’re following and now I’m one of the persons that make sure we’re really doing it. The process includes things like organizing regular code reviews, keeping track on the test coverage status for each of the projects that we’re working on, sharing knowledge between the teams etc…We will write a blog post on our site soon which will describe everything in detail as we believe it might be useful for other companies.

OK. Batch mode turned off. I’m glad I finally have the time (and energy) to write something here! G’nite

About a month ago I installed Gentoo Linux on my MacBook Pro as I’ve become really disappointed with OSX. Being a linux user for a few years it’s hard to get used to such a limited operating system like OSX…Anyway I just want to show you some screenshots of a just released KDE 4.2 RC that is totally amazing…

Main Desktop Activity

This is where I work. I have two “Folder Views” with my Home and Downloads folders. There’s also a trash plasmoid, a big one so I can easily drop files there even when I’m drunk

Multimedia Activity

Here I have “Folder Views” of my Music and Video folders and a filtered Downloads “Folder View” where only multimedia files and folders are displayed. Those 2 icons in the upper-right corner are Amarok and SMPlayer shortcuts. Next to them is a “Now Playing” plasmoid. This is just the beginning of my Multimedia activity, but it’s already quite useful.

Tools Activity

When my Mac is on fire I go here to see the temperatures of the hardware, as well as the CPU load and system messages from the log file. I can also check out my disk usage. Oh, and there are also calendar, dictionary and calculator plasmoids.

File manager – Dolphin

I love this little yet powerful piece of an application. Dolphin is the best file manager I’ve ever used. It’s tiny, has all of the crucial features AND supports remote protocols. It also has “split view” which makes me so happy, that I don’t use Krusader (a twin panel file manager) anymore.

Music player – Amarok2

There are people whining about the new Amarok2. Personally I love it. Simplified playlist view, extended context view (with activity-like zooming!), fantastic collection browser and a decent integration with Last FM. I don’t need anything more.

Document viewer – Okular

Perfect for my needs and it doesn’t start 3 minutes like Adobe Reader.

Image viewer – Gwenview

Gwenview is terrible in KDE 3.x series, but in KDE4 it’s superior! It’s integrated with semantic desktop feature of KDE4 too so you can search and filter by tags and ratings.

Quick Access – KRunner

This is something like QuickSilver in OSX. I use KRunner to open applications or access files, but you can use it for many other tasks like calculations, spell checking, opening web bookmarks etc.

…it’s so good to use KDE again, I feel I can breath again.

Web applications are getting more and more complex. The user interface of a modern web application can be as rich as its desktop equivalent. If we use JavaScript/HTML/CSS trio to build this UI then we definitely want to use AJAX. A typical approach is to use AJAX to update parts of our page using an HTML response, everyone knows that, right? Does this approach allow us to create a responsive, fast and flexible UI? The answer is no.

Here are 4 main downsides of using AJAX requests to load UI parts:

• You increase the server load – yes, you make an AJAX request only because you need a piece of HTML code that you want to insert to an already rendered page. That was cool a few years ago when AJAX was such a great innovation. Nowadays it should be considered as a less efficient solution.

• You complicate the server-side code – because you need parts of your page to be returned by the server you, obviously, need to handle that by writing more server-side code. You end up having many actions in your controllers that return different fragments of HTML. I know, you think it’s normal, everyone does that.

• You loose a lot of control over the UI – you use DHTML techniques to deal with the UI and in the same time you need the server to get parts of that UI. This leads to a code duplication and in many cases ends up with a big mess.

• A user will have to wait until a request is done – that just sucks, that poor guy has to wait because you went back to the server for a little piece of HTML. How you are going to implement a responsive UI this way? “Your servers are fast”. Of course they are, but what if user’s ISP sucks? What if the user is downloading something and 99% of his bandwidth is gone?

Rendering HTML on the client-side is ridiculously simple. Consider the following example. Let’s say we have a page with a list of some people, the list is just a simple HTML table. It could look like this:

<table>
  <thead>
    <tr>
      <th>First Name</th>
      <th>Last Name</th>
      <th>E-Mail</th>
    </tr>
  </thead>
  <tbody id="people">
    <!-- here go people -->
  <tbody>
  <tfoot>
    <tr colspan="4">
      <td>
        <a id="previous" href="#">Previous</a> 
        <a id="next" href="#">Next</a>
      </td>
    </tr>
  </tfoot>
</table>

As you can see the tbody element is empty, we will load its content after the entire page is loaded. Instead of a bunch of “tr” elements the server should return a nice JSON data which could look like this:

var people = [
 { id : 1, first_name : 'John', last_name : 'Doe', email : 'john.doe@somewhere.com' },
 { id : 2, first_name : 'Jane', last_name : 'Doe', email : 'jane.doe@anywhere.com' },
 { id : 3, first_name : 'Third', last_name : 'Guy', email : 'third.guy@nowhere.com' }
];

To render these data we obviously need a template. Prototype gives us a handy class called Template which is perfect for our needs. To create a template and render the list of people we need a few lines of JavaScript:

var personRowTemplate = new Template(
  '<tr id="person_#{id}"><td>#{first_name}</td><td>#{last_name}</td><td>#{email}</td></tr>');
 
var peopleRows = '';
 
people.each(function(person) { 
  peopleRows += personRowTemplate.evaluate(person); 
});
 
$('people').update(peopleRows);

That’s pretty much it. It doesn’t look spectacular, huh? Now just think about the benefits of this approach:

• You have the data in JSON format, you can use them to render things like an edit form without going back to the server, thus user experience will be better

• You can be focused on building a nice JSON API for accessing data instead of implementing actions that return small pieces of HTML

• Your client-side code is cleaner and more consistent

Sounds like a good deal, doesn’t it?

Because of the rails & merb merge thing I have decided to hold off on working on Utype until the merge is finished. Unfortunately I don’t have enough time to finish Utype using Merb 1.x just to port it to Merb 2.x and then to Rails 3.0. As a side effect of my decision I have migrated my Utype-based blog to Wordpress, which is a scary PHP-based piece of software with one important advantage – it does the job right. It’s not as cool as I thought but I will be using it anyway since it’s probably the best CMS out there (at the moment…:)).

The fact that I’m using Wordpress now and I don’t spend hours working on my own CMS system means that finally I will have time to write something here more frequently.

…and BTW - Happy New Year Everyone

Recently, new versions of jQuery and Prototype have been released – it’s a perfect moment for a part number 2. On the official Prototype blog we can read that the general performance of CSS selectors is now improved, unfortunately only for Safari 3, but Element#up/#down/#next/#previous should now be faster on all browsers, it’s a good news as they were really slow. On the other hand we have jQuery official announcement with information that jQuery is now 300% faster – we’ll see!

This time I made a step forward and decided to use a custom JavaScript-based testing environment instead of running tests using Firebug profiler. The obvious advantage is that I was able to run all the tests on 4 different browsers. New test cases aren’t much different then in the first part, let’s say it’s a modification of the previous ones with some extra operations and a little more complex HTML structure.

Test environment setup

Libraries:

• jQuery 1.2.2
• Prototype 1.6.0.2

All the tests were run on the following browsers:

• Firefox 2.0.0.11
• Konqueror 4.00.00
• Opera 9.50_beta1
• Internet Explorer 7 (*but using Windows on VirtualBox!*)

A tiny piece of JavaScript code is responsible for running the tests, each operation is called only once inside a try-catch block, so the essential part looks like this:

    try {
      var start = new Date;
      test();
      var end = new Date - start;
      this.writeResults(test, end);
    } catch(e) {
      test.resultCell.innerHTML = '<div style="color: red">Exception caught: '+e.message+'</div>';
    }

There is a 3 seconds break between each test run, results are automatically inserted into the results table. If you want, you can check it out on your own, just go right here and hit the ‘run tests!’ button.

The results

I’m happy to see that all tests pass on the latest Konqueror, previous version from KDE3 fails on some Prototype tests. I don’t own Mac, so you won’t see Safari results here, although I’ve run the tests on my friend’s MacBook with very similar hardware as my laptop has (Intel Core Duo 2ghz + 2 gigs of RAM), and it was faster even then Konqueror (no, it doesn’t mean his MacBook is faster then my laptop!!!! ).

I’ve run everything 3 times, here are average results in ms:

$('td.counter').addClass('marked')

$$('td.counter').each(function(el){ 
  el.addClassName('marked') 
})

$('td.counter span.special').removeClass('special')

$$('td.counter span.special').each(function(el) { 
  el.removeClassName('special') 
})

$('td.content span.odd').css('color', 'red')

$$('td.content span.odd').each(function(el) { 
  el.setStyle('color: red') 
})

$('td.content span.even').before(
  '<h3 style="display: none">text</h3>'
)</code

$$('td.content span.even').each(function(el) { 
  el.insert({ 
    before:'<h3 style="display:none">text</h3>' 
  }) 
})

$('td.content h3').show()

$$('td.content h3').each(Element.show)

$('div.special').hide()

$$('div.special').each(Element.hide)

$('div.special, td.content .odd').toggle()

$$('div.special, td.content .odd').each(Element.toggle)

$('span.odd').remove()

$$('span.odd').each(Element.remove)

$('#data p.lost:first').html('gotcha!')

$('data').down('p.lost').update('gotcha!')

Conclusion #2

Prototype was at least 2 times faster then jQuery in 15 cases, and jQuery was faster then Prototype in 8 cases. What library should I choose? In my case I will stick with Prototype, because it offers the same functionality as jQuery does + more and it's faster. jQuery is probably better for projects where there's a need for some fancy UI effects and that's it, but it's just an assumption, correct me if I'm wrong...

Prototype 1.6.0 was released to the public 4 days ago, at first I decided to check its performance and new features in comparison to the previous version, but being interested in other JavaScript libraries, I’ve changed my mind. Lets see how you can accomplish same tasks with the latest Prototype and jQuery libraries and simply see which one is faster. In this part I’m going to show the results of running single operations, in next part(s) I will prepare a sample website and write more complex test cases and, again, check how fast jQuery and Prototype can be (or how slow…).

Test environment setup

The following software was used:

• Prototype 1.6.0
• jQuery 1.2.1
• Firefox 2.0.0.9
• Firebug 1.05
• Webdeveloper 1.1.4

Test page contains only one table with 500 rows, it’s generated using the following RHTML template:

<table>
<% (1..500).each do |i| %>
  <tr>
    <td class="first">
      <div><%= i %></div>
    </td>
    <td class="second">
      <div><%= "hello from #{i}" %></div>
    </td>
  </tr>
<% end %>
</table>

Running the tests

Each operation was executed using Firebug’s console with Profiler turned on and repeated 3 times, between each execution the page was reloaded. Cache in Firefox was disabled using Webdeveloper plugin. Here are the results of 7 test operations showing average times and number of method calls in each operation:

1. Adding ‘marked’ CSS class to every cell having ‘first’ CSS class:

$('td.first').addClass('marked')

$$('td.first').each(function(cell) { cell.addClassName('marked') });

$$('td.first').invoke('addClassName', 'marked');

Comment: no practical difference, although jQuery is a little faster.

2. Removing CSS class from every table cell having “second” CSS class:

$('td.second').removeClass('second')

$$('td.second').each(function(cell) { cell.removeClassName('second') });

$$('td.second').invoke('removeClassName', 'second');

Comment: No big difference, especially when comparing Prototype #2 option with jQuery.

3. Setting ‘color’ CSS property in every div element which is inside a cell having ’second’ CSS class:

$('td.second div').css('color', 'red')

$$('td.second div').each(function(el) { el.setStyle({ color : 'red' }) });

$$('td.second div').each(function(el) { el.setStyle('color : red') });

$$('td.second div').invoke('setStyle', 'color : red');

Comment: Same here, Prototype 2 x faster

4. Adding new elements before every div element which is inside a cell having ’second’ CSS class:

$('td.second div').before('<h3>text</h3>')

$$('td.second div').each(function(el) { el.insert({ before: '<h3>text</h3>' }) });

$$('td.second div').invoke('insert', { before: '<h3>text</h3>' });

Comment: Wow…jQuery is almost 4 times faster, I should point out that Element#insert is a new method introduced in Prototype 1.6.0.

5. Removing all div elements which are inside cells having ’second’ CSS class:

$('td.second div').remove()

$$('td.second div').each(Element.remove);

$$('td.second div').invoke('remove');

$$('td.second div').each(function(el) { el.remove() });

Comment: Prototype more then 2 times faster.

6. Hiding and un-hiding all div elements which are inside cells having ’second’ CSS class:

$('td.second div').toggle();$('td.second div').toggle();

$$('td.second div').each(Element.toggle);$$('td.second div').each(Element.toggle);

$$('td.second div').each(function(el) { el.toggle() }); $$('td.second div').each(function(el) { el.toggle() });

Comment: jQuery tragedy, Prototype toggles visibility of 500 divs 10 times faster!

7. Attaching event listeners to all div elements which are inside cells having ’second’ CSS class:

$('td.second div').bind('click', function(){ alert(this.innerHTML) })

$$('td.second div').invoke('observe', 'click', function(){ alert(this.innerHTML) });

$$('td.second div').each(function(el) { el.observe('click', function(){ alert(this.innerHTML) }) });

Comment: no practical difference.

General conclusion and impression

Executed tests show that Prototype seems to be faster then jQuery, with the exception of the new insertion method, which performance should be improved. Although I like jQuery syntax more then Prototype, the performance is way more important then saving few lines of code. Of course tests that I made don’t show how these libraries act in a real application, which is my task for the next part(s) of this article. Despite the results I must admit that I’m very excited about jQuery, my general impression is that this library is more mature then Prototype.

You may want to check out part ||

Ruby on Rails gained so much attention and appreciation mostly because it simplifies the development process of AJAX-driven applications. When I started to learn Rails I was already very familiar with other MVC-based frameworks, and actually I’ve created one myself (in PHP5) in my previous work. My framework also uses Prototype JavaScript library, so when l was learning Rails it was nothing new when I saw “Ajax.Updater(…)”. I remember that when I added first AJAX-feature in the Depot (it’s a tutorial application used in well known “Agile Web Development in Ruby on Rails” book) I was shocked about how simple it is, but then I looked into the HTML output and it shocked me once more…

JavaScript Helpers

These nice methods generate for you HTML with some addition of JavaScript code, one can say “You don’t need to know JavaScript to create AJAX web apps! Just use Ruby on Rails!”. It’s a catchy slogan, and in some way it’s true, you don’t need to know how Ajax.Request works, you just write link_to_remote and you’re done. In Rails API you can find 4 helper modules, all related to JavaScript code generation, and here they are:

* General JavaScript Helpers – actually there’s nothing interesting there
* JavaScript Macros Helpers – whole thing is deprecated in the upcoming Rails 2.0
* Prototype Helpers – probably the most popular methods, including link_to_remote and other AJAX goodies
* Scriptaculous Helpers – you know, drag’n'drop and visual effects goodies

When I first saw what link_to_remote helper creates I was really surprised, back then I said to myself “hey, that’s…just bad!”. Unfortunately I had quickly forgotten about my negative thoughts on JavaScript helpers, because “everybody” use them, and that’s a shame in my opinion. I don’t know why JavaScript helpers are included in the Rails core, maybe it was just a pure marketing trick or something So, what’s so evil about JavaScript helpers?

DRY - ooooh reaaally?

We, the Ruby on Rails developers, use proudly our favorite MVC framework, we remember everyday about Don’t Repeat Yourself principle and other good and well known practices. How come that people like us write scary pieces of code like this:

<table id="users_list">
  <% @users.each do |user| -%>
  <tr id="user_<%= user.id %>">
    <td><%= user.login %></td>
    <td>
      <%= link_to_remote(
             'Delete',
             :url => user_path(user),
             :method => 'delete',
             :confirm => 'Are you sure?',
             :complete => "Effect.DropOut('user_#{user.id}')",
             :failure => 'alert("Could not delete user: #{user.login}")'
          )
      %>
    </td>
  </tr>
  <% end -%>
</table>
  <% end %>
</table>

Pretty common rhtml snippet, right?? (yes, I know, we use partials, but it’s just an example) Let’s have a look at the HTML output:

<table id="users_list">
    <tr id="user_2">
    <td>jane</td>
    <td>
      <a href="#" onclick="if (confirm('Are you sure?')) { new Ajax.Request('/users/2', {asynchronous:true, evalScripts:true, method: 'delete', onComplete:function(request){Effect.DropOut('user_2')}, onFailure:function(request){alert('Could not delete user: jane')}}); }; return false;">Delete</a>
    </td>
  </tr>
    <tr id="user_1">
    <td>john</td>
    <td>
      <a href="#" onclick="if (confirm('Are you sure?')) { new Ajax.Request('/users/1', {asynchronous:true, evalScripts:true, method: 'delete', onComplete:function(request){Effect.DropOut('user_1')}, onFailure:function(request){alert('Could not delete user: john')}}); }; return false;">Delete</a>
    </td>
  </tr>
    <tr id="user_4">
    <td>paul</td>
    <td>
      <a href="#" onclick="if (confirm('Are you sure?')) { new Ajax.Request('/users/4', {asynchronous:true, evalScripts:true, method: 'delete', onComplete:function(request){Effect.DropOut('user_4')}, onFailure:function(request){alert('Could not delete user: paul')}}); }; return false;">Delete</a>
    </td>
  </tr>
    <tr id="user_3">
    <td>peter</td>
    <td>
      <a href="#" onclick="if (confirm('Are you sure?')) { new Ajax.Request('/users/3', {asynchronous:true, evalScripts:true, method: 'delete', onComplete:function(request){Effect.DropOut('user_3')}, onFailure:function(request){alert('Could not delete user: peter')}}); }; return false;">Delete</a>
    </td>
  </tr>
  </table>

Where did DRY go? Hello? Why we don’t apply our OOP practices also to JavaScript? “Why bother!?” you might ask, well, BECAUSE IT MATTERS.

JavaScript won’t hurt you

Creating webapps without a good understanding of JavaScript is like working with ActiveRecord and having no idea what SQL is. I think you know what I mean. There are plenty of great JavaScript libraries, Ruby on Rails comes with Prototype and it makes writing JavaScript as easy&cool as writing Ruby code. Okey, here’s above example without redundancy, the quickest solution would be:

<table id="users_list">
  <% @users.each do |user| -%>
  <tr id="user_<%= user.id %>">
    <td><%= user.login %></td>
    <td><%= link_to 'Delete', '#', :onclick => "deleteUser(#{user.id})" %></td>
  </tr>
  <% end -%>
</table>

And in application.js (or wherever else):

function deleteUser(userId) {
  if(confirm('Are you sure?') {
    new Ajax.Request(
       '/users/'+userId, {
         method : 'delete',
         on200 : function(){ Effect.DropOut('user_'+userId) },
         on500 : function(xhr){ alert(xhr.responseText) }
    });
  }
  return false;
}

Now, our ouput looks like this:

<table id="users_list">
  <tr>
  <tr id="user_2">
    <td>jane</td>
    <td><a href="#" onclick="deleteUser(2)">Delete</a></td>
  </tr>
  <tr id="user_1">
    <td>john</td>
    <td><a href="#" onclick="deleteUser(1)">Delete</a></td>
  </tr>
  <tr id="user_4">
    <td>paul</td>
    <td><a href="#" onclick="deleteUser(4)">Delete</a></td>
  </tr>
  <tr id="user_3">
    <td>peter</td>
    <td><a href="#" onclick="deleteUser(3)">Delete</a></td>
  </tr>
</table>

Advantages:
* We don’t have a redundant JavaScript code in the HTML output
* We are not limited to what link_to_remote generates
* We have a generic JavaScript function which deletes a user, we can make it even more generic and use successfully in other places

Disadvantages:
* Obtrusive JavaScript code in HTML

Progressive enhancement and unobtrusive JavaScript

I found out about this approach about half a year ago, when I started to use Dan Webb’s UJS rails plugin which makes an extensive use of LowPro library. I was very excited about its functionality, thanks to that plugin I’ve stopped using JavaScript helpers. UJS is a dead project now, you can find out why here but it doesn’t matter, thanks to it I’ve learned two important things:

• We can divide View layer into two sub-layers: the presentation (HTML+CSS) and the behaviour (JavaScript)
• Presentation layer can be extended using JavaScript by adding various behaviours to the DOM elements

Currently I don’t use UJS or pure Low Pro, instead I just code my JavaScript using Prototype and Scriptaculous. Let’s see how this looks in practice. Here’s how our users table example could be implemented using progressive enhancement and unobtrusive JavaScript code. First of all, we’re going to create plain HTML links, without onclick event and without even href attribute (I assume we’re writing an application which requires JavaScript to work):

<table id="users_list">
  <% @users.each do |user| -%>
  <tr id="user_<%= user.id %>">
    <td><%= user.login %></td>
    <td><a>Delete</a></td>
  </tr>
  <% end -%>
</table>

Above rhtml template generates this HTML output:

<table id="users_list">
  <tr id="user_3">
    <td>peter</td>
    <td><a>Delete</a></td>
  </tr>
  <tr id="user_4">
    <td>paul</td>
    <td><a>Delete</a></td>
  </tr>
  <tr id="user_1">
    <td>john</td>
    <td><a>Delete</a></td>
  </tr>
  <tr id="user_2">
    <td>jane</td>
    <td><a>Delete</a></td>
  </tr>
</table>

The very last thing to do is to add an actual functionality to our plain HTML code. Let’s create a simple module called Users, which will include method for deleting users:

var Users = {
  onWindowLoad : function() {
    $('users_list').getElementsBySelector('tr').each(function(userRow){
      userRow.down('a').observe('click', Users.onUserDelete);
    });
  },
  onUserDelete : function(event) {
    if(confirm('Are you sure?')) {
      var userId = Event.element(event).up('tr').id.split('_').last();
      new Ajax.Request(
       '/users/'+userId, {
         method : 'delete',
         on200 : function(){ Effect.DropOut('user_'+userId) },
         on500 : function(xhr){ alert(xhr.responseText) }
      });
    }
  }
}
Event.observe(window, 'load', Users.onWindowLoad);

This way we:

• Write reusable and object oriented code
• Create clean and easy to maintain RHTML templates
• Have a clean separation between visual and behavior layers in our applications
• Decrease site loading time by writing less JavaScript (you can even compress it too)
• Improve general performance of our application’s UI
• Learn JavaScript!

The final word

I didn’t write anything about so called graceful degradation issue, leaving JavaScript helpers behind was the main reason for this article. If you totally disagree with me or/and you know an even better approach, leave a comment, I’m always open to a discussion.