8 ms·

I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low

by actf 9y ago

I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low level, UI framework for cross platform applications. What the author has done here is a cool idea, but ultimately this still feels flawed, and like it's a workaround to the difficulties of writing a cross platform UI. Everytime I read something like this I can't help but think about how great a low level, cross platform C (or C ABI) library would be (think something like libuv but for UIs). Such a library would abstract away the OS specific system calls of the UI while still providing the ability to easily do things like: * Create a window * Draw to the screen * Declaratively (i.e. html like) add UI widgets to a scene * Apply CSS like styling (like QML, JavaFX, or XAML) * Use native file dialogs, menus, notifications, etc * Statically link as a single dependency I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements. Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of is https://github.com/andlabs/libui https://github.com/andlabs/libui I think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e. html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this.

mherrmann 9y ago
> Qt's [...] biggest flaw is that it's difficult to link to an application and setup a development environment for. Check out (my) https://github.com/mherrmann/fbs https://github.com/mherrmann/fbs. It's for PyQt but I think does get around the obstacle you mention.
arel 9y ago
There is a point that is always missed about Electron - UI. By using HTML, CSS & JS you have an extremely rich toolkit to create UI with constant improvements from browser vendors and standards bodies. If a designer can create a pattern library in sketch then chances are it can be implemented using web technologies. This is a much bigger and more active open platform when contrasted to the capabilities of a particular framework and community. Theres another topic around whether you should detour from the OS UI look and feel. But most designers and product owners worth their salt are conscious of keeping known UX patterns and least surprise.
ninkendo 9y ago
Am I the only one with the opposite opinion? I don't think cross-platform UI toolkits should exist, period. Your cross platform code should live underneath the UI layer, and you should write a custom UI for each platform you're bringing your logic to. Mac apps should look and feel like mac apps, windows apps should look and feel like windows apps, etc. Trying to abstract away all these platform differences either nets you a lowest common denominator that doesn't feel at home on any platform, or is so complicated to develop for that you end up doing more work in the end (and still isn't as good as writing native UI's for each platform.)
- swsieber 9y ago
  You're probably not alone. Here's the tired counter-argument: I'd rather have an app with a slightly awkward ui for my os, than no app at all. The advantage of these cross platform toolkits (and our bane), is that it makes it significantly easier to make build for other platforms.
  - alsetmusic 9y ago
    > Here's the tired counter-argument: I'd rather have an app with a slightly awkward ui for my os, than no app at all. I agree. However, I also think that this has an undesirable effect of discouraging a platform-specific app from being created, especially in niche markets. Edit: clarity
    - tracker1 9y ago
      I think it's great that so many apps are available for mac or linux that wouldn't otherwise be available. Electron provides a baseline that simply is much more difficult with platform specific code, or other cross platform applications. It's not all in the box, and far from perfect. But the fact is, I get to use VS Code, Teams, Spotify (I know not electron specifically, but similar enough) and a handful of other apps everywhere I run. For the most part I stick to cross platform apps, if that means a "lesser" electron based app, so be it. And most of them look far better than other cross platform and even native options a lot of the time.
arconis987 9y ago
Have you tried Sciter? https://sciter.com/ https://sciter.com/ It's a lightweight HTML and CSS renderer for native desktop apps. Used heavily in the anti-virus industry. Not open-source, unfortunately.
- actf 9y ago
  I have looked at sciter and it looks pretty cool, but not being open source is a pretty major downside.
nukeewelerr77 9y ago
The examples here look more interesting than libui https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear There’s a typical window app, game ui, something that looks like unreal engines visual programming. Seems like a flexible system Haven’t actually tried to use it though. That’s where it will win or lose, IMO Edit: and just got to end of the README. Bindings available for rust, python, go, lua, java and more. Gonna have to kick the tires on this one.
mamcx 9y ago
I think about this lately and write about this on: https://talk.remobjects.com/t/potential-way-to-do-almost-cross-platforms-guis/15647 https://talk.remobjects.com/t/potential-way-to-do-almost-cro... ---- Is well know the problem of try to do a cross-platform GUIs. But in the other end, the necessity to do that have increased with the arrival of mobile and the emergence of OSX as a viable target for commercial apps. Is kind of ironic that is easier to port a full 3d-game but a “simple” business app is a huge undertaking :) The key, IMHO, is decouple some tasks (kind of separate “back-end” UI from “front-end” UI). We can do “partial/almost” cross-platform UI, if we think that some stuff can actually cross cleanly: - Layout (the big one, IMHO) with something like https://yogalayout.com7 https://yogalayout.com7. This one was my main block before. - A well defined way to separate the back from the front UIs. The ELM architecture is a good contender (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction.html4 https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) (called Update-Model-View, similar to react + redux but simpler and easier to call servers/async) A big chunk of the logic is totally cross-platform and “only” need to adapt the render of controls. This way of working allow to work with pure objects for the model and the view without actually commit to exactly what is the view UI. Instead, is delegated to the “update” side. It can totally be just in-memory, testeable object. Dispatching, events and similar stuff, that is not visual. This need a bridge but I don’t think will be complicated. Then finally, the rest can be fully native: - Controls - Drawing - Animations - Call to native libs This mean that we build components instead of a class hierarchy and is possible to swap what is a “control”, like, from HTML to iOS Views without moving the rest of the logic. The big question is what to use for coding this. I’m using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with elements. Wish to have a coding partner to do this :slight_smile:
- erlend_sh 9y ago
  There’s a fast-growing interest to create something like this in the Rust community. An unofficial working group led by a Mozilla employee is being formed: https://internals.rust-lang.org/t/thoughts-on-rust-guis/6894?u=erlend_sh https://internals.rust-lang.org/t/thoughts-on-rust-guis/6894...
