Ajax On Rails

mu-sly writes "Ajax and Rails - probably two of the biggest buzzwords in web development at the moment. In this article over at ONLamp, Curt Hibbs introduces the incredibly powerful Ajax support that is part of the Ruby on Rails web application framework. It's a great read, and serves as a gentle introduction to the cool stuff you can accomplish with ease using the Ajax features of Rails."

Comments

Rails, great for those fed up with J2EE.

[newdamage]

I'm sure many developers like myself have a day job that probably involves J2EE. The first time I did the iniitial tutorials for Rails several weeks ago I was blown away. Connecting to a database is not susposed to be this easy.

Even when using newer frameworks like Spring, Tapestry and Hibernate (I hate you so much Struts) Rails still manages to be easier.

I highly suggest any developers looking for a change of pace at least give Ruby on Rails a few hours of your evening. While it's not nearly as comprehensive as Java, it's gaining libraries and functionality by leaps and bounds.

And just so I don't get labeled as a Rails fanboy/Java basher: Rails is not perfect, I still would recommend using J2EE for large corporate projects. It's just a much more mature solution with less unknowns. I think Rails needs another year at least before people are ready to really give it a shot in the corporate environment.

Re:Rails, great for those fed up with J2EE.

[Uber Banker]

I've not tried RoR from a development perspective (I have no need/desire to write web apps), but from a user perspective it rocks! Well done Javascript can be a nice user experience, but sites that need regular reloading rarely use it, the main exception I can think of being Gmail.

RoR, IMHO, is a major step forward to web deployed applications becomming mainstream.

Re:Rails, great for those fed up with J2EE.

[Cyberax]

Ruby is easier. Until you try to do something even moderately complex.

Our company recently tried to do a web-project (workflow management application for a publishing house) based RoR. It was a spectacular failure - LOTS of things are mostly absent from RoR: caching and transaction support, object-relational mapping is inferior (yes, ActiveRecord is NOT enough), etc.

RoR is nice, but it needs lots of polishing and some redesign. In its present state RoR can't be compared with J2EE solutions, they are far more powerfull and _flexible_.

Re:Rails, great for those fed up with J2EE.

[marcello_dl]

hmmmmm troll alert?

Ruby can't do complex things java can??? You meant rails, probably, and such confusion of terms is not a good sign.

Have you checked out the latest rails versions' API? I see transaction support and caching of db data and cgi actions too.

As for the 'inferior' object relational mapping: indeed Active record tries to keep things simple: I'm grateful for it. Rails developers got too far sometimes, as you see if you have a column named 'type' in your tables ;)
But, that's not being inferior, it's being different. If your app requires convolute mappings, either extend active record to suit your needs or do without it (possibly dropping rails altogether and wasting precious ram with a JVM ;) ).

Re:Rails, great for those fed up with J2EE.

[ajm]

So what you're saying is that RoR is becoming more complex as it tries to handle the complex things J2EE has to handle? There is a certain irreducable amount of complexity in writing enterprise software (whatever that is). Frameworks that try to support this completely generally become more and more complex themselves until they reach J2EE levels. The vast majority of the "complicated" things in J2EE are in there because they are needed to solve real world problems. Anything that attempts to solve the same set of problems will approach the same complexity.

Re:Rails, great for those fed up with J2EE.

[abulafia]

Were you trying to shoehorn rails onto an old schema?

This, I think, is the crux.

My company has a library, too, that makes certain assumptions about the DB. We're really wicked-fast when using it, when building an app from the gound up. It has hooks for overriding some assumptions, so we can shoe-horn it in to some other projects. But if the DB is hopeless, the game is over, and we have to do things like everyone else.

And nearly every company out there has a hopelessly messy DB, that can't be refactored because of X, where X is legacy apps, no money, management resistance, [...]

Hell, even Hibernate/middlegen has a problem related to this: all it takes is one clueless app developer that scorns DB constraints, and you have a Situation that can cost 10s of K to fix.

