Declarative UI: Swift/Dart vs Qt/QML approach

[medvednikov]

Hi,

Update

V UI has been released, V itself is used for declarations.

I'm working on declarative UI right now.

Which approach do you think is the best: Swift/Dart (using the same language for declarations) or Qt/QML (using a smaller cleaner different language)?

It's nice to have only one language, but the "VML" approach looks cleaner to me.

Also, I'd need to modify V a lot, for example to allow things like [TextBox{}, Button{}].

[nedpals]

I like Dart's approach. It's easy to debug and understand the properties of the component.

[Delta456]

I like QML's approach because it's quite small and is more easy to understand IMHO .

[dumblob]

Hi @medvednikov, a good UI is undoubtedly a valuable endeavor. Believe me though, it's kind of waste of your precious time. Read carefully the discussion vlang/ui#1 (comment) on this topic and dive thoroughly into the technical story (part 1, part 2) behind making modern UIs as referenced in the post.

To put it bluntly, don't even try to create yet another retained UI (as QML, Dart, WPF, Qt, GTK, ... you name it). It won't be used much and your work won't bring the fruits you'd expect and like to. There are literally hundreds of cross-platform UIs (sometimes embedded into applications, sometimes separated as a library). Your UI reminds me a lot of Lua tekUI and of QML. Don't recreate them, it's pointless 😢 (unless you want to avoid bindings to existing good UI libraries and an the same time make V a mainstream language, not a "better one" as I understood it until now 😉).

All this boils down to can be summarized as:

For UI all approaches are equally necessary - declarative compile-time retained, then declarative run-time retained, then compile-time immediate (i.e. non-declarative), and finally run-time immediate (i.e. non-declarative) mode.

Above-mentioned frameworks do offer though just the declarative compile-time retained approach and partially the run-time retained, but not at all compile-time immediate nor run-time immediate.

---

P.S. Full-featured UIs are about as complex as full-featured programming languages offering builtin parallelism and stdlib. UIs can eat up all your time for years...

[medvednikov]

@dumblob there's no good cross platform native desktop UI library, this was one of V's main features. I've already written thousands of lines of UI code, I don't see a reason not to release my work :)

[ylluminate]

@medvednikov I must lean towards purist methodologies such as keeping it declared in the language itself vs having to remember something else or breaking out into a different methodology. When you get into generative aspects and such it seems superior to keep the language completely universal...

If i'm going to go for friendlier syntax, i'd just stick to Ruby. V is a far cry from the elegance of Ruby in terms of syntax and robust expression, but that's not why I value V and so i tend to think sticking with the "one way" mantra is the right way here.

Sidenote BTW (😀): I'm always for reducing boiler plate and simplifying syntax. If I could have V in Ruby syntax buddy you can believe I'd be first in line (!), but I realize there are tradeoffs. Hopefully at some point someone will take the initiative to write Ruby in V (similar to this Ruby with Rust project). :)

[gslicer]

I plead for declarative UI in V syntax

[dumblob]

I've already written thousands of lines of UI code, I don't see a reason not to release my work :)

If it's only about releasing, then sure, go ahead 😉.

there's no good cross platform native desktop UI library, this was one of V's main features.

Well, this is a very bold statement and I'd argue it's exaggerating a lot. I know several very good cross platform libraries which are very hard to beat in their functionality and overall quality. Some of them are (very) minimalist, some of them leverage programming language(s) of their choice (pretty much like your declarative UI library uses V and will be hard(er) to use efficiently and as easily in other languages), some of them are more modern (allowing tighter integration with constrained platforms like web), etc.

