I hope they solved the spaghetti code nature of QML (basically everything can refer to anything else; you end up with children that have dependencies in the internals of their parents).
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.
Yes, we use static typing and everything is statically known within a single file.
This allows to preview each control on its own since they don't depends on their parents.
- Library is under the GPL 3, vastly more restrictive than most existing GUI toolkits
- WebAssembly rendering in Firefox most certainly not living up to the name. I think the slide animations on the print example are managing around 5-10 fps
- Keyboard input / control focus seems absent in the demos. This would also suggest the much more important detail of accessibility also missing
- Compiles layouts to code. Is this really necessary? Visual cortex places severe restraint on how much complexity can go into a UI. Code generation on the other hand says a lot about how painful the dev-build-debug cycle is likely to be.
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 :)
This is pretty cool, and it probably works very well on other platforms, but the compiled-to-WASM isn't great. For one, text boxes don't actually focus while capturing input, so my keyboard shortcuts kept firing while I was trying to type into their text box.
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.
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 :)
The use of the Qt backend is only temporary to get native style quickly on every platform. In the future, we would use a native windows and mac bckend.
> This release also includes new Rust and C++ APIs to dynamically load .60 files, with the sixtyfps-interpreter crate in Rust, and the sixtyfps::interpreter library in C++. This also allows embedding a component as a QWidget in a Qt application.
in case Widgets and QML and HTML in one app wasn't bad though
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.
SixtyFPS is the first project with a company behind it which uses femtovg, a Rust nanovg port. https://github.com/femtovg/femtovg for rendering. SixtyFPS added WebGL support which lets you run femtovg in the browser https://tronical.github.io/femtovg/examples/index.html.
Recently, femtovg added an experimental wgpu backend which is for now in my fork of the project https://github.com/adamnemecek/femtovg.
Join the femtovg discord https://discord.com/invite/V69VdVu.