Hacker News Reader

Comment by fasterdom | Hacker News Reader

Is anybody working on bringing reactivity to GUI development?

After working with Vue/React, doing GUI apps "the old way" feels like writing quick-sort in assembly language.

Actually reactivity in GUI (maybe declarative GUI programming is a more accurate form?) is also "the old way" in the GUI development. I mean it is already done a decade ago, even before react. Try QML. The view is automatically updated when a signal is triggered or its state changes.

You will notice that it is surprisingly simpler than React.

React got so popular because React implemented it very nicely in the web browsers, not because it brought new concepts.

Last time I looked at QML (a few years ago), you couldn't just use any data in your UI directly, you had to wrap it in clunky models.

When using C++, looks like you have to use things like QAbstractListModel https://qmlbook.github.io/ch16-qtcpp/qtcpp.html#a-simple-mod...

Even without C++, there are things like ListModel and ListElement https://qmlbook.github.io/ch07-modelview/modelview.html

This is a far cry from React where you just use language-native data structures directly (you only need to do mutations in specific ways).

As far as I can tell, you also can't just use native language constructs like functions/ifs/.map, etc. to compose the UI elements. Instead you have containers like Repeater.

It seems very different to me compared to React, like built around a significantly different philosophy.

Your comment seems to just be highlighting the fact that inspecting types at runtime is non-idiomatic at best in C++ or similar languages, so it would make sense to require a specific data structure or format.

Even defining what a "native" type is seems like it would be fraught. I guess the c++ way would be to accept begin and end iterators - but of what type?

I don't think I understand how RTTI/reflection relates to this.

When I imagine how a C++ implementation of something like React would look, my first thought is a bunch of functions which take whatever custom types they need (props), and return a tree of UI primitives (analogous to DOM element representations). Nothing that would require inspecting types.

And that works in other languages because you can iterate through trees and properties without needing to specify how to iterate through them or how they are stored.

Think about it. How do you iterate the tree? What even is a tree? The typical c++ answer depends on templates and iterators within the template. Which means they wildly change at compile time. It is clumsy for a shared library to deal with this, or, say, bind properties from an XML file or similar parsed at runtime.

Hence, it would make sense for a c++ solution to impose its own format or base class for trees or models. (Perhaps a template could help to wrap it.)

I'm thinking of a structure similar to https://reactjs.org/blog/2015/12/18/react-components-element...

There may be some limitations and some things may need to be done differently because of C++, but from a brief look it should be basically possible. The UI library doesn't need to iterate through props, those can be a single opaque structure from its point of view.

I tried doing something similar in Kotlin a few years back and from what I remember there wasn't any reflection used for that part. https://github.com/peterholak/mogul

That Kotlin project looks pretty cool! What happened to it – was there some fundamental problem, or just lack of time?

Mostly just lack of time, more important things got in the way, and it became less fun after the initial excitement.

I'm also still not convinced that Kotlin/Native will catch on in any significant way, but we'll see.

The .NET Framework, specifically the WinForms and the WebForms did that. Of course you could change everything manually, but DataBinding was a core concept which relied on changing data to change the contents of the GUI.

WPF still has the same kind of approach and to be terribly honest, Silverlight, as hated as it was, did it before React.

Oh, I see - I take my comment back then :-)

Sciter ( https://sciter.com ) and Sciter/Rust for that matter: https://github.com/sciter-sdk/rust-sciter

It adds single 5mb DLL to the equation.

Yet it allows to build native applications where UI structure is defined by HTML, style by CSS and reactivity by script or by Rust (or by C++, Go, Python, etc.)

"Sciter makes GUI programming genuinely fun!" https://sciter.com/forums/topic/attach-detach-behavior/#post...

Sciter has very likely the right approach : HTML/CSS for the GUI, native languages for the logic.

However it has one major issue : it's proprietary... And that's a no go for many project / companies.

I would not make my entire business depend on a blob which I have no control on it.

> I would not make my entire business depend on a blob which I have no control on it.

You can buy Sciter License.

This way you a) will solve the problem and b) will help further Sciter development.