So, generally there is no need for a cross platform UI library as they already exist and work well (might be less known, but that's another story). The only issue UI libs have is, that they are cumbersome to use. Still in each of them you can in the end achieve anything you need (beginning with animations, going through canvas-like painting up until fully dynamic behavior of widgets & any visual objects including their size/shape/content/position and their creation and/or destroying on demand in reaction to e.g. user input).

Don't take me wrong, but I'd rather say, don't try to push yourself to create a good UI library, as it's provably impossible with a declarative UI in the first place (in short: many of the above-mentioned requirements "animations ... on demand" are impossible with declarative UIs unless they're to be significantly more complicated then all the web CSS stuff nowadays).

[medvednikov]

Well, this is a very bold statement and I'd argue it's exaggerating a lot. I know several very good cross platform libraries which are very hard to beat in their functionality and overall quality.

I'm very interested in what these are. They key is native and cross-platform.

So Qt, GTK, Nuklear are not an option.

I can think of only wxWidgets and libui, and the latter is still at a very early stage and not under active development.

[dumblob]

They key is native and cross-platform.

Assuming native means

looking exactly as native, behaving as native, using native widgets/constructs everywhere where there is feature-set equivalent available

and cross-platform means

Windows, X11 (i.e. Linux/BSD, ...), macOS, maybe Android

then off the top of my head (in random order): .NET WinForms, libui, Python tkinter, wxWidgets, [Red/VID](https://doc.red-lang.org/en/vid.html , VCLua, Qt (it mimicks it very well), QML (same as Qt), GTK (yes, it uses native DLLs for look&feel), IUP, Solvespace GUI abstraction, ...

Regarding the risk of (not) being developed, it's the same risk of any project disregarding whether proprietary or open source. Btw. V and it's ecosystem has this risk way higher than libui because "nobody" uses V, but hundreds of active users use libui.

---

(Not speaking about the fact, that libui is actually being actively developed - not sure where does the misinformation about abandoned development come from. Also libui is way ahead of V and it'll stay so for months, maybe years even if the V's development pace won't decrease.)

P.S. Btw. libui is also a perfect showcase why retained UIs are the wrongest decision for UI development - look at what's on the libui TODO list to get a grasp of what's needed for retained UIs, but is absolutely unnecessary e.g. for immediate mode UIs.

[ylluminate]

Ultimately we need a native facility for UI implementation in V that provides native "widgetry" for each platform. For Windows and macOS that means to provide access to these systems' own UI toolkits with V interfaces. For Linux that obviously means something a little different and that, as you've noted, has been done via mechanisms you already have in place. Furthermore WASM and JS are also going a native and customizable UI interface that is immediately provided as well in this same vein (so it's essentially lumped in with Linux). From what I can tell you're on the right track @medvednikov.

I hear what @dumblob is saying, but I fear it may not hold true in this situation. Could libui fill this void and facilitate a UI for each platform with the necessary cross-compilation requirements that V needs to cleanly provide this? I don't know, I guess only you @medvednikov really can answer this. If V-UI is does this and does it cleanly and efficiently in native V then perhaps it's better and more maintainable than going with an existing C library.

If libui is even an option, for example, would it be time to create what we previously discussed with this back-and-forth tooling that will facilitate translation in both directions and diffing in order to keep projects in sync? Would that be a better investment of time? Again, I don't have the answer to this.

The one thing that I know is that we very much need a V-UI facility and it's something that cannot wait. It's also something that needs to be - LIKE V - cross compilable in every direction.

C proper has failed at this goal over the decades. It's a shame because C was supposed to be what V is. Everyone who has ever set out with C has effectively lost their way and got caught up in proprietary thought that has now yielded all of these platforms. It was a terrible mistake. Microsoft & Apple started the mess to a large degree (I know there were licensing issues at that time, but there were ways around it). Steve Jobs tried to bring some sanity back (and did) with NeXT, but here we are with Linux and this nightmare fragmentation. Too many of us hate GTK. Qt just simply didn't win thanks to the crap that went on with that circus. Etc. Etc. Etc.

So I guess at the end of the day I go back to my original thoughts: Alex, you've put a lot of work into this. You've done an amazing thing in a short period of time just bringing forth what you have. You have your own GUI needs with apps you've been working on. We need a true cross platform UI lib. Can V-UI do better than all of the other options and work in V's Live development mode? If all of this is the case, then let's do it your way and see what happens. And if all of this is the case, let's keep it in pure V.

Sometimes naivety and fresh perspective, as problematic as it can be, is the solution in this twisted metal wreck of computer science and software that presently exists.

[medvednikov]

then off the top of my head (in random order): .NET WinForms, libui, Python tkinter, wxWidgets, [Red/VID](https://doc.red-lang.org/en/vid.html , VCLua, Qt (it mimicks it very well), QML (same as Qt), GTK (yes, it uses native DLLs for look&feel), IUP, Solvespace GUI abstraction, ...

.NET WinForms (Mono) is not native, the link you referenced mentions that:

Why Not Use Native Widgets?

It's also C#, which makes it very hard to usefrom C.

Qt is anything but native. It renders everything, and Qt apps, just like Java GUI apps are notorious for their "un-native" look. I use a Qt password app every day (KeePassX) and it's very visible. Besides, Qt is a multi gigabyte C++ monstrosity with a custom C++ dialect, so it's not easy to integrate it into a small language like V.

GTK is just... No comments :)

libui is a one person project mostly that's still in alpha after more than 3 years of development. andlabs/libui#274

libui is also a perfect showcase why retained UIs

If we want to have a native toolkit, then we have no choice but to use retained UIs, because that's what Win32 and Cocoa are.

I know that it's not 2007 anymore, and people don't care about the native feel that much. And the desktop app market is stagnating and being replaced by mobile. I also realize that what I'm doing may look like

But I'm 100% confident that's the right choice.

From the reviews I received, people are tired of 200 MB tray apps written in Electron/JavaScript just because there's no good and easy to use cross-platform UI toolkit.

And like @ylluminate mentioned, this is all going to be in pure V, with hot reload and cross-compilation, which is something none of the existing desktop toolkits offer.

[ylluminate]

@medvednikov is spot on here. The comic is apropos, but (strangely) sometimes this is okay. I've been a project manager for an engineering firm and software engineer for a long time. I understand this ecosystem and frankly the ecosystem is so horrifically painful.

This issue about memory could be likened to a massive infection upon the software industry. It's like the visible head on a massive pustulant cyst on someone's face or head that they're trying desperately to hide, but it keeps growing and growing. Google is a nightmare with their Chrome practices and the web devs who have adopted technologies such as Chromium/Electron are compounding the situation. This kind of insanity must stop.

I agree that this SEEMS like we're going to end up with a mess, but I believe Alex is right. I may not be excited about some things like like spending time on making a Discord replacement due my desire to see that time dedicated to V-UI and other pet features, but ultimately the UI (today) is as integral and inextricably connected to success as the language's innate stability and robustness itself... :s

[gslicer]

@dumblob perhaps we should give @medvednikov a chance to show what he has built until now and if this could be an option to go or better to offer V bindings to existing UI frameworks

btw: I consider GTK+ as one of the "native" GUIs under GNU/Linux (because it supports very well Wayland) - another one supporting this protocol is Enlightenment (might be worth to take a look into it)

[dumblob]

I do fully understand what @medvednikov, @ylluminate and others expressed here. I have to admit, it's my dream for almost two decades now. The one and only one obstacle which makes me rather pessimistic about the (current) plan for V UI is what @medvednikov wrote about V UI:

If we want to have a native toolkit, then we have no choice but to use retained UIs, because that's what Win32 and Cocoa are.

Which in stark contrast with what @ylluminate wrote:

Sometimes naivety and fresh perspective, as problematic as it can be, is the solution in this twisted metal wreck of computer science and software that presently exists.

and thus makes its way directly towards the 15. competing standard from the perfectly fitting xkcd comic.

It's fine to have V UI being the lowest common denominator across platforms. It's small, easy to maintain, fully native, fast. This'll then become a slightly less capable IUP but for V and not Lua. Originally I misunderstood and thought that V UI shall be more capable - therefore all my "warning" comments which you can ignore now 😉.

---

.NET WinForms (Mono) is not native, the link you referenced mentions that...

Yeah, just the behavior is native (rendering isn't). Still, WinForms theming is better than in Qt and GTK and an average user wouldn't often probably notice.

libui is a one person project mostly that's still in alpha after more than 3 years of development. andlabs/libui#274

It's one person project, but as I linked above it got forked many times with many active contributors and active merging => it's far from being dead. Also the linked thread andlabs/libui#274 clearly states it's not dead at all plus defines a roadmap etc. Last thing is the "alpha" state. Well, in practice libui is well usable (even the number of GitHub issues underpins it - yeah, 139 for such a big project means "all is perfect") with hundreds/thousands of users. The libui author is underestimating a lot - compared to other about as complex projects it would already be 1.x. On the other hand, libui is IMHO not a good fit for V for other reasons.

with hot reload and cross-compilation, which is something none of the existing desktop toolkits offer.

The following is not meant to disappoint anyone, but this is simply by far not true - e.g. Red GUI is unbelievably capable and offers hot reload (even better than V as one can edit the underlying application pretty much like in smalltalk environments), full cross-compilation (done right) for Windows, macOS, Linux (GTK), Android (!), etc. and is super fast.

Let's stop comparing thuff and rather rationally discover what everything can be done with the lowest common denominator of retained UIs. If not capable enough for V's basic needs in stdlib, then rather skip this completely and don't make it into V's stdlib at all and take some existing promising lib like Quarks, accommodate it to V (in case of Quarks even a rewrite in V would be a sane solution), maybe even use some native widgets as backend for uses matching the lowest common denominator and finally add it to VPM.