Rails is neat (I'm a pretty big perl bigot, and I like it), but it isn't designed for integration. Folks playing around with it should recognize that up front, so that they don't try to do the wrong thing with it.

Re:Rails, great for those fed up with J2EE.

[Cyberax]

First, you have some misconeptions about J2EE.

True, you can't just drop J2EE on your desktop because there's no such _thing_ as J2EE. J2EE is a set of standards (which contains just about everything).

The only things you need to start developing J2EE applications are: Tomcat (http://jakarta.apache.org/tomcat/index.html), optionally a web-framework (like http://jakarta.apache.org/tapestry/index.html) and you can start developing tomorrow (if you know Java of course) and a decent IDE (http://www.eclipse.org/). It will cost you about $0.

Java has some metaprogramming featues starting from version 1.5. Right now we're writing application in C++ and Python, so I don't miss metaprogramming features :)

RoR is extensible, but some features are just very hard to implement: maintaning persistent object identity, complex mappings support, distributed caching and long-running transactions with optimistic locking.

We had previous expirience in dynamic languages (Python, Perl, PHP). This project was a sort of expirement - we wanted to see what can be done with RoR.

Substitute for s

[fa2k]

Can this again help reducing bandwidth consumption in a similar, but prettier way, than html frames?

Re:Which is the bigger irony:

[AKAImBatman]

Then Microsoft created XMLHttpRequest in Internet Explorer 5, which let browser-side JavaScript communicate with the web server in the background without requiring the browser to display a new web page.

This isn't quite correct. IFrame and hidden IFrame communication was invented before that. The catch is that browsers weren't stable enough or compatible enough to make use of these channels.

XMLHttpRequest does more or less the same thing as an IFrame (via an ActiveX contarol), except that it adds the overhead of an XML parse. AFAIK, Google doesn't use the XMLHttpRequest for any of their applications.

Rails changes the whole Web development game

[Peter Cooper]

Most of this product comparison site was developed in Ruby on Rails within the last two months, and it already does more than Froogle, has more search features, etc.

I've also developed a large marketing system for the restaurant industry in Rails which lets restauranteurs develop e-cards, e-gifts, and send them to their customers on certain days.. or certain days away from their birthdays, etc.. and that will be going fully live soon.

My 10,000 user strong RSS Digest will be making the leap to Rails soon (July 1st) and this is a system driving over half a million uses a day.

I developed a del.icio.us-style tagged Code Snippets site in Rails within two days! It's had further refinements since then, but less than two weeks after launch, it was getting thousands of pageviews a day and hundreds of visitors a day from Google.

I was ready to give up development work 6 months ago, and now it's the most fun and profitable work out there for me. Ruby on Rails deserves the attention it's getting. You can put together your ideas in a fraction of the time you'd have ever imagined.

Re:Dont Forget Zope

[Ranger]

If you can get your head around Aqusition[sic], the ZODB and Product Deveopment[sic] then Zope is a super-fast development platform.

I recenty became the web administrator at a small university and the college I work for uses Zope. I knew a little Zope and Python beforehand and it helped me get the job. I was all hot and heavy to switch them to a PHP/MySQL solution, though my first love is Perl. Doing stuff in PHP was fast. As I studied Zope and Python more and more I came to realize that my initial impression was correct. It does have a steep learning curve (Zope not Python), but it is very powerful and reasonably fast. I'm not crazy about ZODB. I'll keep Zope put it behing Apache and connect to MySQL when I redesign the site. Also I'll throw Plone on top.

What does this have to do with Ruby and Rails? Not much. The user base of Plone/Zope/Python (8) is much smaller than the PHP (5)/MySQL crowd. The Ruby (23) on Rails is even smaller than the Plone crowd.

Re:Ruby on Rails as a threat to PHP?

[DoctoRoR]

What a troll. PHP is so low performance and scales so poorly that major web sites moved to it from the Java world, and there are enterprise-focused solutions like Active Grid that are now available. It's so un-"useful" that myriad discussion boards and community portals are invariably PHP-based. New development tools and plug-in support for popular design/programming tools are popping up. Each of these web technologies has a sweet spot, but your narrow-minded viewpoint is best revealed by your aversion to "this ancient approach of text-edited, interpreted syntax." Yeah, right. Google and every other major web presence must agree with your assessment since they only use Java and .NET now.