"ruby on rails" with "ajax"
2005-09-02 17:03
561 查看
Ruby on Rails 跟 ajax 有一点联系,在 web development 中可以协同使用。
ajax的应用越加广泛,可以被整合到各种应用中,Ruby on Rails 可算一例。Ruby on Rails Koolaid, Redux
Excuse me for a moment while I eat crow with some humble pie for dessert... In February, after reading Curt Hibbs' Rolling with Ruby on Rails, I posted a blog entry titled Ruby on Rails Koolaid. That blog entry was based solely on Curt's article: I took issue with his assertion that development with Rails was at least 10 times faster than with any Java framework.
I took a fair bit of abuse for that post and it seems that even 6 months later, some folks are still upset with me. I must say though, that Curt has been most gracious even though I publicly disputed his claims.
In retrospect, my post was stupid and irresponsible. To publicly disparage claims about a framework I knew nothing about was wrong, not to mention just plain dumb, and to those I offended, I offer my sincere apologies.
So, with that out of the way, was Curt right? Is Rails development at least 10x as fast as your favorite Java web application framework? In a word: maybe. I would definitely agree with 5-10x as fast, but I'm not sure about numbers over 10. Note: my observations are based on about 1 month of Rails experience coupled with what I've read.
Why is development with Rails so much faster than with JSF, Tapestry, Struts, or whatever? The single biggest reason is zero turnaround time. You make changes to your application, refresh the browser, and voila, instantaneous feedback. For some, this might not be as appealing as it is for me. Coming from a SmallTalk background, I like to make tiny little changes quickly in succession. Some folks, like my friend Rob, who I worked with on my Cleveland job, like to write a ton of code before redeploying the app in the servlet container. In fact, I took quite a ribbing from Rob because I wasn't man enough to write large chunks of code at a time.
One thing that surprised me about Rails, once I started using it, was how robust it is. There are some very cool things in Rails: Active Record (Rails' ORM and the single biggest component of Rails) makes it drop-dead simple to write CRUD applications and from what I can tell, is robust enough to easily work with legacy databases; scaffolding gives you canned views and controllers, and although you will indeed replace nearly all of the generated scaffolding, it nonetheless provides a significant productivity boost; partial views are sort of Tiles-lite—you get ~70% of the functionality in Tiles (and SiteMesh, for that matter)—and partials are very simple to use (I've found that 70% to go a long way); convention over configuration lets you adhere to simple naming conventions instead of specifying tedious details in configuration files; 3 environments, one each for development, testing, and production, make each of those phases a little easier; testing baked into the framework makes it easy to implement tests, which means you're much more likely to actually write tests; and finally, Ajax support is absolutely killer in Rails.
Another thing that I didn't realize early on was how much Ruby shines through the Rails. With Ruby, you can, at runtime, add methods to classes, and Rails takes great advantage of this feature by stocking your models with methods that represent what's in database tables. That alone makes Rails very intuitive to use. And as I've said before, once you've been loosed from the confines of static type checking, you may never want to go back.
But of course, Rails is not perfect. For example, Rails suprisingly provides no built-in support for i18n or client-side validation. Yes, you can wrestle with get_text() and use that in conjunction with Rails to localize text, but who wants to endure that pain, not to mention, you've still got other i18n issues, such as unicode, localizing dates and times, etc. Frankly, I'm baffled by Rails' lack of support for i18n. Lack of client-side validation's not that big of a deal—especially now that we can easily use Ajax to validate w/o page refreshes—but lack of i18n support, especially in today's flat world, is hard to understand. And it's not like Rails users don't want i18n; I have recently witnessed Rails users drooling over the idea of resource bundles. Imagine.
And then there's the static type checking issue. I know some folks wouldn't dare to develop mission critical apps without stc, and I won't try to convince them otherwise (although the tight corset that Ada straps on wasn't enough to prevent the infamous Ariane 5 Rocket disaster). One thing about letting the wind blow up your skirt is that you've got to write tests. No choice, when things are this free and loose. Luckily Rails makes tests a breeze to write.
As most of you know, I was on the JSF 1.0 Expert Group, so you might be curious to know how I would compare Rails and JSF. We'll leave that to another post, or perhaps set of posts, but for now let me say one thing: JSF was created primarily for tool vendors, whereas Rails was created for developers. A fair percentage of what Rails does (perhaps 80-90%) could be implemented in a killer JSF-based IDE that featured incremental deployment, active record, etc., but we're simply not there yet in the JSF world. (Note: for Tapestry users, you might want to check out Trails. I haven't used it yet, but it looks interesting, although I'd rather do time in Jails
)
Everything Zen
Everything Zen
I don't think so
Everything Zen
from sixteen stone by Bush
ajax的应用越加广泛,可以被整合到各种应用中,Ruby on Rails 可算一例。Ruby on Rails Koolaid, Redux
Excuse me for a moment while I eat crow with some humble pie for dessert... In February, after reading Curt Hibbs' Rolling with Ruby on Rails, I posted a blog entry titled Ruby on Rails Koolaid. That blog entry was based solely on Curt's article: I took issue with his assertion that development with Rails was at least 10 times faster than with any Java framework.
I took a fair bit of abuse for that post and it seems that even 6 months later, some folks are still upset with me. I must say though, that Curt has been most gracious even though I publicly disputed his claims.
In retrospect, my post was stupid and irresponsible. To publicly disparage claims about a framework I knew nothing about was wrong, not to mention just plain dumb, and to those I offended, I offer my sincere apologies.
So, with that out of the way, was Curt right? Is Rails development at least 10x as fast as your favorite Java web application framework? In a word: maybe. I would definitely agree with 5-10x as fast, but I'm not sure about numbers over 10. Note: my observations are based on about 1 month of Rails experience coupled with what I've read.
Why is development with Rails so much faster than with JSF, Tapestry, Struts, or whatever? The single biggest reason is zero turnaround time. You make changes to your application, refresh the browser, and voila, instantaneous feedback. For some, this might not be as appealing as it is for me. Coming from a SmallTalk background, I like to make tiny little changes quickly in succession. Some folks, like my friend Rob, who I worked with on my Cleveland job, like to write a ton of code before redeploying the app in the servlet container. In fact, I took quite a ribbing from Rob because I wasn't man enough to write large chunks of code at a time.
One thing that surprised me about Rails, once I started using it, was how robust it is. There are some very cool things in Rails: Active Record (Rails' ORM and the single biggest component of Rails) makes it drop-dead simple to write CRUD applications and from what I can tell, is robust enough to easily work with legacy databases; scaffolding gives you canned views and controllers, and although you will indeed replace nearly all of the generated scaffolding, it nonetheless provides a significant productivity boost; partial views are sort of Tiles-lite—you get ~70% of the functionality in Tiles (and SiteMesh, for that matter)—and partials are very simple to use (I've found that 70% to go a long way); convention over configuration lets you adhere to simple naming conventions instead of specifying tedious details in configuration files; 3 environments, one each for development, testing, and production, make each of those phases a little easier; testing baked into the framework makes it easy to implement tests, which means you're much more likely to actually write tests; and finally, Ajax support is absolutely killer in Rails.
Another thing that I didn't realize early on was how much Ruby shines through the Rails. With Ruby, you can, at runtime, add methods to classes, and Rails takes great advantage of this feature by stocking your models with methods that represent what's in database tables. That alone makes Rails very intuitive to use. And as I've said before, once you've been loosed from the confines of static type checking, you may never want to go back.
But of course, Rails is not perfect. For example, Rails suprisingly provides no built-in support for i18n or client-side validation. Yes, you can wrestle with get_text() and use that in conjunction with Rails to localize text, but who wants to endure that pain, not to mention, you've still got other i18n issues, such as unicode, localizing dates and times, etc. Frankly, I'm baffled by Rails' lack of support for i18n. Lack of client-side validation's not that big of a deal—especially now that we can easily use Ajax to validate w/o page refreshes—but lack of i18n support, especially in today's flat world, is hard to understand. And it's not like Rails users don't want i18n; I have recently witnessed Rails users drooling over the idea of resource bundles. Imagine.
And then there's the static type checking issue. I know some folks wouldn't dare to develop mission critical apps without stc, and I won't try to convince them otherwise (although the tight corset that Ada straps on wasn't enough to prevent the infamous Ariane 5 Rocket disaster). One thing about letting the wind blow up your skirt is that you've got to write tests. No choice, when things are this free and loose. Luckily Rails makes tests a breeze to write.
As most of you know, I was on the JSF 1.0 Expert Group, so you might be curious to know how I would compare Rails and JSF. We'll leave that to another post, or perhaps set of posts, but for now let me say one thing: JSF was created primarily for tool vendors, whereas Rails was created for developers. A fair percentage of what Rails does (perhaps 80-90%) could be implemented in a killer JSF-based IDE that featured incremental deployment, active record, etc., but we're simply not there yet in the JSF world. (Note: for Tapestry users, you might want to check out Trails. I haven't used it yet, but it looks interesting, although I'd rather do time in Jails
)
Everything Zen
Everything Zen
I don't think so
Everything Zen
from sixteen stone by Bush
相关文章推荐
- RubyOnRails with Ajax
- RubyOnRails with Ajax
- ruby on rails 如何使用gem "twitter-bootstrap-rails"
- NetBeans Ruby on Rails中使用Ajax(一)
- RAILS 4 ON RUBY的AJAX实现过程
- [Ruby on Rails实战圣经]Ajax 应用程式
- ruby on rails ajax select
- NetBeans Ruby on Rails中使用Ajax(二)
- Building Dynamic Web 2.0 Websites with Ruby on Rails
- Installing Ruby and Railswith RVM on Fedora 14
- 在Ruby on Rails中使用AJAX的教程
- Ruby On Rails connect with MySQL
- Rolling On Rails With RubyStack
- RailsSpace: Building a Social Networking Website with Ruby on Rails
- Ruby on Rails安装过程中出现"no such file to load -- mkmf"错误的解决方法。
- [Ruby on Rails Issue] When Setting Sqlite version on the Gemfile, Show error "An error occurred while installing sqlite3 ",
- Ruby on Rails 使用 Ajax
- 用 Selenium 对 Ruby on Rails 和 Ajax 应用程序进行功能测试
- How to connect DB2 with ruby on rails 如何连接DB2数据库
- Ruby on Rails: "无法启动此程序,因为计算机中丢失LIBMYSQL.dll"问题解决