Hacker News Reader

Comment by jeswin | Hacker News Reader

ES Modules are better in every way.

But I do believe they got the syntax wrong - should have been "from fs import { readFile }" so that auto-complete works. Python got that right, but that's the only thing Python got right ;)

View on HN

I tend to agree, but I’ve found it mostly doesn’t matter as I stopped typing import statements almost altogether. I type a reference to the thing I want to import, in the place I want to use it, choose a suggestion from the editor, and let the editor write the import statement as a side effect. It only doesn’t work when dealing with aliases, and even then only when something isn’t cached yet.

You can type the real name, import it with autocomplete, then rename the symbol (f2), which creates the alias.

I should’ve been more clear that I meant import specifier aliases. Eg in TypeScript, this is often determined by `paths` in tsconfig.json. It may also be controlled by `imports` in package.json, or any number of other tools and configs.

That doesn't work so well for default or wildcard imports.

(I'd argue that default + wildcard imports are bad, but ESM went out of its way to have them :shrug:)

It works okay for defaults IME, and yeah I generally avoid both but especially namespace (wildcard) imports.

We considered that syntax, but `from` was not a reserved keyword already, whereas `import` was, so the parsing situation with the actual syntax was much better.

    import "./foo_bar.js" (for FooBar)

why not just `import 'fs' { read }`?

I've been newly doing a lot more front-end development and I've been sort of impressed by the autocomplete. You start typing the name you want to import and it autocompletes the name and module that it comes from. That actually seems more useful to me.

Yep. Especially with relative imports, it’s easier to type `import { myHelperFunc` and let LSP complete `tion } from "../../../util"`.

> But I do believe they got the syntax wrong - should have been "from fs import { readFile }" so that auto-complete works.

Personally, I prefer the "import x from y" format because it makes it easier to visually scan where an import is coming from; fair point about auto-complete though.

You can work around this by typing your import statement inside-out:

import {} from 'fs';

Then move your cursor back inside the {} and you'll have nice autocomplete. Works with object destructuring, too.

I think that particular issue could be solved with tooling - if you can autocomplete from “package name” to a given exported identifier, you must already have a mapping from “package name” to “exported identifier” somewhere in your machine’s memory; duplicate this mapping and swap the keys for values, now “exported identifier” points to “package name” as well.

But I do agree that it should be “from ‘foo’ import { … }”, because then the code would look nicer.

> I think that particular issue could be solved with tooling - if you can autocomplete from “package name” to a given exported identifier, you must already have a mapping from “package name” to “exported identifier” somewhere in your machine’s memory; duplicate this mapping and swap the keys for values, now “exported identifier” points to “package name” as well.

Sorry I don't follow. What the "from ..." syntax does (when typing it) is to narrow down 10k possibilities (the set of all exported functions in all in-scope modules) down to a few dozen. How would this be possible otherwise?

Illustration:

Case 1: import <just about anything is possible here - can't auto suggest>

Case 2: from fs import <only fs functions are in scope, start autosuggesting on keypress>

I dislike the assumption that natural languages are a good base for the syntax of programming languages,

In my personal contrarian opinion I would have wanted something along the lines of

    import "url" with {namedImport}, defaultImport;

With other keywords like import assertion mixed at the same level

    import "url" assert {type:"js"} with {namedImport}, defaultImport;

I admit that `with` is not a great choice...

A core problem here is that modules are generally a unique key, but exported identifiers are not. My editor does what you're talking about, but can be unhelpful because if I type in "create" I get 83,000 results. That would be much more helpful if it were pre-filtered by module so I get 6 results instead.

I’m so used to fuzzy search at this point that it didn’t even occur to me, but yeah, you’re right.

I guess tooling can still provide a solution - a snippet on “import”, where the first tab stop takes you to the module path string, and the next tab stop jumps back to inside the braces?

I feel like it’s going to be an inevitable language update to allow that syntax. I’m surprised TypeScript hasn’t succumbed to the pressure to support that syntax, but they’re really strict about where they allow deviations from the JS superset.

> I’m surprised TypeScript hasn’t succumbed to the pressure to support that syntax

They won't do this without consensus in TC39. They shouldn't either; that'd be worse than this niggle.

Whether they should or not and whether that would be bad or not depends on how close of a relationship you believe should/does exist between TypeScript and JavaScript l, specifically in the TS to JS direction.

If I said language foo that isn’t TS but transpiled to JS all the same was considering that syntax, people might have a different opinion.

Since Typescript 1.0 it has mostly taken the path of wanting to follow TC-39's standards rather than lead them. The most notable exception was an experimental flag for decorators at too early of a stage that's currently playing out in a compatibility war between the too many projects depending on the experimental flag in Production builds versus the actually standardized behavior.

Between that and some remaining warts from <1.0 mistakes/incorrect assumptions, there's plenty of evidence that it is a good thing that other than its type system TS focuses on following standards rather than trying to lead them.

There's a place for the language "foos" that want to lead and champion new standards. As an ecosystem we all seem to benefit from Typescript not being that language (anymore, mostly not since 1.0 with the few obvious mistakes aside). It's a part of what makes Typescript trustworthy as Production tooling. It's also what helps make Typescript mostly "cheap" and "unextraordinary" in Production build pipelines.

This was a great decision, and what distinguishes Typescripts from other guest languages, by constraining themselves with being a linter and compiler, it is the same world.

Not a two world reality where the guest language has its own mini-platform and tooling, on top of the actual platform.

It is not that big of a deal, you can write

    import {} from "some/package"

And then go back with working autocompletion

Typescript devs acknowledged that one reason of its success is being a linter for JavaScript and little else, hence why they no longer do language level experiements outside the type system.

They've made zero functional difference to me. What do you like about them?

Really? I have a project that loads modules based on calculated values. How will you do that in a pure ESM world?

You wouldn’t, because it’s a misunderstanding of what “module” means and how they work. It’s like saying “maybe I need this file” - there is no maybe, you either need it (to run conditional logic upon) or you don’t.

You get an approximation of conditionally loading a module by simply converting everything to ESM and enabling tree-shaking. When module loading has no side effects this is simple to do. If you’re unsure at build time whether you will call a certain function from a certain module and that’s the reason you’re conditionally loading it, again enable ESM and tree shaking and import the function and call it conditionally except do so at runtime. You’ll only get exactly what you need to avoid the bloat of the whole module and your dependency graph will also be more correct as a bonus!

You are simply wrong.

I've been a full time NodeJS programmer for fourteen years. Module isn't some pure theoretical concept. It is a file that exports something in Node.

There's a ton of 'maybe I need this file' in the world. For example, I have things that are polymorphic by instance. I grab a config entry to decide which of several modules are going to be used. The others are completely unnecessary.

You might say, just add a build step that chooses the right ones. To which I would say, Are you nuts? Why would I screw up a perfectly working paradigm?

To get "an approximation of conditionally loading".

As a matter of fact _module_ is a pure theoretical concept. The fact that we’re discussing at least two different implementations of modules alone proves that it’s at least more abstract than _file_. It’s certainly not strictly related to Node, plenty of languages (and their associated runtimes, if applicable) have modules. Further, it wouldn’t matter what a specific implementation of modules within Node is, nor would 14 years of experience with Node.

You’re missing the point entirely, perhaps intentionally? If you’re using modules you’re already using a “build step” - code that runs before your actual code. Your “perfectly working paradigm” is only such if you intentionally disregard the core reason for modules: modularity.

> code that runs before your actual code But this is not a build step. A build step would transform the code beforehand

For good measure, it is an operation that executes by the runtime for every execution, not as a redeployment.

Turns out that the ESM purists struggle to find reasons to condemn those of us who don’t have the need or resources to the chase bleeding edge of purity.

Your point is that modules has a conceptual underpinning. My point is that the actual world in not the same as that concept.

I use modules for all the reasons. Your assertion that require() or importSync() represents a willful misunderstanding is silly and arrogant.

My assertion is that, having been made aware of the pitfalls of effectful imports, continuing to argue for using them requires a willful misunderstanding.

People outside the context of this discussion could simply be uninformed, they don’t need to be willfully misunderstanding.

No. It is a result of a practical, engineering perspective. I love theory. It's necessary for moving the world forward.

I also love getting things to work. Three quarters of NPM packages are CJS. Several of them are ones I wrote.

The reason they are not ESM is that the theoretically pure folks had control and I voted with my fingers because everything I do has to fit in my a substantial amount of existing CJS code.

Arguing for practical solutions that accommodate an imperfect world is absolutely correct.

Using dynamic import. Here's some documentation to get you started.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Dynamic import() is asynchronous. I have things that are not asynchronous.

To rewrite to be asynchronous gets me exactly nothing.

In work that is asynchronous, I use import(). It's fine. Also, it gives me nothing but, since that particular thing is already async, why not?

This is a terrible, badly thought out thing that was done by ECMA that harms a ton of developers and that would have been entirely saved if somebody had asked me.

I would have said, add importSync() and there will be literally no problems ever again.

No code or event handlers could run while importSync is resolving. I think including it would have been a mistake. The only other thing that's remotely similar are alert() and inputBox().

IMO it would be a pandora's box of unending problems. A function doing a synchronous dynamic import creates a bad user experience. It's also a pretty rare circumstance in my experience. Dynamic imports are relatively uncommon to begin with. Having one that must be inside a non-async function is unheard of for me.

If you had your way, I think the net result would have been worse.

I don't think it is a big problem given functions like fs.readFileSync already exists. It doesn't have to be a JS standard but be a server-side JS runtime specific function, which can be used when hacks are needed.

Node could just do that. `fs` isn't an ES spec, and nor does `importSync` need to be. The blame can't be placed on ESM for this.

I agree. The blame belongs to the NodeJS steering committee. It's their failure and it's a big one.

The only excuse is that ESM happened during the big Deno Node wars when the community was split, everyone was mad and, apparently making dumb decisions.

I read that a new version of NodeJS has revised require() to bring in ESM modules. That's good enough. (I would prefer importSync() for clarity.)

I understand that importSync() is blocking. That is fine when it is fine. I am a programmer. I can make sync vs async decisions.

The browsers would never implement it.

This is not a talk about browsers, hence the readFileSync examples

The reason we got here in the first place was trying to standardize the language and its module loading. If you come up with a solution that doesn't work in browsers, we're back to the same thing. Instead of the `require()` polyfill, we'd need the `importSync` polyfill.

Nor do they have require(). That’s not the point.

And the fact that require() is non-standard is why we're talking about ESM now. Node can cook up another non-standard package loading thing whenever they want. It just won't be ESM. And if you don't care what browsers do, then we're not talking about ESM.

Reply on news.ycombinator.com