8 ms·

It’s a solved problem? The most difficult to navigate and extended codebase I ever saw was a medium-to-large sized Rails codebase.

dilyevsky 5y ago
Just a simple matter of programming
valyagolev 5y ago
I absolutely agree with your comment and I’m sad that it’s being downvoted. Thing is, I see all the times web frameworks that would be used in those cases, but improve in many directions almost irrelevant for it. Performance? Ability to do same webapps in yet another boring scripting language? Very specific and rigid abstractions and fancy tools that provide for very little flexibility? Fancy reactive approaches that manage to turn the codebase inside out, create hard and undebuggable problems out of the easy ones, and sometimes provide random subset of guarantees of various degrees of usefulness (I’m actually a fan of FRP, just not the misuse of it)? Somehow Django, with its clear admin system and other out-of-the-box QoL modules remains as close to the most practical and useful approach as one can imagine. (Still even people who use it manage to reimplement its parts for no reason. Every sufficiently big webapp contains a bad, buggy, incoherent implementation of 90% of Django) There are incredible amounts of money and effort and time to be solved by creating frameworks and abstractions that help with the glorious use-case of “huge, annoying, evolving in all the wrong directions essentially CRUD app”. Yet we’re not even stuck with Django - I see webdev regressing into horrifying piles of JS…
bcrosby95 5y ago
Because Rails doesn't encourage modularization. It's fine at small sized codebases but eventually you want to "package by feature" (to borrow a Java term) rather than by layer.
- Lio 5y ago
  Out of the box rails provides Modules, Concerns, Engines and Gems as mechanisms to package by feature. If you want to back that up with static types Ruby > 3.0 provides that out of the box too. What is it you think it's lacking?

dilyevsky 5y ago

Just a simple matter of programming

valyagolev 5y ago

I absolutely agree with your comment and I’m sad that it’s being downvoted. Thing is, I see all the times web frameworks that would be used in those cases, but improve in many directions almost irrelevant for it. Performance? Ability to do same webapps in yet another boring scripting language? Very specific and rigid abstractions and fancy tools that provide for very little flexibility? Fancy reactive approaches that manage to turn the codebase inside out, create hard and undebuggable problems out of the easy ones, and sometimes provide random subset of guarantees of various degrees of usefulness (I’m actually a fan of FRP, just not the misuse of it)? Somehow Django, with its clear admin system and other out-of-the-box QoL modules remains as close to the most practical and useful approach as one can imagine. (Still even people who use it manage to reimplement its parts for no reason. Every sufficiently big webapp contains a bad, buggy, incoherent implementation of 90% of Django) There are incredible amounts of money and effort and time to be solved by creating frameworks and abstractions that help with the glorious use-case of “huge, annoying, evolving in all the wrong directions essentially CRUD app”. Yet we’re not even stuck with Django - I see webdev regressing into horrifying piles of JS…

bcrosby95 5y ago

Because Rails doesn't encourage modularization. It's fine at small sized codebases but eventually you want to "package by feature" (to borrow a Java term) rather than by layer.

Lio 5y ago
Out of the box rails provides Modules, Concerns, Engines and Gems as mechanisms to package by feature. If you want to back that up with static types Ruby > 3.0 provides that out of the box too. What is it you think it's lacking?