9 ms·

Ruby on Rails: Still the Best Web App Framework for Most Teams

62 points by sairamkunala 6y ago

mkrishnan 6y ago
What? looks like you don't really understand the power of aws/serverless/Kubernetes/kafka/cassandra/graphql/react. when your app becomes instant hit after featuring in the frontpage of HN, you will have 1 billion daily active users and your business goes into flames because of new workload.
- cue_the_strings 6y ago
  I chuckled... sensibly.
- cwackerfuss 6y ago
  You must be a masochist.. I'd rather spend 1/10th the time finding out if I have a hit on my hands and address scaling problems later than battling with kubernetes and kafka. Build product not infrastructure.
  - lovegoblin 6y ago
    Yes I believe that's the joke.
- slantaclaus 6y ago
  Thats one hell of a stack
- mkrishnan 6y ago
  I forgot to mention Hadoop/hdfs/elixir/<fancy-tech-relesed-last-week> ...
marstall 6y ago
Rails fanboy since 0.9. Great framework. It's just such a ... comfortable? space to be in. Highly recommend it even after all these years - though now I use it mostly for modern SPA-style apps where rails simply provides an API. Which it is, yup, great for!
- Okawari 6y ago
  You hit the nail on the head there! Ive been tinkering with rails since Rails 4, but in my dayjob I use Laravel a whole lot. At this point I have spent way more time in Laravel than Rails. Yet pretty much every time I have to work with Laravel, I wish it was rails instead. Rails being "comfortable" is quite apt, and definitly something I'm missing.
  - cyrialize 6y ago
    Could you go over the differences between Rails and Laravel? I'm thinking of picking up a framework for myself. I very much enjoy the Laracasts videos and I work in PHP currently so I've though about starting their Laravel learning series. On the other hand, I create a RoR application for my university and I've always loved Ruby - but it's been a long time since I've done anything with Ruby.
    - Okawari 6y ago
      I realize that this comes down to preferences but here are some of the things I can come up with of the top of my head. Again, most of these changes are in the comfortable category. To be very brief * PHP. This comes up everytime we talk about Laravel. Its the same reasons a lot of people dislike it. I think the language is just kind of jank. * A lack of the powerful metaprogramming aspects of Ruby makes the Api to bootstrap and use features in Laravel feel clunky and akward compared to Rails. For example the laravel router having a lot of its features requiring you to pass arguments using associative arrays which does not get autocompletion for example. * Ability to inject code using function calls gives you very nice ways of defining validations on the model itself instead of a request validator that is located in the controller. I think it makes more sense for them to be there. The syntax for defining them is a lot slicker and less cumbersome. * I dont like observables and how they can affect code somewhere else without being referenced in the location where they are mutating an object. I feel like i loose track of laravel projects earlier than rails as lines of code increase. I find it easier to follow where the code is going with rails. * I think the templating system of Laravel is poor compared to just plain embedded ruby. I know you can just use normal php. But a lot of blade helpers are then disabled and the documentation for them are subpar as the developers expect you to use blade. I think the need for special syntax (@directive) makes things harder to parse, and I dont like how @stack lets you effectively push code to somewhere earlier in the file/code. It makes things harder to reason around because as you read the code you cant really reason about what a stack actually contains. And if you read a component that pushes to the stack then you dont know exactly where that ends up. I think normal embedded ruby templates is way cleaner and better. As I said you can use plain php instead of blade. But it is not that well supported, documentation is poor. It is probably quicker and easier to just use blade components, but using blade features sparingly. For me it primarilly comes down to these kinds of small grievances I have with it the project that just makes me wish I could just write them in ruby instead.
