5 ms·

JavaScript just gives to much options. I keep having problems with libraries because ES6 allows import x from "library"; import {x} from "library"; impor

• IshKebab 6y ago
  You can also do `import x, {y} from ...`. Very confusing to learn. I think they did it like that for compatibility with CommonJS.
• sroussey 6y ago
  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.
• dimgl 6y ago
  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`.
• greggman3 6y ago
  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.
  • manigandham 6y ago
    That’s not true. You can use aliases just fine. .NET is great with this.
    • greggman3 6y ago
      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
      • manigandham 6y ago
        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-reference/keywords/extern-alias 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.
  • smt88 6y ago
    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).
    • greggman3 6y ago
      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
• randomsearch 6y ago
  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.
• dbetteridge 6y ago
  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!
  • fireattack 6y ago
    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/Reference/Operators/Destructuring_assignment https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    • Kinrany 6y ago
      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`
      • deleted 6y ago
        [deleted]
      • fireattack 6y ago
        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.)
• Macha 6y ago
  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
  • cel1ne 6y ago
    Version the API and switch to Java-time everywhere. Or forward everything to another class.
    • Macha 6y ago
      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.
  • Serow225 6y ago
    C# has exactly that FWIW: using foo.lib = libfoo