flatbuffers: missing --js is disruptive
In the 2.0 release the --js option was removed. This is rather disruptive for live production sites requiring the need to use multiple versions of the flatc tool for different languages.
After some digging it becomes apparent that you can use the tsc tool to convert --ts output to javascript, but this is not straight forward because the output is not the same format, and worse, the tsc toolchain is invasive and not always easily installable.
Apart from short term breakage, it is problematic that it requires heavy tooling in addition to flatc.
The argument that there are many flavors of javascript and modules doesn’t really hold. It would be possible to simply support Ecmascript 6 which would be acceptable to all modern browsers and presumably node.js.
Also, the now lost bundled single file output is fairly signficant for web site inclusion without extra tooling, but I could see a --js and --output-file option combined to achieve that, if multi file output like --ts is preferred.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 4
- Comments: 34 (16 by maintainers)
@bjornharrtell I agree a tsc wrapper would be pointless. I do not accept the argument that you always need transpilation. If that were the case, I could accept ts as the only output. But the usecase is to dump a .js file in a simple webpage and send and receiver flatbuffers from an API endpoint. The previous js did that just fine.
Eh, this is just too hand-wavy to me, and feels like it ignores the kinds of users flatbuffers is likely to attract. flatbuffers is a performance centric library, and perormance-centric developers disproportionately concern themselves with minimizing both build time and runtime deps because they understand that all deps have a cost to a project. So it stands to reason that the “flatbuffer users” vs. “developers that care about minimizing dependencies” venn diagram is going to have a fairly large middle section, rather than a thin (i.e. niche as you’ve suggested). Whereas devs that don’t care about things like performance and dependency cost will be more likely to use json parsers everywhere and eschew things like flatbuffers altogether.
I have to agree with @mikkelfj that this was a disruptive change. Implementations of javascript exist outside of the node/typescript ecosystem, including a host of lightweight/embedded machine implementations. Flatbuffers, being a library/file format that is all about packing and reading data in performant way is a very natural pairing for many of these embedded and minimalist contexts.
I could get behind a “npm/node is the standard, everything else is niche” attitude if we weren’t talking about a performance oriented data serialization library, but we’re talking about a performance oriented data serialization library.
I’m bumping into this as well. Is there a migration guide from 1.12.0 JS to 2.0.0 TS?
I’ve inherited a project built with JS and it seems I have to update all the references when using TS
“Dumping” a plain .js file into a page is a concept which has been abandoned in practice years ago. While there surely are legacy projects which still do that, we would like to support a more contemporary approach of using modules. Nevertheless, you still can transpile TS and create one giant blob of js, if you wish. If, for any reason, you don’t want to do that, you can stick with a previous version, which is binary compatible with 2.0.
With that line of argument, you could just use C++ instead of typescript since typescript is a niche case.
Not everyone is using node.js, let alone npm. On web site builds it now requires node.js and npm to be installed. FlatBuffer from web to server is a very real thing.
For developers generating code from schema and check it in to a repo, these all require node, npm and tsc to be installed in order to generate code.
Regarding the same format, I cannot elaborate and I may have been mistaken. A coworker used the swc tool instead of tsc due to installation issues and could not get this to work (trivially, and reverted to flatc 1.12). As I recall the FlatBuffers doc mentions that the format might be different.
You cannot argue that ECMA Script 6 is an abritrary choice. A few years back it would be different, yes.
As nice as TS is, it lends itself to the all too heavy tooling needed to build modern web sites (looking at webpack). I think it is nice, and relevant, to have TS output. But omitting JS is not good.