orbtk VS tauri

i was gonna bring up https://github.com/redox-os/orbtk only to discover it's no longer under active development.

OrbTk is sunsetting in favor of Iced, slint, and future renderer-agnostic toolkits: https://github.com/redox-os/orbtk

Orbtk

The GitLab repo was deleted. You will need to update the submodule path to https://github.com/redox-os/orbtk.

That said, I'm not totally convinced about SixtyFPS today. There are some other interesting options that are suitable GUI toolkits for Rust. Such as OrbTk and Iced. Each toolkit is approaching the GUI space in a different way, so it'll be interesting to see where we end up in a few more years. QML-esque SixtyFPS, ECS-based OrbTk, Elm-based Iced, and a few others out there.

What's written in this article isn't the development of a GTK fork, but some reasoning for exploring alternatives to GTK. There aren't very many suitable candidates in this space, but Rust GUI toolkits like Iced have potential. Personally, I would add that OrbTk is also a suitable candidate.

I use orbtk, it is pretty easy to use, has an active dev team, works on windows mac and linux, and cross compiling from linux to windows is also easy with it. It is still pretty beta, but depending on the project you need it could work. (https://github.com/redox-os/orbtk)

Orbtk is an option. The default is backend is orbraq, which uses OrbClient. OrbClient will use SDL on Linux, and on Redox it should be a "pure" rust experience.

OrbTK recompiling stuff has been fixed in the development branch as far as I can tell: https://github.com/redox-os/orbtk/pull/409

OrbTK

Hi, dear Tauri! Long time no see. I published my first post, Developing a Desktop Application via Rust and NextJS. The Tauri Way almost a year ago. Since then, Tauri has become stronger. I'm happy about that! And now, I am very pleased to make a useful contribution to the Tauri community. As a full-stack developer, I frequently face situations where I need to start a DB-based UI project as fast as possible. It's stressful if I need to start the project from 100% scratch. I prefer to keep some boilerplates on hand, which will save me time and nerves and will be the subject of this article.

Hey Thanks!

Just electron & vite. I might actually migrate off electron, Tauri (https://tauri.app/) seems to be getting more stable and it's gotten great reviews.

I think this is the boilerplate I used though https://github.com/cawa-93/vite-electron-builder.

Well the great thing about WebAssembly is that you can port QT or anything else to be at a layer below -- thanks to WebAssembly Interface Types[0] and the Component Model specification that works underneath that.

To over-simplify, the Component Model manages language interop, and WIT constrains the boundaries with interfaces.

IMO the problem here is defining a 90% solution for most window, tab, button, etc management, then building embeddings in QT, Flutter/Skia, and other lower level engines. Getting a good cross-platform way of doing data passing, triggering re-renders, serializing window state is probably the meat of the interesting work.

On top of that, you really need great UX. This is normally where projects fall short -- why should I use this solution instead of something like Tauri[2] which is excellent or Electron?

[0]: https://github.com/WebAssembly/component-model/blob/main/des...

[1]: https://github.com/WebAssembly/component-model/blob/main/des...

[2]: https://tauri.app/

Welcome to the 2nd episode of our series “Building with Tauri”, where we chat with developers who build amazing projects and products using Tauri.

Tauri seemed like the "thing" I should switch to because everybody loves Rust (heh), and because it ships significantly smaller apps.

First of all, I will be using npm as my package manager but feel free to use whatever you prefer. Find more info here.

Today I'm talking about Tauri! Do you know all the various tools that allow you to develop native applications starting from web languages? They often need an intermediate compilation, in the middle of which you end up encountering various problems not always transparent and directly solvable with a language mostly detached from native development. On the other hand, there's still the ease of developing attractive and easily usable interfaces, which are more difficult to develop with low level languages.

I think Tauri is the most established framework using that approach

https://tauri.app