3 ms·
I'm working with Rails for 17 years now, still love it and still prefer it even for the frontend. It give you all the options to separate your code without the
by TomK32 2y ago
I'm working with Rails for 17 years now, still love it and still prefer it even for the frontend. It give you all the options to separate your code without the head of your files becoming a unnecessary long list of `includes` like I see in the angular app I have to work on for a client. I don't see a disadvantage in splitting logic and markup for the frontend, it allows you to test the logic independently and normally when you hunt a bug you should know whether it's in the markup or the logic. Tracking down a bug thus becomes more easy.
I've written my fair share of far too long ruby methods, 200 lines and more, but those are truly my fault. With a more granular unit test regime those can be prevented.
- Etheryte 2y agoYou know what else allows you to avoid having that long list of includes? Making everything global. I'm not sure if I see this as a benefit. Imports can take up a lot of space, yes, but they also make it explicit how everything ties together. If they're in your way, you can always have your IDE collapse them.
- axelthegerman 2y ago> but they also make it explicit how everything ties together So does the autoloader used in Rails, it's called convention over configuration. There are only very few places it will look for the code (and in production everything gets preloaded too) So unless you want your class User actually in iMeanThisUser.ext or ../../../a/random/path/that/makes/no/sense/user.ext you shouldn't need explicit configuration