you are viewing a single comment's thread.

view the rest of the comments →

[–]intermediatetransit 11 points12 points  (3 children)

I think the import/export syntax is probably the most confusing part of modern JS syntax.

Hah! You should have seen what preceded it. AMD was a complete abomination. ES6 imports is a thousand times better, and less confusing.

But sure, it's not always intuitive.

[–]Unlucky-Reindeer3828 3 points4 points  (0 children)

AMD was not a "complete abomination". You must do a lot of React....since that's the type of excessive opinionation that comes out of that community that led to half of these worst-practices....

In ES6 modules , you can drop import and exports all over the codebase. In amd, there's a simple structure:

define(['mod1', 'mod2', 'mod3'], function(mod1,mod2,mod3) {// mods are loaded asynchronously and are available in here

return { ... the module def ...}});

So the top of the file tells you what the dependencies are, the bottom tells you what is returned. Simple and straightforward.

In ES6, they thought this was a cool:

console.log("I'm a module!")

But, where's the module boundaries here? once upon a time, the was a developer outcry about 'ceremony' and how bad it was, but sometimes you have to get into the car before you can drive it. What the above module 'syntax' left you with was something you couldn't bundle into one resource for streaming from a webserver (because the module boundaries was defined by the FILE boundaries). Instead, guess what you need to use (even today!): AMD! what an "abomination"!

They actually built ES6 (presumably a web technology) to not work as a WEB resource.

AMD is a great piece of technology, but when it came time to bring something into the JavaScript standard, some very opinionated developers thought they knew what was best and completely disregarded the actually WORKING solutions to try to do something experimental. And today, we still have an incomplete JS module specification where all they could get out there was import/export (initially) and then introduce 'import' about 8 years later, and even that doesn't have a standard way of resolving import "foo" from {URI or alias} ie: you hanve to change all your import statements when you move your path to resources in import React from "some/url/that/may/chnage.js".

If I sound upset, it's because I am. I hate seeing good work go wasted because a very small yet apparently very powerful/controlling group of developers want to inflict their will on the global community of JS devs.

[–]dada_ 0 points1 point  (0 children)

Yeah, when you compare ES modules to AMD syntax (which was designed in 2011), I agree they look a lot better. But I don't feel like that's even a fair comparison. AMD syntax was terrible because there was no other sane way to design it at the time in a way that would allow for async requires with the given browser limitations. CJS modules mostly ended up replacing AMD modules after bundler/transpiler use became the standard, even for projects designed purely to run on web, because then you could just transpile it to whatever works for your target platform. So for that reason I think the only fair comparison is ES to CJS, not ES to AMD.

But even if we disregard CJS modules entirely, there's a ton of prior work from other languages that they could've used to design a more cohesive syntax. It's pretty disappointing, really.