Otherwise you don't really need Sciter sources.

It does not solve anything sorry.

You protect your business, That's your choice. But it will make me stay with Qt until better OSS alternative.

What HTML/CSS rendering engine does it use? And in case it has its own implementation, then how good and up to date is the HTML/CSS support?

It uses its own HTML/CSS engine designed by myself to be embeddable from ground up. Check this: https://sciter.com/10-years-road-to-sciter/

As of HTML: most of HTML5 constructs (I participated in HTML5 spec development at W3C as Invited Expert)

As of CSS: CSS2.1 in full. Some practically useful modules of CSS3 - transitions, transforms, etc.

I haven't added FlexBox as I think it is an architectural disaster - will not survive on the long run. Instead Sciter offers "flow and flex units" module: https://sciter.com/docs/flex-flow/flex-layout.htm that covers as FlexBox as Grid in unified manner. Yet check this: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....

Yet, I've added quite a lot of HTML/CSS features that are the must for specifically desktop UI:

- <menu class=popup> and <popup> elements and their CSS support - windowed DOM elements that are rendered outside of main window canvas.

- <frame type=pager> - print preview and print feature.

- view.dialog("some.html"), view.window("some.html"), view.msgbox("some.html") - HTML defined windows and dialogs.

- <htmlarea> - native WYSIWYG HTML editing widget.

More on this: https://sciter.com/developers/for-web-programmers/

Out of curiosity, what is your criticism of flexbox?

I only very rarely do CSS, but from a user perspective it's a huge improvement to what we had before.

Are you talking about implementation complexity?

1. FlexBox breaks existing CSS Box model that mandates that dimensions of the element are defined by its width/height properties.

2. FlexBox introduces 12 (sic!) new properties in already overcrowded CSS property map. But as demonstrated by Sciter that can be achieved by just one property `flow` and flex units.

3. Flexbox and Grid are conflicting in the sense that the flexibility (as a feature) is defined in two different ways: separate properties (FlexBox) and 'fr' units (Grid) - overall CSS architecture becomes a zoo. Yet CSS has that famous 'auto' value that in some cases is just 1fr ( 1* in Sciter terms).

4. FlexBox is applied through 'display' property that is conceptually wrong. 'display' specifies how the element itself is replaced among its siblings but flexbox is rather about layout of element's children. These two entities are orthogonal. Example:

display:list-item; or display:table-cell; cannot be flexboxes. Just because of architectural specification error but physically nothing prevents <td> to use flexbox layout for their children.

5. Flexbox arrived too late. We started talking about the feature 12 years ago on www-style WG at W3C. And all these years Sciter already used flexibility (the must for desktop UI).

More on this: https://terrainformatica.com/2018/12/11/10-years-of-flexboxi...

Not the parent, but in my view it is basically a 1-dimensional subset of Grid, which is great for mostly-1D website design. But when it comes to making applications (which often use the whole screen, with tabs and whatnot, instead of being scroll-oriented), it makes some things either really difficult, either still requiring custom code to get it just right, or having a handful of wrapper elements for relatively simple layouts.

Don't get me wrong, it's _miles_ better for web layout than the old systems, but since Sciter seems to be focused on application-style layouts, it makes sense to prefer a layout system that can better represent common patterns in that domain.

