6 ms·

Show HN: Xel, widget toolkit for native-like Electron apps

38 points by jarek-foksa 10y ago

zerr 10y ago
A question: Why bundling Electron/chromium is better than bundling JVM?
- tomjakubowski 10y ago
  Support tooling for web UI development is superb. I don't know the state of the art in Java/JVM GUI, but the rapid prototyping you can achieve with live code reloading, browser DOM inspectors, etc. is unmatched in my (admittedly limited) experience with UI toolkits. QtQuick is the only other that's come close for me, and it's heavily inspired by the front-end web "toolkit". It's probably more about the developer experience than anything else. Bundling Electron in every application is pretty bloaty.
  - pjmlp 10y ago
    RAD tooling for native UIs was already a thing in the mid-90's. Web tools are still catching up with 4GLs and RAD environments.
- auggierose 10y ago
  Depends on your needs. You could argue that user interface development with electron is much more convenient, you can use for example React. Basically, if you prefer developing for the browser over developing for java, choose electron, otherwise vice versa.
- pjmlp 10y ago
  Learning anything else other than HTML/CSS/JavaScript is too hard. Funny enough, for anyone able to do proper Swing/JavaFX coding, the JVM applications take less space, are better integrated into the OSes and perform better than Electron ones, but it requires skill to do so.
- edko 10y ago
  The JVM comes with an embedded Webkit browser (via the included JavaFX). This lets you code as much as you need/want in HTML/JS/CSS, but also gives you the option of easily interacting with Java, Scala, Clojure, Groovy, Kotlin, Ceylon, Frege, etc. I think this is more powerful than Electron/Chromium.
