4 ms·

I’ve never really understood why javascript developers hate global scope and state in general. I always make a point of having some form of app object that I c

I’ve never really understood why javascript developers hate global scope and state in general. I always make a point of having some form of app object that I can drill into and inspect from the console to see what’s going on anywhere in the application. It just speeds up development so much to be able to know what’s going on without having to set a breakpoint deep in some nest of function calls and hope you’ve been handed some form of scope that tells you what you need. It’s also handy not to have to pass a user object down through every single component in you app so that it trickles down to the corner of the navbar where you’re going to use it. I can certainly understand if you’re publishing a library that other people are going to use, you wouldn’t want to leak out of your own box. But when it’s your own app, it just feels silly to stick in these artificial restrictions so that some junior dev who took a functional class doesn’t make snarky comments.

mmazzarolo 5y ago
To me, there are two many reasons to avoid the global scope: 1. Like prototype extensions of JS types like "String", you're basically using a namespace that in the future might be used by a built-in API of the JavaScript engine — which would break your code. 2. You don't know for sure where your code will run in the future. A couple of years ago I worked on a migration where "standard" SPA were migrated to a micro-frontend app (where multiple SPA could be loaded on after another at the root level and each SPA would have to clean-up its own globals and listeners). BTW I'm not against it — I DO put some stuff in the global object. If you put your entire state in a namespace like __MY_CUSTOM_SPACE__ the risk of encountering those two issues is basically 0. But I still thing there aren't many valid reasons to do so, especially with nowadays' toolings.
jasonkester 5y ago
One thing I missed above is "But what about Testing???", since that's a common reason for building things this way. For me, the most important aspects of a codebase are "is it Readable" and "is it Debuggable". In my mind, the problem with building in a functional style for Testability sake is that you have to trade off a lot of Debugability to get there. It's the "know what's going on" bit I wrote above. For me, it's not an acceptable tradeoff. Bug reports come in from users as "debugging requests" rather than unit tests, so I want to optimize for that sort of future work. I actually wrote an article about this a dozen years ago [1] listing my priorities in a codebase, and I don't even think Testable made the list. I'm all for testing where it makes sense, but I'm not going to rearchitect my thing just so that testing is easier. [1] https://www.expatsoftware.com/articles/2007/06/getting-your-priorities-straight.html https://www.expatsoftware.com/articles/2007/06/getting-your-...
- mmazzarolo 5y ago
  At this point I’m not even sure if the post is talking about the same thing you’re mentioning. It’s not about “global state” in a sense of state available across the app, it’s specifically about not using the JS engine’s global object (https://developer.mozilla.org/en-US/docs/Glossary/Global_object https://developer.mozilla.org/en-US/docs/Glossary/Global_obj...) to avoid common pitfalls.

mmazzarolo 5y ago

To me, there are two many reasons to avoid the global scope: 1. Like prototype extensions of JS types like "String", you're basically using a namespace that in the future might be used by a built-in API of the JavaScript engine — which would break your code. 2. You don't know for sure where your code will run in the future. A couple of years ago I worked on a migration where "standard" SPA were migrated to a micro-frontend app (where multiple SPA could be loaded on after another at the root level and each SPA would have to clean-up its own globals and listeners). BTW I'm not against it — I DO put some stuff in the global object. If you put your entire state in a namespace like __MY_CUSTOM_SPACE__ the risk of encountering those two issues is basically 0. But I still thing there aren't many valid reasons to do so, especially with nowadays' toolings.

jasonkester 5y ago

One thing I missed above is "But what about Testing???", since that's a common reason for building things this way. For me, the most important aspects of a codebase are "is it Readable" and "is it Debuggable". In my mind, the problem with building in a functional style for Testability sake is that you have to trade off a lot of Debugability to get there. It's the "know what's going on" bit I wrote above. For me, it's not an acceptable tradeoff. Bug reports come in from users as "debugging requests" rather than unit tests, so I want to optimize for that sort of future work. I actually wrote an article about this a dozen years ago [1] listing my priorities in a codebase, and I don't even think Testable made the list. I'm all for testing where it makes sense, but I'm not going to rearchitect my thing just so that testing is easier. [1] https://www.expatsoftware.com/articles/2007/06/getting-your-priorities-straight.html https://www.expatsoftware.com/articles/2007/06/getting-your-...

mmazzarolo 5y ago
At this point I’m not even sure if the post is talking about the same thing you’re mentioning. It’s not about “global state” in a sense of state available across the app, it’s specifically about not using the JS engine’s global object (https://developer.mozilla.org/en-US/docs/Glossary/Global_object https://developer.mozilla.org/en-US/docs/Glossary/Global_obj...) to avoid common pitfalls.