Knajjars 6y ago
I did 5 years of JS full stack development (both professional and for personal projects), until I decided to learn a more "boring" and mature language and framework. Never looked back and each day I love RoR more.
stephen82 6y ago
I guess it assumes we already know how to use the Ruby language, therefore it's a good option to choose for new projects? I personally know near nothing about Ruby, other than read a couple of documentation pages. Since I don't know how to use it the right way, I cannot take any side so I can agree or not with this suggestion.
- horsawlarway 6y ago
  For a single person project, Rails is decent. I actually think RoR is an utter garbage fire the second you have a team of 3+. Also, to be blunt, RoR most reminds of me of the old Microsoft web frameworks at this point (asp.net, before core). It's all pre-configured. You have very few structural choices to make, and you can focus on the actual project meat right away. The problem, coming in as someone without experience in the platform, is that documentation is becoming incredibly fragmented. The second you need to touch a config file, suddenly you have to know exactly what version of rails you're running (because they change config names CONSTANTLY), and what the asset pipeline was like in that version, and so and such forth. Of course, googling what you want links you to docs for Rails from 2 years ago, which no longer works. It's eerily reminiscent of microsoft products that tried to the same thing - because "The best out of the box experience" changes every year or three, and they all try to meet current expectations. So long post aside, having used Rails for a while professionally, but also having come in with a LOT of alternative experience (mainly Node/TSNode/C#/Golang) I find it functional, but fairly unimpressive, for small projects. Also, the older I get, the more I want type systems. I should try giving Sorbet a spin (ruby, but with types), Because RoR on a large team is a nightmare. Types would help a lot.
  - HeyZuess 6y ago
    > I actually think RoR is an utter garbage fire the second you have a team of 3+. This isn't a a Rails issue, I have worked on teams with 30+ members with no problems. It is an organizational problem. > The second you need to touch a config file, suddenly you have to know exactly what version of rails you're running (because they change config names CONSTANTLY), and what the asset pipeline was like in that version, and so and such forth. I cannot remember the last time I needed to touch a Rails configuration truthfully. I prefer not to touch any configuration. This is a subjective opinion, but less I need to configure the app over time the more stable the configuration is. The configurations don't change that much, you expect them to change during major version releases. I don't know how often you change Rails versions. > Of course, googling what you want links you to docs for Rails from 2 years ago, which no longer works. Ok this one I am going to strongly disagree with. Rails has some really good documentation, and solutions are very easy to find for a lot of problems. > Also, the older I get, the more I want type systems. I should try giving Sorbet a spin (ruby, but with types), Because RoR on a large team is a nightmare. Types would help a lot. But Ruby is not a typed system out of the box, it is supposed to be duck typed. Now while I might have a leaning towards typed systems also myself, it is not a limitation of the language and layering types on top of duck typing erodes some of the flexibility.
nunez 6y ago
I wish Ruby became what JavaScript is now. It's such a good language to write stuff in.
- j_crick 6y ago
  Didn’t you mean that the other way around? If Ruby ecosystem became what current JS ecosystem is now, it wouldn’t be Ruby anymore, at least the way people who love it love it. I’m not quite sure that it would benefit from dispersion of focus on itself onto flavour of the <insert your noun here> every <relatively frequent period of time>. It’s such a good language to write stuff in not least because indeed it keeps trying to move along the axis of that aspect of it.
  - nunez 6y ago
    I meant in its popularity, not in its insanity
- Knajjars 6y ago
  I differ, I believe JS is in a place no other programming language should be at. Every week you have doubts of the framework/lib you chose because there is a new cool kid in town. It's just so much distraction from things that actually matter, like shipping a product
vr46 6y ago
Started with Ruby in 2004, loved Rails until I switched away in 2015 as the jobs market was plateauing, and has stayed where it was. But it is fantastic and I’m back to tinkering with it using the fabulous new Stimulus Reflex stuff. The market is still rubbish, though, and there’s not enough good people out there.
klaustopher 6y ago
I remember reading this a while back. So true https://medium.com/@timbuchwaldt/rails-is-boring-thats-great-f896e9ab2cb https://medium.com/@timbuchwaldt/rails-is-boring-thats-great... I am also very happystill to spin up `rails new` for every little side project
arpyzo 6y ago
When I understand something in Rails, it's wonderful, but the sheer quantity of "magic" in Rails makes it very difficult to deal with when you only touch Rails projects periodically. I never had this issue with Java frameworks. I could drop into a large Java codebase almost anywhere and quickly get a lay of the land.
- ericb 6y ago
  Annotations? Beans? Generators? @Entity @Type @JsonProperty Maybe any technology seems magical until you understand it. I see at least as much magic in Java as Ruby now.
  - throwaway189262 6y ago
    Java's codegen is mostly done with standardized annotation processors, and they write code at build time so you can go look at the source they generated if you need to. And since it's generated at build time, everything is visible to the IDE. There's a lot of reflection magic but it's not the wild west like Ruby can be because there's limits on what you can do to a class file once it's loaded. It's mostly limited to peeking at annotations on fields and methods and calling those methods or reading fields. You can't redefine the methods or fields on an object at runtime, which prevents a lot of misguided insanity.
- tmm84 6y ago
  On my personal project Rails' magic was okay because it simple. However, in my work I have found Rails projects written by really knowledgable Ruby users to be difficult to understand. More than likely it tends to be overuse of dynamic meta-programming. I have worked in several languages sever side and I have never had a problem jumping into a codebase until I had a Ruby project to join.
