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

Why we have banned default exports in JavaScript

blog.neufund.org

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Why we have banned default exports in JavaScript

#11

Post by betageek »

iamleppert wrote: post #10

I'll preface this by saying I'm not a huge fan of ES2015 modules. Everything ES2015 provides (syntactical sugar) could be achieved with CommonJS exports. If you don't want to export an object and only a single thing, you can enforce those restrictions via code reviews, linting tools, etc. rather than bloating the language spec. And the backwards compatibility is very poor with older CommonJS (the weird __default stuf…

ESM is the standard now, the CommonJS ship has sailed.

Let's discuss IDE preferences, that's totally not something we've discussed a million times.

Good Point.

U R Very Smart.

Re: Why we have banned default exports in JavaScript

#12

Post by egeozcan »

z3t4 wrote: post #4

I can for my life not understand why the standards committee did not make the NodeJS module system the standard, what where they thinking !?

IIRC there were some technical challenges to implement the same structure on the client side. Also, they wanted to make imports declarative.

Re: Why we have banned default exports in JavaScript

#13

Post by kroltan »

iamleppert wrote: post #10

I'll preface this by saying I'm not a huge fan of ES2015 modules. Everything ES2015 provides (syntactical sugar) could be achieved with CommonJS exports. If you don't want to export an object and only a single thing, you can enforce those restrictions via code reviews, linting tools, etc. rather than bloating the language spec. And the backwards compatibility is very poor with older CommonJS (the weird __default stuf…

DCO is still important in libraries. If you have a large-ish library of mostly unrelated code (think lodash/underscore), DCO is pretty darn useful for the end users: you don't need to weigh in filesize (pun intended) as much when developing new features.

Re: Why we have banned default exports in JavaScript

#14

Post by jack9 »

iamleppert wrote: post #10

I'll preface this by saying I'm not a huge fan of ES2015 modules. Everything ES2015 provides (syntactical sugar) could be achieved with CommonJS exports. If you don't want to export an object and only a single thing, you can enforce those restrictions via code reviews, linting tools, etc. rather than bloating the language spec. And the backwards compatibility is very poor with older CommonJS (the weird __default stuf…

> I personally use vim and once I know a code base I rarely need to look stuff up.

Must be nice to work on stuff you're familiar with for years, day in and day out. That's not the use-case.

Re: Why we have banned default exports in JavaScript

#15

Post by kozak »

Semantic difference between default and named exports is that as a user of the module you are forced to choose a name for the default export, and these names will likely be different across different usages of the module. For linking units within one project, this is a bad thing, because you should be consistent in naming your things. But for modules that are published to the global NPM, maybe why not.

Re: Why we have banned default exports in JavaScript

#19

Post by k__ »

kozak wrote: post #15

Semantic difference between default and named exports is that as a user of the module you are forced to choose a name for the default export, and these names will likely be different across different usages of the module. For linking units within one project, this is a bad thing, because you should be consistent in naming your things. But for modules that are published to the global NPM, maybe why not.

If you import stuff from many libs, chances are they're named the same and you have to rename them anyway
Post reply on HN