Neutrino only babel-compiles first party source (the JSX -> JS transformation is handled by a babel plugin). It does this because even when using the module entry in package.json, it's expected that the provided file (and it's imports) still be JS and not in some other format - ie: the only difference from the content in main should be that it can use modules syntax (that is import and export rather than require etc).

One thing that matters is if code uses browser-specific (example: Dom) or server-specific (example: filesystem) features.

Input: JavaScript with stage 4 features or older, in ES modules. Output: whatever JavaScript runs best on the target platforms.

The use of a bundler to create a file(s) suitable for running on a client.

It allows the module code (and subsequently dependants on the module) to not use preprocessor hacks, source code changes, or runtime detection hacks to identify which code is appropriate when creating a client bound package.

The browser field is where the module author can hint to the bundler which elements (other modules or source files) need to be replaced when packaging.

When a javascript module is prepared for use on a client there are two major concerns: certain features are already provided by the client, and certain features are not available. Features provided by a client can include http requests, websockets, dom manipulation. Features not available would include tcp sockets, system disk IO.

You can simply prevent a module or file from being loaded into a bundle by specifying a value of false for any of the keys. This is useful if you know certain codepaths will not be executed client side but find it awkward to split up or change the code structure.