The front end logic compiles to vanilla JS and ends up lightning fast compared to React/Vue with much smaller file sizes.
The back end framework is extremely light so you need to pull external packages in or build your own solutions. For example there's no built in ORM or such. This can be seen as a huge negative for some but personally I like to use raw SQL and build my own libraries for things anyway.
I've found insane value in using one language for both front end and back end. Reducing cognitive friction and context switching is a huge win and it allows you to share logic in both places.
My validation logic is defined in exactly one place, so if a piece of data will end up invalid on the back end then realistically it has no chance of even getting there since my submit buttons on the front end will be disabled if my inputs fail that same validation logic.
Similarly I have objects with state classes defining allowable behavior. I can use these state classes in both the front and back end. Why on earth would I want to define these things in two separate places, in two separate languages? Defining once reduces potential errors and obviously saves massive amounts of time. For your average CRUD web apps in 2022 I have no idea why you would reach for a solution that doesn't allow code reuse in both the front and back end. It's such an obvious and huge win for me.
While I've never used Symfony, when I've tinkered in Laravel it felt like the frameworks were pretty similar (if you've ever used Laravel).
If you want to do something more 'cloud native' in Ruby, you could use something like Ruby on Jets (at its core it uses AWS's API Gateway and Lambda, but can be extended for other AWS services with events)
- I would also suggest FastAPI for writing up your API and using your favourite front-end framework. If you are looking to learn something on the front-end React/Next.js would be a good choice.
Add some gems like avo-admin/jumpstart and you'll have fully featured(CRUD operation) app within few hours.