3 ms·
>Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? My complaint is
by ramesh31 3y ago
>Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks?
My complaint is that I don't want things in my code affecting my code that aren't code. Most web frameworks avoid this, while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. It's kind of the same argument as SQL stored procs. Should you rely on embedding your business logic directly into the runtime? Probably not.
Ultimately it's just personal preference. But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO.
- shortrounddev2 3y ago> Most web frameworks avoid this I don't know if that's true, but I doubt it. > My complaint is that I don't want things in my code affecting my code that aren't code Many things affect your code under the hood that you don't see. There is no difference between using a decorator/attribute and having a config.json file for other things. > while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. Because they are responsible for larger services which need to be more maintainable and stable. > But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO. This would preclude ever using a programming language or framework which you don't already know. You have been taught to write web services in one particular way; the fact that you don't know other ways doesn't make them "unreadable", it just means you don't know how to read it