Why critics of Rails have it all wrong (and Ruby's bright multicore future)(unlimitednovelty.com)
unlimitednovelty.com
Why critics of Rails have it all wrong (and Ruby's bright multicore future)
http://www.unlimitednovelty.com/2012/03/why-critics-of-rails-have-it-all-wrong.html
126 comments
This is sadly too true. We have over a dozen Rails apps that need indefinite maintenance and we end up specifying explicit gem versions and/or burning lots of time just staying current. Still, it's better than everyone doing their projects in ad-hoc PHP.
and by the way, I can't recommend Node either. As far as I can tell, they're eagerly making these same mistakes.
Node is no panacea, but that's not quite true about stable APIs. npm is great about maintaining separately versioned libraries and reducing conflicts.
In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps.
Part of the reason this works is that the npms you install are kept in the local folder, not stored globally as many other package managers do, so some other random app on you box won't trample your delicate library configuration.
In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps.
Part of the reason this works is that the npms you install are kept in the local folder, not stored globally as many other package managers do, so some other random app on you box won't trample your delicate library configuration.
sure, but, if you chose to upgrade to Express 3.0.0, would your application still work? or are all the method signatures in Express 3 different from Express 2.5 ?
And (as you note above), is 2.5 still getting critical bug fixes? There's a thin line between stable and stagnant.
If you use ruby with bundler you get same behaviour. Something like bundler should have been built into rubygems in the first place.
I do understand the need to refactor and clean up code, however, there is a lot to say for at least deprecating things for a very long time as I find the current RoR far too volatile like you say. Unless you are doing prototypes, short lived sites OR have a fulltime team on it all the time (who upgrades to every small increment of every lib and fixes/refactors/tests the entire project), I don't like it so much. I have done and supported RoR projects and it really takes out the initial wins when you sit swearing behind your monitor because even trivial libs (for which, in fact, you already had to resist the urge not to roll your own) stop working after installing the latest and the greatest. Sure, then don't upgrade to the latest; for a lot of things that's not an option (security would be one, needing another feature this new gem has is another) and it should just give you a nudge 'this is deprecated, please fix' warning for the next year+ instead. If you didn't fix it by then, then at least you were warned plenty in advance.
To pour a little cool water on this bombastic post -- I have much love and respect for Rails. We (NYT Interactive News) continue to use it for nearly everything we build that requires a server-side component.
All I was trying to say (in a direct reply to Jeff) was that I think that putting Rails on hold for 2-3 years while merging in Merb (or the Merb team, depending on how you want to look at it) wasn't, in retrospect, a wise decision.
But that's old news, and doesn't need to be re-hashed now -- it's great to see Rails 4 starting to pick the pace back up, and exploring new features like improved streaming, granular cacheing, built-in queues, and more.
All I was trying to say (in a direct reply to Jeff) was that I think that putting Rails on hold for 2-3 years while merging in Merb (or the Merb team, depending on how you want to look at it) wasn't, in retrospect, a wise decision.
But that's old news, and doesn't need to be re-hashed now -- it's great to see Rails 4 starting to pick the pace back up, and exploring new features like improved streaming, granular cacheing, built-in queues, and more.
Jeremy, I think you know better, but you find this argument too convenient to give up. We did not "put Rails on hold". You could just look at the commit logs, but let me be more explicit.
* December 23, 2008: Merge announced
* March 15, 2009: Rails 2.3 released
* June 25, 2009: Rails XSS protection plugin for Rails 2.3 is released
* July 20, 2009: Rails 2.3.3 is released
* July 29, 2009: The first version of bundler (0.3.0) is released
* February 3, 2010: Bundler 0.9.0, the first "modern" version of Bundler, is released with support for Rails 2.3.5
* February 4, 2010: The first Rails 3.0 beta is released
* May 22, 2010: Rails 2.3.6 is released
* June 8, 2010: The first beta of Bunder 1.0 is released
* July 26, 2010: The first Rails 3.0 RC is released
* August 29, 2010: Bundler 1.0 is released
* August 29, 2010: The first Rails 3.0 final is released
As you can see, activity in Rails hardly ground to a halt during the time period we were working on Rails 3. We didn't even ship Rails 2.3 until three months after the merge, and continued active development for some time thereafter. And during this time, we backported two major new Rails 3 features, Bundler and Rails XSS, to Rails 2.3, actively releasing new versions of Rails 2.3 to take advantage of these backports.
Further, Rails 3 itself was a MAJOR feature release. Saying that Rails was "put on hold" for 2-3 (?!) years to merge in the Merb team is like claiming that Obama is going on an international apology tour. See below for a summarized list of important features.
I won't even talk about the improvements in Rails 3.1 or 3.2, which were possible because of the firmer footing we put the entire project as part of Rails 3 development. And this analysis doesn't even cover the major ways that the project structure changed during that time (full embrace of GitHub, significant increase in long-term contributors, acceleration of the guides project and other improvements to documentation).
---
Rails 2.3 was a major Rails release, with the following features:
* Completion of the Rack integration work begun earlier in the Rails 2.3 series
* Full integration of the Engines feature that was first softly integrated in Rails 2.2
* Localized views
* Support for public HTTP caching
* Ruby 1.9 support
* Nested Attributes (in both ActiveRecord and ActionView)
* Nested Transactions, even in MySQL
* A whole slew of other significant ActiveRecord improvements (http://guides.rubyonrails.org/2_3_release_notes.html#active-...)
* Unified rendering (render :foo, render "foo", etc.)
* HTTP Digest Auth
* Various performance improvements
* Rails application templates
* A whole lot else, see http://guides.rubyonrails.org/2_3_release_notes.html
---
Rails 3.0.0 was a major Rails release. Here are a few of the important features, but summarizing them all would be difficult:
* Incorporated direct support for Bundler, and drove the initial Bundler feature-set.
* Many architectural improvements, which drove improved, more stable third-party libraries in the Rails 3.x era (http://guides.rubyonrails.org/3_0_release_notes.html#rails-a...)
* A much bigger emphasis on eating our dog food: Rails 3 internals use exposed public APIs that any third-party extension can use. In fact, ActiveRecord itself is built as an extension!
* TMail, used by Rails 2.3, was unmaintained and extremely buggy (it often crashed when reading mail). The `mail` gem, written from Rails 3, is a ground-up rewrite.
* The ActiveRecord query interface is a night-and-day difference from the Rails 2.3 query interface. Users of ActiveRecord can now mix and match query parts (where clauses, group, order, limit) without having to worry about how to describe everything in terms of a single hash. This is probably the biggest change to the way developers use a major Rails component since the embrace of REST in Rails 1.2.
* ActionMailer finally got the update it needed. By Rails 2.3, ActionMailer had become a red-headed stepchild, sharing many features of the mainline render system on an ad-hoc basis. That meant inconsistencies galore. In Rails 3.0, ActionMailer got updated to share code and interface with ActionController, locking the two together to avoid another redheaded stepchild problem.
* Large improvements to Internationalization.
* ActiveModel makes it possible to use parts of ActiveRecord without using its SQL persistence layer. Apps have used this to spruce up plain Ruby objects, and libraries like Mongoid have used this to make alternate persistence libraries feel like the ActiveRecord people know and love.
* The router was completely rewritten, adding commonly requested features like the ability to match on any element of the request (commonly used for subdomain matching) and optional segments.
* The new ActiveRecord, ActionMailer and Router APIs maintained backwards compatibility with the older APIs until Rails 3.1 or 3.2, making upgrading plausible for more people.
---
Rails 2.3.3 was a minor update, with the following features:
* `touch` in ActiveRecord, to update a record's timestamp manually or automatically when associated records change
* Improved support for legacy schemas in ActiveRecord
* A general-purpose JSON encoding API and support for the `json` and `yajl` backends
* Other features: http://weblog.rubyonrails.org/2009/7/20/rails-2-3-3-touching...
Rails 2.3.6 through 2.3.9 (The Bridge to 3.0) was a significant update, with the following features:
* Direct support for the Rails XSS plugin
* Support for permanent and signed cookies
* Support for table-name-prefixes for all ActiveRecord classes in a module
* Lots of 3.0 ActiveSupport backports and improvements
* Improved support for Ruby 1.9
* See more at http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...
* December 23, 2008: Merge announced
* March 15, 2009: Rails 2.3 released
* June 25, 2009: Rails XSS protection plugin for Rails 2.3 is released
* July 20, 2009: Rails 2.3.3 is released
* July 29, 2009: The first version of bundler (0.3.0) is released
* February 3, 2010: Bundler 0.9.0, the first "modern" version of Bundler, is released with support for Rails 2.3.5
* February 4, 2010: The first Rails 3.0 beta is released
* May 22, 2010: Rails 2.3.6 is released
* June 8, 2010: The first beta of Bunder 1.0 is released
* July 26, 2010: The first Rails 3.0 RC is released
* August 29, 2010: Bundler 1.0 is released
* August 29, 2010: The first Rails 3.0 final is released
As you can see, activity in Rails hardly ground to a halt during the time period we were working on Rails 3. We didn't even ship Rails 2.3 until three months after the merge, and continued active development for some time thereafter. And during this time, we backported two major new Rails 3 features, Bundler and Rails XSS, to Rails 2.3, actively releasing new versions of Rails 2.3 to take advantage of these backports.
Further, Rails 3 itself was a MAJOR feature release. Saying that Rails was "put on hold" for 2-3 (?!) years to merge in the Merb team is like claiming that Obama is going on an international apology tour. See below for a summarized list of important features.
I won't even talk about the improvements in Rails 3.1 or 3.2, which were possible because of the firmer footing we put the entire project as part of Rails 3 development. And this analysis doesn't even cover the major ways that the project structure changed during that time (full embrace of GitHub, significant increase in long-term contributors, acceleration of the guides project and other improvements to documentation).
---
Rails 2.3 was a major Rails release, with the following features:
* Completion of the Rack integration work begun earlier in the Rails 2.3 series
* Full integration of the Engines feature that was first softly integrated in Rails 2.2
* Localized views
* Support for public HTTP caching
* Ruby 1.9 support
* Nested Attributes (in both ActiveRecord and ActionView)
* Nested Transactions, even in MySQL
* A whole slew of other significant ActiveRecord improvements (http://guides.rubyonrails.org/2_3_release_notes.html#active-...)
* Unified rendering (render :foo, render "foo", etc.)
* HTTP Digest Auth
* Various performance improvements
* Rails application templates
* A whole lot else, see http://guides.rubyonrails.org/2_3_release_notes.html
---
Rails 3.0.0 was a major Rails release. Here are a few of the important features, but summarizing them all would be difficult:
* Incorporated direct support for Bundler, and drove the initial Bundler feature-set.
* Many architectural improvements, which drove improved, more stable third-party libraries in the Rails 3.x era (http://guides.rubyonrails.org/3_0_release_notes.html#rails-a...)
* A much bigger emphasis on eating our dog food: Rails 3 internals use exposed public APIs that any third-party extension can use. In fact, ActiveRecord itself is built as an extension!
* TMail, used by Rails 2.3, was unmaintained and extremely buggy (it often crashed when reading mail). The `mail` gem, written from Rails 3, is a ground-up rewrite.
* The ActiveRecord query interface is a night-and-day difference from the Rails 2.3 query interface. Users of ActiveRecord can now mix and match query parts (where clauses, group, order, limit) without having to worry about how to describe everything in terms of a single hash. This is probably the biggest change to the way developers use a major Rails component since the embrace of REST in Rails 1.2.
* ActionMailer finally got the update it needed. By Rails 2.3, ActionMailer had become a red-headed stepchild, sharing many features of the mainline render system on an ad-hoc basis. That meant inconsistencies galore. In Rails 3.0, ActionMailer got updated to share code and interface with ActionController, locking the two together to avoid another redheaded stepchild problem.
* Large improvements to Internationalization.
* ActiveModel makes it possible to use parts of ActiveRecord without using its SQL persistence layer. Apps have used this to spruce up plain Ruby objects, and libraries like Mongoid have used this to make alternate persistence libraries feel like the ActiveRecord people know and love.
* The router was completely rewritten, adding commonly requested features like the ability to match on any element of the request (commonly used for subdomain matching) and optional segments.
* The new ActiveRecord, ActionMailer and Router APIs maintained backwards compatibility with the older APIs until Rails 3.1 or 3.2, making upgrading plausible for more people.
---
Rails 2.3.3 was a minor update, with the following features:
* `touch` in ActiveRecord, to update a record's timestamp manually or automatically when associated records change
* Improved support for legacy schemas in ActiveRecord
* A general-purpose JSON encoding API and support for the `json` and `yajl` backends
* Other features: http://weblog.rubyonrails.org/2009/7/20/rails-2-3-3-touching...
Rails 2.3.6 through 2.3.9 (The Bridge to 3.0) was a significant update, with the following features:
* Direct support for the Rails XSS plugin
* Support for permanent and signed cookies
* Support for table-name-prefixes for all ActiveRecord classes in a module
* Lots of 3.0 ActiveSupport backports and improvements
* Improved support for Ruby 1.9
* See more at http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...
> But that's old news, and doesn't need to be re-hashed now
Well gee Jeremy, thanks for rehashing it then! ;)
I work on a legacy Rails 2.x app at my day job. Wading through the alias_method_chain soup is not fun. I for one am glad the time was spent to eliminate the technical debt that came from too much feature push in earlier versions of Rails and an underemphasis on code quality. They now have a great foundation on which to add future features (which is more or less what you're saying at the end)
Well gee Jeremy, thanks for rehashing it then! ;)
I work on a legacy Rails 2.x app at my day job. Wading through the alias_method_chain soup is not fun. I for one am glad the time was spent to eliminate the technical debt that came from too much feature push in earlier versions of Rails and an underemphasis on code quality. They now have a great foundation on which to add future features (which is more or less what you're saying at the end)
I don't understand why you think Rails was on hold for all that time and that the modularity is not worth it. Yes it was a tremendous refactoring effort that took a lot of cycles, but Rails 3 has come out with great features.
I mean arel, unobtrusive js, bundler, routing API, and actionmailer overhaul just in 3.0. The asset pipeline, full engine support, modularity benefits such as pluggable ORMs and log subscribers. I find all this stuff to offer huge practical benefits on the ground.
For me the pain of Rails is mostly just the pain of Ruby—ie. it's slow, and concurrency is not really part of the DNA yet.
What are the killer features that Rails has neglected and caused it fall behind in your view?
I mean arel, unobtrusive js, bundler, routing API, and actionmailer overhaul just in 3.0. The asset pipeline, full engine support, modularity benefits such as pluggable ORMs and log subscribers. I find all this stuff to offer huge practical benefits on the ground.
For me the pain of Rails is mostly just the pain of Ruby—ie. it's slow, and concurrency is not really part of the DNA yet.
What are the killer features that Rails has neglected and caused it fall behind in your view?
It is worth pointing out that you're talking to the dude who wrote Jammit. The asset pipeline was not an innovation in or by Rails3.
The idea of asset packaging, of course, is not innovative. Jeremy's original claim was that Rails was put on hold. Integrating an asset pipeline solution into Rails took time and commits, and providing an ecosystem-wide solution for something like this has a strong impact on the overall productivity of the ecosystem.
I know who Jeremy is, and my question is legit. Innovation is a loaded term, and has nothing to do with the question of Rails stagnating. Rails is known for the nice packaging of good ideas, not for brand new ideas. I think you could argue the same about Node or 99.99% of all software since new ideas are extremely rare as are really good quality implementations.
So in all I seriousness, I want to know where he feels Rails is lagging.
So in all I seriousness, I want to know where he feels Rails is lagging.
I said exactly the same thing at the time. The Merb merge felt like it had a lot more to do with politics and ego than engineering. Unfortunately two years is a long time in this world.
I just want to chime in and say that you guys at NYT Interactive always inspire/blow-my-mind. Thank you for doing dataviz right.
I may be wrong but I can't help seeing a little anti-Katz bias there.
Beyond this 'cheap' psychological interpretation, I think the merb merge was mainly paying the huge technical debt 'young rails' contracted in its fast growth.
Rails 3 set the ground for the future. All big project go through this teenage phase, and if Rails 4 has so much potential today is because the 'alias_method_chain' and other quick hacks were cleaned out with well thought architectural principals - even though rack and streaming don't play well...
Oh god and I haven't read the whole post yet...
Beyond this 'cheap' psychological interpretation, I think the merb merge was mainly paying the huge technical debt 'young rails' contracted in its fast growth.
Rails 3 set the ground for the future. All big project go through this teenage phase, and if Rails 4 has so much potential today is because the 'alias_method_chain' and other quick hacks were cleaned out with well thought architectural principals - even though rack and streaming don't play well...
Oh god and I haven't read the whole post yet...
Having developed software on both Rails and Django, I prefer the latter. Reasoning: python's community seems more professional. They have well-defined language change and enhancement processes (the PEP), good docs online, almost every question imaginable has been answered already somewhere, and the performance ain't too bad.
Plus the code smell overall is just... lesser.
Then again, I came from a background of C and scheme, and somebody on c2 wrote that python appeals to people like me more.
Plus the code smell overall is just... lesser.
Then again, I came from a background of C and scheme, and somebody on c2 wrote that python appeals to people like me more.
Having moved from rails to django development the thing I am missing the most is the wide range of mature testing tools in the ruby ecosystem. Django's testing tools feel very primitive comparatively and there's no clear separation of unit, functional and integration tests.
I'd agree that in general the python community feels more professional and that the quality of documentation is typically better.
Last I checked out Django they had just added a bunch of features from Rails 1.2. (Edit: sorry, Rails 2.1)
Python suffers from their web framework community being too fragmented, so none of the projects are as mature as Rails.
Python suffers from their web framework community being too fragmented, so none of the projects are as mature as Rails.
I use Django for my projects and I don't share this opinion on the maturity aspect. Can you explain your statement a bit more? What aspects of Django are immature?
The release notes for Django 1.4, for example, list support for both Time Zones and Selenium.
Time Zones were added to Rails 2.1 in 2008. selenium-on-rails also debuted in 2008.
Does it not seem strange to you that it took 4 years after Rails for Django to get these features?
Time Zones were added to Rails 2.1 in 2008. selenium-on-rails also debuted in 2008.
Does it not seem strange to you that it took 4 years after Rails for Django to get these features?
There were plenty of extensions that allowed you to use Selenium with Django, I maintained one of them. Django is fairly conservative about including new features into the core that work well as extensions. And this is something I value a lot.
The time zone support, though, was really overdue.
The time zone support, though, was really overdue.
Really, if you wanna complain about something that's in Rails and not in Django properly, talk about database migrations.
South...but I agree that database migrations should be part of the Django core.
Not really a fair feature comparison. If db migration wasn't in Rails, ActiveRecord wouldn't work the way it does. You can't say the same about Django's ORM.
Also, the Django docs is awesome. Nothing gets into master without proper documentation.
"Modern HTML5/JS apps depend on beautiful, consistent RESTful JSON APIs."
"Rails is great for JSON APIs."
"Many of these companies have client-heavy HTML5/JS applications which consume a JSON API coming out of Rails. Many of them have APIs that are routinely cited as archetypical RESTful JSON APIs."
Rails is great for JSON RPC over HTTP. It's not great for beautiful, consistent RESTful APIs. It still lacks basic support for hypermedia. Without hypermedia you aren't being RESTful and you aren't reaping the benefits of being RESTful. All you have is a weak convention for doing RPC with HTTP methods.
None of those companies are examples of REST either, they're all doing JSON RPC, and propping them up as RESTful does a disservice to REST and a disservice to Rails. How can Rails make progress towards hypermedia APIs if people won't even acknowledge that it's lacking?
I know people like Steve Klabnik are valiantly trying to get Rails to adopt hypermedia, but it isn't there yet, and there are significant technical and political barriers to overcome.
Node.js frameworks, being in their relative infancy, aren't burdened with the same barriers as Rails and have the opportunity to move faster than Rails could. No framework has dominated the Node.js community like Rails dominates the Ruby community; there's still the opportunity for a Node.js framework for building hypermedia APIs to take center stage.
"Rails is great for JSON APIs."
"Many of these companies have client-heavy HTML5/JS applications which consume a JSON API coming out of Rails. Many of them have APIs that are routinely cited as archetypical RESTful JSON APIs."
Rails is great for JSON RPC over HTTP. It's not great for beautiful, consistent RESTful APIs. It still lacks basic support for hypermedia. Without hypermedia you aren't being RESTful and you aren't reaping the benefits of being RESTful. All you have is a weak convention for doing RPC with HTTP methods.
None of those companies are examples of REST either, they're all doing JSON RPC, and propping them up as RESTful does a disservice to REST and a disservice to Rails. How can Rails make progress towards hypermedia APIs if people won't even acknowledge that it's lacking?
I know people like Steve Klabnik are valiantly trying to get Rails to adopt hypermedia, but it isn't there yet, and there are significant technical and political barriers to overcome.
Node.js frameworks, being in their relative infancy, aren't burdened with the same barriers as Rails and have the opportunity to move faster than Rails could. No framework has dominated the Node.js community like Rails dominates the Ruby community; there's still the opportunity for a Node.js framework for building hypermedia APIs to take center stage.
there's a gem called roar that's been around for a while for producing hypermedia in ruby. there's also a roar-rails gem specifically for integration with rails.
Biggest gripe I had with rails is its learning curve. I have started to read Michael Hartl's impressive tutorial book but gave up when I started to deal with errors related to gemfile dependencies (if the versions do not match with the tutorial the expected outcome does not happen at best or you deal with errors at worst). I have bought Agile Web Development with Rails and thinking to start again because it is really new and I don't believe I'll encounter any problems. What do you do when you encounter such errors by the way?
The Rails Tutorial is at least as up-to-date as Agile Web Development with Rails. For example, two weeks ago I bumped the version of RSpec used in the tutorial, fixing a few minor bugs in the process. Just be sure to use the online version at http://railstutorial.org/book or the most recent ebook from http://railstutorial.org/ so that you get the freshest copy.
If you use the Gemfile at http://railstutorial.org/gemfile in a clean Ruby environment and run bundle install, the issue of dependencies shouldn't even come up. If you continue to have trouble, drop me a line at [email protected].
If you use the Gemfile at http://railstutorial.org/gemfile in a clean Ruby environment and run bundle install, the issue of dependencies shouldn't even come up. If you continue to have trouble, drop me a line at [email protected].
Run `git blame` on the code pathway that's throwing the exception (in the gem.) Look at the changes that have occurred on it and either move back to a version of the gem that works, or change my code to suit the new version.
Alternatively, look at the changelog or just manually decrement the version number until my tests pass, obviously taking care not to move back past any critical security updates.
Also, the precise version numbers used in railstutorial are available in the code listings here: https://github.com/railstutorial/sample_app_2nd_ed/blob/mast...
The (fast paced|aglie|slapdash) nature of the rails ecosystem does necessitate a certain degree of attention to detail when it comes to versioning. However this applies equally to sinatra. It's worse with node.
Alternatively, look at the changelog or just manually decrement the version number until my tests pass, obviously taking care not to move back past any critical security updates.
Also, the precise version numbers used in railstutorial are available in the code listings here: https://github.com/railstutorial/sample_app_2nd_ed/blob/mast...
The (fast paced|aglie|slapdash) nature of the rails ecosystem does necessitate a certain degree of attention to detail when it comes to versioning. However this applies equally to sinatra. It's worse with node.
Thank you. Far as I understood there is no easy way to handle those errors. I'll take your comment into consideration when I start to learn it.
Use the source, luke!
but I shouldn't get cocky, eh? :)
In case it wasn't clear, that aphorism is supposed to be telling you to get into the habit of reading the source code of the libraries you use. It is often the fastest way to solve your problems, and you'll learn a lot about the lib and about the language in the process.
Without the ability to do this one can only be a plumber fitting other peoples' appliances.
Without the ability to do this one can only be a plumber fitting other peoples' appliances.
Han Solo says, "Don't get cocky, kid," to Luke.
For me, the biggest problem with rails is that it boots really slow on development so it's really boring.
I switched to padrino a while ago due to this issue. Also I prefer padrino's router since it's more explicit.
Seriously? How often do you need to reboot Rails? In dev mode it reloads code as it's changed, so pretty much the only time you need to reboot Rails is when you change the configuration or update your gems. Maybe once a week, say. The startup time is a couple of seconds, so you switched frameworks to save a couple seconds a week. Hardcore.
heh. running specs requires to boot rails, starting the console, switching branchs, reviewing code, etc...
rails boots fast if you have few files but when the project is big it is a pain, it takes a lot of time to boot and it's not fun. That's why the article says rails is "a day job".
I just hope the rails team don't think like you.
rails boots fast if you have few files but when the project is big it is a pain, it takes a lot of time to boot and it's not fun. That's why the article says rails is "a day job".
I just hope the rails team don't think like you.
You don't need to restart the rails app when running specs if you use spork. Also ruby 1.9.3 vastly improved rails application boot times over 1.9.2, just in case your slow experience was with 1.9.1.x - 1.9.2.x.
Spork's a fine notion, but it's no panacea. Pretty regularly we would be running down some weird bug only to discover that we had to restart. It doesn't take a lot of 10-minute debugging excursions to eat up all the time that Spork saves on starting tests.
The boot times is one of the main reasons rails feels like a day job for me. It is there for every rake task, every time I need to generate a migration, every time I need to use the console. All this waiting makes me lose my flow and forget what I was doing.
You should check out Zeus (https://github.com/burke/zeus). "Boot any rails app in under a second". It'll use more memory, unless you want to GC-patch your ruby (instructions in the repo).
yeah already saw it, but why are these hacks needed in first place?
I am pretty sure there's a good way to fix rails to load faster in a reasonable amount of time (again, I am talking about big projects).
Extensive work has already gone into improving Rails startup time. If you want to further improve it, try removing railties you aren't using.
6 month old flame bait dug up and reaired as more flame bait.
I feel I've been struggling with Rails for a while now, at the time I've got excited about the promise Merb brought, but the merge hasn't noticeable changed the way I work. Mountable engines seems like a big hack to me and I some times struggle with class reloading in development because of it. Sinatra got mountable apps from the beggining because of being closer to rack, one could just us rack mount to inclue another app. I worked for a while on a big Sinatra app and it was a pleasant experience allthough Sinatra provides too little, but latelly I started a personal project on Padrino and a found a joy I havent felt in a wile using the languaje and tools I learned to love, Padrino is like I've allways wanted Rails. I am gratefull of what Rails has taught me, but I want to get off the bandwagon, Rails has grown to big and complex for my taste.
Jose Valim heard about people avoiding Rails thanks to it not having a Sinatra-like routing syntax, and he just decided to code one up:
https://gist.github.com/3717973
https://gist.github.com/3717973
> Meanwhile, Node.js is the new hotness, and many in the Node community have sought to build Node up by bringing Ruby and Rails down
This is exactly what the Rails community did to PHP when Rails was the new hotness.
This is exactly what the Rails community did to PHP when Rails was the new hotness.
Java is the better analogy. Rails is now a mature enterprise-worthy framework, but it suffers in some basic areas that Node handles well despite a relative lack of maturity.
> Java is the better analogy
Agreed, good catch.
Agreed, good catch.
Shouldn't this be listed on http://rubydramas.com/? Name-calling, platform bashing... Why can't we just get along?
I read this article a few weeks ago as a result of Tony writing "debunking the Node.js gish gallop" in response to my "Rails, Node, and the web apps of today" blog post.
I have a response coming in the next week/2 weeks, so I won't go into much here, but I will say that Tony's efforts to defend Rails are admirable; despite some snarkiness and elements of being reactionary, he raises good points in his posts.
One quick question. Tony, what are your thoughts on Elixir?
I have a response coming in the next week/2 weeks, so I won't go into much here, but I will say that Tony's efforts to defend Rails are admirable; despite some snarkiness and elements of being reactionary, he raises good points in his posts.
One quick question. Tony, what are your thoughts on Elixir?
I'm friends with Jose and quit developing my language Reia because I thought Elixir was better. I've since gone on to develop Celluloid and haven't looked back ;)
I use Rails for most projects. It has its warts and there are many things I dislike about it. I also like node, but after experiencing the sad state of nearly ever node module I tried, I came to the conclusion that the ecosystem is just not there yet. If you want to start from scratch, node may be the way to go. If you like leveraging existing code, node can be hell.
Thankyou for this!
2013 is the year of rails on multicore.
No other programming community on the planet cares so much about how they're perceived.
I suspect there's a silent majority...
I suspect there's a silent majority...
Any new and active programming community should be vocal, and node is no different. In fact, both node and rails have very loud supporters and detractors (IE, you).
I don't think loud people contribute to the health of a community. In fact, I consider it a "community-smell" - when there is too much incentive to be a "rockstar", too many people will focus on being rockstars and not enough will be focus on actually getting the job done.
Right, totally agree, in the Enterprise Java world (love Java, can't stand the enterprise connotation) things ran a muck and we ended up with J2EE. Spring isn't better only different. Too loud voices in any camp just mess things up, then they move on and we are left to sort things out.
When it came out, Spring was massively different from J2EE. "J2EE Development without EJB" was mindblowing for the Enterprise community back in 2004
This is a classic problem among engineers. The notion of bloat and cruft that goes unsubstantiated, and is really code for 'new and shiny'.
Older software projects offer more features, but that doesn't mean they're materially slower or worse in any objective way.
We use Rails at Pose to deliver JSON to over 1M users on either Android, iPhone, or our Backbone Web UI. It works well, it scales, and it's clean. No complaints.
Older software projects offer more features, but that doesn't mean they're materially slower or worse in any objective way.
We use Rails at Pose to deliver JSON to over 1M users on either Android, iPhone, or our Backbone Web UI. It works well, it scales, and it's clean. No complaints.
Yeah. Just read the top comment (as I write this): "You don't need all the ceremony and structure of Rails and MVC."
I think the problem with this outlook is that you don't need it...until you, you know, need it. Rails has a lot of niceties that you lose with Sinatra. Why not start from a superlight Rails app (using any of the many gems or ActionController::Metal options) and then add on bits and pieces when you need one? I think that this method is either just too difficult for some people to wrap their heads around or it offends their sensibilities as a programmer.
I've had too many personal Sinatra projects that have bogged down when I started reimplenting Railslike functionality.
I think the problem with this outlook is that you don't need it...until you, you know, need it. Rails has a lot of niceties that you lose with Sinatra. Why not start from a superlight Rails app (using any of the many gems or ActionController::Metal options) and then add on bits and pieces when you need one? I think that this method is either just too difficult for some people to wrap their heads around or it offends their sensibilities as a programmer.
I've had too many personal Sinatra projects that have bogged down when I started reimplenting Railslike functionality.
For me personally it's because Rails is so fucking slow these days. That's it, I don't mind having all that structure and ceremony sitting there. It doesn't stop me from architecting things however I please in lib/ and app/models/. But when it takes seconds for a brand new app to run `rake -T` it forces me to look for speedier alternatives. Speed will probably be what ultimately pushes me off Ruby as my bread and butter for good some day.
Do not blame ruby for the failings of rails.
Personally I have never had any problems with speed when developing large projects with Ramaze, Sinatra or Padrino. In my experience this only happens to Rails. No clue why though. Maybe some gems used by Rails take too long to load.
Personally I have never had any problems with speed when developing large projects with Ramaze, Sinatra or Padrino. In my experience this only happens to Rails. No clue why though. Maybe some gems used by Rails take too long to load.
Ah but if Ruby were faster Rails would be faster. Whether it's possible to do less and be acceptably fast is besides the point, I like Rails.
rake -T One second for me running Ruby 1.9.3p125 with Rails 3.2.8.
To solve this problem is why Padrino was created. Padrino is a collection of "Railslike" functionality for Sinatra. So either start with a Sinatra project and then pick stuff from Padrino or start with Padrino in the first place. Padrino is highly modular.
I have no complaints about Rails.
What you said about bloat and cruft is partly true. But there are other things which sometimes substantiate it - boilerplate and cognitive overhead, for example; sometimes older things have more of these than necessary, and are kept anyway because of their maturity and usefulness (and because a community has already developed which fit its brain to the project and has memorized the quirks already).
That is a good reason to keep the old thing, but it does not mean that the older thing is always optimal or even better than a newer thing.
What you said about bloat and cruft is partly true. But there are other things which sometimes substantiate it - boilerplate and cognitive overhead, for example; sometimes older things have more of these than necessary, and are kept anyway because of their maturity and usefulness (and because a community has already developed which fit its brain to the project and has memorized the quirks already).
That is a good reason to keep the old thing, but it does not mean that the older thing is always optimal or even better than a newer thing.
I love Ruby, but I have no love for Rails. Want to write a nice JSON API using something light and nice? Use Sinatra, pick your favorite ORM (even ActiveRecord) and go to town. Why mess with all the other Rails junk when you can have a simple app.rb for your sinatra app and just write simple little controller actions and you're good to go?
You don't need all the ceremony and structure of Rails and MVC to write a JSON api, you just don't.
Worrying about Rails' future and if it's still "winning"(for some definition of winning?) compared to node.js is silly and reminds me of how many Java devs had an existential crisis about the future of Java since Java 7 took a few too many years to ship.
Rails is a web MVC framework, that's it. It's not even the only or best web framework in ruby. Rails is not ruby. It is not designed to compete with node. Node is a totally different thing.
Compare node and ruby and that's a more interesting and correct comparison, but I've happily used both and neither one is going to "kill" the other any more than Rails killed PHP or Java killed C++.
You don't need all the ceremony and structure of Rails and MVC to write a JSON api, you just don't.
Worrying about Rails' future and if it's still "winning"(for some definition of winning?) compared to node.js is silly and reminds me of how many Java devs had an existential crisis about the future of Java since Java 7 took a few too many years to ship.
Rails is a web MVC framework, that's it. It's not even the only or best web framework in ruby. Rails is not ruby. It is not designed to compete with node. Node is a totally different thing.
Compare node and ruby and that's a more interesting and correct comparison, but I've happily used both and neither one is going to "kill" the other any more than Rails killed PHP or Java killed C++.
I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails.
Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.
This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.
Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.
This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.
My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it...
However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.
I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.
But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.
Great when building but it sucks when debugging and maintaining.
However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.
I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.
But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.
Great when building but it sucks when debugging and maintaining.
The more abstraction you shove down the programmer's throat, the less he will understand what's really going on behind the scenes. Eventually the abstractions become more of an impediment than a panacea, e.g. when you try to do simple things. And we also end up with the creation of "leaky abstractions", since programmers who create them have developed a love for abstraction (what might contribute to that?) but little understanding of the lower levels.
There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.
There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.
Do you think that a "legacy" Node(or Sinatra for that matter) app will be easier to understand than a "legacy" Rails app?
Legacy is where conventions actually shine!
Padrino (www.padrinorb.com) is a sinatra-based 'rails without the bloat' framework.
It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!
But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.
It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!
But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.
I agree that the total lack of structure in Sinatra can be harmful at times, but don't blame a technology for your team problems.
That's just the bad workman blaming his tools for the faults of the toolbags he works with.
That's just the bad workman blaming his tools for the faults of the toolbags he works with.
Blaming the tools is completely reasonable if your problems can be solved by better or more appropriate tools. If I need to drill a hole precisely and accurately and the team or management has standardized on hand drills, it's entirely appropriate to bemoan the use of hand drills versus a proper drill press with an appropriate jig.
Oh you guys/gals and your programmer to carpenter analogies :)
yeah what can be wrong about a framework imposing design & coding discipline on sheeple :P
"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs.
Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go?
You don't need all the ceremony and structure of Sinatra to write a JSON API, you just don't.
Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go?
You don't need all the ceremony and structure of Sinatra to write a JSON API, you just don't.
You're absolutely right, you don't need Sinatra to write a JSON API either. The more ruby devs that realize this the better. Really, just people getting out of the mindset that Rails is the be all end all of ruby is all I'm going for.
You cannot really compare Sinatra with Rails. Rails has scaffolding, DB migrations and all this ultra-highlevel stuff rendering debugging to pure guess-work. Reminds me of doing template-metaprogramming with C++. If it works it's great and the performance rocks, if not you are left alone with cryptic errors and nobody can help you.
If you want Sinatra with scaffolding there is Padrino which I personally find to have superior scaffolding compared to rails.
Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd.
One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again.
And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects.
So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.
One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again.
And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects.
So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.
Unless I vastly misunderstand your statement, it's nowhere nearly that hairy.
https://gist.github.com/3719513
Did I miss something?
Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework.
My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.
https://gist.github.com/3719513
Did I miss something?
Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework.
My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.
I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites.
I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams).
But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.
I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams).
But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.
I absolutely agree with you. What sticks in my craw is the oft-repeated mantra that "Rails is too heavy" or the perception that Sinatra is doing something that Rails isn't.
When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use.
I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.
When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use.
I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.
Sinatra has a lot less boilerplate than the typical Rack app.
Because it has a lot more "ceremony and structure". Sinatra is a Rack app. It hides the raw boilerplate from you just like Rails hides a lot of the boilerplate you end up putting into a Sinatra app of any significant size.
There's a continuum of "more manual work" <----> "more framework", and there's no one right answer, even for something like a JSON API.
There's a continuum of "more manual work" <----> "more framework", and there's no one right answer, even for something like a JSON API.
Rails is a Rack app too. While I agree there are diminishing returns the lower in the stack you go, your original reduction is misleading.
The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.
The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.
FTA: https://gist.github.com/1942658
Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?
Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?
Agreed, when you want to build an API use Sinatra, and when you want to do web MVC there is Padrino which turns Sinatra into a very competent MVC framework.
I've used Padrino for a couple of projects now, but unfortunately it slips into "Uncanny Valley Rails" territory (particularly when it comes to the rake tasks you expect to have but turn out to be missing, eg. db:test:prepare).
I really enjoy Sinatra and am indeed using it for REST style API hosting, but the counter argument might be all the security stuff that is built into the Rails routes/controllers. this might be a great case for a stripped down rails app as opposed to a Sinatra app.
I thought most of the security in Rails is provided by the rack-security middleware? Or am I forgetting something which Rails provides here?
Escaping everything by default to avoid XSS attacks. that's a nice feature to have.
This can be done in Sinatra: http://www.sinatrarb.com/faq.html#auto_escape_html
Cheez, the reason to not use Sinatra for me is that I'd have to implement all the security measures myself. Sure for a hobby project or a really simple project it might be OK. I guess it all depends on what budget you have for spending time re-implementing all the plumbing.
https://github.com/spastorino/rails-api
Problem solved.
Problem solved.
"Rails is great for JSON APIs"
Rails is good for simple APIs (especially adding an API to an existing HTML site).
However, if you want to do more than that, elegantly - it isn't great yet. You quickly end up with some fairly messy serialization hacks and confusion between what should sit in the controller and the model.
The active_model_serializers gem is a really good start, but there is a way to go to get to the level of convention the rest of Rails provides.
Soon it will be great I have no doubt and the convention/stability of Rails will lead a lot of businesses to start using it.
Rails is good for simple APIs (especially adding an API to an existing HTML site).
However, if you want to do more than that, elegantly - it isn't great yet. You quickly end up with some fairly messy serialization hacks and confusion between what should sit in the controller and the model.
The active_model_serializers gem is a really good start, but there is a way to go to get to the level of convention the rest of Rails provides.
Soon it will be great I have no doubt and the convention/stability of Rails will lead a lot of businesses to start using it.
Why not use a format-specific DSL, like DHH does with jbuilder?
That's not messy at all, it's basically just another TemplateHandler.
That's not messy at all, it's basically just another TemplateHandler.
Or RABL if you want both XML and JSON output
Or XSLT if you want both Oracle and IIS at the same time
That sounds horrible.
I do agree that the way to provide APIs has been poorly conveyed by the core members. All of the samples end up amounting to:
render :xml => @objects
Use decorators. Draper is my personal favorite, and it very cleanly solves the issue of serialization nightmares and controller/model confusion.
(I hope that it ends up in the Rails core someday, because it really is a gamechanger in how Rails is used for non-HTML content!)
(I hope that it ends up in the Rails core someday, because it really is a gamechanger in how Rails is used for non-HTML content!)
Agreed, Draper + Jbuilder and you got yourself plenty of decoupling and beauty.
> Edit: Contrary to what I said here, José Valim is not stepping down from Rails core, he is merely on sabbatical. My bad.
And then later in the article...
> Jose Valim, (now former) Rails core member,
When you have to issue a retraction, you should update the article. The way the Times does it is to make the edit and then put a small note at the end of the article recording the original error. Like so: http://well.blogs.nytimes.com/2012/09/10/early-music-lessons....
And then later in the article...
> Jose Valim, (now former) Rails core member,
When you have to issue a retraction, you should update the article. The way the Times does it is to make the edit and then put a small note at the end of the article recording the original error. Like so: http://well.blogs.nytimes.com/2012/09/10/early-music-lessons....
Either way is valid. This way, you don't change the text you originally wrote, which some might view as more honest, and in addition the reader is warned in advance that there's an inaccuracy. As long as they can't come away with the wrong impression, the update's good.
> Meanwhile, Node.js is the new hotness, and many in the Node community have sought to build Node up by bringing Ruby and Rails down.
And this post attempts to return the favor?
> Node is three years old now. Where are the Node.js success stories? Who's built a brand on top of Node?
> Meanwhile code quality is de-emphasized and large Node programs degrade into incomprehensible, byzantine structures of callbacks and flow-control libraries
Edit: added examples. The whole post is as much an attack on Node as it is a defense of Rails.
And this post attempts to return the favor?
> Node is three years old now. Where are the Node.js success stories? Who's built a brand on top of Node?
> Meanwhile code quality is de-emphasized and large Node programs degrade into incomprehensible, byzantine structures of callbacks and flow-control libraries
Edit: added examples. The whole post is as much an attack on Node as it is a defense of Rails.
I agree a lot with this but it contains its own absolutely huge non-sequitur: How on earth is Cramp an example of damn simple websockets in Rails? It's Ruby, not Rails.
It's also probably worth mentioning that it literally only works with Thin, is unmaintained, largely undocumented, and that the latest master on GitHub doesn't actually work. Not really the best example to pick!
It's also probably worth mentioning that it literally only works with Thin, is unmaintained, largely undocumented, and that the latest master on GitHub doesn't actually work. Not really the best example to pick!
There's also faye with faye-rails
https://github.com/faye/faye
http://faye-rails.sociable.co.nz/
https://github.com/jamesotron/faye-rails
https://github.com/faye/faye
http://faye-rails.sociable.co.nz/
https://github.com/jamesotron/faye-rails
Cramp is based on Rack, just like Rails... there is nothing stopping you from using the two in conjunction.
Well, no. But if someone said "CodeIgniter sucks" and the counter-argument was "No it doesn't, there's this great framework called Symphony" you'd probably take issue with that, no?
As far as using websockets with Rails goes, I just wanted to mention that I've been having a really good experience using the websocket-rails gem (https://github.com/DanKnox/websocket-rails) in a text game (MUD) I'm working on as a Rails 3 app.
A Rails-powered MUD? You're doing God's work, son.
That sounds amazing! When you've got this MUD on Rails going, please do submit it here. Similarly, I'm working on a MCaaS (MUD Client as a Service ;]) half tongue-in-cheek to learn more about Node. There's no feeling like using new & exciting tech to solve the problems of our neckbearded forefathers.
That sounds cool too, have a demo up anywhere? I'm kinda doing a deploy as I code thing, I've added the url to my profile.
There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade the gems, your code will stop working, because most of the gems will have changed their public API. If you've got a non-trivial application, you will essentially be unable to upgrade. You will stop getting security updates. What minor upgrades you can manage to do will leave things partially broken, and you'll just get used to it being broken. (for example, one project I've worked on is stuck with a brain-damaged RSpec library that reports error messages without interpolating the strings, you always get "Expected CONDITION, got FAILURE, see CODE" in the logs)
My recommendation: only use Rails for short term projects that will be completely shut down after a few months.
I know that it's common wisdom that "no ruby engineer will ever want to switch to java", but that's because you've never been saddled with a 2-year-old rails project (or a 5-year-old plain-ruby project, which will have the same symptoms, just more slowly). Then your team will be begging for something that runs its test suite quickly, that has enough static analysis to know if you're using an outdated API, that has a decent metrics library, where you can query the state of the VM, that doesn't constantly leak memory, that plays nicely with databases that have real constraints, that has fewer race conditions in common libraries, etc etc etc.