5 ms·

This is why I like the Clojure community, which in this regard is very different from Rails. Clojure has developed a culture that favors small libraries over mo

This is why I like the Clojure community, which in this regard is very different from Rails. Clojure has developed a culture that favors small libraries over monolithic frameworks. The eco-system of Clojure is all about picking and choosing among a variety of tasty dishes, which is the exact opposite of this: "Rails is not that. Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere." The folks who like omakase are of course free to enjoy Rails. More power to them. I personally learn more, and enjoy more, when I get to assemble a different menu for each project -- a menu suited to the project.

malandrew 14y ago
Same with the Node.js community. When I moved from Rails to Node.js, the focus on small libraries held together by an exceptional package manager was a huge breath of fresh air. If anything, Rails poisons things in the Ruby community because the monolithic approach of the biggest framework in the community simply works against small libraries with small interfaces that are very compatible and remixable. In fact, one of the best developments in the Ruby community lately has been the increase of other frameworks like grape, padrino, rack, sinatra, etc. I know some of these have been around for a long time, but it wasn't until Rails started getting long in the tooth that they started getting more and more attention.
- mylittlepony 14y ago
  Same with Symfony2. All of its components are decoupled and can be used as standalone libraries. They even have their own separate docs.
- phillmv 14y ago
  You really can't lump Rack in there, given that it's a meta framework, and a meta framework to which Rails has been built around since 2.3.
- deleted 14y ago
  [deleted]
phillmv 14y ago
Rails has a lot of moving parts, which is certainly daunting for the beginner, and having worked in it professionally for three or however many years it's been I have a certain cognitive bias going on here but bear with me: What part of Rails is… monolithic? I don't understand this complaint. Rails 3 these days is pretty modular. For the same reason I can't stand Sinatra et al; two-to-four hours into most projects I find myself saying "Oh yeah, I could really use an ORM, and some route helpers, and a view layer would be nice and how do I get this testing framework to play nice?" and before you know it you've wasted more time trying to cobble something together.
- nahname 14y ago
  The prevention of bikeshedding is one of rail's greatest strengths.
- vidarh 14y ago
  After you've done it once or twice, you will have a list of the components you prefer and that works for your style, as a starting point. I find that for my personal projects, that list is very different both in size and contents of what Rails pulls in. Another big difference to me is coupling: In theory Rails might be modular, but because of what Rails is, while you may be free to tear out ActiveRecord for example, it takes very little before you're knee deep in dealing with shit from 3rd party code that assumes the default stack. If you can't rely on all the Rails plugins and extensions, and you want to replace a major component of Rails, then there's suddenly a lot less reason to use it at all.
steveklabnik 14y ago
These days, Rails is very much pick-and choose: https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api and https://gist.github.com/1942658#file-config-ru https://gist.github.com/1942658#file-config-ru
edwinnathaniel 14y ago
Sounds like the trend is to follow Java (to certain extend, if you ignore the debacle of the old J2EE, Struts, and Tapestry). ORM? Hibernate or JPA2 can be run anywhere: inside or outside container (i.e.: desktop app, web-app, or simply daemon/service) DI? Spring or CDI Unit-test? JUnit or TestNG or others Mocking? EasyMock, Mockito Message Queue? Pick one out there Templating? JSP, JSF(ish), Velocity, FreeMarker. RESTful? Restlet, Jersey Everybody plays well with one and the other.
- lkrubner 14y ago
  Not exactly. The current trend is towards the JVM, but not Java. I wrote about this last week: http://www.smashcompany.com/technology/the-jvm-is-part-of-a-world-wide-conversation http://www.smashcompany.com/technology/the-jvm-is-part-of-a-... Even the cutting edge of Ruby is now on the JVM, as Rubyists see a need for threads and find jRuby the most convenient way to move forward: http://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto... Rails took off in 2004 as a rebellion against the overly-heavy Java frameworks like Struts. But now what good ideas Rails offered have been incorporated into languages that run on the JVM, and a lot of innovation, in particular with concurrency, is happening on the JVM, and some of those things are areas where Ruby (other than JRuby) is weak.
  - edwinnathaniel 14y ago
    I see 2 trends here: Trend #1: modular components Trend #2: platform (performance optimization as well) What you described falls into #2 while what I refer to falls into #1.
Xylakant 14y ago
You're comparing a language to a framework. Rails is but one of rubys web-frameworks. There's sinatra and built on top of that padrino. There's camping, static page generators like octopress and that's just the web-world. Even rails is not a monolithic bloc: You can use activerecord or activesupport as libraries and rails itself uses a ton of libs itself. The ruby community values small libraries that can be plugged together to a bigger whole - and rails is basically a very opinionated collection of libraries with some glue code (and magic) to form a cohesive API. It's good for some kind of projects and it's certainly the oldest and biggest ruby framework, but it's by far not the only one.
freshhawk 14y ago
But for agency type developers, where you are working on many different crud websites at once, you have different needs from a framework. If you are starting your own startup then clearly you want to pick the individual libraries that best suit your problem. You have to deal with them for a long time and the payoff from a small improvement gets large. You write a little glue code and you are good to go. If you are working on a large number of CRUD sites all the time then you want a stable set of libraries that cover most of the problems you will encounter and having scaffolding and other glue code replacing mechanisms is preferrable, even if they aren't as flexible or efficient or elegant as could have been done manually. When you write the same glue code over and over again you end up automating it, and generalizations have tradeoffs. There is really no comparison between the framework needs of single site developers and developers working for a web agency or who are working on many sites or spinning up a few new sites a month.
zem 14y ago
there's sinatra and padrino for the pick-and-choose way. rails expresses the philosophy that it's more productive to pick a stack and stick to it, and then let the ecosystem optimise itself against that stack. it's true that the ruby webdev community has tended to coalesce around rails rather than sinatra, but that's because the rails community has solved a lot of genuine real-world problems that keep cropping up in its target space and has been able to write them as libraries that will work with anyone's rails setup.

