2 ms·

I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code chang

I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code changes the behavior on 50 other pages. To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file. Especially for websites, the path to rendering a page should be pretty clear. Have some weird JS requiring menu functionality? Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu. Or yes, if you count the menu as part of those pages. Have some video player stuff? Well it is going to affect all pages where there is the video player. Something for forms? All pages where you have such forms. Then there are things like maybe animations or checkbox states. But I fail to come up with examples, where the scope of the change is so unclear, that one can't relatively quickly figure out what will be affected and what not. It must be some WordPress mess or something. Then I can imagine it. But with a site built from ground up? Nope, must be bad design or structure. Of course you could just have made up that example as a straw man as well.

Swizec 1y ago
> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file Yes and that’s normal. Big ball of mud is the worlds most popular software architecture. Original: http://www.laputan.org/mud/ http://www.laputan.org/mud/ My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popular-software-architecture/ https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popu... > Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu MVC frameworks, used traditionally, don’t support this super well. If you want some dynamic value in the menu supplied by the backend, every view has to make sure it passes that value into the template layer. Change the menu, gotta go around changing every view to supply that new value.
- threetonesun 1y ago
  MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.
  - Swizec 1y ago
    > why the menu is tied to the view at all, and not deriving its state from the user session Yes! But it turns out in some of these frameworks “the user session” is not a magic global, your view has to pass it into the template. And even if it was a global, you are super limited in how much derived data/queries you can compute off of it. Because you’re not using a full-powered language – instead it’s jinja, mustache, or similar.
fenomas 1y ago
This is doing the same thing described in the GP of your comment. If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.

Swizec 1y ago

> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file Yes and that’s normal. Big ball of mud is the worlds most popular software architecture. Original: http://www.laputan.org/mud/ http://www.laputan.org/mud/ My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popular-software-architecture/ https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popu... > Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu MVC frameworks, used traditionally, don’t support this super well. If you want some dynamic value in the menu supplied by the backend, every view has to make sure it passes that value into the template layer. Change the menu, gotta go around changing every view to supply that new value.

threetonesun 1y ago
MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.
- Swizec 1y ago
  > why the menu is tied to the view at all, and not deriving its state from the user session Yes! But it turns out in some of these frameworks “the user session” is not a magic global, your view has to pass it into the template. And even if it was a global, you are super limited in how much derived data/queries you can compute off of it. Because you’re not using a full-powered language – instead it’s jinja, mustache, or similar.

fenomas 1y ago

This is doing the same thing described in the GP of your comment. If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.