←back to thread

197 points onnnon | 1 comments | | HN request time: 0.197s | source
Show context
caseyohara ◴[] No.44502713[source]
> I know, we can vibe away all the boilerplate required for Rails apps. But how much fun is that? How much do you enjoy setting up RSpec, again, in your new Rails app? How tired are you of changing the “front end solution” every few years? And aren’t you just tired of debating where your business logic goes or if it’s OK to use HTTP DELETE (tunneled over a _method param in a POST) to archive a widget?

For your personal hobby project, go nuts. Break all the rules and cowboy all your own conventions.

But for business applications, the conventions Rails enforces at least make codebases somewhat familiar if you've seen a Rails codebase before.

At a certain codebase size, boilerplate is almost unavoidable. Unpleasant, but necessary. Personally, I'd rather have some conventions, rules, and guardrails for where the boilerplate lives rather than trying to navigate your homegrown pile of code. Good luck maintaining that spaghetti when you've got multiple developers.

It's not clear how this new web framework avoids boilerplate anyway, so I don't see how this is an improvement over Rails. Presumably you'll still need to set up lots of stuff yourself, like RSpec. If the framework sets all of that stuff up for you in a conventional way, then you're just back to square one as soon as you need to fight against the framework's conventions.

replies(3): >>44502836 #>>44503031 #>>44505426 #
1. ◴[] No.44502836[source]