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

Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

redfin.engineering

Post reply on HN
Print view View original

71–80 of 152 posts

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#71

Post by gridlockd »

wruza wrote: post #58
tlarkworthy wrote: post #3

Wow that was informative. So ES Modules is really about the Red functions [1] getting module support. I find it fascinating watching our understanding of async computation mature over the years. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

The last time I asked here why async-await is even a thing, when you can just introduce light/green threads, coroutines, you name it, everyone jumped that it is even better when you mark awaiting points explicitly. Now that it goes from a blog post of some popular language designer, seems no one gonna disagree. >async computation mature over the years A good thing, really, but would be much better if the experience f…

The reason why async/await is a good fit for Javascript is that it neatly wraps up asynchronous callback hell and Promises, which were already ubiquitous in Javascript code, because the web runtime enforces non-blocking IO.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#72

Post by DaiPlusPlus »

indeyets wrote: post #47

Sorry about nitpicking, but I feel that we shouldn't say that CJS has named exports. It does not. CJS has a single export which might be an object. And objects have named properties/fields. On the other hand, ESM CAN have unnamed "default" export and CAN have arbitrary number of named exports.

> On the other hand, ESM CAN have unnamed "default" export and CAN have arbitrary number of named exports.

And this is a constant source of confusion and frustration for me when working with so many npm modules lately...

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#73

Post by pansa2 »

gridlockd wrote: post #71
wruza wrote: post #58

Earlier quoted context omitted.

The last time I asked here why async-await is even a thing, when you can just introduce light/green threads, coroutines, you name it, everyone jumped that it is even better when you mark awaiting points explicitly. Now that it goes from a blog post of some popular language designer, seems no one gonna disagree. >async computation mature over the years A good thing, really, but would be much better if the experience f…

The reason why async/await is a good fit for Javascript is that it neatly wraps up asynchronous callback hell and Promises, which were already ubiquitous in Javascript code, because the web runtime enforces non-blocking IO.

Do Promises and async-await work together better than, say, Promises and Lua-like stackful coroutines?

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#75

Post by samth »

tlarkworthy wrote: post #3

Wow that was informative. So ES Modules is really about the Red functions [1] getting module support. I find it fascinating watching our understanding of async computation mature over the years. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

No, this is not correct. The split long predates async in JS The fundamental reason behind the difference between ES modules and CJS is that require() does synchronous I/O in a function, but that's not acceptable in the browser context. So you either need to make require an asynchronous function (meaning with a callback, back in 2010 when this happened) or move the I/O out of the execution of module itself, as import does.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#76

Post by wruza »

gridlockd wrote: post #71
wruza wrote: post #58

Earlier quoted context omitted.

The last time I asked here why async-await is even a thing, when you can just introduce light/green threads, coroutines, you name it, everyone jumped that it is even better when you mark awaiting points explicitly. Now that it goes from a blog post of some popular language designer, seems no one gonna disagree. >async computation mature over the years A good thing, really, but would be much better if the experience f…

The reason why async/await is a good fit for Javascript is that it neatly wraps up asynchronous callback hell and Promises, which were already ubiquitous in Javascript code, because the web runtime enforces non-blocking IO.

It may be the reason, but not the only option.

  function cpsfoo(cb) {...}
  function foo() {
    var thread = this_thread()
    cpsfoo(x => thread.resume(x))
    return thread.yield()
  }
Error and immediate cb invokation handling omitted for clarity. Similar wrapper or wrapper-generator (uncps(f), unpromise(f)) may be done for other primitives.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#77

Post by throwanem »

ThePadawan wrote: post #31
pjmlp wrote: post #13

Earlier quoted context omitted.

They might be great animals, but as you know here trying to have a picnick with them arriving as an uninvited gang doesn't turn out a great outdoors experience.

I can't say I have ever been bothered by hornets as opposed to wasps. (Central Europe)

US here, but I've never been particularly bothered by wasps, at a picnic or otherwise. I suppose it helps that I don't mind them, or mind sharing food with them; they're peaceful until given cause not to be, cleanly in their personal habits, and quite beautiful.

One of my earliest memories is of sitting on the open tailgate of my mom's truck, carefully holding a slice of pizza so as not to disturb the black-and-yellow mud dauber who had landed on it to nibble daintily at the edge of a bit of pepperoni. In the general run of human theory, I gather, such a moment should require all sorts of histrionics, but neither she nor I saw any need for them, and no one else was around to disturb her appetite or my fascination. On reflection, I suppose that moment must have done something to set a tone for my life in terms of my relationship with aculeates.

And it's not as if they eat enough for a human appetite to notice, anyway. They're hell on caterpillars - I've seen a few P. metricus foragers entirely depopulate a thriving fall webworm nest in the course of a couple of days - but, having never developed a taste of my own for such things, that really doesn't bother me. And I do very much enjoy watching them hunt!

Squirrels, on the other hand, can all go straight to hell.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#78

Post by cookiengineer »

wruza wrote: post #76
gridlockd wrote: post #71

Earlier quoted context omitted.

The reason why async/await is a good fit for Javascript is that it neatly wraps up asynchronous callback hell and Promises, which were already ubiquitous in Javascript code, because the web runtime enforces non-blocking IO.

It may be the reason, but not the only option. function cpsfoo(cb) {...} function foo() { var thread = this_thread() cpsfoo(x => thread.resume(x)) return thread.yield() } Error and immediate cb invokation handling omitted for clarity. Similar wrapper or wrapper-generator (uncps(f), unpromise(f)) may be done for other primitives.

> Error and immediate cb invokation handling omitted for clarity.

... but this is exactly the reason why callback hell existed. Error handling down the callback branches were a total mess, especially with networked state transfers.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#79

Post by Kinrany »

fireattack wrote: post #30
dbetteridge wrote: post #26

Earlier quoted context omitted.

1. Get the default export as x 2. Get the exported value x 3. Get all exported values and call the object x 4. Get the exported value x and call it y They're all different because they allow you to do different things, and fairly readable. Edit: Just realised dimgl said the same 45min ago, my bad!

I think people (like the author of this article) should explain the syntax of destructuring assignment {x} briefly to make it make more sense for the unfamiliar. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This looks similar to detructuring assignment, but it isn't:

- no recursive destructuring

- `import {y} from 'x'` is not the same as `import x from 'x'; const {y} = x`

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#80

Post by nailer »

masklinn wrote: post #63
kqr wrote: post #48

Earlier quoted context omitted.

Sure, but maybe upgrading the existing Python 2 code wasn't the problem: the vast majority of the Python 2 code alive when Python 3 was released was probably scrapped by the time Python 2 was EOL'd . Over a decade is a very long time for a codebase to live. (Again, there are exceptions, but the vast majority of websites or data processing scripts or whatnot are significantly re-written or decommissioned in – pulling…

> Porting Python 2 code to Python 3 was never the problem. You're, frankly, high as a kite. As the author of one such port on a large codebase, porting Python 2 code to Python 3 was absolutely a problem. The issue with 2to3 is that it assumed you'd do the conversion as a one-shot and straight flip over with entirely separate codebases (or dropping Python 2 entirely) from there on, which is completely insane. What the…

> You're, frankly, high as a kite.

https://news.ycombinator.com/newsguidelines.html

"Be kind. Don't be snarky. "

Post reply on HN