4 ms·

Because of my career path spent almost entirely as a consultant and now working with lots of startups, I must have seen 100+ web application builds. The produc

Because of my career path spent almost entirely as a consultant and now working with lots of startups, I must have seen 100+ web application builds. The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software.

andrewstuart 3y ago
Can someone explain in concrete terms this sense that ROR let’s people be highly productive? It’s hard for me to imagine what could be so much more productive than any number of other languages//frameworks. What does ROR actually have that the next technology doesn’t?
- pantulis 3y ago
  A web framework can be conceived as a selection of design choices already taken for you. The choices RoR does for you are extremely successful and very simple to understand, hence the name: you are developing "on rails" and as such you build things much faster. This was very true more than a decade ago before the Node revolution adn when the alternatives where Struts or Spring MVC in Java, or Zope with Python. Fast forward to 2023, I would say that other platforms have caught up a lot, but my personal opinion is that Rails still has the edge.
- stefcoetzee 3y ago
  Sane defaults for most (all?) aspects of the run-of-the-mill CRUD app, a.k.a. "convention over configuration". Helps focus development energy on solving the problem at hand as opposed to on bike shedding or being slowed down due to decision fatigue. AFAICT, one has to go with the conventions as far as possible. Straying off the beaten path can lead one to lose time fighting the framework.
  - herbst 3y ago
    And that is the sole reason many rails projects are still easily maintainable 10 years later. Even if they aren't your own
- ryanSrich 3y ago
  Simple litmus. Ask ChatGPT to create a basic Rails app that has authentication, routing, and a dashboard page only accessible after login. Then ask ChatGPT to do the same thing, but with any other language/framework.
  - andrewstuart 3y ago
    So batteries included user signup auth flow? I can see why that would get you going quick. Certainly Django doesn’t provide that. Most other frameworks I know don’t provide that. I know I’m dead sick of building my 50th user signup flow. Having said that, once it’s built that’s done. What’s the ongoing productivity gain beyond that?
    - imetatroll 3y ago
      It isn't batteries included sign up. You have to select a 3rd party lib for that (a gem).
      - gedy 3y ago
        Yeah that was first thing that struck me about Rails, I had kept hearing "batteries included", then DHH suggests rolling your own auth? Always seemed a strange gap.
    - frankwiles 3y ago
      Django provides built in auth that is pretty great and extensible. OAuth/SAML and canned or customized registration flows are just a matter of adding the django-allauth module.
    - ryanSrich 3y ago
      No. My point isn’t about using devise (I’m almost certain that’s what ChaGPT recommended). My point is that if you actually attempt to do both (code a simple app using ROR vs. another framework), you’ll find ROR just works 95% of the time. You might not like Ruby, or the syntax, or how a lot of what’s actually happening isn’t obvious. But to people who need to standup and build an MVP in a weekend there’s nothing that allows you to do it as fast.
- deleted 3y ago
  [deleted]
- jaggederest 3y ago
  It makes doing the standard thing extremely easy. It also removes much of the repetition (problematically so at times!) For example working on a typescript next.js app, you'll have definitions in your Prisma schema, you'll have some form of model wrapper to load and save your model instances, and you'll have front end code to render your model instances. All of that is gone with rails. The default is that your schema defines the attributes of your model, and your model has no code. If you scaffold your controllers, your entire app consists of a set of routes, a schema file, some empty model files, a default controller, and generated views. I am admittedly a rails expert, but I could redo most of the typescript apps I've worked on in a few weeks as rails apps, but not so vice versa. That being said, these days I mostly choose Typescript because the long term sustainability of a flexible type system beats the short term productivity gains that rails builds in for you. But if I was building a prototype or wanted an MVP as fast as possible because I was bootstrapping with my own money, I would reach for rails. There's no better framework for discovering what your customer actually wants to pay for.
  - dandy23 3y ago
    If you want type system you can use PHP and Laravel.
