Portability.
Say I wanted to make language X run on all platforms, but I didn't actually care about compiling it on all platforms. I can just write a relatively simple VM for each platform. This is one of the reasons Java was and still kinda is so ubiquitous
Why would it be less work? The interpreter will need to implement whatever operations a VM can perform, so a priori it's at least as much work. Bonus, if you can bootstrap the source->bytecode process, then you only need to write (and compile) that once to get a full-fledged interpreter on every host with a VM
As others mentioned, source code should be distributed that way, and I think creating a simple VM is easier than a simple language parser. But of course, an optimizing one can be really quite complex in both cases.
This is a Rust library for reading and writing the LEB128 integer compression format. LEB128 is a representation of arbitrary-size integers: https://en.wikipedia.org/wiki/LEB128
As I understand it, this library is optimized to avoid branching (which incur an overhead) and take advantage of SIMD instructions (which process data in parallel).
yes it is sub-optimal, but that is not because building it takes so much time, it is because of the node_modules. I am looking into migrating to Hugo as has been suggested by MANY people
yeah, that is a mistake. I just did not fully rethink my code when I moved the build layers. I will be removing that tonight along with a few changed suggested here
On a second thought, I also don't understand why do npm in two different images, why not just copy the webpack bundles from the builder image into the nginx image ?
For me the cause of the big image size was in
COPY --from=npmpackages /app /app
From your third Dockerfile, it seems replacing the above with the following would have done the trick without adding an extra stage
I do npm in two different images so that the node_modules can be cached between builds. this massively speeds up my build. The npmpackages layer only installs the npm modules