Feel free to reply to any of my 5 points above instead of repeating that the arguments are true. Because this does not make them true. STOP reinforcing what seems true to you on others I'd be interested in you pointing out where I do that. Because I never wrote that Phoenix is more productive, which you seem to want to counter in the replies. To the contrary, I actually wrote that Rails is probably a better choice, but these are poor arguments to prove that. You can try building an MVP using both frameworks and then can come back to this article to verify yourself. I did, thank you. Have you?

This is not about which one is better, it's about using arguments that are not true. It's wrong, no matter what the final verdict is.

While Rails might really be a better choice, at least for people who are familiar with it, the article contains mostly lies or very poor research: Could you explain why you compare Rails scaffold generator with Phoenix schema generation, not Phoenix "scaffold" generator mix phx.gen.json or mix phx.gen.html ? Phoenix actually has authentication built into framework, which by the standard you laid shuold be superior to having to add a gem. This is purely subjective, don't paint it as a objective measure. I really don't see how Hotwire example is "objectively better here", aside from the fact that you did not include comments/comment partial, so the amount of code looks smaller. Rails does not provide RSpec, you should compare to minitest (which Rails provide) I know you need to sell your services, but try to not build your brand on misinformation.

We use almost exactly that ;) It worked for about a year, but now there's a feeling it started to be messy and difficult to manage. We'll see how it goes with our own panel.

Nice post! I did not know about Torch. About Kaffy, I have kind of different experience. Custom actions do not really have enough flexibility for our needs and we are rolling out our own panel slowly, as you suggested in the last paragraph ;)

Is there actually an inline mutation of Integer possible, so that freezing it prevents it? Sorry if it sounds nitpick-y, but I'm curious.

Thanks Lucian Ghinda ! This post actually was supposed to be the base for the next one, where I present more about this idea of having events just to organize code. Maybe I'll finally be able to post it soon.

I agree a lot with your statements that Ruby used to push boundaries more and that it became too conservative (while hiding behind empty statements like "it's good that it's boring). But on the other hand, we have features like Guilds/Ractors, that promised solving most pressing issues with GIL and concurrency, but their implementation is half-baked at best, they are slow , not reliable, don't work with Rails (the latter might not be language's fault, but still). I can kind of understand why people are not very trigger-happy to try out new things in their production code, given the bad history of releasing new things with Ruby in past few years. And this is the only way to wide adoption. Libraries can't do it, because they usually target older versions of the language as well.

I really like the idea in the post! For some time already I feel that passing data between the controller and the view by setting an instance variable is one of the biggest and most fundamental design flaws of Rails – and I think you provide great examples of how to avoid it. However, personally I'm not so sure about this keeping the controller action as a one-line render-only thing. Controllers are procedural in nature and I actually like to see what is happening in a step-by-step way. I can understand the allure of hiding the complexity of filtering books in a private method, but honestly I would prefer to at least set the user directly: def index user = User .find (params[ :user_id ]) books = get_filtered_books render locals: { user: , books: } end I wonder what is your take on that.

Mani Gopal What do you think the future of carbon is ? I have no idea, honestly. It is from Google, so definitely some people will try to jump aboard the hype train. But probably C++ die-hards won't. I doubt it will get enough resources for newbie-programmers to learn it as a first language. So either it will get some traction as "C++ but Rust and form Google" or will join Google's cemetery of failed projects. Probably the latter.