8 ms·

Tree-shaking also.

jampekka 2y ago
Static analysis and tree shaking have been done with CJS for about a decade. https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d...
- wffurr 2y ago
  In a limited way due to side effects from the require function. Reading that rant, the author did not seem to take much time to understand the rationale behind ES modules: “ yet for some completely unclear reason, ESM proponents decided to remove that property” is just pure ignorance.
  - jampekka 2y ago
    > In a limited way due to side effects from the require function. In a limited way that covers something like 99.9% of CJS usage. Bundling is based on static analysis. If by side effects you mean running code, not just declaring exports, ES6 import does these side effects too. Thinking that CJS can't be used for static analysis or tree-shaking is the widest spread pure ignorance.
- 9dev 2y ago
  The main argument in that post doesn't even hold; using ESM, you can always using dynamic imports: await import( someExpression ) Besides, static analysis and tree shaking completely break down if modules impose side effects from being required, which is one of the main gripes of Python as well. ESM completely alleviates that.
  - jampekka 2y ago
    That forces dynamic imports (and is horrible ergonomics as discussed in the post). CJS requires can be statically analyzed to figure out whether a require can be static, as is done e.g. in all bundlers. ESM import runs side effects as well.
    - 9dev 2y ago
      We have had top-level await for a while now. I don’t know what’s so horrible about this: const app = express() app.use("/users", await import("./routers/users")) …if you’re so inclined to do things exactly as you did in the past. I’m pretty sure bundlers will even transform that into an ordinary module import. The cases where you actually need dynamic imports are few and far between. Are we actually talking about engine limitations here, or is it just a few snowflakes that insist on creating loggers like this? require("debug")("acme") What is so particularly pretty about that is beyond me. > ESM import runs side effects as well. At runtime, yes. Not during static analysis.
forty 2y ago
I'm doing server code (which I guess is the main use case for nodejs), I just COPY the project folder in the docker and ship that. No need for bundling, shaking and other annoyance.
- 9dev 2y ago
  You'd likely still benefit from using TypeScript and transpiling that to plain JavaScript (preventing a lot of subtle bugs), and tree shaking to minimize your Docker image size (yielding faster deployments).
  - forty 2y ago
    We do use TS already. And yeah sure, we could save a second or two on our deployment, but I'm not sure that's worth the mess
    - 9dev 2y ago
      In case you ever get to that point; have a look at Unbuild (https://github.com/unjs/unbuild https://github.com/unjs/unbuild). It's what Vite uses for their own builds, and really painless to set up.
      - forty 2y ago
        Haha I'm probably getting too old or something but I really cannot see what this tool does exactly and why I'd need it. I have been working on what is now a fairly large typescript/nodejs monorepo (over 1M LoC) for the past ~13 years, and we can simply build it all with tsc -b, and COPY it in the docker image as I said, it's nice and simple and works great.
- WorldMaker 2y ago
  Tree-shaking also happens in GC heap space (both in the server and in the browser): V8 and SpiderMonkey and JavaScriptCore will all eventually treeshake unused code out of memory entirely. The ESM format was designed to allow that. Modules actually only reference each other through weak references and things like import * build proxy objects of weak references designed for tree-shaking. Depending on how your application is structured, an ESM version of a server-only Node application may still benefit from the performance optimizations of the server being able to do dead code elimination at runtime.

Tree-shaking also.

Static analysis and tree shaking have been done with CJS for about a decade. https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d...

wffurr 2y ago
In a limited way due to side effects from the require function. Reading that rant, the author did not seem to take much time to understand the rationale behind ES modules: “ yet for some completely unclear reason, ESM proponents decided to remove that property” is just pure ignorance.
- jampekka 2y ago
  > In a limited way due to side effects from the require function. In a limited way that covers something like 99.9% of CJS usage. Bundling is based on static analysis. If by side effects you mean running code, not just declaring exports, ES6 import does these side effects too. Thinking that CJS can't be used for static analysis or tree-shaking is the widest spread pure ignorance.
9dev 2y ago
The main argument in that post doesn't even hold; using ESM, you can always using dynamic imports: await import( someExpression ) Besides, static analysis and tree shaking completely break down if modules impose side effects from being required, which is one of the main gripes of Python as well. ESM completely alleviates that.
- jampekka 2y ago
  That forces dynamic imports (and is horrible ergonomics as discussed in the post). CJS requires can be statically analyzed to figure out whether a require can be static, as is done e.g. in all bundlers. ESM import runs side effects as well.
  - 9dev 2y ago
    We have had top-level await for a while now. I don’t know what’s so horrible about this: const app = express() app.use("/users", await import("./routers/users")) …if you’re so inclined to do things exactly as you did in the past. I’m pretty sure bundlers will even transform that into an ordinary module import. The cases where you actually need dynamic imports are few and far between. Are we actually talking about engine limitations here, or is it just a few snowflakes that insist on creating loggers like this? require("debug")("acme") What is so particularly pretty about that is beyond me. > ESM import runs side effects as well. At runtime, yes. Not during static analysis.

forty 2y ago

I'm doing server code (which I guess is the main use case for nodejs), I just COPY the project folder in the docker and ship that. No need for bundling, shaking and other annoyance.

9dev 2y ago
You'd likely still benefit from using TypeScript and transpiling that to plain JavaScript (preventing a lot of subtle bugs), and tree shaking to minimize your Docker image size (yielding faster deployments).
- forty 2y ago
  We do use TS already. And yeah sure, we could save a second or two on our deployment, but I'm not sure that's worth the mess
  - 9dev 2y ago
    In case you ever get to that point; have a look at Unbuild (https://github.com/unjs/unbuild https://github.com/unjs/unbuild). It's what Vite uses for their own builds, and really painless to set up.
    - forty 2y ago
      Haha I'm probably getting too old or something but I really cannot see what this tool does exactly and why I'd need it. I have been working on what is now a fairly large typescript/nodejs monorepo (over 1M LoC) for the past ~13 years, and we can simply build it all with tsc -b, and COPY it in the docker image as I said, it's nice and simple and works great.
WorldMaker 2y ago
Tree-shaking also happens in GC heap space (both in the server and in the browser): V8 and SpiderMonkey and JavaScriptCore will all eventually treeshake unused code out of memory entirely. The ESM format was designed to allow that. Modules actually only reference each other through weak references and things like import * build proxy objects of weak references designed for tree-shaking. Depending on how your application is structured, an ESM version of a server-only Node application may still benefit from the performance optimizations of the server being able to do dead code elimination at runtime.