Experimental Unstable Raw Imports Feedback

[delicate belfry]

1. Stability Consideration

Deno has recently introduced support for raw binary imports under the --unstable-raw-imports flag. While this is a welcome step forward, it is recommended that the feature remain unstable for the time being. This would allow the community to evaluate its ergonomics and performance characteristics, while also providing time to align with the upcoming Immutable ArrayBuffer proposal currently under consideration by TC39.

2. Import Type Naming

The current use of type: "bytes" for binary imports could be refined for clarity and semantic precision. I propose renaming it to:

import data from "./file.bin" with { type: "octet" };

• The term "octet" is consistent with established terminology in networking and MIME types (e.g., application/octet-stream).
• It avoids confusion with higher-level abstractions like Uint8Array, reinforcing that the import represents raw binary data.

3. Return Type: ArrayBuffer vs. Uint8Array

Rather than returning a Uint8Array, the import should yield an ArrayBuffer directly. This approach offers several advantages:

• Uint8Array is a view over binary data, not the data itself. Returning an ArrayBuffer makes the semantics of the import more explicit.
• It encourages developers to consciously select the appropriate view (e.g., DataView, Uint16Array) based on their specific needs.
• This design aligns with APIs like the Web Crypto API, which also favor ArrayBuffer for safety and clarity.

4. Future Integration with Immutable ArrayBuffers

Once Immutable ArrayBuffers are standardized and adopted in ECMAScript, this import mechanism should be updated to return immutable ArrayBuffer instances. This would provide:

• Security: Prevents accidental or malicious mutation of imported binary data.
• Performance: Enables zero-copy semantics, particularly relevant when using deno compile, where binary data can be referenced directly without memory duplication.
• Consistency: Aligns with the ES imports trend where imported modules objects are immutable data structures.

This is also the primary reason I recommend delaying the stable release of raw binary imports until Immutable ArrayBuffers receive official approval from ECMA. Doing so would allow Deno to adopt a more future-proof and efficient design from the outset, avoiding the need for breaking changes later.

5. Conclusion
By adopting type: "octet" and returning ArrayBuffer (eventually immutable), Deno can offer a more explicit, and forward-compatible mechanism for binary module imports. This design encourages thoughtful handling of binary data and unlocks performance and safety benefits for both interpreted and compiled applications.

[delicate belfry]

Dynamic imports with bytes/text types does bypass file system restrictions in practice

[runic timber]

It is recommended that the feature remain unstable for the time being.
As far as I know, that's exactly the plan. See denoland/deno#29904.
Rather than returning a Uint8Array, the import should yield an ArrayBuffer directly.
No. According to the Web Platform Design Principles, no new APIs should return ArrayBuffer.
The term "octet" is consistent with established terminology in networking and MIME types.
Literally the only place where I see the term “octet” used is in the application/octet-stream media type. Everywhere else it's called “bytes”—from the bytes method on Blob, Request and Response, to the accept-ranges: bytes HTTP header. Have you done your own research?

[delicate belfry]

I might be a bit old school, so sorry if it looks like i am missing something, your points are really nice and clear, but i want to mention few things, i don't care much about ArrayBuffer/Uint8Array, even if i still think ArrayBuffer makes more sense here, anyway here some points why "octet"

🧠 1. “Octet” is unambiguous and architecture-neutral

• Historically, “byte” was not always 8 bits—some systems used 6, 7, or 9 bits per byte.
• “Octet” always means 8 bits, making it the most precise term when clarity is critical—especially in specs, protocols, and cross-platform communication.

🌐 2. It aligns with established standards in networking and MIME

• Protocols like IPv4 define addresses in terms of octets, not bytes.
• The MIME type application/octet-stream is a widely adopted standard for binary data.
• RFCs and IETF documents consistently use “octet” to avoid ambiguity in binary data transmission.

📚 3. It signals intent: raw, uninterpreted binary

• “Octet” emphasizes that the data is not encoded or structured - just a stream of 8-bit units.
• This can be helpful in APIs or specs where you want to discourage assumptions about encoding, structure, or interpretation.

🧪 4. It’s already entrenched in low-level and security-sensitive domains

• In cryptography, networking, and binary serialization, “octet” is the preferred term.
• Using “octet” in APIs that deal with raw binary data can signal rigor and precision.

🧰 5. It avoids semantic overload of “byte”

• “Byte” is overloaded in many environments—it can refer to:
  • A unit of memory
  • A character encoding unit
  • A file size metric
• “Octet” avoids these connotations and focuses purely on the binary unit

as bytes make sense for method identifier it doesn't make sense for naming loader type thats structure dependent, byte is something runtime dependent, octet is more precise when it comes to files and raw data and way they are loaded