5 ms·

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. Py

by jeswin 2y ago

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 ;)

ComputerGuru 2y ago
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.
- jeswin 2y ago
  > 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.
  - ComputerGuru 2y ago
    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.
    - WorldMaker 2y ago
      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.
      - pjmlp 2y ago
        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.
- afiori 2y ago
  It is not that big of a deal, you can write import {} from "some/package" And then go back with working autocompletion
- pjmlp 2y ago
  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.
fwlr 2y ago
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.
- jeswin 2y ago
  > 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>
- afiori 2y ago
  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...
- everforward 2y ago
  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.
eyelidlessness 2y ago
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.
- eddd-ddde 2y ago
  You can type the real name, import it with autocomplete, then rename the symbol (f2), which creates the alias.
  - eyelidlessness 2y ago
    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.
- paulddraper 2y ago
  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:)
  - eyelidlessness 2y ago
    It works okay for defaults IME, and yeah I generally avoid both but especially namespace (wildcard) imports.
- deleted 2y ago
  [deleted]
jajag 2y ago
> 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.
tqwhite 2y ago
Really? I have a project that loads modules based on calculated values. How will you do that in a pure ESM world?
- zarathustreal 2y ago
  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!
  - tqwhite 2y ago
    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".
    - zarathustreal 2y ago
      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.
wvenable 2y ago
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.
- MatthiasPortzel 2y ago
  Yep. Especially with relative imports, it’s easier to type `import { myHelperFunc` and let LSP complete `tion } from "../../../util"`.
samth 2y ago
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.
- cxr 2y ago
  import "./foo_bar.js" (for FooBar)
- h1fra 2y ago
  why not just `import 'fs' { read }`?
danvk 2y ago
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.
akira2501 2y ago
They've made zero functional difference to me. What do you like about them?

by jeswin 2y ago

ComputerGuru 2y ago

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.

jeswin 2y ago
> 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.
- ComputerGuru 2y ago
  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.
  - WorldMaker 2y ago
    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.
    - pjmlp 2y ago
      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.
afiori 2y ago
It is not that big of a deal, you can write import {} from "some/package" And then go back with working autocompletion
pjmlp 2y ago
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.

fwlr 2y ago

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.

jeswin 2y ago
> 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>
afiori 2y ago
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...
everforward 2y ago
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.

eyelidlessness 2y ago

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.

eddd-ddde 2y ago
You can type the real name, import it with autocomplete, then rename the symbol (f2), which creates the alias.
- eyelidlessness 2y ago
  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.
paulddraper 2y ago
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:)
- eyelidlessness 2y ago
  It works okay for defaults IME, and yeah I generally avoid both but especially namespace (wildcard) imports.
deleted 2y ago
[deleted]

jajag 2y ago

> 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.

tqwhite 2y ago

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

zarathustreal 2y ago
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!
- tqwhite 2y ago
  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".
  - zarathustreal 2y ago
    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.

wvenable 2y ago

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.

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

samth 2y ago

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.

cxr 2y ago
import "./foo_bar.js" (for FooBar)
h1fra 2y ago
why not just `import 'fs' { read }`?

danvk 2y ago

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.

akira2501 2y ago

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