malandrew 14y ago

Same with the Node.js community. When I moved from Rails to Node.js, the focus on small libraries held together by an exceptional package manager was a huge breath of fresh air. If anything, Rails poisons things in the Ruby community because the monolithic approach of the biggest framework in the community simply works against small libraries with small interfaces that are very compatible and remixable. In fact, one of the best developments in the Ruby community lately has been the increase of other frameworks like grape, padrino, rack, sinatra, etc. I know some of these have been around for a long time, but it wasn't until Rails started getting long in the tooth that they started getting more and more attention.

mylittlepony 14y ago
Same with Symfony2. All of its components are decoupled and can be used as standalone libraries. They even have their own separate docs.
phillmv 14y ago
You really can't lump Rack in there, given that it's a meta framework, and a meta framework to which Rails has been built around since 2.3.
deleted 14y ago
[deleted]

phillmv 14y ago

Rails has a lot of moving parts, which is certainly daunting for the beginner, and having worked in it professionally for three or however many years it's been I have a certain cognitive bias going on here but bear with me: What part of Rails is… monolithic? I don't understand this complaint. Rails 3 these days is pretty modular. For the same reason I can't stand Sinatra et al; two-to-four hours into most projects I find myself saying "Oh yeah, I could really use an ORM, and some route helpers, and a view layer would be nice and how do I get this testing framework to play nice?" and before you know it you've wasted more time trying to cobble something together.

nahname 14y ago
The prevention of bikeshedding is one of rail's greatest strengths.
vidarh 14y ago
After you've done it once or twice, you will have a list of the components you prefer and that works for your style, as a starting point. I find that for my personal projects, that list is very different both in size and contents of what Rails pulls in. Another big difference to me is coupling: In theory Rails might be modular, but because of what Rails is, while you may be free to tear out ActiveRecord for example, it takes very little before you're knee deep in dealing with shit from 3rd party code that assumes the default stack. If you can't rely on all the Rails plugins and extensions, and you want to replace a major component of Rails, then there's suddenly a lot less reason to use it at all.

steveklabnik 14y ago

These days, Rails is very much pick-and choose: https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api and https://gist.github.com/1942658#file-config-ru https://gist.github.com/1942658#file-config-ru

edwinnathaniel 14y ago

Sounds like the trend is to follow Java (to certain extend, if you ignore the debacle of the old J2EE, Struts, and Tapestry). ORM? Hibernate or JPA2 can be run anywhere: inside or outside container (i.e.: desktop app, web-app, or simply daemon/service) DI? Spring or CDI Unit-test? JUnit or TestNG or others Mocking? EasyMock, Mockito Message Queue? Pick one out there Templating? JSP, JSF(ish), Velocity, FreeMarker. RESTful? Restlet, Jersey Everybody plays well with one and the other.

lkrubner 14y ago
Not exactly. The current trend is towards the JVM, but not Java. I wrote about this last week: http://www.smashcompany.com/technology/the-jvm-is-part-of-a-world-wide-conversation http://www.smashcompany.com/technology/the-jvm-is-part-of-a-... Even the cutting edge of Ruby is now on the JVM, as Rubyists see a need for threads and find jRuby the most convenient way to move forward: http://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto... Rails took off in 2004 as a rebellion against the overly-heavy Java frameworks like Struts. But now what good ideas Rails offered have been incorporated into languages that run on the JVM, and a lot of innovation, in particular with concurrency, is happening on the JVM, and some of those things are areas where Ruby (other than JRuby) is weak.
- edwinnathaniel 14y ago
  I see 2 trends here: Trend #1: modular components Trend #2: platform (performance optimization as well) What you described falls into #2 while what I refer to falls into #1.

Xylakant 14y ago

You're comparing a language to a framework. Rails is but one of rubys web-frameworks. There's sinatra and built on top of that padrino. There's camping, static page generators like octopress and that's just the web-world. Even rails is not a monolithic bloc: You can use activerecord or activesupport as libraries and rails itself uses a ton of libs itself. The ruby community values small libraries that can be plugged together to a bigger whole - and rails is basically a very opinionated collection of libraries with some glue code (and magic) to form a cohesive API. It's good for some kind of projects and it's certainly the oldest and biggest ruby framework, but it's by far not the only one.

freshhawk 14y ago

But for agency type developers, where you are working on many different crud websites at once, you have different needs from a framework. If you are starting your own startup then clearly you want to pick the individual libraries that best suit your problem. You have to deal with them for a long time and the payoff from a small improvement gets large. You write a little glue code and you are good to go. If you are working on a large number of CRUD sites all the time then you want a stable set of libraries that cover most of the problems you will encounter and having scaffolding and other glue code replacing mechanisms is preferrable, even if they aren't as flexible or efficient or elegant as could have been done manually. When you write the same glue code over and over again you end up automating it, and generalizations have tradeoffs. There is really no comparison between the framework needs of single site developers and developers working for a web agency or who are working on many sites or spinning up a few new sites a month.

zem 14y ago

there's sinatra and padrino for the pick-and-choose way. rails expresses the philosophy that it's more productive to pick a stack and stick to it, and then let the ecosystem optimise itself against that stack. it's true that the ruby webdev community has tended to coalesce around rails rather than sinatra, but that's because the rails community has solved a lot of genuine real-world problems that keep cropping up in its target space and has been able to write them as libraries that will work with anyone's rails setup.