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

31–40 of 76 posts

Re: Why we have banned default exports in JavaScript

#31

Post by hungerstrike »

k__ wrote: post #22
dmitriid wrote: post #18

I'd ban default exports if and only if JS had a Java-like import syntax declaration. import {x,y,z} from 'module' ^ this is an abomination

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.

Re: Why we have banned default exports in JavaScript

#32

Post by iamleppert »

dwg wrote: post #25
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…

Your comments don't scale well. Projects have dependencies from teams with various skill levels and external dependencies over most of which you have little or no control. For this and many others reasons "refactoring to simplify" often isn't an option. Similarly, tree shaking doesn't just apply to the code from your project. Also, what about the time when you first start on a project? Or maybe you're only working on…

If the source of the problems are external dependencies, which, as you stated, you lack control, how would you go about banning default exports in those libraries?

The correct and pragmatic course of action to address problems in code quality is to address them by refactoring, one file at a time. If you want to see the effects of explicit imports, go ahead and look at any large java code base. What ends up happening is fragmentation and enormous and tediously huge import declarations at the top of every file. Again, it's better to address the real problem and not the symptom of poor code quality.

Re: Why we have banned default exports in JavaScript

#34

Post by chrisfosterelli »

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…

Agreed, I'd argue the developer experience is often worse using named exports. I can find myself wondering 'What names does this module export again?' and it often can encourage putting only tangentially related things in a module together.

Re: Why we have banned default exports in JavaScript

#35

Post by dmitriid »

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.

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 to first type `import {} from module` and then go back to {} to invoke the autocomplete. This is especially infuriating when you don't really remember the name of the thing you're importing.

Re: Why we have banned default exports in JavaScript

#36

Post by alangpierce »

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.

How much code do you work with, out of curiosity? At my work, we have about 500,000 lines of code, and while I'm usually working on a specific part of that, modifying and interfacing with other parts of the code is common. And, of course, for new people and people switching teams, all code is unfamiliar. IMO, expecting people to "just know the code" is really unreasonable; working with code you're not familiar with is very common in software engineering, and our tools and practices should take that into consideration.

Re: Why we have banned default exports in JavaScript

#37

Post by dmitriid »

dmitriid wrote: post #35
hungerstrike wrote: post #31

Earlier quoted context omitted.

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.

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;

Re: Why we have banned default exports in JavaScript

#38

Post by Waterluvian »

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.

That's a good way of putting it. I often have modules that ARE one thing. By using the module, you're using the entirety of that one thing. For example, a JSX component.

Re: Why we have banned default exports in JavaScript

#40

Post by ljharb »

kroltan wrote: post #13
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.

default exports are precisely as tree-shakeable/dead-code-eliminate-able as named exports; this topic just isn't remotely relevant to the discussion.
Post reply on HN