quickjspp VS pngsource

I think that my Storage implementation that is built-in into JavaScript in QuickJS and Sciter is still unbeatable as an integrated JS Storage solution:

"custom version of React he publishes..."

It is not a a custom version of React but rather extension of DOM model by just these:

1. Native JSX support. In Sciter QuickJS was extended to support JSX literals out of the box: https://github.com/c-smile/quickjspp/blob/master/quickjs-jsx...

2. Native methods:

   - Element.patch(...JSX expression...) - native VDOM reconciliation implementation.

In fact 1.8 Mb is quite a lot for QuickJS.

Whole Sciter engine that includes as QuickJS as HTML/CSS engines is about 6 Mb.

My port of QuickJS [1] that also includes persistent storage (think of MongoDB built into JS) is 736 Kb on Windows.

[1] https://github.com/c-smile/quickjspp

I've added built-in persistence to QuickJS: https://github.com/c-smile/quickjspp/blob/master/storage/doc/introduction.md

I might go a little offtopic here. Any plans to integrate https://github.com/c-smile/quickjspp. That way you can target mobile platforms too. QT supports mobiles well

As for desktop only this is great. Great work. Many people are commenting on NodeGUI only. They have forgotten to mention how Svelte also contribytes to saving memory footprint and cpu cycles over other frameworks with a much easier way to write apps. Add a small learning curve to that.

I've added JSX to JS used in Sciter that allowed to have JSX available for Mithril and PReact

This is really neat. Reminiscent of how drawio.com can embed the source inside exported PNGs (see also https://github.com/Fusion/pngsource)

I would love to see this approach extended to add some animation too.

I see, in this thread, talks about what Sciter does and does not offer.

It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.

I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)

On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.

The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.

I cross-compile the apps using xgo (https://github.com/karalabe/xgo)

It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)

However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.