Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CommonJS is hurting JavaScript

deno.com

Post reply on HN
Print view View original

31–40 of 134 posts

Re: CommonJS is hurting JavaScript

#31

Post by klodolph »

jhp123 wrote: post #15

the benefits of esm are not compelling enough to rewrite everything. Browser-native module loading is a niche use case which can never be as performant as bundling (even if per-request overhead is minimized in http2, a chain of dependencies will lead to excess round trips).

Bundling works better with ES6 modules. Compare the experience of using, say, browserify to rollup/esbuild. Plus, with ES6 modules, you can do bundling for your release builds, and do your development work directly with the original source files.

Re: CommonJS is hurting JavaScript

#32

Post by freedomben »

striking wrote: post #4

That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.

This is exactly my beef. The testability with commonjs is great, being able to easily mock dependencies is a huge boon for testing. I'd have no issue using only ESM if it had feature parity, or at least some way to achieve dynamic loading.

Re: CommonJS is hurting JavaScript

#33

Post by bdcravens »

yafbum wrote: post #27

> I really think that the needs of server side code are different enough than the needs of client side code that we’re better off drawing from Python and Ruby than from Dojo and jQuery. This sentence sounds ok until Python and Ruby are held as the apparent gold standard of server development. That's not really the case, I think?

Thinking back to when CommonJS was implemented, absolutely. I don't think you'd want to call Spring or ASP the gold standards.

Re: CommonJS is hurting JavaScript

#34

Post by freedomben »

yafbum wrote: post #27

> I really think that the needs of server side code are different enough than the needs of client side code that we’re better off drawing from Python and Ruby than from Dojo and jQuery. This sentence sounds ok until Python and Ruby are held as the apparent gold standard of server development. That's not really the case, I think?

Remember this was 10+ years ago. Many of the contemporary gold standards weren't fully a thing yet.

Re: CommonJS is hurting JavaScript

#35

Post by andrewmcwatters »

No, ESM spec writers are hurting productive developers. I literally never think about require or import, because they're not problems I have.

But now, I get to fight importing dependencies with cancerous ESM design and think about language basics, while spec writers revert us all to CS 101 students trying to figure out how to do elementary things.

Which isn't going to change any of my mature code, either, I'm going to wrap the entire script in:

    (async () => {
    })();
and then:

    const { default: foo } = await import('bar');
So, has anything meaningful changed? No. I don't need to tree shake on the server, and if you're tree shaking on the client-side, you've already screwed up, and you're too inexperienced to realize it.

Re: CommonJS is hurting JavaScript

#36

Post by geenat »

The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions).

We all lose the ability to simply have a local index.html file, and have it Just Work (TM):
This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery.

Deno doesn't care about retaining this level of developer experience because Deno is marketing its own runtime / build step / ecosystem.

Re: CommonJS is hurting JavaScript

#38

Post by olias »

striking wrote: post #4

That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.

Use vitest.

Re: CommonJS is hurting JavaScript

#39

Post by tracker1 »

Didn't see mention of Browserify and other bundlers after it that made CommonJS the defacto standard for client/browser libraries as well.

I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle.

Frankly, I like the Deno way of things better. I find it annoying, to say the least that the TypeScript team won't consider allowing you to import with a .ts(x) extension, and convert to .js(x) as part of the build process... no, you must omit the extension.

I've been using the import/export syntax since well before it was standardized via babeljs, these days I kind of want to remove webpack/babel from my pipelines altogether and mostly just rely on esbuild. I've also been using/following rome.tools development, having switched over several projects from eslint already, and will probably start with their bundler when it's ready.

I think there's a way to go with tree shaking and static analysis in that direction to reduce load. I also would not mind seeing the efforts to treat TS extensions as comments in the JS engines in that it would be easier to serve up straight TS/JS without bundling/minifying. I'm not sure we'll ever see a return to that in practical terms.

In the end, it's evolving. I'd also like to see Cloudflare, Deno and others come together on a more common server interface so that you can target multiple clouds with a single codebase. I don't know how well that would ever work out at this point though. There's aspects that I definitely like to all of them.

Re: CommonJS is hurting JavaScript

#40

Post by taink »

I wouldn't go as far as saying CommonJS is hurting JavaScript, but it's current status in the node ecosystem is definitely painful. I mean the default remains CommonJS, so using esmodules is awkward on 'native' node, but if you use the most popular bundling systems, the default becomes esmodules. I won't pretend I know which is better between the two, but the decision should be made to either make it optional or deprecate it if esmodules is really the Best Module System™. The current in-between is far from ideal, that's for sure.
Post reply on HN