4 ms·
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 w
by 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 agoThe term "proprietary" does not always refer to software licenses, but that's one of the common causes of something to be proprietary.
- SahAssar 3y agoHow 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 agoI 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.
- chlorion 3y agoIt depends on the context I guess. In the context of not software licensing, I would define it roughly like you said. Interfaces that are designed in a way that is not compatible with existing software or easily implemented by others. An example would be QT, the GUI framework for C++. It has it's own implementation of stuff that already exists in the standard library, like the string container for example (std::string). You can't use standard C++ types with QT and you can't use QT types with non-QT C++ libraries or types. I am not a C++ or QT expert so there may be some level of compatibility between the types when using generics or in general, but from my very tiny use of QT it seemed like you had to use their types.