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

51–60 of 76 posts

Re: Why we have banned default exports in JavaScript

#51

Post by krzkaczor »

ef4 wrote: post #42

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.

I assure you that I know how static analysis work but how could you rename something that doesn't have any name? How could you perform "rename" refactoring on `export default function () {...}` since this expression is not associated with any symbol.

It's clear for me that in this case you could talk only on refactoring like "rename all default imports to:" This is different than simply renaming a symbol and I don't know IDE that supports this operation.

Re: Why we have banned default exports in JavaScript

#52

Post by kevin_thibedeau »

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.

OSV grammar is legitimate English.

Re: Why we have banned default exports in JavaScript

#53

Post by nycdotnet »

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 !?

Also the use case in Node of loading files from local disk is very different than the use case of loading scripts over HTTP in the browser.

Re: Why we have banned default exports in JavaScript

#55

Post by frankjr »

Default exports don’t export any name ie. symbol that can be easily associated with a exported value. Named exports, on the other hand, are all about having a name (pretty obvious right ) . This makes possible for IDEs to find and import dependencies for you automatically, which is a huge productivity boost.

There's no reason a default export cannot have a name.

  export default function foo() {...}
With this in place VS Code is able to auto-import the dependency and refactor its name if necessary.

Re: Why we have banned default exports in JavaScript

#56

Post by drinchev »

What I feel strange about default export is that you can actually mix it with named exports.

    export default class Foo { }
    export const Bar = "";
and then

    import Foo, { Bar } from "./module"
I would expect if a module has a default export, then it should not have named ones. Why? At least it puts more structure in your code architecture.

Re: Why we have banned default exports in JavaScript

#57

Post by ricardobeat »

nycdotnet wrote: post #53
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 !?

Also the use case in Node of loading files from local disk is very different than the use case of loading scripts over HTTP in the browser.

Only this year the syntax for importing modules at runtime has been worked out. Current behaviour is exactly the same as commonjs and only useful for static analysis, 7 years later.

Re: Why we have banned default exports in JavaScript

#58

Post by [deleted] »

krzkaczor wrote: post #51
ef4 wrote: post #42

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.

I assure you that I know how static analysis work but how could you rename something that doesn't have any name? How could you perform "rename" refactoring on `export default function () {...}` since this expression is not associated with any symbol. It's clear for me that in this case you could talk only on refactoring like "rename all default imports to:" This is different than simply renaming a symbol and I don't…

[deleted]

Re: Why we have banned default exports in JavaScript

#59

Post by ricardobeat »

alangpierce wrote: post #46

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 ag…

I miss the simplicity of CommonJS.

> Ecma Script Modules which finally solved the problem of sharing code between files (modules) on a language level. It was a huge step forward

Step forward? We were writing modules just fine in 2010. I don’t know a single project off the top of my head that actually benefits from tree shaking. It has been 5-6 years since modules appeared and there is little to show for it. We could do almost the same with node’s commonjs. You could write code that would run anywhere without pre-processing or transpiling. Every time I see a project where the first three pages of documentation are about setting up Babel and webpack I feel like switching off.

Re: Why we have banned default exports in JavaScript

#60

Post by seniorsassycat »

krzkaczor wrote: post #51
ef4 wrote: post #42

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.

I assure you that I know how static analysis work but how could you rename something that doesn't have any name? How could you perform "rename" refactoring on `export default function () {...}` since this expression is not associated with any symbol. It's clear for me that in this case you could talk only on refactoring like "rename all default imports to:" This is different than simply renaming a symbol and I don't…

Your editor knows the symbol of every value referencing the default export. Try go-to-references on a default export.

If your IDE doesn't support rename-references that's your IDE's deficiency - not default exports.

Post reply on HN