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.).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.).