VUI for Web

[ylluminate]

One critically attractive point for vui will be to also have a standardized UI presentation for the web as well so that WebASM compilation will produce an equally attractive UI comparable macOS, Windows and Linux.

One problem here could be that there might not be a standardized UI component or presentation set that can be readily used. Hopefully we can decide on something here in this regard or maybe there's something already that exists that makes sense.

I have a couple thoughts from some older interesting projects I've seen that seem to make sense and will try to add these later on when I have some time to find them again.

[ylluminate]

So the previously very interesting platform I was thinking about was built on Cappuccino (Wikipedia) via Objective-J. This perhaps is particularly interesting because it has similar goals to V in the "one language for everything" sense in that the idea was to use Cocoa (Objective-C) and then be able to use Objective-J in the same way even to the point where you could use Apple's own Interface Builder to crank out the user interfaces (even though Apple kind of ended this Cappuccino's Objective-J momentum via shifting things over to Swift).

An example of an extremely nice app that was a webapp clone of Apple’s Keynote was this (before they were acquired and folded into Motorola Mobile): https://web.archive.org/web/20101208065929/http://280slides.com/

Mockingbird is another example: https://gomockingbird.com/home

There is also the interesting concept of the ORM interface between the GUI and backend: https://github.com/jivadevoe/CappuccinoResource (There used to be one called CActiveRecord)

This is/was the default theme for Cappuccino: https://github.com/280north/aristo (backup)

The PSD could serve as a nice template to created standardized templates for 1) a modern macOS, 2) Windows, and 3) Linux default appearances. Heck, this could create a nice little market in and of itself for people making nice custom skins that can be used across platforms and as desired. Something to think about.

[GaryMiller]

https://speckyboy.com/open-source-front-end-ui-kits/

[ylluminate]

Yes @GaryMiller there are a lot of options. I fear that we'll get caught up in an HTML/CSS loop for web app development when we could have something much, much, more directed and cross platform with a clean theme system vs the additional and unnecessary complexities of HTML+CSS that have to respect all of the various web browsers and their idiosyncrasies. WebAssembly SHOULD essentially eliminate this at some level by way of providing the ability to have an actual application in the browser...

