Posted by stanislavb 10 hours ago
I gave RoR a try last year, and so far I'm at the same level I was with the other projects but I actually enjoy programming the project after the PoC phase. Maybe because third time's a charm? Maybe because I know what I need to do? Who knows! But RoR fits in that idiom.
Just to note, its a really boring app thats been done before (odeva.app)
I think once you're deep into a project, you of course know the features needed and the constraints and you'll be more efficient the next time around.
I think the challenge is to keep working on your old legacy projects.
Plus Symfony is quite flexible on how you want to organize your code. Modular monolith, monolith, DDD, microservices, "junior developer just setting up controllers and entities".
however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django
I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth.
But now, I use AI for scaffolding, and for my side-projects often never have to touch code.
So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI?
I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
Go and Rust fill in lots of gaps for more serious performance stuff.
I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
I started my dev career with php and then nodejs, but recently got a job with rails, and honestly, it’s the worst among the 3.
There is no static typing whatsoever, it’s littered with magically generated methods, on a moderate size project the controllers or models directories grow to dozen of files. In general it feels like you need a lot of mental context in order to work with Rails, and I believe this is the reason people who run it for 10+ years in production love it. They simply carry all the magic in their heads, rather than let the framework guide you.
I, however, get much more DX and production stability by building with a boring (router + server side rendering) NodeJS stack with typescript and schema validation. My services are more stable and do not crash on “undefined method foo for nil”.
I guess people will defend whatever they know best, even if it has quirks.
On a positive note, I like ruby as a language. It has cool features like pattern matching, named arguments, or dropping verbose statements like “return” at the end of the function.
However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lot of times, there is not even SQL injection prevention in them.
Compound this with someone who just vibe codes their app on top of these frameworks - that's how you end up getting hacked. Every week there is an incident. That's why good frameworks like Rails are very important. People who actually care about writing secure, good quality software are on the decline, but thank God rails still exists as an option in 2026 despite the fact.
JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.
That said, absolutely worth a look.
But you can also pick tight packages that do one thing well. Something like oRPC + Drizzle that lets you pipe data from your database to frontend with full typing and cross-boundary go-to-definition while covering most of what Nest and Adonis do with better focused APIs.
And in terms of security, I'll take Typescript with a strong compiler config anyday. For example, I disable: `any`, non-null asserts (no `!`), floating promises without `void` for explicitness, no unnecessary conditions, and a bunch of other strict rules. I also use Branded Types liberally. All of that makes logical errors that can become app-specific security issues (and are thus less readily detected) much less likely to happen. And as a bonus you get really reliable code too.
that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages.
edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever.
i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.
I’m usually a Go person and love it, but building simple crud routes is not the fun part of it.
As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive.
Due to my experience with Tcl, and continuous rewriting into C modules, if a JTI isn't in the box, I kind of don't bother unless it is due to external factors.
Not until they get their gradual typing story straight.