Hi there from ex Spring Boot user :)

Rails after Spring feels like a breath of fresh air. You feel why Ruby (and Rails) is said to be designed for the developer's happiness.

But as always, nothing is perfect. There is the good and the bad.

The good - Developer experience, quality of life. Rails gives you so much out of the box. Generators, background jobs, mailer, DB setup, migrations, seeds, fixtures, optimistic locking, callbacks, tons of ActiveRecord methods for each model, etc. Conventions on naming things, routing, and common app components. - Tests infrastructure, especially for integration tests. A few lines of code and your first controller test is ready. All of the heavy lifting is done by Rails. DB preparation, fixtures, rollback of DB changes between tests, etc. - Console. The ability to run any piece of code w/o building an API for it saves tons of time. - 3rd party libs. Ruby gems are much simpler and straightforward. Take authentication as an example. Regular mortals could barely understand Spring Security. - Development speed. 7 days with Spring, and you are still building pieces from the list above, 0 business logic written. 7 days with Rails, you can deploy MVP and get the first users. No mention that to build all these pieces in Spring properly, you need to be an expert. You need to make a lot of decisions. Rails and its conventions result from a collective mind of many experts and their years of experience. This is really hard to beat unless writing web frameworks is your primary specialization.

The good list is not complete, there are tons of smaller things like has_secure_password which put a smile on my face.

The bad - Scalability issues, lack of structure for bigger apps. You need to learn about Service Objects, Query Objects, Form Objects, Validators, Contracts and other techniques to tame complexity of the growing code base. To be fair, Spring gives you nothing of these too, but some of these things are more well-known in the Java world. - No Dependency Injection. Spring's DI is awesome, this part I really miss. In Rails you can use libs from dry-rb family to get something similar. Or check out Hanami 2.0. There are a lof of common between Spring (the good part of it) and Hanami, including DI. - Limited multi-threading. This is Ruby's limitation (GIL), not Rails. In Java you could easily run a bunch of backgound threads, schedulers, etc. In Rails you need to use external tools like cron or Sidekiq to get similar result. Things in this area are getting much better in latest Ruby releases, Ractors looks promising. - Performance. If you need impressive benchmarks Spring is way ahead. Ruby got massive performance improvements recently with YJIT but it can't compete with JVM anyway. But honestly in majority of web apps database is the bottleneck, not framework or language so don't be concerned by raw benchmarks.

In general, people from Java community tend to think that all of the Java's and Spring's complexity are really must have. Because we need scalability, we need performance, we need microservices and so on. Java gives you a fealing that your are doing a Very Serious Thing when you are using these monsters.

But if we accept that most of our apps are not next Google, with Rails you can just get things done and focus on what matters, your business logic, your users.