8 ms·

> This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you

by aikah 8y ago

> This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly. Not really. You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. I don't see how big frameworks like Rails make all these things better, especially when they don't give you the choice as to what tool to use. If you ever developed a non trivial application, you also know that your first concern will be to avoid unnecessary bloat and complexity and only bring in libraries that are strictly required. And as we are moving from traditional html rendered server apps, big frameworks lost even more value since there is no need for a templating libraries, html form libraries,...

gravypod 8y ago
The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think! You also get a uniformity of understanding of your library and a support network.
- ryanbrunner 8y ago
  Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.
  - jashmatthews 8y ago
    > I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.
    - Doctor_Fegg 8y ago
      And indeed, openstreetmap.org is a Rails site (though key parts of the API have been rewritten in C++ for performance).
matthewmacleod 8y ago
I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose. That’s not always perfect or suitable for every use case, but it’s not a bad thing.
- steveklabnik 8y ago
  Agreed; those days are when I worked on Rails, and that was a lot of the things that made 3.x different from 2.x. I wrote a blog post about it that’s one of my most popular ever: https://words.steveklabnik.com/rails-has-two-default-stacks https://words.steveklabnik.com/rails-has-two-default-stacks This sentiment also was a major theme of my forward to The Rails Way. I’ve been thinking about this stuff a lot in the context of Rust...
  - canhascodez 8y ago
    > I’ve been thinking about this stuff a lot in the context of Rust... Do you mind extrapolating further, or will that be the topic of a future blog post?
    - steveklabnik 8y ago
      For now, what I’ll say is that I’ve seen how Node never really got a rails, and how Rust has a zillion microframeworks but no Rails either, yet. Do we need one? What would it look like? That kind of thing.
      - ethagnawl 8y ago
        > Node never really got a rails I'm, admittedly, out of the loop when it comes to Node, but I do remember Sails looking promising when it was first announced. I recently suggested it to someone (who uses Node regularly) as a possible solution for a project we're working on and they'd never heard of it. So, between that reaction and the fact that I haven't heard of anyone else using it (or anything similar), I think you're right that a Railsy solution never took off. Elixir is an interesting counterpoint, though. It seems like Phoenix was released and saw broad adoption very early on. I'm wondering if this dichotomy is a result of where people are coming to these newer languages from: people writing Elixir probably aren't coming from the FE/JS world, but there's a very good chance people writing Node are. Prior to the somewhat recent proliferation of JS client app frameworks, using a smattering of libraries was a very common approach to solving problems. (It arguably still is, albeit at a different level of abstraction in React/Babel/Webpack land.) Anyways, I'll be looking forward to reading the post you alluded to above, should it ever come together.
