|
|
|
|
|
by WorldMaker
1489 days ago
|
|
I think the history shows that Node's CommonJS was the half-baked approach that even at time browser owners and frontend programmers were complaining couldn't operate correctly in a browser environment. (AMD is awful, but it was at least designed around the constraints of a browser.) ES Modules are possibly over-baked, but they are certainly not half-baked: they are extremely carefully designed to operate well under the constraints of browser environments (and Deno and Node 12+ shows they work well in other environments too). It's not this ES Module spec's fault that Node picked a half-baked module format that was known to be deficient at the time and built a massive legacy ecosystem on top of a bad module format. As nasty as AMD is to write, had Node picked something much more like it the backwards compatibility story would have been much, much simpler all around. It's fair to suggest that because the Node ecosystem has become so dominant that the lack of backward compatibility is a serious concern in practical usage of ES Modules, but that doesn't mean ES Modules are half-baked, it means the ecosystem has growing pains and migration needs. Many of those growing pains and migration needs are getting solved. It wasn't the ES Module spec's job to magically prevent growing pains/migration needs, it was to set a solid "goal spec" for the end result to migrate to. I think it did a relatively good job at that just as I sometimes lament the growing pains and migrations I experience in my own apps. I blame CommonJS though. CommonJS should never have become such a widely deployed "standard" with no strong compatibility with browser environments built in. |
|