3 ms·
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
by 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.