Introduce SUPPORT_SHELL, SUPPORT_NODEJS, SUPPORT_SPIDERMONKEY, SUPPORT_IE11 etc. -s settings

[juj]

Currently we diligently make the build outputs executable in all environments that we possibly can, i.e. the same .js file is possible to be run in all possible browsers, but also in shells like node.js, SpiderMonkey, etc.

I think we should migrate to a model where we make compile time choices about which compatibility support to add in. That is, have -s SUPPORT_NODEJS=0/1, -s SUPPORT_IE11=0/1, etc. style of parameters, to allow controlling what kind of compatibility fallbacks we want to have.

By default, all of these flags would be enabled, to keep everyone getting every target out of the box.

The motivation from this comes from the observation that when one is targeting a browser-only html file, there is relatively much redundant code that is added in the runtime to also enable support for node.js and SpiderMonkey, which the developer might not be interested in the slightest. Same goes for the opposite direction, i.e. one might only be interested in running the build output in a specific shell, and not at all in the browser. With these types of compile-time targets, we would be able to much more aggressively dead code eliminate out unnecessary runtime bloat.

For some things, I feel that we could even have trinary configs. For example with IndexedDB, we could have flags

-s TARGET_INDEXEDDB=0 // Make a compile time choice to not to support IndexedDB at all, i.e. output code that knows at compile time that IndexedDB will not be available and should not be referred to.
-s TARGET_INDEXEDDB=1 // Enable targeting IndexedDB at runtime if possible, with potential fallbacks if not available (default)
-s TARGET_INDEXEDDB=2 // Make a compile time choice to require support for IndexedDB. If IndexedDB is not available, do not attempt any fallbacks, and then the page does not need to run at all.

(or -s TARGET_INDEXEDDB='no', -s TARGET_INDEXEDDB='runtime', -s TARGET_INDEXEDDB='compiletime' respectively, if we wanted to use strings)

Similar trinary treatment could be given to items such as -s TARGET_WEBAUDIO, -s TARGET_AUDIO_TAG, -s TARGET_OFFSCREENCANVAS, -s TARGET_WEB_WORKERS, -s TARGET_PERFORMANCE_NOW and the existing -s USE_WEBGL2 flag.

These types of settings would give ways for developers to specifically target desired runtime configurations and shipped web specifications. Some developers might not be interested in having any WebGL 1 fallback code around, and others might not want to pay for the code size related to being aware of running in a web worker configuration.

For difficult version-related items, we could take the approach of -s SUPPORT_FIREFOX_VERSION=55 to allow one to specify at compile time the minimum Firefox version they expect to have present, and same for other browsers. This would allow gating out old compatibility code that assumes things based on a version, such as this commit cab6be0 which is quite inconvenient.

The idea is that all of these flags would default to "support everything" mode, so that the current convenience for getting started and compatibility is retained, but that people would be able to tune knobs to allow dead code eliminating. This could be a good way to phase out legacy cruft, such as the horrors we have with all browsers handling fullscreen mode switches wildly differently.

Previously we have done some "indirect deductions" about what can be dropped. For example, we know that when we are targeting WebAssembly only, then performance.now() is guaranteed to exist in the browser environment, since all browsers that ship WebAssembly have done so a long time after they added performance.now(). However these types of implicit/indirect deductions are difficult to follow if one does not know the timeline history of these, so the explicit scheme of a -s TARGET_PERFORMANCE_NOW would be a better explicit way to proceed.

The downside is that this would possibly add a lot of new build options and preprocessing macros in code. Because of that, #5494 will probably be good to be addressed first.

[kripken]

In a previous discussion of a related topic, we added Module['ENVIRONMENT'] support, where the user can set that at runtime to force one environment to be used. We could allow setting it at compile time too. And then we could rely on js optimizations to fold away if (ENVIRONMENT_IS_NODE) { .. } code into nothing if we statically know the value of that constant.

[rawrmaan]

Being able to force the environment at compile time would fix this framework's compatibility with React Native. Right now you can't build for RN without commenting these two lines under the ENVIRONMENT_IS_NODE check:

    if (!nodeFS) nodeFS = require('fs');
    if (!nodePath) nodePath = require('path');

This is the case because RN's metro-bundler statically analyzes requires and throws when it realizes that fs isn't an available module in the RN environment.

[CMCDragonkai]

Will this also allow support of ES6 modules?

[juj]

Adding support for structuring as ES6 modules sounds like a good feature, though best to treat that as a separate bug item, since adding support for that will need introducing new code, whereas this item is mostly about adding compile time checks to dead code eliminate away already existing code.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.