flyweight VS ts-proto

Hey. This is my first electron app. It is called Quietone and I just thought it would be cool to navigate and manipulate videos by their transcript because searching through videos for the things I was looking for was very slow otherwise.

I used whisper.cpp to do the transcribing. It has held up really well. The tiny model (the fastest one) can transcribe 2 hours of video in a couple of minutes on my m2 mac mini and the accurate of even the tiny model is pretty good.

I used Electron Forge to package the app for different operating systems and distribution channels. There are no guides on the internet on how to do that properly so that took quite a bit of time to figure out.

At multiple stages I had to look through source code of Electron Forge's dependencies to figure out how I was supposed to use it to correctly sign the app for the mac app store.

I made this app using the tools I like to use, which is not very typical. I use straight javascript, no transpiling, and I wrote every single library myself from the ORM https://github.com/thebinarysearchtree/flyweight to the front-end framework, which is a thin wrapper over web components.

Oh yeah, Electron recently started supporting esm, but Electron Forge doesn't fully support it so I had to use esbuild to compile to cjs just for the packaging step.

I use events to make everything change in real-time in the UI. Umm... oh yeah I did include yt-dlp features but had to remove that for the store versions.

It is available on the mac store, and soon on the windows store. There is also a trial you can download. The windows store experience is not very polished compared to the mac store. I was amazed that there are humans reviewers looking through everything I upload. hah.

Anyway, I have to go find a job now and hope my username doesn't check out. Bye. Thanks for reading my blog.

I wrote https://github.com/thebinarysearchtree/flyweight in JavaScript, not TypeScript. It generates TypeScript declaration files as it types SQL, which helps with intellisense support in VSCode. That is the only reason I use TypeScript.

I don't like TypeScript though, and would never write anything in it. I have a long history with C# and I came to conclusions about this topic a long time ago. I just prefer writing JavaScript, it is more fun and more productive.

Flyweight is quite a complex library. It parses arbitrarily complex SQL. This is more complex than most of the things people work on and claim they need static typing. It isn't millions of lines of code, but often those codebases aren't complex, they are just many independent components that in themselves are not that complex.

The amount of time I spend having to update the TypeScript aspect of my library is really quite annoying. Also, with regards to your point about libraries not including type information - this is also true for the actual native APIs in the browser and so on as well. For example, TypeScript doesn't recognise the "indices" property of regular expression matches.

I created it so that I could use `protoc` and `ts-proto` to convert the otel proto files into typescript files.

Re libraries incompatible with certain typescript versions - e.g. protobufjs fix - it’s been my experience that you want to try and only use compilers specific to each library and compile libraries separately. It’s unfortunate but the JS community often tries to run all JS for a project through the same single compiler tool chain, using one global version of the compiler instead of relying on and effectively linking the JS output for each library. Unless you routinely rewrite third-party libraries to match your toolchain’s expectations, you’re going to have a hard time doing that.

For a library that generates code, that’s a special case, as the code it generates must target a particular language version. You have three choices: 1. Upstream a fix as you propose; 2. Side-by-side install both TS 4.6 and TS 4.7 using workspaces or sub-projects and have some of your code compile with 4.6 and then link the results or 3. Find a replacement that is updated to 4.7. For example, https://github.com/stephenh/ts-proto has 4.7 support listed in its readme.

With ts-proto, I can pass a --ts_proto_opt=outputServices=generic-definitions as a flag to protoc to generate "generic service definitions". These definitions contain descriptors for each method, which allows to generate server and client stubs at runtime, and also generate strong types for them at compile time.

Curious to see their typescript implementation and how it compares with https://github.com/stephenh/ts-proto which works great for grpc-web.

I'm planning on modding https://github.com/stephenh/ts-proto to use https://github.com/ianstormtaylor/superstruct on the client.

We also use protobufs and typescript, so we use ts-proto for codegen + binding to grpc services.

Fwiw I maintain ts-proto (https://github.com/stephenh/ts-proto/) and it'd be cool to have the functionality you're building supported in ts-proto at somepoint, if you're curious/want to poke around/etc. :-) Right now there is grpc support via the improbable-eng grpcwebproxy, but supporting GCP's transcoding as well would be great.