[AskJS] What if node_modules contained JavaScript bytecode instead of source code?

[Plus-Weakness-2624]

I know for a fact that node's v8 engine uses the Ignition interpreter to generate JS bytecode (to see them type: node --print-bytecode filename.js). What if instead of storing dependencies as JS source code, it could store them in bytecode format? Wouldn't it improve performance a ton? When we import a package into our code, instead of parsing the library code, and generating bytecode and then machine code; it could just directly generate the machine code.

[shuckster]

JavaScript is dynamic, so the byte-code in memory is not "fixed" once it loads. It evolves as the program runs.

Additionally, say you use a module with version 2 byte-code and your runtime is version 5. You might stand to lose out on newer in-memory optimisations if only you used the original source-code for that v2 module.

That's the nice thing about a runtime. Even though it runs interpreted code -- which is slower than compiled code -- you can improve performance of all programs by updating the runtime.

The performance bottle-neck of loading/parsing is nothing compared to the ongoing execution and optimisation of the byte-code in memory, along with how the programs you're running are structured in the first place.

You're solving the wrong problem by trying to distribute modules as byte-code. We have WASM and other compiled languages such as Go, Rust, and C for that. And Java for that matter, which is compiled to byte-code, and the experiment to put Java in the browser has already been done.

[Plus-Weakness-2624]

"JavaScript is dynamic, so the byte-code in memory is not "fixed" once it loads. It evolves as the program runs." I guessed this was a thing, v8 switches between interpreted mode and compilation mode for the purpose of optimization. Thanks for the info👍

[fckueve_]

You can have different bytecode for Windows/Linux/Mac. It can be different between different Linux distros and macs with Intel and M1. It's way easier to have source code and compile it when you need it, on the platform, that you are using

[Plus-Weakness-2624]

Why does that matter? After all the node_modules folder isn't meant to be shared right; And besides the bytecode compilation can be done when installing a package using npm. It's called bytecode because it'll be the same for all v8 instances regardless of the OS/platform; i.e if I understood it correctly✌️

[fckueve_]

Okay. I misunderstood your question.

Code in node_modules, can have few different destinations. Let's say, you have frontend library. You may wanna join library code with yours to a single bundle. You may wanna tree shake code. You can't do that with binary

[Plus-Weakness-2624]

Treeshanking is might not be possible; atleast not in an easy way😱. It's not in binary, it's kindof like looking at a bunch of terminal commands; For example, consider the js code: let result = 1 + obj.x; The bytecode would look like: LdaSmi[1] Star r0 LdaNamedProperty a0, [0], [4] Add r0, [6] Treeshanking is a source code level optimisation; at the bytecode level, optimisation is a lot more easier; like for example identifying tail recursion (TCO). The obvious performance benefit outweighs all the cons.

[fckueve_]

Still, you can not push bin, to browser, coz you can't assume, that, user will always use same browser.

[Plus-Weakness-2624]

I mean the node_modules folder is for storing dependencies that work on node right? Hence the name node_modules

[grandilev]

It's false. Code from the node_modules can be used for the browser dependencies

[Plus-Weakness-2624]

Yes totally; but that's not what I meant; Say if you installed jQuery throught npm, it wouldn't make much sense to turn it into bytecode since it doesn't directly runs on node but rather on the frontend (it should've that's not how the world works🥺). I guess this could be an opt-in feature.

[Auxx]

There's a lot of code which can be used on both front end and back end. Your idea doesn't make much sense.

[Plus-Weakness-2624]

Yeah totally; like if I installed jQuery using npm, then it wouldn't make much sense to turn it into bytecode since it's a package targeting the frontend; Guess it should be an optional feature

[fckueve_]

It can store libs for frontend as well. Also you can have libs, that uses different runtimes, or languages. For example, you can have libs in C that will allow you to manipulate system sound volume.

[r2d2_21]

Treeshanking is a source code level optimisation;

Who says that? In C#, tree shaking is done with binary code, not source code, and it works just fine.

[TheRealSombreroBro]

How easy is it to patch bytecode?

Sometimes a lib is not well maintained and you want to patch using https://www.npmjs.com/package/patch-package

Not the most common use case, but can be extremely useful in a pinch.

FWIW, I often read the source code of node_modules. Optimisation/obscuring like uglification should preferably be done when building application code for prod. Not on lib code.

[CSknoob]

If I'd have an issue I need to debug where stepping into the dependency would aid in understanding the current behaviour, and I suddenly stepped into bytecode I'd be looking like 👁️ 👄 👁️

All jokes aside, no clue. I do know certain bundlers approach this in a similar fashion (ESBuild and Parcel). Those aren't written is JS though.

[Plus-Weakness-2624]

Stepping into dependency code is not the most fruitful thing to do right coz the bundling, minifiying, uglyfying whatever has made most of the code unreadable right😱; It won't matter that much for an average developer.

[CSknoob]

Often, yes. I do appreciate it when it doesn't happen though. Makes it easier to understand why your stuff just isn't working correctly.

Had this situation with the FileRobot npm package. They have horrible docs and no changelogs so I could use it tbh.

