[cxr]

> Within the actual language, there isn't a universal syntax just to use a package.

There is. The issue is one of mindset. You recognize Maven and Gradle as belonging to a sort of "parastandard" set of technology, offering proprietary (albeit free/open source) glimpses of how one could conceivably solve the set of problems that they're meant to be used for, but when it comes to JS, you're elevating the parastandard stuff to the level of being part of "JS".

Neither CommonJS nor NodeJS's `require` nor package.json nor TypeScript nor esbuild are part of JS. You shouldn't give them any privileged status that you aren't willing to give to Maven or Gradle when you think of Java.

[smt88]

I think you're misunderstanding what I'm saying. You're still talking about package managers and build systems. I'm talking only about syntax. TypeScript, NPM, esbuild, Gradle, and Maven are completely separate from what I'm talking about.

[cxr]

I'm not misunderstanding. (The difference between parastandard tech like package managers vs base-level stuff in e.g. the language itself was actually the point of my message, so I understand the distinction.) You're saying that unlike Java, JS at the language level doesn't have imports, but what you're saying is untrue.

It's entirely possible that the projects you're most familiar with aren't using them, but the JavaScript language has native modules, including standardized syntax and semantics for import statements.

[smt88]

Yes, I know JavaScript has native modules at the language level, but they are not universally supported.

Most importantly, there can't/won't be a breaking change for the previous iterations of module import, so we will continue to have many different ways to import.

It's not an issue of whether JS has a "blessed" way of doing it (and it didn't even have that for a long time). It's that there's more than 3 ways to do it, and many of them look similar and have confusing conflicts with compilers/packagers.

[klodolph]

Yes, imports in JS are very frustrating. A big part of it is that your imports might be interpreted in, say, four different environments, and you have to consider how those four different environments work, how they can be configured, and pick some way of importing your packages that works in all four.

The four environments I often end up with are: Browser, Node.js, Rollup.js, and TypeScript.

For example, for a long time now, it has been sensible to just use "import" statements in code you intend to run in the browser. For a debug build, you don’t have to bundle, since browsers support import, but the imports have to be relative and have the full pathname. Node.js has a configuration option that allows you to use "import", but it is finicky and it can be surprising how many things will break when you turn it on—the alternative is to use ".mjs" as an extension. TypeScript has specific requirements about file extensions as well, and does not modify them. Finally, Rollup.js is hopelessly configurable.

Consider a simple requirement, “This code runs in the browser, I want to write a test using Jest.” I know it can be done, but I’m spending a bunch of time digging through forum posts to make it work, and understand how to make Jest load the code that already runs in the Browser, because the Node.js environment is so different… and most of the time, I end up writing code just to get something to build.

So the more than 3 ways, off the top of my head:

- Import paths: non-relative? relative? relative with leading slash?

- Import paths: .js suffix? no .js suffix?

- Files: use .mjs / .js suffix? use .js / .cjs suffix?

[cxr]

You wrote, "I was talking about import in JavaScript itself, not build tools or package managers," and keep mentioning things like "the import syntax of the language", so this feels like retconning.

The confounding details you bring up are entirely the result of that idiosyncratic tooling. JS itself has `import`, thus there is no problem of the sort that you describe—at least not as you've described it. (I.e., this isn't to say that there are no problems, only that the way that your characterization of the problem as being one with "JS itself" doesn't match the problem that actually exists.)

To say it again, if you see a problem with JS, that's because you're elevating the parastandard stuff to a higher level than it deserves. If you're able to meaningfully separate "Java" from "Maven and Gradle" in your mind, then you should be able to do the same with "JS" and the NodeJS derpitude.