Hacker News Reader

Comment by fn1 | Hacker News Reader

JavaScript just gives to much options. I keep having problems with libraries because ES6 allows

  import x from "library";
  import {x} from "library";
  import * as x from "library";
  import {x as y} from "library";

Just to compare Java uses this:

  import java.lang.Double;
  import java.lang.*;

No renaming, not a gazillion options during in- and export, but one statement. If you want to rename something, assign it to a variable.

I don't understand why ES-module authors made it that complicated, when they had the chance to introduce a proper module system.

Why did they not just copy Java's system and be done with it.

View on HN

1. Get the default export as x

2. Get the exported value x

3. Get all exported values and call the object x

4. Get the exported value x and call it y

They're all different because they allow you to do different things, and fairly readable.

Edit: Just realised dimgl said the same 45min ago, my bad!

I think people (like the author of this article) should explain the syntax of destructuring assignment {x} briefly to make it make more sense for the unfamiliar.

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

This looks similar to detructuring assignment, but it isn't:

- no recursive destructuring

- `import {y} from 'x'` is not the same as `import x from 'x'; const {y} = x`

Thanks for pointing it out, didn't know that.

But I think your second point is more to do with the fact `import` by default imports `default` instead of the whole thing.

If you use import * as x from 'x'; then `const {y} = x;` works.

I personally will consider it is `import from` being different from a typical object instead of {x} here being different from typical destructuring assignment (by that I mean they still follow the same pattern; not necessarily say they're the same thing.)

Java's package system has its own problems, and all of those examples you gave are very straightforward.

1. Import the default export as the name `x`.

2. Import named export `x` as the name `x`.

3. Import all of the named exports under an object named `x`.

4. Import named export `x` as the name `y`.

The order of operations was different: the packages ecosystem came before the imports language construct. The location and the name of libraries are not correlated (PHP is closer to Java here, in the default case). Also, the idea of tree-shaking means you don’t want to import the whole thing (options 1 and 3) when you use something like webpack. Renaming let’s you use competing names. There are decades worth of history and libraries to accommodate.

Your last sentence is like a C dev asking a Java dev why they don’t just compile to x64 and be done with it. It comes across as flippant and will likely attract downvotes.

So what happens when you need to deal with java.time and Joda Time in the same class (e.g. because Joda was part of your public API but you're migrating to Java time). Fully qualified names everywhere, when it would be nicer to have a construct like:

import org.joda.time.Instant as JodaInstant;

The rest of the weirdness is to make it look like JS destructuring

Version the API and switch to Java-time everywhere. Or forward everything to another class.

Unless you're going to duplicate the logic too, you're still going to have the facade class providing the legacy Joda API that also needs to use the new types to forward onto the new API.

That class doing that transformation will need to refer to both the Joda and java.time class.

C# has exactly that FWIW: using foo.lib = libfoo

Java's packaging system sucks as does all the similar ones like C#, C++ etc compared to JavaScript's IMO.

All of those the space of namespaces is global. You can't have 2 modules named math.quaterinions in any of those languages. You can in JavaScript. To put it another way, in order to prevent name clashes in C++/C#/Java you have to know the name of every other project on the planet. If someone uses the same namespace then if you ever need to use those 2 projects together one of them will have to be re-factored.

That problem doesn't exist in modern JavaScript. There are no namespaces. There is just floating references to code.

That’s not true. You can use aliases just fine. .NET is great with this.

in one file declare

    namespace foo {
      class Bar ...
    }

In another file declare

    namespace foo {
      class Bar ...
    }

Now use both foo.Bar from file 1 and foo.Bar from file 2 in the same project. Aliases don't help with this

Different assemblies with the same assembly name, namespace and class? Use an extern alias (which is how different versions of the same assembly can be used if necessary): https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Different assemblies with different assembly names but same namespace and class? Just use the fully qualified type name (and alias it for a shorter name).

Single assembly/project and namespace with the same class in multiple files? If you're just spreading out the code then use partial classes, otherwise why would you define the same type twice?

C# (and other languages) that use virtual namespaces can do everything that file-based namespaces can do, but also support many more scenarios.

I honestly have no idea where you got the idea that namespace conflicts are a problem in C# or Java. Both have solved this problem (C# with aliasing and Java with packages).

aliases help you use bar from foo.bar and moo.bar. They don't help you with 2 files both of which declare foo.bar

Why would you declare the same type in 2 different files in the same project?

you don't have control of all 3rd party libraries.

Then it's not the same project and the fully qualified type name will be different.

> Java's packaging system sucks as does all the similar ones like C#, C++ etc compared to JavaScript's IMO.

There is one gazillion things that are much more a problem than "namespace conflicts" in packaging and package management.

Including security & code authenticity, parallel multi-version handling, sensibility to side effects, speed, auditing and reproducibility.

And in these domain the JavaScript packaging system generally range from being 'catastrophic' to 'absolutely terrible'.

If I have to take an example package management system for the world I would certainly quote cargo, Nix, Guix or Spack but certainly not npm which is quite close to what you should really not do for a package manager.

As a Java programmer dropped into JS land, I totally agree. Keep it simple, one way to achieve something wherever you can. Pythonic, in other words. What I don’t understand is why we didn’t learn from other major languages that had gotten this right already.

You can also do `import x, {y} from ...`. Very confusing to learn.

I think they did it like that for compatibility with CommonJS.

Reply on news.ycombinator.com