Also, if you plan on go responsive, the required flex wrappers kind of hold you back when you need to reorient a bunch of your layout to fit a vertical screen (or horizontal, if you're doing mobile-first), while Grid's `grid-area` is beautifully flexible in that regard.

TL;DR: If you're gonna have to have Grid, then just having Grid is perfectly fine as it can do everything Flex can and more.

Is Sciter used in some desktop apps like Norton Antivirus or McAfee Antivirus? Thought I read that somewhere.

Norton Antivirus, Norton Internet Security and almost all other desktop facing products of Symantec use HTMLayout and the Sciter since 2007.

McAfee - not.

But these AV and security providers - yes:

- ESET (NOD32 Antivirus)

- AVAST Antivirus

- AVG Antivirus

- Bitdefender Antivirus

- Comodo Antivirus

- Dr.WEB Antivirus

- WEBROOT Security Antivirus

- 360 ( 360.cn ) Antivirus

- Secui antivirus

So Sciter's code works on any PC that has any of these installed.

Thanks.

I know about revery[0] and cljfx[0], though I haven't had the chance to use them in anger. These both seem like very nice approaches to me - I'm partial to cljfx because I've been utterly spoiled by the clojure/script development experience, but I've also come to enjoy the typescript environment and revery seems to another step along that road.

[0]https://github.com/revery-ui/revery [1]https://github.com/cljfx/cljfx

Be sure to also check out fn-fx. I've tried both but haven't really done anything complex enough to bring out which one is a clear winner

https://github.com/fn-fx/fn-fx

Fn-fx is a more complex beast and no one seems to really know how it all works internally except the creator who isn't maintaining it.. so unfortunately it's in a semi unmaintained state. But the interface was a bit cleaner when I tried it

cljfx is actually inspired on fn-fx, and presents a much cleaner and more usable api, just by comparing the docs. I'm pretty sold on data-based apis instead of macro-based ones, though, so maybe it's just catering towards my preferred style of development.

oh okay. you sound more knowledgeable than me, so thanks for the input. I'll stick to cljfx then. I found it clunkier to mix with Java code, so I was considering switching back to fn-fx

See this [0] native UI for Rust. It's the primary UI for Redox OS and it's inspired by React.

[0] https://github.com/redox-os/orbtk

Yes, about 10 years ago with WPF, QML, JavaFX.

I've used WPF extensively 10 years ago. It's nowhere near as easy to create a complex GUI as Vue/HTML/CSS. And that just for functionality. If we talk about looks, WPF is very clunky to theme.

I happen to have the opposite view, specially with Blend and component libraries into the mix.

CSS had to get WPF grid design in order to not be a poor table sibling in what concerns layouts.

While WPF is backed by DirectX, CSS requires playing with Z order, so that some browsers might eventually put the rendering into the GPU, but one needs to take care because space is limited.

While I can render anything down to pixel level control, if I wish to do so, I am still waiting for Houdini and worlets to actually become available.

And the whole template language with events and theming for low level customisation of control behaviours? Nowhere to be seen.

Using Blend feels to me like using Word to create HTML pages - the resulting output is horrible.

CSS layout was indeed a struggle many years ago, but now with flexbox I never failed to put stuff exactly where I wanted, and I barely understand it. And the new shiny thing, CSS Grid, is supposedly even better at controlling layout.

There is QML and it can compile natively for many platforms.

With the same source code, my applications are natively compiled to:

Linux, Windows, MacOS, Android, iOS, QNX, Browser (WebAssembly / WebGL Streaming)

And you are free to theme it as you like, one example:

https://imgur.com/Ti02n6Y

Similarly to many MS technologies from that era, WPF/XAML is not half bad at the core, but so verbose. Probably intended to be primarily generated by tooling.

Having been a Turbo Vision and OWL user, which lacked UI designer support, following up with VB and Delphi/C++ Builder, I never understood the macho attitude of doing GUI design manually without tooling support.

Any framework that comes with tooling support out of box is a plus for me.

Hence in what concerns Web, I care mostly about WebComponents, CMS middleware with page designers and SPA frameworks like Angular.

For me, there's nothing macho about it, more like weary resignation when said tools cannot do what needs to be done. I have never used delphi though.

I reckon for designers are excellent for forms. The further you go beyond a data crud app, the less benefit you get from visual designers, because more stuff will be animated, contextual, custom, etc.

CRUD apps is a really big application space to cede, though, I totally think tooling is worth it.

It depends very strongly on how you used WPF. It had many footguns, due to a foolish decision to seemingly support the expectations of winforms developers.

Microsoft and others have MVVM frameworks, such as WPF, which have reactive data binding. Qt Quick also, but I haven't tried it myself. That said, it is not that similar to React or Vue because the "DOM"s are so different.

Try to use WPF from anything other than dotnet. It will be hard, given that you will have to hack its main loop to work with an external code. I'm not sure if that was ever done.

It works from any language that speaks COM.

Any real world examples?

Probably not the way you are thinking.

- Write the WPF view code in any .NET language and expose the classes to COM as COM Callable Wrapper (https://docs.microsoft.com/en-us/dotnet/framework/interop/co...)

- Similar way, but using Windows HWND messages instead, https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc...

- Or if using Windows 10, given that UWP is COM vNext, and Microsoft is merging both worlds, use XAML Islands, https://docs.microsoft.com/en-us/windows/apps/desktop/modern...

I've been in involuntarily involved in webdev for quite a few years. I will give everything to get that quick and easy manner of building GUIs in GTK+ to the web.

I wrote my first GTK+ program in my high school years in 2014-2015, and I can't think of any native toolkit ever approached the ease of work of GTK.

> I can't think of any native toolkit ever approached the ease of work of GTK.

Which other native UI toolkits do you have experience with to make that claim?

Been working on Windows side with every Microsoft's take on GUI library, Android, tried Qt (before QML,) and am involuntarily dealing with all those Web toolkits on almost every project involving web.

Typo, my school years were a decade earlier :)

Microsoft very actively works on React Native for Windows, and last I checked there were decent RN desktop ports for Linux and MacOS. So that's one potential option.

Given that they were even measuring the performance against Electron, there is some small hope that eventually VSCode gets rewritten in it.

I don't think they care about performance a tiny bit.

Here's very simple to implement change which saves dozens of MB of IO bandwidth every startup: https://github.com/Microsoft/vscode/issues/61343

"We will very likely not do this."

Then check BUILD 2019 talk about React Native for Windows. Electron gets a couple of jabs, including a very nice bar comparison chart.

JavaFX actually has a lot of reactive elements in its design. Basically every attribute of any GUI element are an “observable” type which allow you to register handlers for doing stuff when the internal value changes.

JavaFX is great and looks fantastic, surprised it’s not used more

There seems to be a perception that anything running on the JVM is going to be slow and look bad. Considering I work with Java every day in a gigantic Swing application, (IntelliJ IDEA, if you didn’t guess) and it has great performance for all the things it’s doing for me, that seems to be an old holdover from early days of Java. Also enterprise apps, which of course are going to be bad and slow. At least the JVM has real threads for background work which don’t take another 100MB of RAM like an electron background worker :)

