You can't, but as the author I can assure you that I'm very trustworthy lol
I've been thinking about a standalone version for a while, but haven't gotten around to it. You could use the vscode/codium extension and disable auto updating for a similar effect.
In my view it's the other way around. If you stick to a state machine for your app logic, you'll end up with an unintentional half built reimplementation of a general purpose programming language.
The fact these state machines aren't the mathematical constructs from CS, but "extended" versions with "context" (this is where all the actual app state goes), should be the giveaway that they aren't a sufficiently capable model for the demands of UI programming. After you add extensions for every possible need, what do you end up with?
I understand the appeal though. UI development is a complicated mess, and people want a formula to make sense of it all. I've went through several iterations of these cookie cutter patterns form MVC to MVVMC++ to flux to redux to redux-saga to immutable.js to Recoil and so on. At best these marginally improve the situation, at worst they end up adding complexity on top of the inherent mess.
At the risk of missing out on the One True Way of doing UI development, I'll pass on this latest installment. I keep open the possibility that state machines "marginally improve the situation" though.
If you can do with an even leighter-weight client, you can try my very own https://sqliteviewer.app. It's all browser/wasm-based and works offline, but has some important shortcomings.
Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable.
It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to the DOM, which will break virtually all of them (including my own sad contributions to this space).
The exception to this are those built using a 3rd party library like lit-element or stenciljs, which fill in the obvious omissions of these specs. Perhaps in another 10 years, a mangled version of half of one of them can be standardized? In the meantime, each component shipping its own frontend library or inlining the same core functions over and over again does nothing in the way of interoperability. You can bundle every popular JS framework and mix their components today. The reason you don't do it then or now is bloat, not the lack of a minimally viable shared component interface.
Besides, if you're going to use a 3rd party library and associated bundler/compiler, you might as well pick a good one such as React, Vue, Svelete, Solid or even jQuery UI. Using any of these, you can design and build an entire app faster than the bikeshedding commissars from goog and aapl can agree on whether "open" or "closed" should be the default for attaching a shadow DOM (at the risk of ruining the joke: there was no agreement; the developer has to provide a value in each instance...)
I've once built a vscode extension. I didn't expect much, but was still suprised at the complete lack of feedback, reviews, etc. despite many downloads. One day I've added a popup asking for reviews. Virtually all my reviews come from the period I've left it up. My takeaway was, letting people know what to do goes a long way.
No sure if I’m missing something, but you can tap directly into the readable stream of fetch which should be at least as good as progress events? I’ve used it here (https://sqliteviewer.app/, click “load a sample”) and it works as expected.
I've been thinking about a standalone version for a while, but haven't gotten around to it. You could use the vscode/codium extension and disable auto updating for a similar effect.