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

41–50 of 76 posts

Re: Why we have banned default exports in JavaScript

#41

Post by hungerstrike »

Well, the most widely used style guide [0] and Facebook and many others including myself disagree. I'd rather see default exports everywhere so I only ever have to import one thing from your file.

None of the points made in the article are even valid.

1) You don't get better DX because you simply cannot use the same symbol name everywhere all the time anyway because names clash.

2) With point 1 gone, point 2 is wiped out as well.

3) This is patently false.

[0] https://github.com/airbnb/javascript#modules--prefer-default...

Re: Why we have banned default exports in JavaScript

#42

Post by ef4 »

I keep seeing this misconception repeated.

Both default and named exports can be rebound to new symbols locally. But that has no effect on how statically analyzable the code is.

“It can’t be auto refactored” just isn’t true. If it’s true for your particular tool, file a bug.

People are using a cargo cult understanding of how code analysis works. It’s not just grepping for a string.

Re: Why we have banned default exports in JavaScript

#43

Post by domenicd »

The historical claim, that default exports we're introduced for compatibility with CommonJS/Node, is not accurate.

Default exports were introduced because often a module wants to export a single value or piece of functionality. In such cases, in module systems where all exports are named, the author of the module and its consumer have to coordinate on some convention to indicate "this is the thing". For example, some languages choose the same as the file name (with fun casing consequences or conversions). Some choose a particular name like "t" (I've heard one of the MLs does this). Some don't have a convention at all and you have to consult the documentation for each import.

When designing JS modules, we decided to bake in a single somewhat-privileged export name for these cases, "default", which gets nice syntax on both the export and import sides to help encourage ecosystem standardization and coordination.

You can choose to deviate from it, in favor of your own convention. (It seems like the author prefers some kind of filename-converted-to-camelCase for their projects.) But do so being aware you're walking away from the ecosystem affordances and it will be unexpected for your consumers.

Re: Why we have banned default exports in JavaScript

#44

Post by captainmuon »

As someone who only occasionally uses JavaScript, module imports are really confusing. Often, I want to do

    import * as mymodule from './mymodule'
Namely, treat the whole module as one thing, and give it a name. It would be great if you could do that without specifying the name manually, e.g. like "import mymodule" in Python.

The other times, I do:

    import SingleClass from './singleclass'
    # or
    import {SingleClass} from './singleclass'
Its rather rare that I want a handfull of single things from a module - either one or all (all can mean "one object that has everything" or "all functions and constants in one wrapper", depending on how stuff is exported). The only time I need the `import {a,b,c} from './utils'` syntax is usually with a grab-bag util function module.

You get used to it, but I sometimes wish things were more like Python.

Re: Why we have banned default exports in JavaScript

#45

Post by sctb »

betageek wrote: post #11
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.

Would you mind commenting according to the guidelines instead of like this?

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

Re: Why we have banned default exports in JavaScript

#46

Post by alangpierce »

Default exports also have some oddities involving live bindings, since the typical syntax is to export an expression, not a binding, but there are workarounds to make it a real live binding. Here's a GitHub discussion where some people who are pretty good with JavaScript are trying to figure out how to properly implement default exports: https://github.com/rollup/rollup/issues/1078

Particularly this comment, which agrees that default exports were a mistake: https://github.com/rollup/rollup/issues/1078#issuecomment-26...

Re: Why we have banned default exports in JavaScript

#47

Post by camus2 »

dmitriid wrote: post #37
dmitriid wrote: post #35

Earlier quoted context omitted.

I commented below, but I'll comment here as well: import module.x IMO is much better: - It goes from "larger to smaller". You parse the line with your eyes and immediately see where things are coming from. With `import {x} from module` you have to do a double-take on what comes from where. - If you use any sort of code assist, you get to autocomplete immediately when you hit `.` With Javascript's weird thing you have…

Even PHP's approach makes sense compared to Javascript's: use Symfony\Component\Form\AbstractType; use Symfony\Component\Form\Extension\Core\Type\ChoiceType; use Symfony\Component\Form\Extension\Core\Type\DateType; use Symfony\Component\Form\Extension\Core\Type\EmailType;

PHP doesn't import anything this way though, it just makes the code aware of namespaces. The actual import is done with spl_autoload_register .

Re: Why we have banned default exports in JavaScript

#48

Post by alangpierce »

ljharb wrote: post #29

A default export is what a module is ; a named export is what a module has . Both tools are useful; both are necessary; most modules should have a single default export.

> Both tools are useful; both are necessary

Maybe a nitpick, but given that most other programming languages don't distinguish named vs default, it's probably not necessary. You can do all your programming where every module is something (like in Java) or where every module only has things (like in Python), but there's certainly value in being able to express one or the other in the same language. The downside is that the named/default distinction adds language complexity and learning curve, makes tooling support a little harder, and makes things like CommonJS interop more of a pain.

Re: Why we have banned default exports in JavaScript

#49

Post by sceutre »

chrisco255 wrote: post #23

Two of the three reasons listed involve refactoring and autocomplete quirks of Visual Studio Code, specifically. For instance, Webstorm has no such issues with default exports. It is smart enough to find all uses of a module and to track them down. The third reason is not all that common in my experience. Tree shaking is an optimization and often a premature one. It's also a technique primarily used for third party l…

In webstorm/intellij say you have a react component, one export per module as you say. The import statements are a tie imo to write by hand:

  import MyThing from "../../components/editors/MyThing";
  import {MyThing} from "../../components/editors/MyThing";
But if it's named, you don't need to stop what you're doing, scroll to the top of the file, type out the import statement by hand, and look over at your code tree and figure out the path to the module you want.

You just type MyT Ctrl-Space and let intellij do all that for you, not even having to move out of the function you're writing.

Re: Why we have banned default exports in JavaScript

#50

Post by k__ »

hungerstrike wrote: post #31
k__ wrote: post #22

Earlier quoted context omitted.

Yes, from 'module' import {x,y,z} would be nicer

No, this is far preferable to human beings who speak English: import {x,y,z} from 'module' Yoda from Star Wars might agree with your preference since he speaks backwards English. All kidding aside, I'd love to hear your logic about why you think the backwards version is better.

when I write the module before the parts, the autocomplete works better
Post reply on HN