All code runs inside some kind of a framework. It might be just the OS process framework, which requires you to implement an entry point that handles command li

All code runs inside some kind of a framework. It might be just the OS process framework, which requires you to implement an entry point that handles command line args, and provides you with access to threads and I/o streams. It might be an http server framework, which hands you requests and waits for your responses. Or it could be the web browser framework, with its Page lifecycle and ui events. You're always in a box of some kind; frameworks typically do things like create a different shaped box within an existing one (eg react creates a reactive box inside the browser's event based one). They can create the same shaped box inside different outer boxes (eg a jvm in a web browser and a web server and a console app). Or they can just make a simpler, more task-specific box. Some frameworks are sandboxes - they don't let you even see the outer box (eg a page running in a web browser can't use the 'OS process' box that the web browser is in). Others give you a way to escape. Sometimes it makes sense to intentionally box yourself in. It makes code easier to reason about. If there's no possible way for code inside this box to directly access files on this server then a whole bunch of security risks become easier to evaluate. If there is simply no way for code in this box to be multithreaded, a whole lot of synchronization risks just go away.