> Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS
I don’t grok this part. Based on my experience with RoR and JS/TS, making changes in TS-land is much easier and quicker than dealing with Ruby.
Is this just a preference/experience thing in the end? For you and your team RoR is faster/easier, so that makes it the better choice. For a different team JS/TS may be faster/easier, so that makes it the better choice?
I should have made the distinction between client-side and server-side JS/TS. Familiarity and expertise will be a main driver of productivity for a team, regardless of language/framework. For us, that's RoR.
Client-side JS however has a multiplying property, where we often need to write more server-side code to accommodate the growth in client-side code. If the client-side code is providing undifferentiated value (e.g. authoring HTML), we now have more pieces in our system to accomplish our goal (author HTML). What's been surprising to me is that you don't need to author HTML client-side to have a reactive experience. With Turbo, Stimulus, and server-rendered HTML, a great experience is possible with fewer layers.
I think the power of fat clients comes when you have different consumers of the same APIs/logic. Like a browser app or two, maybe backend services, a few task queues, etc. Then having a clean separation between client code and business logic becomes super valuable.
In my experience with SPA we got to a point where my team could go weeks, even months, without having to make changes in server code. Whole new features that were fully supported by our existing APIs because they were written as reusable APIs. If you’re having to write a bunch of Rails to support the growing client code, you probably didn’t need a separate client yet.
But when your codebase gets to that point even Rails is just a frontend really. So it’s mostly about which tradeoffs you prefer. Unfortunately I left Rails right around the time Turbo was becoming a proper thing you could use so I don’t have the best feel for what it’s like.
Thank you for writing this all up. Just curious if you ever considered switching away from Ruby? I think many people are living in parallel stacks (TS, Go, Python, Rust) and it would be interesting to hear how it’s been going more recently in that ecosystem from your perspective.
As to rendering, I’ll be honest and say that my code has moved more towards client-side (using ConnectRPC and my framework ojjs.org—-shameless plug :), but I love that you have had success with a different path. Super interesting, and thanks again!
I don't have a reason for switching away from Ruby at this point in my career. Things can always change down the line. Maintaining multiple languages at the same layer sounds like a personal nightmare to me. I'd rather learn to write PHP and have that be the only language, than to write Ruby+another language on the server-side.
We're building our company on Rails because we think it's the best choice for a young company, since it allows us to respond to customer feedback more quickly. That's what we're optimizing for right now!
I don’t grok this part. Based on my experience with RoR and JS/TS, making changes in TS-land is much easier and quicker than dealing with Ruby.
Is this just a preference/experience thing in the end? For you and your team RoR is faster/easier, so that makes it the better choice. For a different team JS/TS may be faster/easier, so that makes it the better choice?