Fri

May 18
2007

Brady Forrest

Brady Forrest

DHH's Rails Keynote

dhh at rails
David Heinemeier Hansson (DHH) is the 37Signals partner who created Rails in 2004 while building Basecamp. He just gave the opening RailsConf keynote on the growth of Rails (a lot) and the new features of Rails 2.

Rails was extracted in 2004. Since then there have been

>1 million downloads of Rails gems
> 600 plugins (5 lines of ruby code); one of the best ways for people to contribute to rails; experimental
~10K members on the rubyonrails-talk Google group
1 job advertisement that is looking for 3 years of Ruby on Rails (longer than Rails has been around)

DHH talked about the new features in Rails 2. If you follow Rails, it is likely that this information is not new.

  • More formats - It is now incredibly simple to turn an HTML page into XML, plain text, a V-Card, ATOM, or RSS. Good.
  • REST is now native - A REST API is now built at the same time as your application. Active Webservice has been rolled into Active Resource so there are no separate Rails calls to generate an API. No more native SOAP, I guess you'll need a plug-in for that. These two features have been shipped in 37Signals' HIghrise (where one page can actually be called in 6 different formats). There are Ruby gems available today that you can use to get access to them (sorry I didn't catch the name).
  • New Debug language - Breakpoints were broken in an earlier Ruby version. This was the impetus for a new debug language, ruby-debugger, to be created.
  • HTTP Performance Improvements - For development purposes it can make sense to keep your CSS and JavaScript files separate. However, the browser can only handle two connections to a host at a time. In Rails 2, all of your JavaScript and CSS will be turned into 1 file and gzipped for deployment; it stays seperate for development. Images are the other big perf hog. Rails 2 makes it easy to send images out from multiple hosts (it remembers the host for caching) which allows for more connections and increased performance.
  • Query Cache - Hitting your database can also slow down your app. Now "selects" will be cached until an insert, delete, or update statement is run.
  • HTTP Authentication - There will now be increased support for letting machines/bots/feedreaders authenticate via HTTP which machines can handle easily, but is too ugly and awkward for human users. Users will get a login box
  • Auto-MIT License - Rails and many of the plugins are open-sourced under the MIT license. From now on the plugin generator will auto-generate an MIT license for the file. You'll still be able to change the license, but this will help to solve the problem of code being uploaded without a license.

DHH also shared some of his thoughts on what else will become core features. Just as AJAX and REST are now native, ATOM will become native. OpenID may become native. Less certainty here as not all apps need OpenID, but going forward Rails will be developed with OpenID in mind. Given the recent Twitter kerpuffle I had originally expected scaling to be addressed more specifically. I don't think that there is a known solution yet to be discussed within the context of Rails 2. I think that is a problem that is yet to be solved and isn't ready to be addressed in the core.

To read more on this keynote check out Justin Ball's and Giles Blowkett's blogs.

Even if you don't follow care about Rails in particular, it is important to note these trends in web application frameworks. An API is assumed. AJAX is assumed. Feeds are assumed. Performance is recognized as an issue (when isn't it). Identity is important, but as I think most feel about OpenID, they aren't sure what to do with it just yet.


tags: web 2.0  | comments: 11   | Sphere It
submit:

 
Previous  |  Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/5508

Comments: 11

  Joseph [05.18.07 04:00 PM]

The only problem is that with each new version Rails seems to run (even) slower.

Please stop adding these "nice to have" features and focus on what people need, speed. Work on JIT compilation. Make it at least comparable to Python. Why is that so hard?

  Tom [05.18.07 05:15 PM]

@Joseph: First of all, wrong audience. Rails is just an application that runs in Ruby. It is not Ruby. Join the Ruby lists for updates on YARV, and Ruby 2.0.

Python does not have JIT yet either. It appears faster than Ruby, I suppose. The Django framework is probably the most functionally comparable to Rails. Have you actually compared the speed of Django to Rails? The performance difference is probably not as great as you think.

  peterko [05.18.07 06:48 PM]

>The performance difference is probably not as great as you think.

@Tom: could you show us some proof?