- Knajjars 6y ago
  I think people confuse metaprogramming with "magic

62 points by sairamkunala 6y ago

What? looks like you don't really understand the power of aws/serverless/Kubernetes/kafka/cassandra/graphql/react. when your app becomes instant hit after featuring in the frontpage of HN, you will have 1 billion daily active users and your business goes into flames because of new workload.

cue_the_strings 6y ago
I chuckled... sensibly.
cwackerfuss 6y ago
You must be a masochist.. I'd rather spend 1/10th the time finding out if I have a hit on my hands and address scaling problems later than battling with kubernetes and kafka. Build product not infrastructure.
- lovegoblin 6y ago
  Yes I believe that's the joke.
slantaclaus 6y ago
Thats one hell of a stack
mkrishnan 6y ago
I forgot to mention Hadoop/hdfs/elixir/<fancy-tech-relesed-last-week> ...

marstall 6y ago

Rails fanboy since 0.9. Great framework. It's just such a ... comfortable? space to be in. Highly recommend it even after all these years - though now I use it mostly for modern SPA-style apps where rails simply provides an API. Which it is, yup, great for!

Okawari 6y ago
You hit the nail on the head there! Ive been tinkering with rails since Rails 4, but in my dayjob I use Laravel a whole lot. At this point I have spent way more time in Laravel than Rails. Yet pretty much every time I have to work with Laravel, I wish it was rails instead. Rails being "comfortable" is quite apt, and definitly something I'm missing.
- cyrialize 6y ago
  Could you go over the differences between Rails and Laravel? I'm thinking of picking up a framework for myself. I very much enjoy the Laracasts videos and I work in PHP currently so I've though about starting their Laravel learning series. On the other hand, I create a RoR application for my university and I've always loved Ruby - but it's been a long time since I've done anything with Ruby.
  - Okawari 6y ago
    I realize that this comes down to preferences but here are some of the things I can come up with of the top of my head. Again, most of these changes are in the comfortable category. To be very brief * PHP. This comes up everytime we talk about Laravel. Its the same reasons a lot of people dislike it. I think the language is just kind of jank. * A lack of the powerful metaprogramming aspects of Ruby makes the Api to bootstrap and use features in Laravel feel clunky and akward compared to Rails. For example the laravel router having a lot of its features requiring you to pass arguments using associative arrays which does not get autocompletion for example. * Ability to inject code using function calls gives you very nice ways of defining validations on the model itself instead of a request validator that is located in the controller. I think it makes more sense for them to be there. The syntax for defining them is a lot slicker and less cumbersome. * I dont like observables and how they can affect code somewhere else without being referenced in the location where they are mutating an object. I feel like i loose track of laravel projects earlier than rails as lines of code increase. I find it easier to follow where the code is going with rails. * I think the templating system of Laravel is poor compared to just plain embedded ruby. I know you can just use normal php. But a lot of blade helpers are then disabled and the documentation for them are subpar as the developers expect you to use blade. I think the need for special syntax (@directive) makes things harder to parse, and I dont like how @stack lets you effectively push code to somewhere earlier in the file/code. It makes things harder to reason around because as you read the code you cant really reason about what a stack actually contains. And if you read a component that pushes to the stack then you dont know exactly where that ends up. I think normal embedded ruby templates is way cleaner and better. As I said you can use plain php instead of blade. But it is not that well supported, documentation is poor. It is probably quicker and easier to just use blade components, but using blade features sparingly. For me it primarilly comes down to these kinds of small grievances I have with it the project that just makes me wish I could just write them in ruby instead.

Knajjars 6y ago

I did 5 years of JS full stack development (both professional and for personal projects), until I decided to learn a more "boring" and mature language and framework. Never looked back and each day I love RoR more.

stephen82 6y ago

I guess it assumes we already know how to use the Ruby language, therefore it's a good option to choose for new projects? I personally know near nothing about Ruby, other than read a couple of documentation pages. Since I don't know how to use it the right way, I cannot take any side so I can agree or not with this suggestion.

