Hello, World! I'm jzombie, a passionate software developer with a knack for problem-solving and a love for open-source. I believe in the power of code to change the world and make our lives easier.
I'm speaking generally to Rails not coming up in an era where, say, GraphQL exists. Sure, there is plenty of support here, but there are also frameworks which really build around this technology as a first-class citizen.
I think it's the general downfall of being around longer and having to support more things. If you really want to go in on a more novel approach to web app development, you may want to go with something that is really designed directly to build around that approach.
I'm a Rails dev myself, full stop, but it's very much general purpose, and if you know you have a need for a different approach that's going to get support from the whole ecosystem, you may want to look elsewhere.
I have been slowly heading from haskell -> scala -> golang (~ few months) -> rails API (this month) over the last six years. I don't see graphql's applicability to a typical backend for frontend scenario. I think its great for build a public facing API, if you are building an API product, where you don't have access to all your potential clients. I may be proved wrong though. So, I don't see anything really missing in the default Rails API approach.
I am slightly concerned that the default recommendation is Turbo, rather than emphasizing React + Rails API, but I don't think it matters that much.
I am slightly concerned that the default recommendation is Turbo
I'm especially concerned given the last point of "DHH drama" since Turbo is still pretty darn immature. It's so much still his pet project and it's just not great if the community isn't acting in a super cohesive way on these things.
Of course, all the stakeholders in Rails aren't going to let this become that much of an actual problem, but it still poses a risk to the direction of the ecosystem. I'd like to think everyone is rowing in the same direction, but I'm not sure that's totally happening at the moment.
On the plus side, I was skeptical about turbo working out well on a static site and it has performed well, decent lighthouse scores. I know static sites are a niche area relative to a regular web UI frontend.
It's pretty easy to point out what's wrong with Rails, but it's still so well loved for a reason. People who get used to working in it tend to be very productive and happy.
Hello, World! I'm jzombie, a passionate software developer with a knack for problem-solving and a love for open-source. I believe in the power of code to change the world and make our lives easier.
I develop a lot w/ JS and I think the cons are rooted in so many libraries defining their own ad-hoc type systems (i.e. JS itself [and TypeScript] one way, Apollo [GraphQL] another way, React prop-types another way, any object validation tool another way, etc.).
I think the directions are to either embrace what Rails is and isn't and build a "majestic monolith", or break an app into services over time.
We're probably through the looking glass in terms of people going crazy with microservices and then coming back to feeling like monoliths aren't so bad after all.
Personally, I think there's a goldilocks zone where an org just gets good at spinning up Rails apps, and each one is a "service". Some could see it as overkill to have "a whole Rails app" for a small service, but orgs that get good at this seem very productive. They can generally share libraries and engines, but also operate in isolation and have a lot of conventional functionality right out of the box.
And to be clear, Rails can be modular, it's just pretty convenient within the framework to not worry too much about that.
embrace what Rails is and isn't and build a "majestic monolith"
I think the back-end community just needs to get over monolith-shaming. There's nothing wrong with having one big app where all the parts perfectly fit together.
What's the point of losing the performance benefit of not having countless abstraction layers between your application's components, when you don't really need any of the benefits?
"Know what you're making" is really the one and only answer to so many of these A vs. B discussions.
I agree with allowing for some monoliths, but I also think rails API needs to advertise stronger as a potential microservice option. It's sad to see everybody choose flask or express. I imagine some percentage of those devs would actually enjoy convention over config, if they considered it a viable option.
I love Rails, its what kickstarted my web dev career. I also really prefer using true intellisense, and I think the Rails "magic" gets in the way of that. I still think we can make a good intellisense tool for Rails, using static analysis, (sorta like rust-analyzer)
Rails is in this cosy place where it's well established, and the pros outweigh the cons by a lot in terms of productivity, but it's also very boring because of this.
Personally I like working with rails at work, but I'd rather learn COBOL than use it for any personal project just for how amazingly uninteresting it is. At every step it keeps you from making exciting, but also irresponsible decisions.
The danger, I think, lies in confusing these two aspects. Nobody should want an "exciting" tech stack at work. The less surprises, the better, really.
Ruby on Rails
Pros
Cons
Do the cons outweigh the pros? They sound pretty hard hitting.
I don't understand this one - reference to isomorphic, blitz, serverless, something else?
I'm speaking generally to Rails not coming up in an era where, say, GraphQL exists. Sure, there is plenty of support here, but there are also frameworks which really build around this technology as a first-class citizen.
I think it's the general downfall of being around longer and having to support more things. If you really want to go in on a more novel approach to web app development, you may want to go with something that is really designed directly to build around that approach.
I'm a Rails dev myself, full stop, but it's very much general purpose, and if you know you have a need for a different approach that's going to get support from the whole ecosystem, you may want to look elsewhere.
I have been slowly heading from haskell -> scala -> golang (~ few months) -> rails API (this month) over the last six years. I don't see graphql's applicability to a typical backend for frontend scenario. I think its great for build a public facing API, if you are building an API product, where you don't have access to all your potential clients. I may be proved wrong though. So, I don't see anything really missing in the default Rails API approach.
I am slightly concerned that the default recommendation is Turbo, rather than emphasizing React + Rails API, but I don't think it matters that much.
I'm especially concerned given the last point of "DHH drama" since Turbo is still pretty darn immature. It's so much still his pet project and it's just not great if the community isn't acting in a super cohesive way on these things.
Of course, all the stakeholders in Rails aren't going to let this become that much of an actual problem, but it still poses a risk to the direction of the ecosystem. I'd like to think everyone is rowing in the same direction, but I'm not sure that's totally happening at the moment.
On the plus side, I was skeptical about turbo working out well on a static site and it has performed well, decent lighthouse scores. I know static sites are a niche area relative to a regular web UI frontend.
It's pretty easy to point out what's wrong with Rails, but it's still so well loved for a reason. People who get used to working in it tend to be very productive and happy.
I was mostly curious is all.
I develop a lot w/ JS and I think the cons are rooted in so many libraries defining their own ad-hoc type systems (i.e. JS itself [and TypeScript] one way, Apollo [GraphQL] another way, React prop-types another way, any object validation tool another way, etc.).
What is the work around for this? Multiple Rails apps a al microservices, if the app grows?
I think the directions are to either embrace what Rails is and isn't and build a "majestic monolith", or break an app into services over time.
We're probably through the looking glass in terms of people going crazy with microservices and then coming back to feeling like monoliths aren't so bad after all.
Personally, I think there's a goldilocks zone where an org just gets good at spinning up Rails apps, and each one is a "service". Some could see it as overkill to have "a whole Rails app" for a small service, but orgs that get good at this seem very productive. They can generally share libraries and engines, but also operate in isolation and have a lot of conventional functionality right out of the box.
And to be clear, Rails can be modular, it's just pretty convenient within the framework to not worry too much about that.
I think the back-end community just needs to get over monolith-shaming. There's nothing wrong with having one big app where all the parts perfectly fit together.
What's the point of losing the performance benefit of not having countless abstraction layers between your application's components, when you don't really need any of the benefits?
"Know what you're making" is really the one and only answer to so many of these A vs. B discussions.
I agree with allowing for some monoliths, but I also think rails API needs to advertise stronger as a potential microservice option. It's sad to see everybody choose flask or express. I imagine some percentage of those devs would actually enjoy convention over config, if they considered it a viable option.
FYI:
Bring Clarity To Your Monolith with Bounded Contexts (2016; YouTube)
I love Rails, its what kickstarted my web dev career. I also really prefer using true intellisense, and I think the Rails "magic" gets in the way of that. I still think we can make a good intellisense tool for Rails, using static analysis, (sorta like rust-analyzer)
Rails is in this cosy place where it's well established, and the pros outweigh the cons by a lot in terms of productivity, but it's also very boring because of this.
Personally I like working with rails at work, but I'd rather learn COBOL than use it for any personal project just for how amazingly uninteresting it is. At every step it keeps you from making exciting, but also irresponsible decisions.
The danger, I think, lies in confusing these two aspects. Nobody should want an "exciting" tech stack at work. The less surprises, the better, really.
I'm not in the loop regarding this one - can you give more details about that?
Edit: Okay, I saw your comment below now. I think Elm community has similar issue now because of it's author.