3 ms·
> I can't say i agree. Projects need idiom reflecting the particulars of said project. Rails as a framework, shouldn't impose idioms to the whole project. I di
by ryanbrunner 3y ago
> I can't say i agree. Projects need idiom reflecting the particulars of said project. Rails as a framework, shouldn't impose idioms to the whole project.
I disagree pretty heavily. There are certain things where it may be valuable for a project to have it's own bespoke idioms or conventions (if it was doing something especially novel because that's what was necessary to solve the problem), but there's all kinds of decisions where this level of uniqueness actively harms a project, because it's not something that developers should be expending energy on. How to log data, how to deal with basic straightforward security concerns, how routing should work, how to connect to a database, how to run routine queries and get an object graph back are all boring problems with well established "good enough" solutions and no particular need to innovate, and expending cycles on those, either in initial development or when new people onboard is wasted time.
I can be pointed at almost any Rails repo and have a baseline understanding of where to find things on day 1. That is almost never the case with a Javascript project.
- jrumbut 3y ago> I can be pointed at almost any Rails repo and have a baseline understanding of where to find things on day 1. That is almost never the case with a Javascript project. And this is a problem that a type system doesn't fix. A type system can't tell you that all ACL logic is in the reporting subsystem for some reason or prevent two components from managing user state in incompatible ways. But every project will need to violate the conventions somewhere. If you just made all of the rules a baked-in part of the language you'd end up with a very inflexible language. There's a lot of power in encoding some things at the human level instead of the machine level.