here is something for starter:
http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

  Nicola Larosa [05.18.07 11:40 PM]

Actually, Python has had a JIT for years, Psyco.

Its author is also one of the author of PyPy, an ambitious project to implement Python in Python, with a number of different backends.

About speed, no need to suppose: the main Python implementation is, on average, faster than the Ruby one.

And Django is (probably, on the whole, IMO) better than Rails in many aspects, hype notwithstanding.

Disclaimer: I am a long-time Pythonista, and one of the organizers of the first Italian Python conference.

  Funny [05.19.07 12:45 AM]

Look at the photo. SNCF means Société Nationale des Chemins de fer Français (French National Railway Company). And the SNCF's TGV has set recently a world speed records.

  Tom [05.19.07 05:39 PM]

@peterko: As I said, the performance difference is not as big as you would expect (from all of the rhetoric). Rails is not the fastest and not the slowest.

But if programmers can develop programs in Rails quickly, does the framework performance really matter that much? Most web apps are re-written every couple of years (if they are even used that long). So code has to be written fast, debugged fast, and extended quickly.

But measuring developer productivity is rather subjective, and clearly developers like whatever language they like. So we are left with objective framework micro-benchmarks, and possibly prove nothing.

@Nicola Larosa: Psyco only supports 32bit i386, making it fairly limiting, and getting more so all the time. Would it even work under Mac OSX? Probably not. You'd probably have to build a 32bit Python binary yourself.

  peterko [05.20.07 09:09 AM]

@tim:
>Have you actually compared the speed of Django to >Rails? The performance difference is probably not >as great as you think.

you were talking about performance not developer productivity (performance-wise django/python is much faster than ruby/rails, that's a fact).

well, ruby is slow (and hence rails is slow, in fact rails 1.2 made rails even slower), if it does not matter for you (because you can buy enough hardware or my favorite, you can drop in C), it's obviously not a problem.


>Python does not have JIT yet either

as Nicola mentioned this is just not true (yes, psyco is not runnning on os x at the moment) but it exists, that was the point.

but if we are talking about developer productivity you are right, use what suits you the best.

peace

  Luke [05.21.07 11:51 PM]

If Django was being marketed as effectively as Rails, there wouldn't be so many Ruby and Rails fanboys out there. That I can tell you. Having worked in both Rails and Django, I have to say Django is significantly better. Number one reason? Faster development cycles. I'm not even talking about deployment. Rails/Ruby are slow to the point that development is a pain in the arse.

  James [05.22.07 12:57 PM]

It's not even about JIT (Pysco). Python is already faster because it compiles your .py file to byte code (.pyc).

"Psyco only supports 32bit i386, making it fairly limiting, and getting more so all the time. Would it even work under Mac OSX? Probably not."

LMAO. I can't recall seeing any kind of web app deployed on Mac OSX!

If you're using Mac anyway, you should probably be a designer, not a programmer...

  Jim [06.01.07 07:13 PM]

@james -> "If you're using Mac anyway, you should probably be a designer, not a programmer..."

Bro, a little VB or J2EE or whatever it is you think you do doesn't make you a programmer. Once you get hair on your balls we'll both look back at what you wrote and have a good laugh. :) In the meantime read this and lay off the pokemon.

  infrid [06.28.07 02:54 PM]

God, what terrible comments in this forum.

I truly would love to see what companies you work for so I can avoid them.

Narrow minded bigots the lot of you. It's very obvious you've jumped all over this.

This is why python doesn't get as much success as rails, because of you're bitching, moaning, whinging and hostility.

So you like python and Django, that's well and truly great. Go and post on python and djanog lists.

I came here looking for info on rails 2 and found this.

Look chaps, I don't go on your django news stories and bitch and act hostile, nor spread my own narrow mindedness around.

Great marketing boys. As it goes Django aint my cup of tea, but I'll certainly tell my friends considering it "the django community is represented by narrow minded loud mouth pricks.. steer clear"

pathetic.

Post A Comment:

 (please be patient, comments may take awhile to post)






Type the characters you see in the picture above.

RECOMMENDED FOR YOU

RECENT COMMENTS