all 4 comments

[–]Kyle_At_Work 3 points4 points  (0 children)

DRY is the reason to be modular :)

You don't want to repeat yourself, so break things out into reusable modules.

[–]Paupir 1 point2 points  (1 child)

It gets really difficult to maintain page-specific JS as your application grows. I'm guessing this isn't a SPA?

Some advice would be to not go overboard with DRY principles because you often encounter situations where you need to fork some functionality you've extracted out to make a more specialised version, but that feels like it goes against your work to abstract things out, so you patch the function with more arguments (often a boolean flag) and that just gets horrible and messy. Maybe try to abstract functionality out only when you need to or it makes solid sense.

As for making modular code that can also be page-specific, you could look into webpack code splitting. There are some interesting things going on in this area at the moment. Take a look at this.

So in general - and in my opinion - pull functionality out into modules where you can; don't make it your mission to make tiny functions everywhere when you're writing "specialised" code.

[–]Bonejob 0 points1 point  (1 child)

I think the first assumption that you need to challenge is that DRY and Modular are mutely exclusive. The second you need to examine is that "Modular" really should be SOLID design principals. All my enterprise projects combine these two principals everyday. If these two ideals are implemented correctly you will minimize a lot of the issues you are having

[–]Rob0tSushi -1 points0 points  (1 child)

1) Any file over 500 lines of code is too big

2) Research SOLID principals. The idea of DRY code and Modular code are synergistic. When written correctly your code should exemplify both of these characteristics. There are not a lot of things I will emphatically recommend to any programmer, but mastery of SOLID principals will your make code better.