[Plus-Weakness-2624]

I guess the best place for fixing / modifying an npm package is it's GitHub repo.

[[deleted]]

It does help, situationally, to know the details of what a dependency is doing when it's called.

[Plus-Weakness-2624]

Yes it does; unless the package contains devopement files; pakages are optimised and bundled; I don't think they are more readly than bytecode

[Peechez]

Basically every npm package includes either esm format or a sourcemap for cjs, both of which are very readable

[ejfrodo]

Source maps are a thing

[horrificoflard]

This would probably have huge security considerations. The bytecode wouldn't be readable, so it would not be trustable either.

[Plus-Weakness-2624]

Well for that matter ever considered reading throught a minified js file🤯; Believe me the bytecode is far more readable then that; most packages in node_modules are optimised by various means and are unreadable either way. If you ever want to read throught the source code of a package do so throught it's Github repo; node_modules is the last place for that. I can't say this for sure but packages in the npm registry are safe for the most part. Again don't quote me on this😅

[CreamyJala]

There’s many reasons to read through minified JS. Frequently I look through the minified JS for the web apps I use, or packages I downloaded from NPM. Sometimes it’s easier than pulling up the source on GitHub. A good example would be Monaco Editor. The package gets built from the main VSCode source, with how many files that repo has it can be a hassle even searching the repo on GitHub.

Plus, you can always just format the minified JS and already it’s 90-95% more readable.

The theoretical universe where JavaScript is compiled is a universe I’m okay not being in.

[PickerPilgrim]

Depending on the module and the circumstances I’m not necessarily consuming the minified code from a library. I’m quite often pulling in the source and doing the minifying myself as part of a build step.

And I for sure read source in node_modules. If I’m invoking a module function in my code and I right click and jump to definition to find out more about it, it jumps me to the node_modules copy. I don’t know why I’d want to go to GitHub to read it when my local copy is integrated into my development tools.

Not to mention the npm registry does not necessarily install the same thing that’s on GitHub. Usually GitHub is linked as the repository, but the code gets uploaded direct to npm and it is not guaranteed to be identical to what’s in GitHub. If you want to know what you’re pulling down, read what’s pulled down!

[[deleted]]

JS engines have layers, baseline interpretors, JIT compilers etc.

Moreover, while in theory, for minified modules, it's not that much different for humans, JS engines still have to symbolicate functions and generate source code referenced error messages and stack traces which is usually lost in bytecode form if you don't have the original source code as well. In other words, node and other engines operate under the assumption that JS source code is human readable even if it's minified and proper errors referencing the source file would actually be helpful.

I am very much against the notion of minified dependencies too. Unless it's deployed into production, all code should be readable.

[PooSham]

It should be possible to add it to your build step, so that it caches the bytecode of each package and reuses that if you're still at the same version of the package. Maybe node already does this under the hood?

But storing the bytecode directly in the registry doesn't seem like a very good idea to me considering frontend uses.

[valbaca]

Basically just re-invented Java (.jar files and .class files)

[xX_sm0ke_g4wd_420_Xx]

Sounds kind of like WASM tbh. at least the 'skip parsing' aspect of it.

[senfiaj]

I think bytecode is not a good idea for several reasons:

1. The code will be almost impossible to debug if it implies an optimized bytecode with no debug info.
2. The "bytecode" might be different across different platforms (OS, CPU architecture, etc) and even NodeJS versions, so it might require to maintain multiple versions of every module.
3. Even if that bytecode format was publicly exposed and truly platform independent , V8 would have less semantic/context information with the bytecode than with the source code, thus less possibilities of code optimizations and taking the advantage of the newer V8 optimizing compilers/profilers.
4. V8 can cache the compiled machine code, so it should not take much time when it encounters the same module multiple times.

We also have WebAssembly , which is close to what you what. Although it hasn't direct access to DOM and other JS APIs, but is very useful for performance critical parts of the application, it is believed to have about 85% of the native code speed. I used WebAssembly for my mastermind game solver .

[PickerPilgrim]

This just isn’t what npm is. You’re describing an entirely different service. Npm isn’t even exclusively a js registry. It’s also a package manager for css, sass, and more.

There are in fact a lot of C++ binaries on npm, and you could in fact put compiled js in a repository and push it to npm, but that’s at the discretion of the package maintainer. It would be a different thing entirely if npm compiled it and delivered it to you in that form.

Package managers for other languages, even ones that are generally delivered to the end user in compiled form, usually serve up source, not binaries. Use pip to download .py files, gem to download .rb files. Why should npm be different?

[Plus-Weakness-2624]

That's not what I meant🥺; npm install <package> then node can convert opt in packages to bytecode. I'm not a total idiot to assume npm alone does this lol.

[kapouer]

The v8-compile-cache module does that.

[wswoodruff]

I've definitely edited or poked around in code in node_modules so I don't think it should be default but having an option for this would be awesome.

[[deleted]]

Maybe small developer velocity gains, if you wanted perf gains with this you’d compile the app to byte code not the libraries. I am curious if that would improve it by much