Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Here's how i replace Rails with the "modern stack":

- Compile Graphql schema into Typescript typings + Fragments for "Active Record"

- React Hooks as controllers action.

- React Suspense for HTML rendering.

- Apollo for graphql caching

- ExpressJS for middlewares.

- @reach/router for routing.

- @loadable/component for code splitting.

- Serverless for API.

I missed Rails, too. But i found that the "modern stack" is not bad at all. It just needs more time to investigate to find out the best way to reuse features.



Your post is a perfect example of why the "modern stack" is a horrible developer experience (and lets be honest, probably crummy user experience) compared to Rails.


You're absolutely correct at current moment.

I hope the DX will get better soon. But this stack beats rails on scalability, universality, user experience, and many more. It's a trade-off that i found worth the effort.


This sounds exhausting! But I'm betting there's some pretty solid benefits or you wouldn't do it. Could you expand on why someone might pick this a little?


The main benefit i got is that, i could independently package SSR React Component, then my application is just a composition of those packages.


Honestly, this is such an un-sexy answer that it might shock some sense into people that are still on the fence. It might not be too late for you.

Seriously, gang: Rails is productive, fun and lets you focus on making your customers happy instead of optimal package composition.


I was a Rails user for about 4 years. The DX of Rails is unbeatable still today.

But this is a trade-off i take into account.

I even have a production system running on Rails, with frontend React.

This stack's benefits to me:

- Universality (one Typescript to rule all backend and frontend)

- Separation of concern (no more MVC, only components)

- Scalability (each part could scale independently)

- Modularity (the business logic now could have its own service as a graphql API)

- User interactivity in less code (this is why SSR with React)

My new application on this "modern stack" is nearly to be released. If you want to know more, ping me on twitter @revskill.


I guess this just seems like a massive amount of hoop jumping that, from the outside, looks like OCD levels of premature optimization for future demands that might well not occur.

Put differently: how much more time and energy would you have had to work on your MVP if you had just used Rails?


Actually, the time spent to setup correctly all the toolings is much more than the MVP itself. The ratio is about 6/1. Once setup, it took me about 1-2 weeks to complete a MVP.

Want new feature ?

- Add a graphql API (if not exists) and compile to Typescript typings.

- Develop and deploy a React Component for that feature.

- Install and add to the application.


Let’s talk in 6 months as those packages evolve and diverge. While rails core team does the work of maintaining all the packages as a consistent whole.


Sure. This is both sides of a coin. Or we get freedom and take care for it with responsibility, or we're stuck inside a box.


You can’t “take care of it with responsibility” if you have a lot of dependencies since you don’t control the library’s maintenance, or how it evolves with other libraries. So then you have to chose between adding dependency (with very real maintenance downsides) vs writing things yourself and reinventing things that should be solved.

Further, being stuck in a box also means that the community can rely on that very box and add more extensions with the architecture of the box in mind. A box gives assumptions to build on top of. Sure if you really really need a triangle it’s painful, but then you should ask, do I really need a triangle?

I think the real insight of DHH is that most web apps are not as “unique” as developers would like to believe and that the harmony that comes with conventions, the speed that comes with a unified end to end integrated system, and the focus developers gain for actual impactful choices when many unimportant choices are made for them is an amazing improvement.

He said recently, that insight is as controversial today as when he launched rails, and he is surprised more rails competitors haven’t emerged.

I think the first end to end GraphQL > Single Page App framework that has a similar level of integration to rails will dominate.


This strikes me as being more archaic than modern.


Except the stack is deployed as a lambda function.


... you had me up until "Serverless".


Actually, this stack is deployed as a serverless function ! "Serverless for API" means i could use any language to develop API. Serverless provides better scalability in my opinion.


Do you have any code samples for this? Sounds interesting.


It's private code. I'm writing a book on this topic and will release once it's done.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: