It's a nice benchmark, and it's always refreshing to see it included in GUI library tutorials. Small note for the title, the page says it's from 2014, not 2018.

And if you're a fan of Lua and need to write a quick CRUD app, IUP isn't on the list of implementations but:

https://www.tecgraf.puc-rio.br/iup/en/7gui/7gui.html

Wow! I'm not sure how to call this moment - so I was randomly browsing the implementations, wondering what Phix is - but it really looks like lua+iup - https://bitbucket.org/petelomax/phix/src/default/demo/rosett... from here -> https://eugenkiss.github.io/7guis/implementations

So turns out, Phix is a language on its own (sorry about that), it just looked like lua (without noticing that it's not actually).

There is an introduction blog post here: https://hackernoon.com/towards-a-better-gui-programming-benc...

If people have similar "benchmarks" for GUIs, would be lovely if you could share them here.

I think the tests as given are rather incomplete. The tests cover data flow and input to varying degrees of complexity but completely avoid the easy or difficulty of producing the layout in question (responsiveness, resizing, alignment, etc) in addition to performance when the layout needs to be computed or updated. Coming up with a minimal API that covers the needs of a modern UI is extremely difficult, and when you add more advanced controls (beziers, transitions/animations, etc) things get even dicier.

They need to test one more aspect: styling. The power and complexity of the web comes from the fact that things need to look pretty and feel "slick", not just usable. The 8th benchmark could be to implement pixel-accurate Material Design (any design language works but Material is quite complete and pushes the limit on performance).

I think animation needs a mention, even though it could be considered part of Material Design, and also accessibility.

Similar to TodoMVC, which includes styling (something other comments here noted the absence of): http://todomvc.com/

Wow those React examples are an absolute mess, compared to the few lines of C# and Elm.

No wonder websites are so slow nowadays.

The counter example for Svelte is remarkably terse.

Taking a brief look at the react code [0] and comparing it with the svelte code [1], it appears the svelte code handles much less. For example the react example handles the following among others:

- programmed to handle arbitrary conversion targets (probably the most verbosity here)

- handles input validation

- handles labels for inputs

And some others. It would be very easy to spin up a similarly terse react example which doesn’t have that much bloat... I imagine it would also get bloated for Svelte as you handle more and more cases. I’d be interested to see a more complex Svelte example and a simpler react example.

The WinForms example [3] would be super difficult to scale at any level because you’re hardcoding the location everywhere. I’d be interested to see a more modern UWP app on there to compare :)

I do really enjoy the abstractions React provides. I never experienced something quite like it in my time developing native iOS, Android, or Windows apps.

I think bloat on the web is horrible for users for sure, but part of that is a lack of a better target for web development. You’re effectively stuck with some flavor of interpreted JS if you intend to build a complex interactive application on the web. It’d be nice if there was a compiled alternative.

Plus, way too many people try to make their simple websites dynamic. If it’s static, render it server-side.

- [0] React code for temperature conversion (https://github.com/andreasgruenh/7guis/blob/master/src/scree...) - [1] Svelte code for temperature conversion (https://github.com/sveltejs/v2.svelte.dev/blob/master/conten...) - [3] WinForms C# code (https://github.com/eugenkiss/7guis/blob/master/C%23-WinForms...)

> it appears the svelte code handles much less.

I think the perspective that the react code does much more explains the problem better. I mean, the definition of the task does not ask any of those extra things. If people don't adhere to the precise description of benchmarked task the comparison will never be any good.

Perhaps, but the mobx example was written by the person who created the challenge, and they are seeking to update their challenge to include more complexity.

Maybe this is a first step.

With Winforms you can avoid almost all the pixel-fiddling with FlowLayouts and TableLayouts. With Dock and autosize properties it's almost as responsive as HTML/CSS in about 1/10 the fuss.

Unfortunately GUI programming across multiple languages is not as amenable to unit testing.

I guess if you specify the geometry as part of the 7 Tasks[0] one could automate testing of these.

[0] https://eugenkiss.github.io/7guis/tasks

Also the temperature example in Svelte was very terse. Compared with fx react/mobx.