6 ms·

Every time I see a new Bun update it's always because Bun has implemented a feature that violates the spec in some way. While this does rely on syntax from a pr

Every time I see a new Bun update it's always because Bun has implemented a feature that violates the spec in some way. While this does rely on syntax from a proposal, said proposal has not made it into the language yet. Another failure I see is the fact that the "type" property is not meant to be used for this type of language augmentation, it's meant to describe the type of the file without inferring from the file extension. I think Bun has a habit of moving too fast and breaking things and if it catches on I worry it will have just as many legacy anti-spec things as Node does.

bluepnume 3y ago
Eh. Just treat Bun as a testing ground for (very) experimental new features. It's no secret that the project moves very quickly, and anything that gains enough traction can be folded back into the spec.
Jarred 3y ago
Import Attributes are a stage3 proposal which means it is very likely to become part of the language. It’s the last stage before becoming part of the language. > Another failure I see is the fact that the "type" property is not meant to be used for this type of language augmentation, it's meant to describe the type of the file without inferring from the file extension It sounds like you’re confusing Import Attributes with Import Assertions, which was the previous iteration of Import Attributes. Interpretation of import attributes is host defined. For Import Assertions, that wasn’t true - they were intended never to impact runtime evaluation. That’s the difference with Import Attributes. Import Attributes do impact runtime evaluation.
- creatable 3y ago
  What I specifically meant is that the "type" property can impact runtime evaluation as per the spec, however it's implied to be used specifically for impacting runtime evaluation based on a file's type. Say I have a module in a language that transpiles to JavaScript based off of the "type" property. In Bun, I would not be able to use any functions exported by it as a macro because the "type" property is being used for defining the module as a macro. That's the specific issue I have.
  - spankalee 3y ago
    Exactly. Import attributes are supposed to effect the imported module, not the importing module. This turns what looks like a function call in the importer into something like macro expansion (it doesn't look like actual macros though).
    - eyelidlessness 3y ago
      I think this is mostly consistent in terms of effect. With any application of import attributes that affect the dependency, the dependent module could behave differently for any affected aspect it accesses. The only inconsistency is that Bun is front loading some of these effects to the server/bundler runtime and effectively memoizing the equivalent behavior before it reaches a client. But it’s not doing that of its own volition, it’s doing it to address an explicit attribute in the source code. The only way this would be a meaningful problem is if the explicit value has a chance of colliding with either existing code in the ecosystem (highly unlikely, no one is really using this syntax yet except perhaps in an equally experimental context), or some plausible pending standard (unless one was proposed in the last couple weeks, I’m pretty sure I can rule that out too). I share other commenters’ lament that this is not a true macro solution (and I think it should actually just be renamed to something like comptime). But I don’t think this deserves the deviation-from-standards challenge it’s getting in this thread. And lest I come off as a Bun fanatic, I think I’m one of the people who more frequently questions potential Bun spec deviations when they come up on Twitter.
- unlog 3y ago
  What about adding signals?
  - deleted 3y ago
    [deleted]
- DanHulton 3y ago
  I mean, it looks like they support Import Assertions, too: https://bun.sh/blog/bun-macros#how-it-works https://bun.sh/blog/bun-macros#how-it-works So the worry about having legacy anti-spec things still seems pretty valid.
paulddraper 3y ago
How do you think features make it into the spec? Specification and implementation are chickend-and-egg.
- badrequest 3y ago
  Is bun actively participating in these discussions, or are they just implementing whatever they wish and not participating in the chicken-and-egg process?
- spankalee 3y ago
  The main JS implementations do not run ahead of the spec. They implement at Stage 3.
  - jakelazaroff 3y ago
    Import attributes are at Stage 3: https://tc39.es/proposal-import-attributes/ https://tc39.es/proposal-import-attributes/
    - spankalee 3y ago
      I'm well aware, but this is not just import attributes. It's using import attributes syntax to trigger a transform of the importing module, in addition to changing the behavior of the exporting module.
      - eyelidlessness 3y ago
        More concise than my previous reply: that’s just moving the same outcome around in time. If a fully runtime-only import attribute would result in inlining a static-at-build-time value where its export is called, this is just inlining it sooner. That seems fine to me unless it doesn’t fit the import attribute use case. In which case… don’t voluntarily use it?
  - paulddraper 3y ago
    A. Import attributes are stage 3. B. If you blur the line between "runtime" and "compiler", you'll realize that a lot of JS ecosystem (e.g. Babel) run ahead of that.
the__alchemist 3y ago
[flagged]
pictur 3y ago
I guess today's software development culture requires it. constantly discover new things and continue by breaking the old.
vikramkr 3y ago
I like that there's an engine willing to break the spec. It's good to have variety and see how people experiment with this stuff, at least for the fun of it!

bluepnume 3y ago

Eh. Just treat Bun as a testing ground for (very) experimental new features. It's no secret that the project moves very quickly, and anything that gains enough traction can be folded back into the spec.

Jarred 3y ago

Import Attributes are a stage3 proposal which means it is very likely to become part of the language. It’s the last stage before becoming part of the language. > Another failure I see is the fact that the "type" property is not meant to be used for this type of language augmentation, it's meant to describe the type of the file without inferring from the file extension It sounds like you’re confusing Import Attributes with Import Assertions, which was the previous iteration of Import Attributes. Interpretation of import attributes is host defined. For Import Assertions, that wasn’t true - they were intended never to impact runtime evaluation. That’s the difference with Import Attributes. Import Attributes do impact runtime evaluation.

creatable 3y ago
What I specifically meant is that the "type" property can impact runtime evaluation as per the spec, however it's implied to be used specifically for impacting runtime evaluation based on a file's type. Say I have a module in a language that transpiles to JavaScript based off of the "type" property. In Bun, I would not be able to use any functions exported by it as a macro because the "type" property is being used for defining the module as a macro. That's the specific issue I have.
- spankalee 3y ago
  Exactly. Import attributes are supposed to effect the imported module, not the importing module. This turns what looks like a function call in the importer into something like macro expansion (it doesn't look like actual macros though).
  - eyelidlessness 3y ago
    I think this is mostly consistent in terms of effect. With any application of import attributes that affect the dependency, the dependent module could behave differently for any affected aspect it accesses. The only inconsistency is that Bun is front loading some of these effects to the server/bundler runtime and effectively memoizing the equivalent behavior before it reaches a client. But it’s not doing that of its own volition, it’s doing it to address an explicit attribute in the source code. The only way this would be a meaningful problem is if the explicit value has a chance of colliding with either existing code in the ecosystem (highly unlikely, no one is really using this syntax yet except perhaps in an equally experimental context), or some plausible pending standard (unless one was proposed in the last couple weeks, I’m pretty sure I can rule that out too). I share other commenters’ lament that this is not a true macro solution (and I think it should actually just be renamed to something like comptime). But I don’t think this deserves the deviation-from-standards challenge it’s getting in this thread. And lest I come off as a Bun fanatic, I think I’m one of the people who more frequently questions potential Bun spec deviations when they come up on Twitter.
unlog 3y ago
What about adding signals?
- deleted 3y ago
  [deleted]
DanHulton 3y ago
I mean, it looks like they support Import Assertions, too: https://bun.sh/blog/bun-macros#how-it-works https://bun.sh/blog/bun-macros#how-it-works So the worry about having legacy anti-spec things still seems pretty valid.

paulddraper 3y ago

How do you think features make it into the spec? Specification and implementation are chickend-and-egg.

badrequest 3y ago
Is bun actively participating in these discussions, or are they just implementing whatever they wish and not participating in the chicken-and-egg process?
spankalee 3y ago
The main JS implementations do not run ahead of the spec. They implement at Stage 3.
- jakelazaroff 3y ago
  Import attributes are at Stage 3: https://tc39.es/proposal-import-attributes/ https://tc39.es/proposal-import-attributes/
  - spankalee 3y ago
    I'm well aware, but this is not just import attributes. It's using import attributes syntax to trigger a transform of the importing module, in addition to changing the behavior of the exporting module.
    - eyelidlessness 3y ago
      More concise than my previous reply: that’s just moving the same outcome around in time. If a fully runtime-only import attribute would result in inlining a static-at-build-time value where its export is called, this is just inlining it sooner. That seems fine to me unless it doesn’t fit the import attribute use case. In which case… don’t voluntarily use it?
- paulddraper 3y ago
  A. Import attributes are stage 3. B. If you blur the line between "runtime" and "compiler", you'll realize that a lot of JS ecosystem (e.g. Babel) run ahead of that.

the__alchemist 3y ago

[flagged]

pictur 3y ago

I guess today's software development culture requires it. constantly discover new things and continue by breaking the old.

vikramkr 3y ago

I like that there's an engine willing to break the spec. It's good to have variety and see how people experiment with this stuff, at least for the fun of it!