Yea, its hard to wash out a stain like that, in general, JIT:d JVM based applications performs as good or better than AOT application, but do still need more memory.

The “or better” tagged into JVM applications really needs to go away. Realistically, most JVM applications do not have as good performance as native ones. Yes, it’s possible to run better, but it’s very hard to create code that JITs to something faster than a thing written in C/C++/Rust/etc. You have to basically write code that looks like C to make it run as fast or faster, because there’s real overhead that comes with a lot of things in the JVM. You don’t just write standard Java or Scala and suddenly it’s as fast as C++, in general. It’s still heckin blazing fast, to be fair, but not AS heckin blazing fast. (As long as you aren’t just going insane with objects, at least, such as huge lists of integer objects)

It always felt incomplete to me. You end up missing a lot of little things that you get off of the box with swing (like the 5000 features of jtable).

Swift is going this way with SwiftUI but you aren’t likely to see it anywhere except Apple platforms in the immediate future.

https://github.com/maps4print/azul

Maybe https://github.com/revery-ui/revery/blob/master/README.md

Microsoft. Their XAML apps are pretty much web apps done right, ie not javascript and a more powerful layout system -- and everything on the gui part is reactive.

https://github.com/antoyo/relm

Yes, I am. https://twitter.com/ivanceras/status/1147594007897202688

https://github.com/pierrejean-coudert/ReduxDelphi

Check out flutter

Reply on news.ycombinator.com