tc39/proposal-import-attributes

Why not indicate that a module is non-executable with a simpler or shorthand syntax?

CxRes opened this issue · 2 comments

CxRes commented

Forgive me if this is a naive question: Why not just indicate that a module is a non-executable and use mime-type to determine format. Something maybe like:

import$ foo from 'foo.json'   // import$ as a new keyword

or

import foo from 'foo.json'!    // ! as the non-executable operator

or

import foo as 'foo.json'       // 'as' being a new keyword for use with import

This would work for a vast majority of cases where one uses a IANA registered media type (or perhaps even one derived from them subject to community consensus). The browser/engine can maintain a mapping or query the media type.

Consider another contrived scenario to illustrate the loss of flexibility: Say in the future, browsers had YAML and JSON parsers built in to the browser. An assertion to JSON would lock in a developer and if the module provider changed over to YAML this would lead to an error, even-though the parsed data might be the same.

I am not challenging the proposal itself, since I can see legitimate reasons to assert a format, mime-type, hashes etc. But why force a developer to add this extra code when a single token might do the job more often than not, leaving the code more readable and a few bytes lighter.

xtuc commented

I don't think using a symbol is very clear, we currently have a syntax that makes it explict and easy to understand. For instance this case nodejs/modules#427 (comment).

Edit: Also here's a comment about it nodejs/modules#427 (comment).

The as syntax was proposed before but we decided to use a more generic approach, see #12.

CxRes commented

@xtuc I am not arguing the explicit nature of the current proposal, neither am I arguing the ease of understanding. As I said above the explicit syntax is needed. However, it just appears to me that in an overwhelmingly large number of cases all a developer would want to indicate is that the thing being imported is not code, please don't try to run it - such a verbose syntax seems like an overkill in those situations and could do with a shorthand! My suggestions are merely the simplest proposals I could think of, better suggestions are of course welcome.

To your specific points:

For instance this case nodejs/modules#427 (comment).

Edit: Also here's a comment about it nodejs/modules#427 (comment).

I am not sure I understand the relevance of the linked comments. The first linked comment asks for an implicit determination of whether the import is executable which would be unclear and a security risk (as explained in the second linked comment). I am asking for explicit shorthand syntax to specify excitability (which mitigates the security risk) only after which mime-type determination would kick in (say a code js or wasm would be executed once marked executable and data whether yaml or json would never be executed once marked as non-executable).

The as syntax was proposed before but we decided to use a more generic approach, see #12.

I am sorry but I reject this contention! My "as" syntax suggestion is different from the one proposed in #12.

Also, Javascript already has a tradition of shorthand syntax. People get used to them, even like them, even if it seems unclear initially. I believe one should strive in a computer language (like we do in spoken language) to balance explicitness and simplicity. And I believe this is the best time to make this determination, before the syntax is finalized, rather than creating yet another proposal.