liveoneggs 8y ago
but in ruby rails dominates all of these components massively
prophetjohn 8y ago
> You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. But I'd rather spend my time creating business value than researching ORMs, templating libraries and mailers. And since I've never not been able to accomplish something with the ones Rails includes by default, I've never seen the need to use something else.
- JasonFruit 8y ago
  I'm surprised to hear that a person can efficiently create business value without knowing the ecosystem of the language they are using. Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)
  - mgkimsal 8y ago
    > Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.) So now you need to factor in research time. Then, continual research time, every time a new library or version of a library comes out. And if your research turns up that, no, in fact, version X or new lib Y is not substantively better (by whatever metric you're looking at), do you count that research time as 'wasted'? > how do you know you're not wasting time and effort? You look at the results of what you're doing vs what expectations were, firstly. You can then, periodically, look at your efforts, and compare reports from others who are claiming to do the same thing, and ... occasionally... spend time determining if a different approach offers radically better returns on the effort/results you have now. Switching to XYZ may also involve huge amounts of refactoring, upgrade, migration, etc. How do you know all that effort won't be "wasted" if new platform XYZ is abandoned 18 months from now? "efficiently" doesn't necessarily mean "at maximum efficiency". Also, "business value" is almost always intertwined with hitting particular date/time goals, which often trump technical metrics.
  - toasterlovin 8y ago
    Rails ain’t exactly new. It works pretty well for most things. I think most Rails developers generally stay abreast of large developments in the ecosystem, but the days where you would see significant benefits from being aware of every little library that comes out are long gone.
toasterlovin 8y ago
The world is filled with other people. IMO, the benefit you get from another person being able to immediately be productive in your codebase vastly outweighs any benefit you would get from hand picking an ORM, a mailer, a templating library, etc. And, anyway, Rails is pretty modular; you can rip out and replace anything that isn’t to your taste.
ryanbrunner 8y ago
The big value that Rails adds is that it eliminates valueless choices. Most of the time, which logging library, ORM, view templating language, whatever doesn't really make all that much difference in terms of effectiveness and essentially come down to aesthetics. When working with a framework that doesn't make those decisions for you, you end up with two big downsides - you waste time and energy arguing over which of these low-value choices you want to take, and new developers take longer to come up to speed with your particular architecture, since they need to learn each of the choices and how they are integrated, whereas in Rails it's obvious where everything is and how it's configured if you're familiar with the framework. Bloat is also over-emphasized, particularly for the backend. You'll load the gems in memory, sure, but they're a fairly small footprint on their own and it's not like Rails is calling the parts of the framework it's not using (save maybe middleware, although most of that is useful for most web applications).
- jrumbut 8y ago
  A big benefit of how opinionated frameworks preempt debates about marginal issues is that it's an externally imposed decision, instead of one team member triumphing over the others. It really helps team cohesion for DHH to tell you that you're using X instead of Y as opposed to the most domineering devs getting their way every time. In my mind this even compensates for some suboptimal choices Rails may make.
sametmax 8y ago
Choosing is much harder than it seems, and much more resource consumming. Then you have to integrate them. And of course test, maintain, document and update said integration. All people I worked with that had your philosophy didn't so that last part, and it had important consequences for the whole project duration.

by aikah 8y ago

gravypod 8y ago

The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think! You also get a uniformity of understanding of your library and a support network.

ryanbrunner 8y ago
Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.
- jashmatthews 8y ago
  > I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.
  - Doctor_Fegg 8y ago
    And indeed, openstreetmap.org is a Rails site (though key parts of the API have been rewritten in C++ for performance).

matthewmacleod 8y ago

I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose. That’s not always perfect or suitable for every use case, but it’s not a bad thing.

steveklabnik 8y ago
Agreed; those days are when I worked on Rails, and that was a lot of the things that made 3.x different from 2.x. I wrote a blog post about it that’s one of my most popular ever: https://words.steveklabnik.com/rails-has-two-default-stacks https://words.steveklabnik.com/rails-has-two-default-stacks This sentiment also was a major theme of my forward to The Rails Way. I’ve been thinking about this stuff a lot in the context of Rust...
- canhascodez 8y ago
  > I’ve been thinking about this stuff a lot in the context of Rust... Do you mind extrapolating further, or will that be the topic of a future blog post?
  - steveklabnik 8y ago
    For now, what I’ll say is that I’ve seen how Node never really got a rails, and how Rust has a zillion microframeworks but no Rails either, yet. Do we need one? What would it look like? That kind of thing.
    - ethagnawl 8y ago
      > Node never really got a rails I'm, admittedly, out of the loop when it comes to Node, but I do remember Sails looking promising when it was first announced. I recently suggested it to someone (who uses Node regularly) as a possible solution for a project we're working on and they'd never heard of it. So, between that reaction and the fact that I haven't heard of anyone else using it (or anything similar), I think you're right that a Railsy solution never took off. Elixir is an interesting counterpoint, though. It seems like Phoenix was released and saw broad adoption very early on. I'm wondering if this dichotomy is a result of where people are coming to these newer languages from: people writing Elixir probably aren't coming from the FE/JS world, but there's a very good chance people writing Node are. Prior to the somewhat recent proliferation of JS client app frameworks, using a smattering of libraries was a very common approach to solving problems. (It arguably still is, albeit at a different level of abstraction in React/Babel/Webpack land.) Anyways, I'll be looking forward to reading the post you alluded to above, should it ever come together.

liveoneggs 8y ago

but in ruby rails dominates all of these components massively

prophetjohn 8y ago

> You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. But I'd rather spend my time creating business value than researching ORMs, templating libraries and mailers. And since I've never not been able to accomplish something with the ones Rails includes by default, I've never seen the need to use something else.

JasonFruit 8y ago
I'm surprised to hear that a person can efficiently create business value without knowing the ecosystem of the language they are using. Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)
- mgkimsal 8y ago
  > Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.) So now you need to factor in research time. Then, continual research time, every time a new library or version of a library comes out. And if your research turns up that, no, in fact, version X or new lib Y is not substantively better (by whatever metric you're looking at), do you count that research time as 'wasted'? > how do you know you're not wasting time and effort? You look at the results of what you're doing vs what expectations were, firstly. You can then, periodically, look at your efforts, and compare reports from others who are claiming to do the same thing, and ... occasionally... spend time determining if a different approach offers radically better returns on the effort/results you have now. Switching to XYZ may also involve huge amounts of refactoring, upgrade, migration, etc. How do you know all that effort won't be "wasted" if new platform XYZ is abandoned 18 months from now? "efficiently" doesn't necessarily mean "at maximum efficiency". Also, "business value" is almost always intertwined with hitting particular date/time goals, which often trump technical metrics.
- toasterlovin 8y ago
  Rails ain’t exactly new. It works pretty well for most things. I think most Rails developers generally stay abreast of large developments in the ecosystem, but the days where you would see significant benefits from being aware of every little library that comes out are long gone.

toasterlovin 8y ago

The world is filled with other people. IMO, the benefit you get from another person being able to immediately be productive in your codebase vastly outweighs any benefit you would get from hand picking an ORM, a mailer, a templating library, etc. And, anyway, Rails is pretty modular; you can rip out and replace anything that isn’t to your taste.

ryanbrunner 8y ago

The big value that Rails adds is that it eliminates valueless choices. Most of the time, which logging library, ORM, view templating language, whatever doesn't really make all that much difference in terms of effectiveness and essentially come down to aesthetics. When working with a framework that doesn't make those decisions for you, you end up with two big downsides - you waste time and energy arguing over which of these low-value choices you want to take, and new developers take longer to come up to speed with your particular architecture, since they need to learn each of the choices and how they are integrated, whereas in Rails it's obvious where everything is and how it's configured if you're familiar with the framework. Bloat is also over-emphasized, particularly for the backend. You'll load the gems in memory, sure, but they're a fairly small footprint on their own and it's not like Rails is calling the parts of the framework it's not using (save maybe middleware, although most of that is useful for most web applications).

jrumbut 8y ago
A big benefit of how opinionated frameworks preempt debates about marginal issues is that it's an externally imposed decision, instead of one team member triumphing over the others. It really helps team cohesion for DHH to tell you that you're using X instead of Y as opposed to the most domineering devs getting their way every time. In my mind this even compensates for some suboptimal choices Rails may make.

sametmax 8y ago

Choosing is much harder than it seems, and much more resource consumming. Then you have to integrate them. And of course test, maintain, document and update said integration. All people I worked with that had your philosophy didn't so that last part, and it had important consequences for the whole project duration.