Hacker News Reader

Comment by skohan | Hacker News Reader

Ironically this is exactly what I don't like so much about Rails. It's such a "batteries included" framework that if you want to do what Rails is good for, it's going to be super easy, but if you want to do something a little bit different a lot of times it feels like you have to almost break Rails to make it work.

To some degree I think it's a matter of taste, but I would much rather start from a blank slate, with a set of sensible tools to build my solution up from scratch, rather than having an almost finished product I have to carve my solution out of.

View on HN

> that if you want to do what Rails is good for, it's going to be super easy, but if you want to do something a little bit different a lot of times it feels like you have to almost break Rails to make it work.

I feel like this is implicit in the name: these are the guide rails, stay on them and you will deliver more value in less time than you ever have before. If you need to do anything where you have to leave them, you have deRailed the whole thing.

The train metaphor is actually a pretty good one.

> you will deliver more value in less time than you ever have before

I think this is arguable. It's also not that hard, for instance, to get a bare-bones node API up and running and pair it with a React single-page app. And that approach is more modular so you can replace components in the future in a way which is harder than with rails.

This gets a hard disagree from me. I _really tried_ to give the whole node + react approach a go because, to me, GraphQL & all the things you can generate with it is _magical_ (especially fine-grained authz with app-specific graphql directives - beautiful!). Singularly, the availability of xstate to replicate business processes identically between api & ui. So useful! So undervalued!

Then I ran into finding myself spending time on background jobs, authentication management (not the basic functionality but tinkering & modification past password reset / session management, blacklist/expiry if jwt's, etc), file upload integrations, db management (when not utilizing prisma or hasura), etc. High variety of effort spent on tasks where I found myself asking the question, "why am I having to work on this...?"

I still ship more in Rails. It's still a better tool for most things. There are cases where I'll reach to node when needs are simple and short-lived. Other tools have the potential to exceed Rails (and I hope they do), but they're not there yet.

One of my least favorite things about Rails, & one of the best ideas to emerge in the past decade or so, is react. The componentization of views driven by state is such a useful approach. Rails has historically had a has & belong to many relationship between controller contexts and views, which is essentially global and easy to get super confusing. React (and now browser-react aka web components) provide a better way of tackling this problem.

And... they hook up directly to my cache? They provide a great way of broadcasting dom updates directly? They interoperate with web components no problem where I need high fidelity interaction/performance? etc etc. Rails... has done it again.

No getting away from how useful it is.

For most of the professional work I've done, I'm doing a CRUD web app. So if Rails or Phoenix lets me get to market faster with a tested solution, I'm sold. I've even got a talk I used to give about getting Rails to work with a legacy database, which has gotten much easier from the early days.

Now that I'm hiring devs, I do not want to pay them to build a CRUD framework from scratch, I'd rather have them building business logic we can't get off the shelf for free.

But whatever ends up working for you is cool!

It’s hard to know what cases you’re discussing without specifics?

A majority of online information based systems take input via forms and retrieve data from a database based on that input.

This is where Rails is the GOAT.

Reply on news.ycombinator.com