- nicoburns 3y ago
  You get built in support (and "couple of lines in config file" integrations with several popular options) for things like: auth, xsrf protection, database access, queues, logging, email, file storage, testing, cli tasks, and countless other things. There are other language ecosystems that have something comparable: notably Python with Django and PHP with Laravel. But most don't have anything nearly so complete. Of course all of these things are achievable in other languages/frameworks. But they require quite a bit more setup, and those setups end up being much less standardised across projects. IMO this doesn't tend to make too much difference over the long term, but something like rails definitely makes it quicker to get started.
  - regularfry 3y ago
    There's also the factor that while some of these things also exist sometimes in a more automated way than with Rails, the way Rails does them still seems to come out ahead. The specific example I've got in mind is database migrations. The default with Rails is that you write them yourself, and the model then interpolates what it finds in the database at runtime. With Django, the pattern (again, by default - but defaults matter) is that you change the model and the migrations are generated automatically. The model is the source of truth. I haven't figured out exactly why yet, but the way Rails splits the responsibilities seems to be much cleaner to me. I'm always slightly uncertain about what Django is going to do. With Rails the database feels closer to the surface, rather than something handed entirely over to the framework.
    - 3c6bYDXLMj 3y ago
      I really don’t follow this. It sounds like you are favouring what you are familiar with, and are back-solving a justification. You’re essentially describing a declarative migration system which on the face of it sounds reasonable. It sounds like you’re dismissing it on this property. After all, the underlying DDL is…declarative, for the initial tables, anyway. When you create a new migration, Django will tell you which actions it’s written into the migration file, i.e. the actions it thinks need to be taken to get from A to B. I don’t see anything opaque about that? You can also look at the migration file yourself. It’s entirely readable. You could even write your own if you wanted to. The Rails community seems to still be carrying a very peculiar compete-with-Django attitude from back in the heyday. I see it all the time here. It’s ridiculous.
adriand 3y ago
> The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software. Rails is certainly productive in the early days of building something, because so much of what you need is already built. But as time goes on that productivity edge vanishes. It's far easier to build slick modern UIs in other frameworks, and there are now Typescript frameworks (e.g. Remix) where you can use the same types (and get type safety, IDE auto-completion, IDE warnings, etc.) across the entire stack (it's amazing!) The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) whereas I have Typescript apps that I built a few months ago that have never triggered an error ever. The list goes on. The world turns, frameworks come and go, and the heyday of Rails is over. I don't know why this is a problem for people, quite frankly. If you didn't want to learn new things, then being a software developer wasn't the right career choice, and you were probably told that on day 1!
- danmaz74 3y ago
  Isn't remix just dealing with view and controller of MVC? That looks difficult to compare with Rails
  - deleted 3y ago
    [deleted]
  - 3c6bYDXLMj 3y ago
    Okay, so Remix and some persistence layer. What’s the point?
- 3c6bYDXLMj 3y ago
  Implying that anyone touting the benefits of an established technology is against learning is just intellectually dishonest. Being able to tell what is and what is not worth looking further into is a mark of a seasoned expert in any field.
cryptos 3y ago
> a CRUD app, which covers the vast majority of business software. Saying that most business applications would be CRUD applications doesn't reflect the reality very well. While technically everything could be broken down to CRUD operations, this term becomes pointless once a relevant amount of business logic is needed to perform the final (database) insert, update or delete. There is a reason why Domain-Driven Design exists (and RoR is, by the way, not the best framework to apply it).

andrewstuart 3y ago

Can someone explain in concrete terms this sense that ROR let’s people be highly productive? It’s hard for me to imagine what could be so much more productive than any number of other languages//frameworks. What does ROR actually have that the next technology doesn’t?

pantulis 3y ago
A web framework can be conceived as a selection of design choices already taken for you. The choices RoR does for you are extremely successful and very simple to understand, hence the name: you are developing "on rails" and as such you build things much faster. This was very true more than a decade ago before the Node revolution adn when the alternatives where Struts or Spring MVC in Java, or Zope with Python. Fast forward to 2023, I would say that other platforms have caught up a lot, but my personal opinion is that Rails still has the edge.
stefcoetzee 3y ago
Sane defaults for most (all?) aspects of the run-of-the-mill CRUD app, a.k.a. "convention over configuration". Helps focus development energy on solving the problem at hand as opposed to on bike shedding or being slowed down due to decision fatigue. AFAICT, one has to go with the conventions as far as possible. Straying off the beaten path can lead one to lose time fighting the framework.
- herbst 3y ago
  And that is the sole reason many rails projects are still easily maintainable 10 years later. Even if they aren't your own
ryanSrich 3y ago
Simple litmus. Ask ChatGPT to create a basic Rails app that has authentication, routing, and a dashboard page only accessible after login. Then ask ChatGPT to do the same thing, but with any other language/framework.
- andrewstuart 3y ago
  So batteries included user signup auth flow? I can see why that would get you going quick. Certainly Django doesn’t provide that. Most other frameworks I know don’t provide that. I know I’m dead sick of building my 50th user signup flow. Having said that, once it’s built that’s done. What’s the ongoing productivity gain beyond that?
  - imetatroll 3y ago
    It isn't batteries included sign up. You have to select a 3rd party lib for that (a gem).
    - gedy 3y ago
      Yeah that was first thing that struck me about Rails, I had kept hearing "batteries included", then DHH suggests rolling your own auth? Always seemed a strange gap.
  - frankwiles 3y ago
    Django provides built in auth that is pretty great and extensible. OAuth/SAML and canned or customized registration flows are just a matter of adding the django-allauth module.
  - ryanSrich 3y ago
    No. My point isn’t about using devise (I’m almost certain that’s what ChaGPT recommended). My point is that if you actually attempt to do both (code a simple app using ROR vs. another framework), you’ll find ROR just works 95% of the time. You might not like Ruby, or the syntax, or how a lot of what’s actually happening isn’t obvious. But to people who need to standup and build an MVP in a weekend there’s nothing that allows you to do it as fast.
