discussion: state and platform info shouldn't be required by js code

[afinch7]

This one comes directly from Philosophy section of the manual.

It will always be distributed as a single executable - and that executable will be sufficient software to any deno program.

Many recent changes involve giving deno programs/scripts/libs access to platform(I.E. build) and state(I.E. permissions) info. While not a bad thing in itself, these sort of features often lead bad practices. From my experience with browser code it's simply better to build code that doesn't need this info to function correctly. In cases where a platform simply doesn't handle some interactions the same way, we should be designing abstractions that actually deal with the root problem instead of expecting deno programs/scripts/libs to implement these workarounds(and thus not be inherently compatible with deno executable on all platforms).

This doesn't necessarily mean reverting these changes. The info they provide may still be needed for debugging, some tests, and error reporting, but I think focusing on some of the key problems, terminal support and file systems(maybe a virtual file system #1836), would be a good goal for future releases. As a clear and simple goal:
"The function of the utilities provided to programs and libraries should be the same on all platforms in respect to usability. "
Essentially when designing a program or library the target platform(s) shouldn't need to be a factor in the way it is designed. I still don't think there is a good way to apply this to tests, but that shouldn't be affect end users running programs.

Thoughts?

[kitsonk]

While you can abstract away most things within Deno, you cannot do that externally. For example Deno allows you to invoke external processes. Depending on the workload, a programme author would need to vary that by platform. There is no way you can abstract that, nor should Deno be in that business.

Permissions is similar in that authors of libraries used by others need to write code that behaves well no matter what the runtime state is, in order to ensure the correct behaviour of their code.

You can always write crap code. We can only do so much to prevent it.

[nayeemrmn]

Old issue, it's needed for plugins and plenty of other stuff.