Now, please note, I'm not talking about web development here to generate websites. I don't believe that that is the goal of VUI (@medvednikov please correct me if I'm wrong). Web development would and should be a different domain and I think it's a very complex one at that in terms of the questions of user interface and web standards. I think this is where a "V Rails" would come into the picture.

Now having said this, it should be possible to use a web app generated with V and VUI (and ORM) entirely in a browser instead of a traditional HTML+CSS based webapp, for example: we have an application that we're working on building and up to now we've actually jumped the ship on traditional web technologies and moved to Unity and C#. We don't really enjoy this option as it's still a bit clunky, but it DOES provide the best cross platform solution to date for when performance and cross platform functionality are top level considerations... At this point now we've paused the project due to the rapid rate at which V is moving and with VUI we have the promise of a universal platform (aka isomorphic) where we maintain ONE codebase and we get top shelf performance! This is huge and is a game changer.

The idea, if you look at some of the Cappuccino apps, was that they could take an app and deploy it essentially either on macOS, iOS (although this really wasn't so much of a thing then) or the web with essentially a single codebase. Motorola bought them due to this attractive proposition, BUT it seems like everything changed so much with Apple and mobile platforms that they just left the project alone. It's a shame they didn't have the vision to keep it going and bring it to the next level.

But here we are. I think @medvednikov's goal here is along these lines, but yeah, let me know if I'm missing the mark. My thought is that VUI as an app UI toolkit and with WASM support it can essentially replace traditional web apps by embedding it into the system. By following a UI development ideology that follows after Apple's Xcode/Interface Builder you can easily handle all of the responsive web design issues that can fly at you with a beautiful app + webapp that "just works" everywhere.

By the way and FWIW @medvednikov I think this article from 2009 is so indicative of where V can go: https://www.sitepoint.com/280-north-announces-atlas-web-app-design-changed-forever/

280 North's Atlas SHOULD HAVE BEEN the future. Things would be so much better today on the web, but yeah, that stuff I mentioned happened and here we are, kinda stagnant, with terrible web technology that caters to creating jobs vs getting work done. Maybe it's time to bring Atlas back with V.

[ylluminate]

@medvednikov the followup to the opengl/wasm question on #ideas-and-suggestions might be best followed up with a read of this: https://insights.dice.com/2019/02/28/webassembly-web-gui-future/

While I don't know if that's entirely authoritative in some aspects, it does give a nice overview and perspective of things and mentions an interesting project called imgui ("Immediate Mode Graphical User Interface") that also has wasm implementation.

I don't necessarily believe that adopting imgui is the right approach here (heck I don't even like the default appearance at all), but I DO think we could learn from it to see what he's up to...

It might also be worth looking around at some other resources: • https://github.com/mbasso/awesome-wasm#web-frameworks-libraries • Not what we want here, but interesting: https://www.vugu.org • Project Houdini sounds very interesting and might have some potential as it apparently allows direct rendering engine access from within WASM

[GaryMiller]

The only point I was making with the link is that we incorporate an existing OpenSource web framework to make the web compatible graphics it should probably be the fastest or close to since speed has always been one of the major goals. WASM support I agree should be the fastest but obviously, speeds of these different interfaces seem to still vary a lot. Maybe the issue with the slow ones is that they do not or only partially support WASM? Just thinking that since web/graphics in games and complex widgets still seem to lag native graphics quite a bit speed should probably factor into the choice as well as ease of use.

[ylluminate]

I enjoyed this read and thought you'd get a few chuckles as well @medvednikov: https://medium.com/@shiyan/rejuvenate-my-old-opengl-gui-with-webassembly-1d46a6baa52e

[ylluminate]

@GaryMiller yes speed is an issue, I've read, that has to do with when HTML+CSS and WASM interaction occur, I believe, due to DOM involvement. Essentially when you work with pure WASM you end up with a very fast interface, but as soon as you throw in the DOM what you're saying becomes an issue. I believe we'll have to consider non-DOM or WASM-DOM options at the moment. More research will need to be done in this area, but it ultimately since we're looking at building apps that are not reliant on HTML+CSS with VUI, then this may not be an issue, at least not right now.

Furthermore I suspect that after WASM get's a proper DOM integration by the working group then these performance problems will perhaps lessen and perhaps we can then look at implementing a Blazor-like ("What is Blazor") solution.

[medvednikov]

I agree with @ylluminate here.

I think using a fast OpenGL implementation of the UI is preferable and could be a game changer.

Besides, WASM still doesn't support DOM 4 years later.

[elimisteve]

WASM code can call DOM-manipulating JavaScript though, I believe. Does that help?

[ylluminate]

@elimisteve the problem with DOM access is that it's not yet part of the implementation standard and has to be essentially kludged in as far as I've read. This is apparently a WIP by the working group... Notice the GC/DOM association here in this roadmap: https://webassembly.org/docs/future-features/ (see 1079 & 16

As noted above, I do think Blazor does this already in some hackish fashion, BUT again, why do we want another HTML+CSS UI for app dev? DOM access can and will help at some point and level for deeper browser interaction and rich embed function... but yeah, as @medvednikov notes we really need/want a fast, clean and beautiful app centric UI that is sexy in the browser without being bound to the nightmare that is HTML & CSS.

This will also facilitate the implementation of a V "Interface Builder" perhaps similar Apple's Xcode Interface Builder since ALL UI code for VUI will be universal. There's NO ONE in their (or a) right mind that wants to tackle making another HTML+CSS design and dev system (we have a bunch and they all pretty much ultimately stink - and that's horribly sad for a situation where HTML was designed to build DOCUMENTS! LOL).

This approach will definitely be a game changer for app + webapp dev.

[ylluminate]

By the way, the more and more I think about this concept not only of VUI for WASM, but VUI generally, the more I realize that responsive design is critical so that the universal UI will be able to scale essentially seamlessly and correctly on any resolution or shape. Basically this is the concept that Apple's Interface Builder pushed and is successful with due to the variety of screens they have to support, but the point of responsive development I mentioned earlier just drives home the critical nature of this since the web app deployment aspect will be so variable. Of course this again makes me realize just how insane it would be to try to do this with HTML+CSS vs a true app centric UI toolset!

[dumblob]

I like the debate and its direction and have the same opinion on the goals "everybody in the world" wants to achieve.

As @ylluminate noted above (especially by linking the article https://insights.dice.com/2019/02/28/webassembly-web-gui-future/ ), there are just 3 software architectures on how to build UI:

1. retained UIs (99.999% of UIs in the world including HTML + CSS) - application state is scattered among visual objects and kept internally in them
2. immediate mode UIs (ImGUI, Nuklear) - application state is centralized and kept outside of visual objects
3. seamless dualism of being both (1) and (2) without compromises (I know just 2 examples: Quarks from the main author of Nuklear - Quarks is a successor of Nuklear, and VID dialect which relies on homoiconicity and other cool features of the underlying language Red)

Programming for (1) is an extreme pain (disregarding whether it's a local technology like winapi, Qt, GTK, ..., you name it) to use and it's inherently (i.e. by definition) slow. Programming for (2) is extremely easy (!), but the limits of that architecture are to be seen in complex UIs. Programming for (3) is extremely easy, but it has no limits even in super complex UIs.

I think the attitude (3) is IMHO the only sane future (Quarks is also the only solution known to me in the world, which seamlessly supports heterogeneous DPIs). I can only recommend taking Quarks and using it everywhere. It works. It really does and I'm really excited about it. Unfortunately nobody knows it exists and I don't have the marketing capacity to spread the word. Read also how Quarks is designed part 1, part 2 (proof of concept implementation back then) and see the testing app. Some additional thoughts of the author on how to write all UIs are also worth reading.

ImGUI (C++11) is not so architecturally clean (it's a non-goal of ImGUI and thus some things are not so easily accomplished with it), but Nuklear (C89) is a bit cleaner (it shall be easier to accomplish also more advanced stuff in a more manageable way). Both have big user base and many backends (Nuklear a bit different ones because Nuklear is cleaner and more portable than ImGUI). There is also a web backend for Nuklear (currently by @tanis2000), but back then it wasn't clean enough to accept it to the repository.

From the user perspective, UIs are generally just about layouting and its full dynamics. Because of that, there is also a separate proof-of-concept layouting library again from the Nuklear/Quarks author trying to be GUI-agnostic and focus just on layouting. In my opinion though, it could be improved in ways (not a topic for this discussion here though), but still the library in its current shape gives a nice insight what layouting means in practice.

(disclaimer: I'm maintainer of Nuklear)

[gslicer]

https://speckyboy.com/open-source-front-end-ui-kits/

It's a pity this list does not include iioEngine that follows the same philosophy as V being single, small (less then 100kb) file with no deps

[dumblob]

iioEngine looks like it has no "widgets" (not even "composable" primitives for making widgets), zero layouting support and on top of that has many game-oriented (i.e. for UI unnecessary) functionality. IMHO there is not much we could get inspired with in this library :cry:.

[JalonSolov]

Might also want to take a look at https://gioui.org/

"Gio implements portable immediate mode GUI programs in Go. Gio programs run on all the major platforms: iOS/tvOS, Android, Linux (Wayland/X11), macOS, Windows, FreeBSD, OpenBSD, and experimental support for browsers (Webassembly/WebGL).

Gio includes an efficient vector renderer based on the Pathfinder project (https://github.com/servo/pathfinder), implemented on OpenGL ES and Direct3D 11. Text and other shapes are rendered using only their outlines without baking them into texture images, to support efficient animations, transformed drawing and pixel resolution independence."

[dumblob]

@JalonSolov yeah, didn't know about Gio, but I know about Pathfinder which is really cool project. Gio though seems to not address the power consumption question as everything is always rendered on GPU (and because the textures are not being saved anywhere, the bus between CPU and GPU seems to stay pretty busy making this solution pretty energy hungry).

On my machine with current Chromium Gio also renders full of artifacts making it totally unusable in practise, so it seems Gio is not mature enough for general use:

[JalonSolov]

Maybe not use GIO directly, but look at pathfinder in Go, and look at his syntax - I find it to be reasonably clear and straight-forward. Also, look at his drivers, which work on all the systems. It's open source... take what you can use. :-)

[akrymski]

I think the easiest solution here would actually be to go the other way: support a minimal subset of HTML & CSS in V UI. This is the approach taken by React Native for example, which lets developers use CSS flexbox and XML markup to layout components. CSS also provides an easy way to style widgets that all developers are familiar with.

I believe that some kind of XML markup + CSS for styling would be super useful for V UI:

• lots of developers are familiar with CSS and XML
• translating XML & CSS to HTML & CSS for web targets would be easy (as React Native Web does)
• being able to develop UIs with a custom look and feel that is consistent across platforms (eg Spotify) is potentially more valuable than native look and feel (this is what CSS allows)
• easier to develop UI builders targeting markup

I believe this can be very performant too: we could pre-compile the markup and CSS into native V UI or do it JIT style like interface builder does. We can then use V instead of JS to modify the nodes as needed.

[hex2f]

@akrymski i don’t really think this has anything to do with V UI. If we’re just reimplementing HTML and CSS in V why not just use them like normal in conjunction with V (either using wasm or js transpilation)

[akrymski]

@memeone I'm afraid you're misunderstanding. I'm not suggesting reimplementing HTML at all. I'm merely suggesting borrowing concepts from XML & CSS - take a look at the way React Native works. XAML is similar.

If we add support for Yoga - V UI would get great layout capabilities powered by flexbox for free. Take a look at the React Native code that it outputs for example - it's not HTML and CSS, it merely borrows the syntax so developers can be instantly familiar.

React JSX isn't HTML either - it just transpiles markup to JS code at compile time.

GUI APIs are large beasts, it would make everyone's life much easier if we adopted well established APIs for styling and layout - CSS and flexbox - so developers could be instantly productive. And there's a large body of C code we can leverage. I think it's a win-win.

[dumblob]

@akrymski hm, so in other words what you're proposing is to build several virtual machines (one for something-like-CSS, one for something-like-XML/HTML-DOM, etc.) on top of V UI. This effectively makes N problems out of initially one problem (just V UI).

And despite it can be made quite fast, it's definitely far from being fast enough - look at e.g. such a "stupid thing" as text editor Atom which needed to rewrite the whole core - the actual text editing - to C++ due to long-lasting performance issues (btw I'm participating in WASM development/architecture occasionally and believe me, there are so many performance issues due to WASM security invariants, that it's really impossible to make a lot of code performant enough).

Not speaking about going strictly against the core V philosophy - have just one way of doing things.

On the other hand, HTML+CSS+JS is way ahead of any available technology in terms how quickly can anyone build something useful in practice (in terms of "better than nothing and close to good enough" and "running everywhere" regardless) - but I still think, that V has the potential to become an important player on that field.

[dumblob]

@akrymski

If we add support for Yoga - V UI would get great layout capabilities powered by flexbox for free.

Not for free IMHO - feel free to implement at least https://github.com/eugenkiss/7guis and https://github.com/eugenkiss/7guis/issues/30 and https://github.com/eugenkiss/7guis/issues/32 and https://github.com/vlang/ui/issues/7#issuecomment-576256637 with Yoga (with other libs & languages of your choice) to see why its capabilities are definitely not good enough.

GUI APIs are large beasts,

True - that's also the reason why I advocated (and still advocate, though not loudly any more) V should focus on the language and other libs, but not UI. But here we are, so let's face it.

it would make everyone's life much easier if we adopted well established APIs for styling and layout - CSS and flexbox - so developers could be instantly productive. And there's a large body of C code we can leverage. I think it's a win-win.

No. Strict no from my side. I'm strongly opposed to wast majority of existing APIs, layouting technologies, UI technologies, UI libs, etc. I'm convinced they're flawed too much to outweight the advantage of their proliferance. You can find my rants and reasonings after searching for involves:dumblob through this issue tracker and other V-related issue trackers.

[medvednikov]

Yeah I agree.

SwiftUI and Flutter work fine without CSS, although there are libs that convert CSS to Flutter declarations.

https://docs.flutter-view.io/guide/styling-with-css

how is

#button {
width: 100px;
}

better than just

ui.button({
  width: 100
})

[akrymski]

@dumblob nope, I'm not suggesting any VMs whatsoever. My approach adds no overhead to V UI. To simplify, let's assume we add compiler support for React Native's JSX to V. Example JSX code:

<MyButton type="primary" style={{
    flex: 1,
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: '#DDDDDD',
  }}>Click Me</MyButton>

this JSX gets compiled to the following JS:

React.createElement(
  MyButton,
  {type: "primary", style: {
    flex: 1,
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: '#DDDDDD',
    }},
  'Click Me'
)

Now this can be rewritten in V as:

ui.MyButton({
  type: "primary",
  style: {
    flex: 1,
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: '#DDDDDD' }
  }, [ 'Click Me' ])

I'm perfectly happy with this latter version because:

1. I can use my knowldge of flexbox and CSS to layout and style UIs. Why learn a whole new framework?
2. I can use GUIs that generate JSX to draw UI, then just translate the markup to V code

@medvednikov I'm not saying CSS code is better syntax-wise, I'm saying why not make life easier by sticking to the CSS API as closely as possible? This is what made React Native successful for example.

[JalonSolov]

I would be happy with something that actually worked cross-platform without having to install extra stuff like glfw, with a syntax that makes sense, and doesn't add so much overhead that I would be better off just using React instead.

Not all developers have drunk the React/Flutter/whatever kool-aid. Some of us are old-timers who actually use plain old HTML+CSS+JS, without the "fancy" frameworks.

Perhaps V should have that level of UI built-in, then others could create the frameworks that sit on top and add all the goodies... and baddies... of that class of code.

[akrymski]

Imagine being able to use Visly to design components for example. The declarative markup (JSX above) it outputs can then be translated to React for web or to V. Creating new components in V would be so much easier - we'd be able to port lots of React components with ease.

@medvednikov sure this isn't useful at all:

#button {
width: 100px;
}

but this is actually very useful:

button {
width: 100px;
}

because now I've styled ALL the buttons in my app with one selector. CSS selectors are powerful ways to declare styles and themes because they cascade. React Native doesn't actually use them at all though (styles are merged in code) but it's not just a syntax gimmick.

I think there's a great opportunity to on-board web developers to V rather than creating yet another Qt.

[medvednikov]

Ok, I see, thanks.

Funnily enough, Qt (not sure about QtQuick) uses CSS for styles. Something like

btn->setStyle("color:red; padding:10px");

Always found that weird.

[JalonSolov]

That's fairly standard, but has one "slight" problem... suppose you had 50 buttons...

[akrymski]

@medvednikov I agree the string syntax in Qt sucks, but at least it avoids the issue of having to read through API docs for yet another UI lib.

@JalonSolov which is why V would need to implement CSS logic (cascading) or React Native approach of being able to merge styles.

Electron apps are very popular now, and being able to write them in V as native apps but making use of CSS styling would be a truly useful use case.

[dumblob]

@akrymski

which is why V would need to implement CSS logic (cascading) or React Native approach of being able to merge styles.

I don't think the "cascading" principle requires anything like CSS. Basically the only thing needed is to have automatically tagged widgets according to different criteria (e.g. type, purpose, size similarity, font similarity, etc.) and very good defaults (e.g. color, texture, border radius, etc.) for each tag plus priority handling (in case values for competing tags will have defined precedence).

Among many other things the problem with CSS is, that it couples actual style (color, texture, border radius, ...) with layout (widget size, font size, coordinates, z-index, ...) and with content (virtual elements, ...) without any way to treat them separately.

IMHO V shouldn't do this mistake and understand styling as pure color/texture/border_radius stuff with tags and defined precedence. All the other stuff (layout & content) should be handled differently (decoupled from the pure style). Allowing e.g. to "merge" or otherwise "refine" style values of a tag would make it a very powerful tool without the complexity of CSS.

I'm saying why not make life easier by sticking to the CSS API as closely as possible?

It won't make our lives easier, it'll just complicate things. I understand, that you'd rather stick with a "known" stuff, but the reality is, that CSS develops extremely fast (basically adding one hack after another due to an utterly wrong design decisions made at the beginning as viewed by modern lenses) and believe me, it's way easier to learn a new better and way smaller API than a CSS-like API which'd need to develop itself by mostly adding hacks forever due to its initial design flaws.

[medvednikov]

Yes, CSS is huge, complicated, bloated, full of bad decisions, and constantly changing.

Supporting all of it will be impossible, supporting just a subset is probably worse than doing our clean and minimal styling system.

[elimisteve]

CSS is the worst-designed technology of any sort I have ever come into contact with.

The biggest problem with the design of Cascading Style Sheets is that they cascade. That's how fundamentally broken the ideas behind them are.

We shouldn't be "pushing" style onto whatever elements that exist inside of an invisible, global namespace that just so happen to meet certain super-broad criteria we describe like "it is a button"; a more targeted approach is needed.

Let us please learn from the past and not make the same mistakes!

I am a backward compatibility fanatic, but when a technology is as catastrophically bad as CSS, bringing the past with us into the future would be a horrendous error -- and one that the world cannot afford for V UI to make; it's too important.

[zimt28]

I'm not using Elm, but Elm UI looks pretty great! It offers a nice abstraction so you don't ever have to touch HTML/CSS directly and makes layouting and styling very simple and predictable. I can recommend watching the talk "Building a Toolkit for Design" by Matthew Griffith.

It would be awesome to have such a library in V which can compile to any target, including HTML/JS.

because now I've styled ALL the buttons in my app with one selector. CSS selectors are powerful ways to declare styles and themes because they cascade

In this case you could simply create a snippet/component/function to reuse throughout the app, or no?

[netesy]

I personally see nothing wrong with the current flutter like sysntax.

[Spencerx]

WebKit or other web engine rendering support in applications built on V can help answer enough questions without getting stuck in web pages.