5 ms·

Because Rails is a good technology for a lot of use cases. If you want to develop a simple crud style app, with user login, mail sending and all that stuff it

Because Rails is a good technology for a lot of use cases. If you want to develop a simple crud style app, with user login, mail sending and all that stuff it is highly productive. Performance is okay and certainly good enough for the average web project. Just get rid of the weird parts like turbolinks (unnecessary and messes up a lot of js) and don't write APIs using it (can't even rename fields easily). There are similar Frameworks in other languages and they all have pros and cons. Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. If you build a website for a niche company to sell odd machinery on, you have to get shit done and you will never need to scale. That means reliable, batteries included, highly standardized and easy to use. Rails ticks those boxes really well.

ravenstine 4y ago
> Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. That's exactly what is making web development decreasingly enjoyable as the years go on. ~99.5% of the web doesn't need the hyperscalable cool-tech du jour one typically reads about on HN. As long as developers don't fall for footguns, there's a lot that can be accomplished even with a language runtime like MRI. If scale becomes an issue, those things can be solved through horizontal scaling, optimizing database queries, not doing stupid shit that's memory-hogging, and moving expensive algorithms into another language. Ruby is perfectly adequate for serving HTTP requests. Whenever I've worked on a Rails app that everyone was frustrated with, the problems were almost always a compound of a bunch of dumbass shit that various developers piled on without much thought (otherwise I'd have seen them discussed in GitHub or Pivotal stories).
itake 4y ago
edit: to down voters: please educate me and not just down vote because you disagree with my question. --- Every tiny rails app that uses rspec ends up with +1hr test times due to tight coupling between activemodel and the db connections. Do you know of any good blog posts the describe how to do rails testing at scale? > Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. Rails devs have to deal with DHH's-flavor-of-the-month.coffee (coffeescript, asset pipeline, webpacker, import_maps)
- worker_person 4y ago
  When you hit scale. Rails is not the concern. It's the datastore. All of the major performance problems at scale I've dealt with came down to a super giant table that keeps getting locked.
  - itake 4y ago
    In another comment, it said Gitlab moved off ActiveRecord. The fundamental problem with rspec + ActiveRecord is for each test: you create db state (tons of inserts), run the test (more db reads and writes), and then tear down the state. This is very expensive when you have 100,000s of tests each taking 500ms. Rails/rspec does not make it easy to stub db state with ActiveRecord.
    - worker_person 4y ago
      http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rails-7-12.html http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rail... Use transactional fixtures as much as possible. Minimal db usage between tests.
      - itake 4y ago
        yes, that improves clean up time, but doesn't help with all of the db writes you have to make to create db state for each test case.
        worker_person 4y ago
        Initial state is loaded via fixtures or whatever. (slow and expensive) Transaction is started. Run Test 1 Transaction rolled back. (quick) Test 2 can be run without the expensive fixtures. Repeat for all tests.
        itake 4y ago
        Does this mean if you only want to run the tests for `users_controller` during development, you still have to load the fixtures for all other tests with each run?

ravenstine 4y ago

> Imho when it comes to web frameworks there is way too much emphasis on the startup style company and the ones with huge traffic. That's exactly what is making web development decreasingly enjoyable as the years go on. ~99.5% of the web doesn't need the hyperscalable cool-tech du jour one typically reads about on HN. As long as developers don't fall for footguns, there's a lot that can be accomplished even with a language runtime like MRI. If scale becomes an issue, those things can be solved through horizontal scaling, optimizing database queries, not doing stupid shit that's memory-hogging, and moving expensive algorithms into another language. Ruby is perfectly adequate for serving HTTP requests. Whenever I've worked on a Rails app that everyone was frustrated with, the problems were almost always a compound of a bunch of dumbass shit that various developers piled on without much thought (otherwise I'd have seen them discussed in GitHub or Pivotal stories).

itake 4y ago

edit: to down voters: please educate me and not just down vote because you disagree with my question. --- Every tiny rails app that uses rspec ends up with +1hr test times due to tight coupling between activemodel and the db connections. Do you know of any good blog posts the describe how to do rails testing at scale? > Companies doing grunt work style web development don't waste their time on flavor-of-the-month.js. Rails devs have to deal with DHH's-flavor-of-the-month.coffee (coffeescript, asset pipeline, webpacker, import_maps)

worker_person 4y ago
When you hit scale. Rails is not the concern. It's the datastore. All of the major performance problems at scale I've dealt with came down to a super giant table that keeps getting locked.
- itake 4y ago
  In another comment, it said Gitlab moved off ActiveRecord. The fundamental problem with rspec + ActiveRecord is for each test: you create db state (tons of inserts), run the test (more db reads and writes), and then tear down the state. This is very expensive when you have 100,000s of tests each taking 500ms. Rails/rspec does not make it easy to stub db state with ActiveRecord.
  - worker_person 4y ago
    http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rails-7-12.html http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rail... Use transactional fixtures as much as possible. Minimal db usage between tests.
    - itake 4y ago
      yes, that improves clean up time, but doesn't help with all of the db writes you have to make to create db state for each test case.
      - worker_person 4y ago
        Initial state is loaded via fixtures or whatever. (slow and expensive) Transaction is started. Run Test 1 Transaction rolled back. (quick) Test 2 can be run without the expensive fixtures. Repeat for all tests.
        itake 4y ago
        Does this mean if you only want to run the tests for `users_controller` during development, you still have to load the fixtures for all other tests with each run?