erlend_sh 9y ago
> I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. Sounds a whole lot like what you’re talking about https://github.com/zserge/webview https://github.com/zserge/webview

by actf 9y ago

mherrmann 9y ago

> Qt's [...] biggest flaw is that it's difficult to link to an application and setup a development environment for. Check out (my) https://github.com/mherrmann/fbs https://github.com/mherrmann/fbs. It's for PyQt but I think does get around the obstacle you mention.

arel 9y ago

There is a point that is always missed about Electron - UI. By using HTML, CSS & JS you have an extremely rich toolkit to create UI with constant improvements from browser vendors and standards bodies. If a designer can create a pattern library in sketch then chances are it can be implemented using web technologies. This is a much bigger and more active open platform when contrasted to the capabilities of a particular framework and community. Theres another topic around whether you should detour from the OS UI look and feel. But most designers and product owners worth their salt are conscious of keeping known UX patterns and least surprise.

ninkendo 9y ago

Am I the only one with the opposite opinion? I don't think cross-platform UI toolkits should exist, period. Your cross platform code should live underneath the UI layer, and you should write a custom UI for each platform you're bringing your logic to. Mac apps should look and feel like mac apps, windows apps should look and feel like windows apps, etc. Trying to abstract away all these platform differences either nets you a lowest common denominator that doesn't feel at home on any platform, or is so complicated to develop for that you end up doing more work in the end (and still isn't as good as writing native UI's for each platform.)

swsieber 9y ago
You're probably not alone. Here's the tired counter-argument: I'd rather have an app with a slightly awkward ui for my os, than no app at all. The advantage of these cross platform toolkits (and our bane), is that it makes it significantly easier to make build for other platforms.
- alsetmusic 9y ago
  > Here's the tired counter-argument: I'd rather have an app with a slightly awkward ui for my os, than no app at all. I agree. However, I also think that this has an undesirable effect of discouraging a platform-specific app from being created, especially in niche markets. Edit: clarity
  - tracker1 9y ago
    I think it's great that so many apps are available for mac or linux that wouldn't otherwise be available. Electron provides a baseline that simply is much more difficult with platform specific code, or other cross platform applications. It's not all in the box, and far from perfect. But the fact is, I get to use VS Code, Teams, Spotify (I know not electron specifically, but similar enough) and a handful of other apps everywhere I run. For the most part I stick to cross platform apps, if that means a "lesser" electron based app, so be it. And most of them look far better than other cross platform and even native options a lot of the time.

arconis987 9y ago

Have you tried Sciter? https://sciter.com/ https://sciter.com/ It's a lightweight HTML and CSS renderer for native desktop apps. Used heavily in the anti-virus industry. Not open-source, unfortunately.

actf 9y ago
I have looked at sciter and it looks pretty cool, but not being open source is a pretty major downside.

nukeewelerr77 9y ago

The examples here look more interesting than libui https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear There’s a typical window app, game ui, something that looks like unreal engines visual programming. Seems like a flexible system Haven’t actually tried to use it though. That’s where it will win or lose, IMO Edit: and just got to end of the README. Bindings available for rust, python, go, lua, java and more. Gonna have to kick the tires on this one.

mamcx 9y ago

I think about this lately and write about this on: https://talk.remobjects.com/t/potential-way-to-do-almost-cross-platforms-guis/15647 https://talk.remobjects.com/t/potential-way-to-do-almost-cro... ---- Is well know the problem of try to do a cross-platform GUIs. But in the other end, the necessity to do that have increased with the arrival of mobile and the emergence of OSX as a viable target for commercial apps. Is kind of ironic that is easier to port a full 3d-game but a “simple” business app is a huge undertaking :) The key, IMHO, is decouple some tasks (kind of separate “back-end” UI from “front-end” UI). We can do “partial/almost” cross-platform UI, if we think that some stuff can actually cross cleanly: - Layout (the big one, IMHO) with something like https://yogalayout.com7 https://yogalayout.com7. This one was my main block before. - A well defined way to separate the back from the front UIs. The ELM architecture is a good contender (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction.html4 https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) (called Update-Model-View, similar to react + redux but simpler and easier to call servers/async) A big chunk of the logic is totally cross-platform and “only” need to adapt the render of controls. This way of working allow to work with pure objects for the model and the view without actually commit to exactly what is the view UI. Instead, is delegated to the “update” side. It can totally be just in-memory, testeable object. Dispatching, events and similar stuff, that is not visual. This need a bridge but I don’t think will be complicated. Then finally, the rest can be fully native: - Controls - Drawing - Animations - Call to native libs This mean that we build components instead of a class hierarchy and is possible to swap what is a “control”, like, from HTML to iOS Views without moving the rest of the logic. The big question is what to use for coding this. I’m using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with elements. Wish to have a coding partner to do this :slight_smile:

erlend_sh 9y ago
There’s a fast-growing interest to create something like this in the Rust community. An unofficial working group led by a Mozilla employee is being formed: https://internals.rust-lang.org/t/thoughts-on-rust-guis/6894?u=erlend_sh https://internals.rust-lang.org/t/thoughts-on-rust-guis/6894...

erlend_sh 9y ago

> I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. Sounds a whole lot like what you’re talking about https://github.com/zserge/webview https://github.com/zserge/webview