horsawlarway 6y ago
For a single person project, Rails is decent. I actually think RoR is an utter garbage fire the second you have a team of 3+. Also, to be blunt, RoR most reminds of me of the old Microsoft web frameworks at this point (asp.net, before core). It's all pre-configured. You have very few structural choices to make, and you can focus on the actual project meat right away. The problem, coming in as someone without experience in the platform, is that documentation is becoming incredibly fragmented. The second you need to touch a config file, suddenly you have to know exactly what version of rails you're running (because they change config names CONSTANTLY), and what the asset pipeline was like in that version, and so and such forth. Of course, googling what you want links you to docs for Rails from 2 years ago, which no longer works. It's eerily reminiscent of microsoft products that tried to the same thing - because "The best out of the box experience" changes every year or three, and they all try to meet current expectations. So long post aside, having used Rails for a while professionally, but also having come in with a LOT of alternative experience (mainly Node/TSNode/C#/Golang) I find it functional, but fairly unimpressive, for small projects. Also, the older I get, the more I want type systems. I should try giving Sorbet a spin (ruby, but with types), Because RoR on a large team is a nightmare. Types would help a lot.
- HeyZuess 6y ago
  > I actually think RoR is an utter garbage fire the second you have a team of 3+. This isn't a a Rails issue, I have worked on teams with 30+ members with no problems. It is an organizational problem. > The second you need to touch a config file, suddenly you have to know exactly what version of rails you're running (because they change config names CONSTANTLY), and what the asset pipeline was like in that version, and so and such forth. I cannot remember the last time I needed to touch a Rails configuration truthfully. I prefer not to touch any configuration. This is a subjective opinion, but less I need to configure the app over time the more stable the configuration is. The configurations don't change that much, you expect them to change during major version releases. I don't know how often you change Rails versions. > Of course, googling what you want links you to docs for Rails from 2 years ago, which no longer works. Ok this one I am going to strongly disagree with. Rails has some really good documentation, and solutions are very easy to find for a lot of problems. > Also, the older I get, the more I want type systems. I should try giving Sorbet a spin (ruby, but with types), Because RoR on a large team is a nightmare. Types would help a lot. But Ruby is not a typed system out of the box, it is supposed to be duck typed. Now while I might have a leaning towards typed systems also myself, it is not a limitation of the language and layering types on top of duck typing erodes some of the flexibility.

nunez 6y ago

I wish Ruby became what JavaScript is now. It's such a good language to write stuff in.

j_crick 6y ago
Didn’t you mean that the other way around? If Ruby ecosystem became what current JS ecosystem is now, it wouldn’t be Ruby anymore, at least the way people who love it love it. I’m not quite sure that it would benefit from dispersion of focus on itself onto flavour of the <insert your noun here> every <relatively frequent period of time>. It’s such a good language to write stuff in not least because indeed it keeps trying to move along the axis of that aspect of it.
- nunez 6y ago
  I meant in its popularity, not in its insanity
Knajjars 6y ago
I differ, I believe JS is in a place no other programming language should be at. Every week you have doubts of the framework/lib you chose because there is a new cool kid in town. It's just so much distraction from things that actually matter, like shipping a product

vr46 6y ago

Started with Ruby in 2004, loved Rails until I switched away in 2015 as the jobs market was plateauing, and has stayed where it was. But it is fantastic and I’m back to tinkering with it using the fabulous new Stimulus Reflex stuff. The market is still rubbish, though, and there’s not enough good people out there.

klaustopher 6y ago

I remember reading this a while back. So true https://medium.com/@timbuchwaldt/rails-is-boring-thats-great-f896e9ab2cb https://medium.com/@timbuchwaldt/rails-is-boring-thats-great... I am also very happystill to spin up `rails new` for every little side project

arpyzo 6y ago

When I understand something in Rails, it's wonderful, but the sheer quantity of "magic" in Rails makes it very difficult to deal with when you only touch Rails projects periodically. I never had this issue with Java frameworks. I could drop into a large Java codebase almost anywhere and quickly get a lay of the land.

ericb 6y ago
Annotations? Beans? Generators? @Entity @Type @JsonProperty Maybe any technology seems magical until you understand it. I see at least as much magic in Java as Ruby now.
- throwaway189262 6y ago
  Java's codegen is mostly done with standardized annotation processors, and they write code at build time so you can go look at the source they generated if you need to. And since it's generated at build time, everything is visible to the IDE. There's a lot of reflection magic but it's not the wild west like Ruby can be because there's limits on what you can do to a class file once it's loaded. It's mostly limited to peeking at annotations on fields and methods and calling those methods or reading fields. You can't redefine the methods or fields on an object at runtime, which prevents a lot of misguided insanity.
tmm84 6y ago
On my personal project Rails' magic was okay because it simple. However, in my work I have found Rails projects written by really knowledgable Ruby users to be difficult to understand. More than likely it tends to be overuse of dynamic meta-programming. I have worked in several languages sever side and I have never had a problem jumping into a codebase until I had a Ruby project to join.
Knajjars 6y ago
I think people confuse metaprogramming with "magic