deleted 3y ago
[deleted]
jaggederest 3y ago
It makes doing the standard thing extremely easy. It also removes much of the repetition (problematically so at times!) For example working on a typescript next.js app, you'll have definitions in your Prisma schema, you'll have some form of model wrapper to load and save your model instances, and you'll have front end code to render your model instances. All of that is gone with rails. The default is that your schema defines the attributes of your model, and your model has no code. If you scaffold your controllers, your entire app consists of a set of routes, a schema file, some empty model files, a default controller, and generated views. I am admittedly a rails expert, but I could redo most of the typescript apps I've worked on in a few weeks as rails apps, but not so vice versa. That being said, these days I mostly choose Typescript because the long term sustainability of a flexible type system beats the short term productivity gains that rails builds in for you. But if I was building a prototype or wanted an MVP as fast as possible because I was bootstrapping with my own money, I would reach for rails. There's no better framework for discovering what your customer actually wants to pay for.
- dandy23 3y ago
  If you want type system you can use PHP and Laravel.
nicoburns 3y ago
You get built in support (and "couple of lines in config file" integrations with several popular options) for things like: auth, xsrf protection, database access, queues, logging, email, file storage, testing, cli tasks, and countless other things. There are other language ecosystems that have something comparable: notably Python with Django and PHP with Laravel. But most don't have anything nearly so complete. Of course all of these things are achievable in other languages/frameworks. But they require quite a bit more setup, and those setups end up being much less standardised across projects. IMO this doesn't tend to make too much difference over the long term, but something like rails definitely makes it quicker to get started.
- regularfry 3y ago
  There's also the factor that while some of these things also exist sometimes in a more automated way than with Rails, the way Rails does them still seems to come out ahead. The specific example I've got in mind is database migrations. The default with Rails is that you write them yourself, and the model then interpolates what it finds in the database at runtime. With Django, the pattern (again, by default - but defaults matter) is that you change the model and the migrations are generated automatically. The model is the source of truth. I haven't figured out exactly why yet, but the way Rails splits the responsibilities seems to be much cleaner to me. I'm always slightly uncertain about what Django is going to do. With Rails the database feels closer to the surface, rather than something handed entirely over to the framework.
  - 3c6bYDXLMj 3y ago
    I really don’t follow this. It sounds like you are favouring what you are familiar with, and are back-solving a justification. You’re essentially describing a declarative migration system which on the face of it sounds reasonable. It sounds like you’re dismissing it on this property. After all, the underlying DDL is…declarative, for the initial tables, anyway. When you create a new migration, Django will tell you which actions it’s written into the migration file, i.e. the actions it thinks need to be taken to get from A to B. I don’t see anything opaque about that? You can also look at the migration file yourself. It’s entirely readable. You could even write your own if you wanted to. The Rails community seems to still be carrying a very peculiar compete-with-Django attitude from back in the heyday. I see it all the time here. It’s ridiculous.

adriand 3y ago

> The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software. Rails is certainly productive in the early days of building something, because so much of what you need is already built. But as time goes on that productivity edge vanishes. It's far easier to build slick modern UIs in other frameworks, and there are now Typescript frameworks (e.g. Remix) where you can use the same types (and get type safety, IDE auto-completion, IDE warnings, etc.) across the entire stack (it's amazing!) The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) whereas I have Typescript apps that I built a few months ago that have never triggered an error ever. The list goes on. The world turns, frameworks come and go, and the heyday of Rails is over. I don't know why this is a problem for people, quite frankly. If you didn't want to learn new things, then being a software developer wasn't the right career choice, and you were probably told that on day 1!

danmaz74 3y ago
Isn't remix just dealing with view and controller of MVC? That looks difficult to compare with Rails
- deleted 3y ago
  [deleted]
- 3c6bYDXLMj 3y ago
  Okay, so Remix and some persistence layer. What’s the point?
3c6bYDXLMj 3y ago
Implying that anyone touting the benefits of an established technology is against learning is just intellectually dishonest. Being able to tell what is and what is not worth looking further into is a mark of a seasoned expert in any field.

cryptos 3y ago

> a CRUD app, which covers the vast majority of business software. Saying that most business applications would be CRUD applications doesn't reflect the reality very well. While technically everything could be broken down to CRUD operations, this term becomes pointless once a relevant amount of business logic is needed to perform the final (database) insert, update or delete. There is a reason why Domain-Driven Design exists (and RoR is, by the way, not the best framework to apply it).