3 ms·

To be honest I don't mind `.mjs` - we renamed everything in our system to that about a year ago, but I do think it's important for it to be consistent with brow

To be honest I don't mind `.mjs` - we renamed everything in our system to that about a year ago, but I do think it's important for it to be consistent with browser standards. The index.js thing is nice, but I think consistency with browsers is more important and I'd be willing to lose it.

BigJono 8y ago
I actually don't see why the whole index.js thing is nice. What happened to prefering explicitness? All it does is save a couple of characters, it doesn't make anything clearer. It's just one more noob trap that's neither here nor there for experienced devs.
- BillinghamJ 8y ago
  One nice benefit was that you could change from a module being defined as a single file to making it a folder with the logic split across multiple files without any other files needing to be changed
  - BigJono 8y ago
    Mehhhh, to quote Joel Spolsky: "This is the kind of thing you solve in 5 minutes with a macro in emacs".
  - pvorb 8y ago
    Yes. You end up with a million index.js files in your project and finding the right one is a PITA.
    - BillinghamJ 8y ago
      ...? That's what directories are for.
tmpfs 8y ago
The problem with .mjs is when you want to share code between the server and browser, handling a different file extension is a PITA.
- TheAceOfHearts 8y ago
  Browsers don't look at the file extension, they use Content-Type [0]. To share code between the browser and server you have to update the server config to set the Content-Type header to text/javascript when serving .mjs files. According to the WHATWG HTML spec [1]: > Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types. Although I'll admit I was surprised to see them suggesting you use text/javascript instead of application/javascript. I've been using application/javascript for years, since I don't have to support old versions of Internet Explorer. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_... [1] https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages https://html.spec.whatwg.org/multipage/scripting.html#script...
JimDabell 8y ago
> I do think it's important for it to be consistent with browser standards. There's no browser standard about .mjs. In fact the web doesn't really notice file extensions; it goes by media types and attributes. A browser knows that something is JavaScript because it is served with the application/javascript media type (or similar), and it knows it is a module because the <script> element has a type=module attribute. A lot of the talk about "browser equivalence" is extremely loosely worded and leads people to think that .mjs is a browser thing, but it's not. It's a Node thing. What they want is for code to work the same way whether it's running on Node or running in a browser. The problem they face is that Node hasn't got the type attribute to decide whether something is a module or not, so they can't use the same mechanism the browser has. The solution they have devised is to assume that .mjs is a JavaScript module and .js is not. The consequence is that if you want the same code to work in Node and on the web, you've got to change what happens on the web to follow the Node idea of naming things .mjs. Otherwise when you import a module named .js – which works in the browser – it will fail in Node. So this isn't about making Node match what happens in the browser, it's about making what happens in the browser match the Node approach, which is not a standard in any sense.
- BillinghamJ 8y ago
  Yes that's my point. As a Node dev, I have no problem changing my extensions. However the browser environment should not be pushed to change and what works on the browser should largely work with Node.

BigJono 8y ago

I actually don't see why the whole index.js thing is nice. What happened to prefering explicitness? All it does is save a couple of characters, it doesn't make anything clearer. It's just one more noob trap that's neither here nor there for experienced devs.

BillinghamJ 8y ago
One nice benefit was that you could change from a module being defined as a single file to making it a folder with the logic split across multiple files without any other files needing to be changed
- BigJono 8y ago
  Mehhhh, to quote Joel Spolsky: "This is the kind of thing you solve in 5 minutes with a macro in emacs".
- pvorb 8y ago
  Yes. You end up with a million index.js files in your project and finding the right one is a PITA.
  - BillinghamJ 8y ago
    ...? That's what directories are for.

tmpfs 8y ago

The problem with .mjs is when you want to share code between the server and browser, handling a different file extension is a PITA.

TheAceOfHearts 8y ago
Browsers don't look at the file extension, they use Content-Type [0]. To share code between the browser and server you have to update the server config to set the Content-Type header to text/javascript when serving .mjs files. According to the WHATWG HTML spec [1]: > Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types. Although I'll admit I was surprised to see them suggesting you use text/javascript instead of application/javascript. I've been using application/javascript for years, since I don't have to support old versions of Internet Explorer. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_... [1] https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages https://html.spec.whatwg.org/multipage/scripting.html#script...

JimDabell 8y ago

> I do think it's important for it to be consistent with browser standards. There's no browser standard about .mjs. In fact the web doesn't really notice file extensions; it goes by media types and attributes. A browser knows that something is JavaScript because it is served with the application/javascript media type (or similar), and it knows it is a module because the <script> element has a type=module attribute. A lot of the talk about "browser equivalence" is extremely loosely worded and leads people to think that .mjs is a browser thing, but it's not. It's a Node thing. What they want is for code to work the same way whether it's running on Node or running in a browser. The problem they face is that Node hasn't got the type attribute to decide whether something is a module or not, so they can't use the same mechanism the browser has. The solution they have devised is to assume that .mjs is a JavaScript module and .js is not. The consequence is that if you want the same code to work in Node and on the web, you've got to change what happens on the web to follow the Node idea of naming things .mjs. Otherwise when you import a module named .js – which works in the browser – it will fail in Node. So this isn't about making Node match what happens in the browser, it's about making what happens in the browser match the Node approach, which is not a standard in any sense.

BillinghamJ 8y ago
Yes that's my point. As a Node dev, I have no problem changing my extensions. However the browser environment should not be pushed to change and what works on the browser should largely work with Node.