I don't understand what actual concrete benefit there is to using .mjs on client-side JavaScript modules. It seems to only cause problems with tools that .js completely avoids. What's the specific upside?
-
-
Replying to @justinfagnani
I follow my sensei
@mathias https://developers.google.com/web/fundamentals/primers/modules#mjs …2 replies 0 retweets 6 likes -
Well familiar with that recommendation :) I still don't see a concrete benefit for client-side libraries. The first point about knowing if it's a module just isn't relevant to any library I know of. They're all modules in source already.
1 reply 0 retweets 7 likes -
Replying to @justinfagnani @_gsathya
It’s not a benefit for libraries. It’s a benefit for human developers writing and reading source code. Node.js decided to have first-class .mjs support for modules, now and forever:https://github.com/nodejs/modules/pull/180 …
2 replies 1 retweet 3 likes -
The implementation is still experimental and behind a flag indeed, but the decision to use .mjs (even in the final version) has been made:https://github.com/nodejs/modules/pull/180 …
0 replies 0 retweets 0 likes -
Replying to @zenparsing @mathias and
Andrea Giammarchi Retweeted Andrea Giammarchi
Andrea Giammarchi added,
Andrea Giammarchi @WebReflectionsince this landed https://github.com/nodejs/ecmascript-modules/pull/32 … nobody has to worry about it anymore. Put the following in you .bashrc and forget forever about .mjs alias node='node -m' use .cjs extension when you really want to import CommonJS Goodbye ambiguity, Everybody is happy
https://twitter.com/justinfagnani/status/1095792602324987904 …Show this thread1 reply 0 retweets 0 likes
That’s great! Thanks for the pointer.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.