One of the lesson that I believe is being learned is that general purpose programming languages for UIs make it difficult to do tooling, especially with dynamic typing.
This particular approach (.60) is not a general purpose programming language and it's strongly typed.
It's designed for the user interface, not for writing the rest of the program in it.
I feel this is rather different from the tcl/tk applications we used to see?
Maybe it could be brought over the top by compiling Qt to wasm and mixing that in. A bit tricky with the emscripten runtime vs wasm32-unknown-unknown target mixing of Rust though ;-).
Jokes aside, we added this embedding because of a specific user need.
Golang with the interpreter we well, but the RealThing(tm) would be a full code generator and binding to the runtime library. That would be awesome, but a little bit more work.
I quite like Go, it’s simplicity and GC is really convenient.
We went for dual licensing (GPL / commercial) in hope of creating a sustainable project.
We do have basic focus handling but the demos don’t really try to show that off - that’s more tailored towards touch based input at the moment. But we’d love to have a17y, full desktop like tab focused etc.
Regarding the compilation: the ability to live preview individual components or the entire design and seeing changes being applied on the fly (we have an interpreter for that) speeds the ui dev cycle a lot. Give it a try :)
Lsp can be used with any IDE, better markup language (static typing, proper module concept), rust and JS APIs, markup compiled to proper C++/Rust AOT, compiler can do asset optimizations (todo) - for example:).
In short: we try to do one thing (UI) and do it well :)
We try hard to avoid that. No magic context properties, good modularity across files (js module concept). Easy to write components. But there is more work to be done.
The software is not built on Qt. The compiler and runtime is written in Rust (Qt is C++), the renderer is a lightweight GLES 2.0 renderer and winit is used for window creation and events.
The runtime’s API is available as plain C++ API (only depends on C++ standard library), JS api in node (via neon) and Rust natively (simply a crate). It’s generally rather lightweight in terms of its surface. Instead the focus is on our compiler generating API for the input design files, to make it easy to manipulate properties or feed data models into the UI.
We’re internally using QStyle calls to produce images of controls when selecting that kind of styling at compile time, but that’s entirely encapsulated. The style you see in the wasm demos for example is entirely done using GLES accelerated primitives (such as SDF based anti-aliases rectangles).
We need to make our description a bit more precise - and we're working on comparisons. In terms of pure RAM usage (as opposed to ROM) in our experience the display resolution contributes a lot to what's left (unless there are dedicated frame buffers). So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?
Generally I think we're aiming a little above LVGL/uGFX in terms of configuration, but also with with a much richer UI / features.
>So if you mention <= 64kb RAM, what kind of displays are you typically dealing with?
Typically displays with integrated SRAM. To give an example, a recent project used a 480x320x16-bit display and an MCU with 64kb SRAM. The display/drawing buffer took 38kb of that (i.e. 1/8 of the display).
Cool! I’d say that’s the very low end for us, but we think that it should be possible to create decent UIs also for such configurations. It would require additional work for us to target that right now but we’d be happy to take that offline. Drop us an email at info@sixtyfps.io please if you’re interested:)
It's not perfect though, and I think we're going to try to create binaries for download alternatively.