- spapas82 10y ago
  Another question. Why bundling Electron or JVM and not Delphi (or its open source brother Lazarus - https://www.lazarus-ide.org/ https://www.lazarus-ide.org/)? I really can't understand why use HTML technologies for the Desktop...
scandox 10y ago
> To view this site, you must use Chrome, Opera or other Chromium-based browser. Well frankly F off
- detaro 10y ago
  And to add insult to injury, it hijacks the back button on that page...
  - jarek-foksa 10y ago
    What web browser are you using? I'm unable to reproduce this bug on Safari.
    - hdhzy 10y ago
      Firefox for Android. Main site redirects to /fallback. Thrn you press back then it goes to the home page and... Redirects to /fallback. :(
    - detaro 10y ago
      Desktop Firefox, Linux and Windows
    - jarek-foksa 10y ago
      Thanks for feedback. This issue should be resolved now (I had to use window.location.replace() instead of window.location.pathname).
      - detaro 10y ago
        works now, thank you!
- pbowyer 10y ago
  Given this is the engine inside Electron, it's understandable if they only work in this rendering engine. Blocking other browsers is a bit extreme, but would reduce the pointless bug reports and bad publicity.
stupidcar 10y ago
IMO, trying to clone native UI widgets in a 3rd party toolkit is a bad idea, and Swing proved it in the early 2000s. No matter how hard you try, you end up in an uncanny valley where it looks and feels almost like a native macOS (or whatever) app, but there are bugs and inconsistencies that make it feel slightly off. Far better and easier to just use a custom widget toolkit that works consistently across all your target OSes. So many actually-native apps use custom widgets anyway nowadays that your app will hardly look foreign for doing so.
- jarek-foksa 10y ago
  AFAIK Swing did not have the advanced theming capabilities that are now possible with modern CSS. Making the HTML widgets look and behave exactly like native Cocoa components is probably not going to happen, but definitely I can do better than Swing or GTK.
  - stupidcar 10y ago
    Swing is an extremely powerful toolkit with very rich capabilities. And since it's backed by Java2D, you can control the painting of a widget at the pixel level, if you want to - which is something CSS won't have until the CSS Painting API arrives[1]. For proof, look at what JetBrains achieves in IntelliJ, which uses Swing. Technical capabilities are not the obstacle. The problem is that you're trying to reverse engineer and build a faithful emulation of a complex set of software components in a completely different language and runtime. And unlike emulating a legacy system, OS toolkits are a moving target. They get tweaked constantly, and often overhauled completely with each new release. [1] https://www.w3.org/TR/css-paint-api-1/ https://www.w3.org/TR/css-paint-api-1/
    - evilduck 10y ago
      IntelliJ still feels like a Java app imitating a macOS app to me. They do better job than most, but if you open up the settings of it and compare it to XCode's setting, it jumps out at you.
    - jarek-foksa 10y ago
deedubaya 10y ago
I'm sure this will be useful for someone, but from a UX perspective I have one comment about the macOS theme. HTML representations of macOS native UI elements have been attempted many times. I still haven't seen anyone get them just right. I think you're better off using a design which doesn't try to replicate native elements as they won't match a user's selected appearance, nor will they automatically update when macOS makes a styling change. This will probably give the user a bad impression of your app.
- kitsunesoba 10y ago
  Indeed. I applaud the effort, but the UI of macOS has many, many subtle details that at first glance don't have much value and end up getting discarded in imitations. Once those details are missing it becomes evident why they the original possessed them. If you're going to imitate a native style, you've gotta go whole hog and nail it down to the last idiosyncrasy or it's going to be vaguely weird/awkward.
  - citrusui 10y ago
    Funny you mention that: I've always had the idea of replicating the Mac's Cocoa interface. Once you extract the System UI assets[0], you have a good reference to use. Actually using that reference to make a (web) framework is something more complicated, but I wouldn't say it's impossible. I haven't tried, mainly because I don't have enough patience, but also because I'm uncertain if it violates any copyright laws, (which it probably does.) [0]: https://github.com/alexzielenski/ThemeEngine https://github.com/alexzielenski/ThemeEngine
    - jarek-foksa 10y ago
      I was also concerned about the possible copyright claims, therefore I have encapsulated the macOS theme in a single CSS file [1] and I added a more restrictive license to it. I might remove it completely in case I receive any complains from Apple. I'm not using any assets from macOS though, everything is done with plain CSS. I'm planning to implement ElementaryOS themes [2] as a safer alternative that looks good on both macOS and Linux. [1] https://github.com/jarek-foksa/xel/blob/master/stylesheets/macos.theme.css https://github.com/jarek-foksa/xel/blob/master/stylesheets/m... [2] https://elementary.io/docs/human-interface-guidelines https://elementary.io/docs/human-interface-guidelines
hartator 10y ago
> To view this site, you must use Chrome, Opera or other Chromium-based browser. I think that's a good summup of the downsides of relying in web technologies to build desktop apps. Can't produce a true website.
- jarek-foksa 10y ago
  It's not a website, it's a single-page app built with Xel, which in turn is an experimental project built with bleeding edge Web Platform technologies such as Custom Elements v1, Shadow DOM v1 or ES2017. I will implement a proper project website for all browsers when the project matures.
  - hartator 10y ago
    Kudos on the effort, I don't want to diminish it in any way, but I think you kind of prove this approach is the wrong way to build things: You are losing performance and interoperability at the same time.
    - penagwin 10y ago
      He doesn't care about interoperability.... It's only made for electron.... Although I do question why his website would use the same framework since it's chromium only. It's fine to make it only for chromium, as he is targeting Electron which is chromium, but his website shouldn't depend on it too.
  - Sir_Cmpwn 10y ago
    Don't do a UA check. Just let it be broken. At the absolute worst put up a page warning users it might not work, then let them try anyway.
    - jarek-foksa 10y ago
      This approach works with mostly static or server-side generated websites, but with JS-heavy SPA unsupported browsers would be just showing a blank page. Currently I'm checking whether the browser supports Custom Elements v1, Shadow DOM v1 and HTML imports. If it does not, I'm showing the fallback page.
comex 10y ago
One macOS behavior this gets wrong that a lot of other clones do too: press-and-hold on menus and select boxes. With the native widgets, you can invoke a menu item either by clicking the menu, releasing, and then clicking the item - or by pressing down on the menu, dragging to the item, and releasing. Xel doesn't support the latter at all. Other toolkits do but get some details wrong, like - if you release on an item that opens a submenu, it dismisses the menu (but the same doesn't happen if you click such an item after clicking the menu); - macOS assumes you're using the press style if either the mouse moves a significant amount between pressing down on the menu and releasing, or it stays pressed for a certain interval. So if you press a menu, wait a second, and release, it dismisses the menu.

38 points by jarek-foksa 10y ago

zerr 10y ago

A question: Why bundling Electron/chromium is better than bundling JVM?

tomjakubowski 10y ago
Support tooling for web UI development is superb. I don't know the state of the art in Java/JVM GUI, but the rapid prototyping you can achieve with live code reloading, browser DOM inspectors, etc. is unmatched in my (admittedly limited) experience with UI toolkits. QtQuick is the only other that's come close for me, and it's heavily inspired by the front-end web "toolkit". It's probably more about the developer experience than anything else. Bundling Electron in every application is pretty bloaty.
- pjmlp 10y ago
  RAD tooling for native UIs was already a thing in the mid-90's. Web tools are still catching up with 4GLs and RAD environments.
auggierose 10y ago
Depends on your needs. You could argue that user interface development with electron is much more convenient, you can use for example React. Basically, if you prefer developing for the browser over developing for java, choose electron, otherwise vice versa.
pjmlp 10y ago
Learning anything else other than HTML/CSS/JavaScript is too hard. Funny enough, for anyone able to do proper Swing/JavaFX coding, the JVM applications take less space, are better integrated into the OSes and perform better than Electron ones, but it requires skill to do so.
edko 10y ago
The JVM comes with an embedded Webkit browser (via the included JavaFX). This lets you code as much as you need/want in HTML/JS/CSS, but also gives you the option of easily interacting with Java, Scala, Clojure, Groovy, Kotlin, Ceylon, Frege, etc. I think this is more powerful than Electron/Chromium.
spapas82 10y ago
Another question. Why bundling Electron or JVM and not Delphi (or its open source brother Lazarus - https://www.lazarus-ide.org/ https://www.lazarus-ide.org/)? I really can't understand why use HTML technologies for the Desktop...

scandox 10y ago

> To view this site, you must use Chrome, Opera or other Chromium-based browser. Well frankly F off

detaro 10y ago
And to add insult to injury, it hijacks the back button on that page...
- jarek-foksa 10y ago
  What web browser are you using? I'm unable to reproduce this bug on Safari.
  - hdhzy 10y ago
    Firefox for Android. Main site redirects to /fallback. Thrn you press back then it goes to the home page and... Redirects to /fallback. :(
  - detaro 10y ago
    Desktop Firefox, Linux and Windows
  - jarek-foksa 10y ago
    Thanks for feedback. This issue should be resolved now (I had to use window.location.replace() instead of window.location.pathname).
    - detaro 10y ago
      works now, thank you!
pbowyer 10y ago
Given this is the engine inside Electron, it's understandable if they only work in this rendering engine. Blocking other browsers is a bit extreme, but would reduce the pointless bug reports and bad publicity.

stupidcar 10y ago

IMO, trying to clone native UI widgets in a 3rd party toolkit is a bad idea, and Swing proved it in the early 2000s. No matter how hard you try, you end up in an uncanny valley where it looks and feels almost like a native macOS (or whatever) app, but there are bugs and inconsistencies that make it feel slightly off. Far better and easier to just use a custom widget toolkit that works consistently across all your target OSes. So many actually-native apps use custom widgets anyway nowadays that your app will hardly look foreign for doing so.

jarek-foksa 10y ago
AFAIK Swing did not have the advanced theming capabilities that are now possible with modern CSS. Making the HTML widgets look and behave exactly like native Cocoa components is probably not going to happen, but definitely I can do better than Swing or GTK.
- stupidcar 10y ago
  Swing is an extremely powerful toolkit with very rich capabilities. And since it's backed by Java2D, you can control the painting of a widget at the pixel level, if you want to - which is something CSS won't have until the CSS Painting API arrives[1]. For proof, look at what JetBrains achieves in IntelliJ, which uses Swing. Technical capabilities are not the obstacle. The problem is that you're trying to reverse engineer and build a faithful emulation of a complex set of software components in a completely different language and runtime. And unlike emulating a legacy system, OS toolkits are a moving target. They get tweaked constantly, and often overhauled completely with each new release. [1] https://www.w3.org/TR/css-paint-api-1/ https://www.w3.org/TR/css-paint-api-1/
  - evilduck 10y ago
    IntelliJ still feels like a Java app imitating a macOS app to me. They do better job than most, but if you open up the settings of it and compare it to XCode's setting, it jumps out at you.
  - jarek-foksa 10y ago

deedubaya 10y ago

I'm sure this will be useful for someone, but from a UX perspective I have one comment about the macOS theme. HTML representations of macOS native UI elements have been attempted many times. I still haven't seen anyone get them just right. I think you're better off using a design which doesn't try to replicate native elements as they won't match a user's selected appearance, nor will they automatically update when macOS makes a styling change. This will probably give the user a bad impression of your app.

kitsunesoba 10y ago
Indeed. I applaud the effort, but the UI of macOS has many, many subtle details that at first glance don't have much value and end up getting discarded in imitations. Once those details are missing it becomes evident why they the original possessed them. If you're going to imitate a native style, you've gotta go whole hog and nail it down to the last idiosyncrasy or it's going to be vaguely weird/awkward.
- citrusui 10y ago
  Funny you mention that: I've always had the idea of replicating the Mac's Cocoa interface. Once you extract the System UI assets[0], you have a good reference to use. Actually using that reference to make a (web) framework is something more complicated, but I wouldn't say it's impossible. I haven't tried, mainly because I don't have enough patience, but also because I'm uncertain if it violates any copyright laws, (which it probably does.) [0]: https://github.com/alexzielenski/ThemeEngine https://github.com/alexzielenski/ThemeEngine
  - jarek-foksa 10y ago
    I was also concerned about the possible copyright claims, therefore I have encapsulated the macOS theme in a single CSS file [1] and I added a more restrictive license to it. I might remove it completely in case I receive any complains from Apple. I'm not using any assets from macOS though, everything is done with plain CSS. I'm planning to implement ElementaryOS themes [2] as a safer alternative that looks good on both macOS and Linux. [1] https://github.com/jarek-foksa/xel/blob/master/stylesheets/macos.theme.css https://github.com/jarek-foksa/xel/blob/master/stylesheets/m... [2] https://elementary.io/docs/human-interface-guidelines https://elementary.io/docs/human-interface-guidelines

hartator 10y ago

> To view this site, you must use Chrome, Opera or other Chromium-based browser. I think that's a good summup of the downsides of relying in web technologies to build desktop apps. Can't produce a true website.

jarek-foksa 10y ago
It's not a website, it's a single-page app built with Xel, which in turn is an experimental project built with bleeding edge Web Platform technologies such as Custom Elements v1, Shadow DOM v1 or ES2017. I will implement a proper project website for all browsers when the project matures.
- hartator 10y ago
  Kudos on the effort, I don't want to diminish it in any way, but I think you kind of prove this approach is the wrong way to build things: You are losing performance and interoperability at the same time.
  - penagwin 10y ago
    He doesn't care about interoperability.... It's only made for electron.... Although I do question why his website would use the same framework since it's chromium only. It's fine to make it only for chromium, as he is targeting Electron which is chromium, but his website shouldn't depend on it too.
- Sir_Cmpwn 10y ago
  Don't do a UA check. Just let it be broken. At the absolute worst put up a page warning users it might not work, then let them try anyway.
  - jarek-foksa 10y ago
    This approach works with mostly static or server-side generated websites, but with JS-heavy SPA unsupported browsers would be just showing a blank page. Currently I'm checking whether the browser supports Custom Elements v1, Shadow DOM v1 and HTML imports. If it does not, I'm showing the fallback page.

comex 10y ago

One macOS behavior this gets wrong that a lot of other clones do too: press-and-hold on menus and select boxes. With the native widgets, you can invoke a menu item either by clicking the menu, releasing, and then clicking the item - or by pressing down on the menu, dragging to the item, and releasing. Xel doesn't support the latter at all. Other toolkits do but get some details wrong, like - if you release on an item that opens a submenu, it dismisses the menu (but the same doesn't happen if you click such an item after clicking the menu); - macOS assumes you're using the press style if either the mouse moves a significant amount between pressing down on the menu and releasing, or it stays pressed for a certain interval. So if you press a menu, wait a second, and release, it dismisses the menu.