The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend.
If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following:
- Make the change on the server to support the new functionality. Deploy.
- Make the change on the client to adopt the new functionality. Deploy.
- Remove the old functionality from the server (optional)
Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer.
With server-authored HTML, this separate client + server deploy is not required.
> 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!
Scholarly is building the operating system for higher education. Think: Gusto, Rippling, or Workday for universities.
We are hiring software engineer #4 for the team. This is a unique opportunity to have a major impact on the company’s success and the team culture.
We are based in Seattle and Denver, with engineering based primarily in Seattle. We are looking for an engineer with at least 5 years of experience in Ruby on Rails.
Scholarly is building next-generation software for higher education with a focus on faculty. Think: Gusto, Rippling, or Workday for universities.
Higher ed is currently undergoing a generational shift in software and technology adoption, and our vision is to build the system of record for the industry. We are building a software platform that enables our customers to make data-driven decisions and to automate essential processes like performance reviews, which will ultimately enable them to better serve both students and faculty. Our team comes from Gusto, Modern Health, and Vail Resorts.
We are hiring software engineer #3 for the team. This is a unique opportunity to have a major impact on the company’s success and the team culture. This engineer will work closely with the CEO and CTO to build the initial version of the product, work closely with customers, and help set the culture of the company. We expect you to be able to define and challenge product requirements, seek customer feedback, and stick with projects until customers are satisfied or we’ve removed the feature. We are looking for a true partner who loves the challenge of building great software from the ground up.
We are based in Seattle and Denver, with engineering based primarily in Seattle.
Job Requirements
- At least 5 years working in Ruby on Rails
- Familiarity with JavaScript
- Experience working with a relational database, like MySQL or Postgres
- Able to work in the United States (citizen or permanent resident). We cannot sponsor visas at this time
Compensation and Benefits
- The salary range for this role is $150k - $200k, depending on experience.
- Substantial equity in the company
- Health, vision, and dental benefits with 100% of premiums covered by the company
Scholarly is building next-generation software for higher education with a focus on faculty. Higher ed is currently undergoing a generational shift in software and technology adoption, and our vision is to build the future system of record for the industry. We are building a software platform that enables our customers to make data-driven decisions and to automate essential processes like performance reviews, which will ultimately enable them to better serve both students and faculty. We are a team of experienced, motivated, and collaborative founders, and we are backed by leading investors in the industry.
We are hiring a software engineer for the team. This is a unique opportunity to have a major impact on the company’s success and the team culture. This engineer will work closely with the CEO and CTO to build the initial version of the product, work closely with customers, and help set the culture of the company. We expect you to be able to define and challenge product requirements, seek customer feedback, and stick with projects until customers are satisfied or we’ve removed the feature. We are looking for a true partner who loves the challenge of building great software from the ground up.
We are based in Seattle and Denver, with engineering based primarily in Seattle.
Job Requirements
- At least 5 years working in Ruby on Rails
- Familiarity with JavaScript
- Experience working with a relational database, like MySQL or Postgres
- Able to work in the United States (citizen or permanent resident). We cannot sponsor visas at this time
Compensation and Benefits
- The salary range for this role is $150k - $200k, depending on experience.
- Substantial equity in the company
- Health, vision, and dental benefits with 100% of premiums covered by the company
Scholarly is building next-generation software for higher ed with a focus on faculty. We are starting off with performance review software for faculty and hoping to grow into a broader HR platform over time.
We were founded in June 2023. We've raised $1M in pre-seed financing and are going live with our first customers. We're looking for a pragmatic, hands-on engineer who loves developing empathy with customers.
Sure, but the point is, a halfway decent type system will eliminate whole classes of errors—consequently eliminating whole swaths of things you would ever need to write tests for.
What's more, though, is that a good type system will help you 'Make Impossible States Impossible'[0]—even more behavior you don't have to test because bad behavior is simply not representable in your program.
Tests are strictly more powerful in the small, because they can be arbitrarily complex, but I would say a (really good) type system is more powerful in the large, because you get way more leverage in terms of overall program correctness.
A lot of my personal projects are in Elm (yeah, yeah, bring on the hate)—the models are really well-defined, but the test suites usually only have a handful of tests of behavior I really want to verify. Haven't even played with the property checker yet, but again, that's something that is strictly more powerful than unit tests, but you can only get it* if you have a type system.
reply