5 ms·

It's good to see that people care about native JS standards. I'm a bit concerned how Bun seems to be adding their own proprietary APIs to their JS runtime, and

by wayvey 3y ago

It's good to see that people care about native JS standards. I'm a bit concerned how Bun seems to be adding their own proprietary APIs to their JS runtime, and can't help feeling that it could be intentional vendor lock-in. Since they are venture backed I'm sure they want some ROI from the project eventually and if they start charging money it will be harder to switch away due to the proprietary APIs without refactoring your project.

thomasreggi 3y ago
It's really because we have some wonderful collaboration between vendors now, and they don't want to have to come up with their own APIs. https://wintercg.org/ https://wintercg.org/
- pjmlp 3y ago
  Cough. Vercel.
jokethrowaway 3y ago
It's still OSS, not proprietary APIs. Feel free to fork it in the future, once they need to make their money back. If it's faster than node and the API to do what I need is better (Bun.FileSystemRouter comes to mind), I don't see why not to switch over. Heck, I would accept even less retro-compatibility to get rid of transpiling, that completely oscene political mess they did with modules and treating TS as a 2nd class citizen. The amount of time I'm still hit by ESM vs CJS is insane. Truly a Python 2vs3 moment for the node.js community.
- chlorion 3y ago
  The term "proprietary" does not always refer to software licenses, but that's one of the common causes of something to be proprietary.
  - SahAssar 3y ago
    How would you define it? The wiki article for it in the context of software (https://en.wikipedia.org/wiki/Proprietary_software https://en.wikipedia.org/wiki/Proprietary_software) seems to pretty much stand it in opposition to open licenses, but I also have a sort of gut feeling that it could also refer to interfaces in OSS that are not designed to re-implementable. Not sure about that though.
    - cxr 3y ago
      "Nonstandard and controlled by one particular organization." <https://en.wiktionary.org/wiki/proprietary https://en.wiktionary.org/wiki/proprietary> XBL, a precursor to Web Components in use in Firefox for 15+ years before any ordinary webdev was talking about shadow DOM, was open source in every sense, for example. It was also proprietary. See also: "Problems with XUL". > XUL is a proprietary technology developed by Mozilla and only used by Mozilla. <https://mozilla.github.io/firefox-browser-architecture/text/0003-problems-with-xul.html#availability-of-example-code-and-help https://mozilla.github.io/firefox-browser-architecture/text/...>
      - mhitza 3y ago
        I don't know when that page was written, but there were other developers that were using XUL before it was deprecated. The only one that comes in mind right now is ActiveState and their Komodo Edit/IDE. But there used to be more developers and I recall their being a dedicated page that listed those other products built on XUL. The documentation of it, and the jump in complexity when it came to XPCOM (which were written in C++), were the reason (in my opinion) why platforms like Electron got popular instead of XUL.
        cxr 3y ago
        Not relevant to this topic.
        mhitza 3y ago
brundolf 3y ago
The accusation of malice goes a bit far, but I agree it's a problem whether it's intentional or not. Bun takes a slapdash approach to shipping features and APIs, which means things get out fast but also rubs me the wrong way re: long-term implications and vision
- eyelidlessness 3y ago
  I’ll vouch for non-malice. Bun’s creator frequently tweets about hypothetical APIs he may want to introduce, often seeking feedback explicitly. The ideas are always earnest “would you find this helpful?” sorts of things. (For what it’s worth, I frequently reply that these hypotheticals are a bad idea when they break expectations etc, at least if I can fit my reasoning in tweet length. I think this has been at least marginally successful in pushing back in some cases.) The problem, with Bun but really with the ecosystem at large, is that shipping stuff is (still) the de facto way that standards kind of congeal into something resembling actual standards.
  - brundolf 3y ago
    Yeah. I follow him on twitter too, and it's both impressive and distressingly chaotic the way he spitballs and then settles on APIs in the form of twitter surveys
    - tomjakubowski 3y ago
      seems to work for twitter's CEO - though he does sometimes ignore what the survey says
    - Aeolun 3y ago
      That works just fine if you are the main person working on something.
lemper 3y ago
> can't help feeling that it could be intentional vendor lock-in. it's always vendor lock-in. can never trust companies, mate!

by wayvey 3y ago

thomasreggi 3y ago

It's really because we have some wonderful collaboration between vendors now, and they don't want to have to come up with their own APIs. https://wintercg.org/ https://wintercg.org/

pjmlp 3y ago
Cough. Vercel.

jokethrowaway 3y ago

It's still OSS, not proprietary APIs. Feel free to fork it in the future, once they need to make their money back. If it's faster than node and the API to do what I need is better (Bun.FileSystemRouter comes to mind), I don't see why not to switch over. Heck, I would accept even less retro-compatibility to get rid of transpiling, that completely oscene political mess they did with modules and treating TS as a 2nd class citizen. The amount of time I'm still hit by ESM vs CJS is insane. Truly a Python 2vs3 moment for the node.js community.

chlorion 3y ago
The term "proprietary" does not always refer to software licenses, but that's one of the common causes of something to be proprietary.
- SahAssar 3y ago
  How would you define it? The wiki article for it in the context of software (https://en.wikipedia.org/wiki/Proprietary_software https://en.wikipedia.org/wiki/Proprietary_software) seems to pretty much stand it in opposition to open licenses, but I also have a sort of gut feeling that it could also refer to interfaces in OSS that are not designed to re-implementable. Not sure about that though.
  - cxr 3y ago
    "Nonstandard and controlled by one particular organization." <https://en.wiktionary.org/wiki/proprietary https://en.wiktionary.org/wiki/proprietary> XBL, a precursor to Web Components in use in Firefox for 15+ years before any ordinary webdev was talking about shadow DOM, was open source in every sense, for example. It was also proprietary. See also: "Problems with XUL". > XUL is a proprietary technology developed by Mozilla and only used by Mozilla. <https://mozilla.github.io/firefox-browser-architecture/text/0003-problems-with-xul.html#availability-of-example-code-and-help https://mozilla.github.io/firefox-browser-architecture/text/...>
    - mhitza 3y ago
      I don't know when that page was written, but there were other developers that were using XUL before it was deprecated. The only one that comes in mind right now is ActiveState and their Komodo Edit/IDE. But there used to be more developers and I recall their being a dedicated page that listed those other products built on XUL. The documentation of it, and the jump in complexity when it came to XPCOM (which were written in C++), were the reason (in my opinion) why platforms like Electron got popular instead of XUL.
      - cxr 3y ago
        Not relevant to this topic.
        mhitza 3y ago

brundolf 3y ago

The accusation of malice goes a bit far, but I agree it's a problem whether it's intentional or not. Bun takes a slapdash approach to shipping features and APIs, which means things get out fast but also rubs me the wrong way re: long-term implications and vision

eyelidlessness 3y ago
I’ll vouch for non-malice. Bun’s creator frequently tweets about hypothetical APIs he may want to introduce, often seeking feedback explicitly. The ideas are always earnest “would you find this helpful?” sorts of things. (For what it’s worth, I frequently reply that these hypotheticals are a bad idea when they break expectations etc, at least if I can fit my reasoning in tweet length. I think this has been at least marginally successful in pushing back in some cases.) The problem, with Bun but really with the ecosystem at large, is that shipping stuff is (still) the de facto way that standards kind of congeal into something resembling actual standards.
- brundolf 3y ago
  Yeah. I follow him on twitter too, and it's both impressive and distressingly chaotic the way he spitballs and then settles on APIs in the form of twitter surveys
  - tomjakubowski 3y ago
    seems to work for twitter's CEO - though he does sometimes ignore what the survey says
  - Aeolun 3y ago
    That works just fine if you are the main person working on something.

lemper 3y ago

> can't help feeling that it could be intentional vendor lock-in. it's always vendor lock-in. can never trust companies, mate!