It's not aiming for 100% compatibility to web standards. More like a familiar way to create GUIs. Electron is a very up to date browser instance, and that is both its strength and weakness.
I have seen its use in Symantec. They were happy with the performance and the looks even though limited. It does a few things and does it well. Comparison with electron is not appropriate here as its like an OS altogether.
HTML/CSS based native interfaces are some of the hardest to use, least reliable, least accessible, least robust interfaces I encounter; The demo interfaces on their website all fit into the unusable pot.
I admit most/all of the interfaces I've personal used are using electron/webkit/ie to render which are all quite bloated. Is this different? It's not entirely clear and would be an important differentiator.
I still don't understand the draw though. The best native apps look and behave natively; using a platform like this prevents that or just makes it harder to accomplish. Using such a platform seems like it's entirely developer-focused and not-at-all user focused, which is a shame.
Lots of native UIs (especially from the past) tend to all have the same "grey boxes" look. I don't see how that's universally better.
Another example was this part of Slack UI https://i.imgur.com/O71fdP5.png - how would you even do something like that with a typical native library? It would certainly take a lot more effort if you had to build that from a limited set of pre-existing components, instead of relying on the more free-form "rectangles and text" building blocks of the web.
I'm not 100% sure but I think the slack design can be achieved in wxWidgets. Yes the native apps look bland but why would I use an app that requires 500M to play music?
Why not? If it works ok and doesn't eat battery/CPU too much when in background, then who cares? For exapmle I like that I can plug my phone into the speakers (yay headphone jack), and control the music from a laptop on the other side of the room.
Also, it's more like 200 MB on my computer, most of which is predictably CEF. In comparison bundling Qt dlls would also add like 50MB if I remember correctly.
I'm talking about RAM not SSD. And no I don't have multiple computers in my house. A single laptop with 16G of RAM is all I have. I have to use it for work. We all know about music apps playing music while using less than 50M at any given time. If its in the background then even less. I know the dev experience is far greater in electron but its simply not performant. But if I were to launch a product on all platforms then I'll go for electron probably cause its the fastest to market
RAM's about the same, hovering slightly below 200MB (Windows shows a sum of all the different Chromium processes). Which for me is firmly in the "who cares" territory. Lightweight music apps don't have the online playlists, discovery mechanisms (Discover Weekly, etc.) and all that other stuff.
They could do though. All the smarts of Spotify comes from their APIs. There's been a bunch of third party low-resource clients / integrations for spotify; despotify, mopidy, recently this thing: https://github.com/hrkfdn/ncspot
Unfortunately iirc the neat dynamically generated playlist stuff isn't supported because it's not exposed properly through their APIs. Certainly when I tried to use Spotify's own libspotify its functionality was crippled to static playlist management, searching for stuff, and playback. despotify was in a similar state at the time.
Also - Spotify sucks HARD at doing all the stuff it does, and I blame this entirely on the UI implementation. The service, I love. The apps, I have become to loathe. They used to be nice and quick and responsive. Now? It can't even get shuffle right!! My mid tier smartphone takes 10 minutes to load search results or my own playlists sometimes; something i've encountered across multiple devices. The desktop app crawls on my 24gb 8-core workstation.
Conversely, I can have a 200gb library of music loaded into mpd or foobar2000 or vlc in all sorts of exotic (and higher bitrate) formats and from weird and wonderful local and remote storage and play it all on shuffle and have all the albumart showing and it organised neatly into a searchable library via the id3 tags and have volume normalized with replaygain and it'll do it in under 20mb and has been doing so for a decade.........
Nearly every native UI framework I’ve touched allows for a rich customized look of UI components. Often this means subclassing an abstract view thing that opens a toolbox of fine grained drawing commands.
Your examples of boring native UI is the result of developers that don’t bother to exploit these features for whatever reasons- probably because it can be extremely time consuming to build native custom UI and adds mental overhead unless one has/is a dedicated designer/artist.
I’m not sure which part of the Slack UI you believe can’t be done natively? Flat colors or the revealing menu?
I'm not saying it can't be done, I'm saying it would take a lot more effort (by a huge amount, plus more in prototyping phase of development when you're trying stuff out), and in the process you will likely lose many of the advantages of native UI that were mentioned (consistent behavior etc.).
Take for example that "Jump to" text box - if your native UI toolkit doesn't let you add icons into the placeholder text like that (does it even have placeholder text natively?), you'll have to deal with drawing offsets, caret position, or possibly nested components, overriding focus outline, in the worst case resizing the stuff when focused, and other stuff that makes the whole endeavor not worth it due to the added complexity (assuming that text box works how I think it works, I haven't used Slack in a while).
As a backend dev, I find that the most annoying part. I don't want free-form; I want something I can put together in a few minutes without having to think about design and it still having it look acceptable on the platform I deploy it on. On the web I can do that with bootstrap (and it's 100.000s of themes), native I can do this with the native libraries but in the html5-for-desktop-apps space it seems I have to spend time on doing stuff I don't want to do or even care about to make it look anything different than vomit; that is simply not worth the time. I know that is very different from your use-case, so not saying you are wrong or anything, just that this is what annoys me about html/css. I think there would be a market for 'electron desktop themes' like (1) (basically unsupported now) but seems there is not (or no-one finds it necessary anyway; maybe i'm the only one with this 'issue', well, me and all my colleagues that is).
At least on those "grey boxes" buttons look like other buttons, there is good contrast, they blend in with the other things in the UI and don't stick out like a sore thumb.
One can preach about "brand identity" the whole day, but as a user, I couldn't care less about your brand. Integrate or die!
> I had a similar discussion on reddit a long time ago, and posted this screenshot of various Linux music players compared to Spotify.
In 90s this was solved by using "skins" which were actually drawn in graphics programs and then spliced and edited in some proprietary editor and/or positioned by hand crafted config file.
We (people outside of Microsoft, Apple and Google) cannot afford UIs nailed down to pixel grids and particular trends.
Years ago it was Skeumorphism, then it was flat UI as Metro, today people started speaking about Skeumorphism again. CSS is just a convenient tool to follow the trends.
And "yes" it "doesn’t mean you need electron" as there are other options :)
Take Sciter and forget about UI problems and "resource hogs" for years to come. HTML/CSS will be with us together with the Internet. And so are UI developers that can take care about it. And C++ developers in case you will need to fix something critical inside the Sciter.
You're taking a lot of crap here. I just wanted to chime in to say I thank you for trying to build something like Electron that's still lean and efficient. On top of it, I always use your licensing plans as a positive example in discussions about beneficial, but sustainable, licensing strategies. licensezero.com comes to mind. Keep up the good work.
> Lots of native UIs (especially from the past) tend to all have the same "grey boxes" look.
it's not "grey box", it's "uses the native theme of the user's desktop". e.g. I use strawberry music player, if I am on a computer with a dark theme it's dark.
Ripcord is another Qt app which is a discord / slack client made by a single guy, which goes more for the native look'n'feel : https://cancel.fm/ripcord/
(contrast this with slack needing dozens of developers and being at their third rewrite of the app because of performance issue :-))
A point I think is worth noting is that Linux software is far more likely to be FOSS, and FOSS is far less likely to have dedicated designers. LibreOffice wouldn't look out of place in 2002 for example, but it's not because of the platform/SDK it runs on. Whereas Spotify most definitely has a whole team of design staff.
That aside, if the rest of my OS has a "grey boxes" look, I would like my software to have a "grey boxes" look.
Sure, your design may be pretty, but if it looks and works completely differently to my other applications and the OS itself, I consider that a pretty huge point against it.
Drab gray boxes may not be as 'engaging' or 'visually rich' but they are more accessible and usable. You know what's interactive, what components relate to what and how they affect the application.
The slack UI is a counter-example of a good UI. It's confusing, it's unpredictable, it's inaccessible. They made the application look like a fancy website instead of an application. That's a bad thing, not a good thing. There should be no attempt to replicate it. Using it as a benchmark to evaluate how flexible a UI framework is a non-starter.
It seems to me at this point that UI/UX developers just refuse to learn low level languages. Qt applications for example are extremely fast and cross platform.
It seems to me that wanting UI developers to learn systems languages is bizarre. We don’t expect Linux kernel developers to learn UI/UX, why would the opposite be the case? They are working on a vastly different abstraction level.
Also, yeah, Qt is indeed fast and cross platform. But somehow every single mainstream Qt application tends to look visually terrible and not any more native than Electron. E.g. Ripcord posted above, or Calibre. Meanwhile, mainstream Electron apps may be hogs in terms of performance, but they look polished.
Finally, Qt’s weird and deceiving licensing is a major reason I would never touch it with a 10 foot pole. I am not a copyright lawyer and have no desire to figure out how I can comply with LGPL, when Electron is MIT.
> Finally, Qt’s weird and deceiving licensing is a major reason I would never touch it with a 10 foot pole. I am not a copyright lawyer and have no desire to figure out how I can comply with LGPL, when Electron is MIT.
I'll let you note the large irony of WebKit & thus Blink & Electron originally coming from KHTML, that is, a KDE project originally built with Qt - Lars Knoll at the top of that copyright header is currently CTO of The Qt Company.
The 'native' 'modern' apps on Windows 10 are not known for being small, fast, or especially well designed either though.
I developed a number of WFP apps (starting with the earliest versions) and it was very very far from being easy compared to html. Debuggability, Stability, Performance were all sub-par.
> HTML/CSS based native interfaces are some of the hardest to use, least reliable, least accessible, least robust interfaces I encounter
This has nothing with HTML/CSS per se but rather questions to particular products. Same complain may apply to any UI.
> The best native apps look and behave natively;
"Native app" term these days is something almost non existent.
In these terms Microsoft Office is not a native app as they use custom UI framework for UI. Pretty much whole Window 10 UI now is not "native" in this sense. UWP is a custom UI layer that uses windowless DirectX based UI.
There are some low level utilities left in dusted corners of Windows that can be classified as "native" but there are just few of them - no one cares.
Consider my https://html-notepad.com as an example (purely sciter app and so HTML/CSS UI), this application simply cannot use "native UI". No OS has needed components out of the box.
Yet pretty much any modern app must have one way to another to render and to produce HTML - we want our applications to be connected (read: interact with the Web).
UWP are an interesting example. They are the most 'native' (at least looking) kind of application on windows 10 but I realize they aren't using win32 (which I think is what we both mean when we refer to native). Regardless, UWP are terrible; they are very hard to use and look awful, if not flat and uncluttered.
Office is a bad example as well; that team is notorious for choosing new/different interface controls just to be different. They try to back it up with studies but the studies are flawed. Accordion and Ribbon come to mind, as does the silly fake shadow they had a few years ago.
Still to this day, the drab boring win32 applications are the best performing and easiest to use.
Miranda IM has always been a solid IM client. All the utility apps that look like they are from windows 2000 work great. All the old control panel apps that UWP/Metro settings app still rely on for a lot of their settings still work better than the pc settings app. All the light-weight notepad clones are great, my fave is notepad3.
VSCode is by far the best Electron app... I mean by miles. It occupies a niche though where people tolerate and even want peculiar user interfaces that are highly optimized for their specific job-- in this case being a code editor and IDE. Electron and other HTML based UIs suck for more normal sorts of apps. They're bloated and look alien and clunky.
Using 'modern' to describe the platform doesn't communicate anything to me as a developer. Tell me what makes it modern. Tell me why its better. Is it lighter weight? is it easier to develop with? is it better for my users? is it less buggy than other frameworks?
I have never used this but something better for GUI would be great even if commercial; what I miss (as a native GUI dev) with all(? if you know any besides framework7 which is basically only mobile) of these html/css frameworks is that there is no equivalent of a control library that can be rapidly used without using (bucketloads) of css. When you browse the examples you see that most have some desktop controls like menus etc; I don't want to 'make' those; I just want to start with a theme (Material) and (as backend dev) never touch css while still being able to make something that looks ok and works like an actual GUI app instead of a web page. Like I can (and do) do in native tech all the time.
Is there anything with Electron-ish apps (Sciter is preferable it seems as it has less bloat)? I searched for instance for a desktop theme for Electron and only found a mac os x theme which indeed works like described above but I don't want everything to look like mac os x or windows or linux or ios or android; either it should look native-ish (nothing beats native though) on the platform it runs on , or it should look like something completely 'new'.
Yeah, I'm using RN + Flutter and it's ok. But I'm not sure why there are more prepackaged web-based solutions. I might/seem to be alone in that wish, so i'll use what works in anger.
>I have never used this but something better for GUI would be great even if commercial; what I miss (as a native GUI dev) with all(? if you know any besides framework7 which is basically only mobile) of these html/css frameworks is that there is no equivalent of a control library that can be rapidly used without using (bucketloads) of css. When you browse the examples you see that most have some desktop controls like menus etc; I don't want to 'make' those; I just want to start with a theme (Material) and (as backend dev) never touch css while still being able to make something that looks ok and works like an actual GUI app instead of a web page. Like I can (and do) do in native tech all the time.
In this regard even Visual Basic was far ahead of most of today's client tech. HTML/CSS/JS are not even close to be called a serious GUI stack for applications despite they are used for that as the Web ate the world.
This may be a lot more viable today than it would have been in the past when there were huge compatibility issues between browsers (e.g. which IE version does the user have on their system?). Especially with the Chromium-based Edge in the future.
Sciter does not use webview or any other existing browser engine implementation. I did HTML/CSS and script engines by myself.
The only place where I intersected with WebKit and Gecko teams is at WHATWG and then HTML WG at W3C in design of HTML5 specification and portions of CSS3.
My main concern with this would be the security and W3 standard support. Browser engines and whatnot do make your life easy, but they add a lot of attack vectors. Also the support for W3 standard is usually limited and incomplete.
Also it seems that the engine itself is distributed as binary only? I can't find source anywhere. That's a -1 for security.
From browsing the docs, it looks like scripts can open sockets so it makes it much easier to jump from exploiting an app's Sciter frontend to attacking other targets
This has been posted a few times to HN [0] and I've looked into it superficially without actually trying it out. For the benefit of anyone interested, these are my tentative conclusions. Please correct me if I've misunderstood anything.
Sciter is a small company (single person ?) project, but the list of enterprise clients is an assurance.
Their flavor of Javascript (TIscript) diverged from ECMAScipt more than 10 years ago, so there would be syntax switching involved when developing in Sciter and doing normal web development in parallel. There are similar issues with the DOM and CSS. But the list of included libraries certainly look like it could compensate for some of that, with implementations that can mimic modern features like promises and CSS3 transitions. [1]
Also, as far as I can see it is not truly cross-platform, i.e. it can not easily be deployed to mobile.
Pricing (even if fair comparatively) and the closed source is also a roadblock (for me). There was a thread by the author on Reddit some time back that vented the idea of open-sourcing the library. That could tip the balance (for me). [2]
Using a Javscript dialect is a huge disadvantage in my opinion. I have worked with a similar dialect, and even if the language is pretty close to Javascript, a huge issue is that it breaks all tools and editors you would usually use. You have to rely entirely on the developers of that dialect to supply the tools you need.
And this situation only gets worse over time, as you're decoupled from the improvements of the language. Especially once there are a bunch of changes in the dialect that conflict with later developments of the parent language. My experience is also that there is inevitably more friction than you might expect when integrating libraries from the parent language.
For me this would be an immediate dealbreaker, it's just not worth it to tie yourself to a small dialect like this.
Not GP, but I do that manually. Inline links often get in the way of the content, if you're using them as reference or support material. I still use inline links if it's central to the point of the comment.
> Various GUI frameworks offer different UI declaration and styling languages, such as QML and XAML (Microsoft WPF). On the contrary, Sciter allows using time proven, robust, and flexible HTML
What a remarkable piece of bullshit. QML and XAML have been designed from scratch right for UI mark-up, HTML is a legacy document mark-up language we are doomed to carry on together with gargantuan rendering engines and the whole pandemonium of frameworks while making UIs.
And so was XAML. Time is passing and now it takes significant excavation effort to find out a project that uses it. Git-for-desktop used to be a XAML app, now it is an Electron app. And so on.
QML is a palliative or compromise if you wish: let's take existing widget-tree-based UI and add some declarativeness to it at least to compete somehow with the web tech stack flexibility and explosion of ideas. Desperate move I would say.
As an C++ UI developer and then UI architect I was working on one project that transitioned from pure desktop VB + native application to pure Web based app. So "I've been there, seen that" and many times since then, all pro et contra of all these.
At some point I've asked myself the question: "Ok, what would you add to Web UI stack so it will be really useful on desktop?"
So I took C++ again and made the Sciter. It is a modern engine that works as on modern high-res monitors and GPU hardware as on ancient XP machines. It supports as retained UI as immediate ones a la ImGUI. As C++, Go, Rust, Delphi as script. As Angular (data bound UI) and React UI (vDOM,JSX) approaches as classic direct element tree composition from native code.
Yes, all this is using HTML/CSS vocabulary because it is a) convenient and flexible, b) 90% of UI developers are Web developers these days and c) HTML/CSS are here now and for generations to come.
I wonder why we see so many of these attempts at bringing html/css to native, while we (or at least I) see so few examples of the inverse.
I loved creating iOS apps with autolayout. Some parts of it were a bit frustrating, sure, but you could do things that were pretty hard with css. Why don't we see any lib for "make an app just as if you were making it for native, but now it runs on the web!"
Couple of words about "native UI" and on statements like: "I (a hard-core software developer) prefer gray boxes".
You (as a software developer), is one of 1% of UI users. But rest of us (99%, sic!) consume UI in form of Web sites, right?
So "Native UI" these days shall look closer to default Bootstrap theme then to something that OS provides. My wife (as an example) has Windows notebook, iPhone and Android based book reader - "native UI" for her is meaningless at best.
About desktop applications in general...
There are two major types of applications:
a) the ones used time to time / rarely;
b) and productive applications used 24/7 - parts of job workflow.
The ones that used time to time (what I name as "one big red button applications") must have descriptive UI - e.g. hot-keys don't work there - no one is bothered to remember them. So the UI shall be self descriptive, pictographic, etc. 1 second looking on window to make decision what to use.
Such applications must follow modern UI trends - who will trust antivirus if it looks as dinosaur from prehistoric times? That's why AV vendors prefer to use CSS, just to minimize maintenance costs, see: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...
Productive applications: MS Office, Adobe Suite, even IDEs like Visual Studio, JetBrain, SublimeText, VSCode, etc.
None of these are using "native UI" as you know. One of the reasons: "native UI" is not expressive enough.
Another reason: these are complex UI systems with complex data model underneath and so complex update graphs. They prefer GC-able runtime environments for those reasons. Yet there are c), d) up until z) reasons why they do that, I can speak about that forever, e.g. Adobe Suite must be cross-platform, right?
So when you use "native UI" please take the above into consideration.
Native to the platform is the common meaning on HN. Native to users is a good point, though orthogonal to reasons HN users may prefer platform-native: lower memory and CPU usage, platform style, familiar shortcuts and behavior.
That's my impression too. I suspect that those "gray boxes" talks (a.k.a. buttons a la turrets of Panzerkampfwagen VI Tiger) are orthogonal to GUI in general.
Yet "memory and CPU usage" is also orthogonal to HTML/CSS per se. One of strict requirements of AntiVirus applications is to to consume as low memory and CPU as possible. And most of AVs are using HTML/CSS UI these days. And so Sciter code works on 600 mln PCs and Macs as a part of these applications.
In fact the main motivator why Sciter started using GPU for UI rendering was R&D director of Norton Antivirus when high-res monitors started to arrive. Retina monitors have 9 times more pixels to rasterize than old 96 ppi monitors. GPU is the only option for the GUI at post-Moore era.
> And most of AVs are using HTML/CSS UI these days.
If AV background and scanner processes use those then that's yet another reason to drop them like a bad habit. (The other reason being they increase the attack surface area.)
No, AV scanning has nothing with UI layer other than posting events "something found - here are details". Even more, usually scans are done in separate processes/daemons.
I've always found AV programs to be slow, unresponsive, laggy, [pick-your-adjective] etc. I suppose a lot of that is caused by the dumb things they do (e.g. hook into the OS and synchronously scan every byte written to disk, or packet received) rather than what UI engine they use.
> Sciter Engine is a single, compact DLL of 5+ Mb in size. Application using it are 10+ times smaller than the ones built with Electron or Qt.
With the HackerNews crowd you should just lead with this. In fact, just answer every question and critique with this. Here’s an example:
HN commenter: “I’m a hard core software developer and I prefer gray boxes to native UI.”
c-smile: “Sciter Engine is a single, compact DLL of 5+ Mb in size. Application using it are 10+ times smaller than the ones built with Electron or Qt.”
HN commenter: “Oh hell yeah, I prefer native UI to gray boxes now. Where do I sign up?”
(I include myself in this satire as one of the HN commenters :D )
Speaking of UI, please set a max-width on your text. My eyes shouldn't have to scan across my whole screen to read your intro blurb. I'm now using the Just Read addon to read your site.
77 comments
[ 4.0 ms ] story [ 105 ms ] threadLooks like something you'd use for UI in a native app.
I admit most/all of the interfaces I've personal used are using electron/webkit/ie to render which are all quite bloated. Is this different? It's not entirely clear and would be an important differentiator.
I still don't understand the draw though. The best native apps look and behave natively; using a platform like this prevents that or just makes it harder to accomplish. Using such a platform seems like it's entirely developer-focused and not-at-all user focused, which is a shame.
https://i.imgur.com/K44tJ2Y.png
Lots of native UIs (especially from the past) tend to all have the same "grey boxes" look. I don't see how that's universally better.
Another example was this part of Slack UI https://i.imgur.com/O71fdP5.png - how would you even do something like that with a typical native library? It would certainly take a lot more effort if you had to build that from a limited set of pre-existing components, instead of relying on the more free-form "rectangles and text" building blocks of the web.
Also, it's more like 200 MB on my computer, most of which is predictably CEF. In comparison bundling Qt dlls would also add like 50MB if I remember correctly.
Unfortunately iirc the neat dynamically generated playlist stuff isn't supported because it's not exposed properly through their APIs. Certainly when I tried to use Spotify's own libspotify its functionality was crippled to static playlist management, searching for stuff, and playback. despotify was in a similar state at the time.
Also - Spotify sucks HARD at doing all the stuff it does, and I blame this entirely on the UI implementation. The service, I love. The apps, I have become to loathe. They used to be nice and quick and responsive. Now? It can't even get shuffle right!! My mid tier smartphone takes 10 minutes to load search results or my own playlists sometimes; something i've encountered across multiple devices. The desktop app crawls on my 24gb 8-core workstation.
Conversely, I can have a 200gb library of music loaded into mpd or foobar2000 or vlc in all sorts of exotic (and higher bitrate) formats and from weird and wonderful local and remote storage and play it all on shuffle and have all the albumart showing and it organised neatly into a searchable library via the id3 tags and have volume normalized with replaygain and it'll do it in under 20mb and has been doing so for a decade.........
Your examples of boring native UI is the result of developers that don’t bother to exploit these features for whatever reasons- probably because it can be extremely time consuming to build native custom UI and adds mental overhead unless one has/is a dedicated designer/artist.
I’m not sure which part of the Slack UI you believe can’t be done natively? Flat colors or the revealing menu?
Take for example that "Jump to" text box - if your native UI toolkit doesn't let you add icons into the placeholder text like that (does it even have placeholder text natively?), you'll have to deal with drawing offsets, caret position, or possibly nested components, overriding focus outline, in the worst case resizing the stuff when focused, and other stuff that makes the whole endeavor not worth it due to the added complexity (assuming that text box works how I think it works, I haven't used Slack in a while).
It would still look mostly native (even though it's clearly not a native control), be very performant and use a tiny amount of memory.
And I don’t think it’s quite as hard as you describe natively, at least on AppKit/UIKit, windows, and android.
As a backend dev, I find that the most annoying part. I don't want free-form; I want something I can put together in a few minutes without having to think about design and it still having it look acceptable on the platform I deploy it on. On the web I can do that with bootstrap (and it's 100.000s of themes), native I can do this with the native libraries but in the html5-for-desktop-apps space it seems I have to spend time on doing stuff I don't want to do or even care about to make it look anything different than vomit; that is simply not worth the time. I know that is very different from your use-case, so not saying you are wrong or anything, just that this is what annoys me about html/css. I think there would be a market for 'electron desktop themes' like (1) (basically unsupported now) but seems there is not (or no-one finds it necessary anyway; maybe i'm the only one with this 'issue', well, me and all my colleagues that is).
(1) http://photonkit.com/
One can preach about "brand identity" the whole day, but as a user, I couldn't care less about your brand. Integrate or die!
While i otherwise agree with you, the "die" part requires users to value such integration and they do not seem to be doing that enough.
In 90s this was solved by using "skins" which were actually drawn in graphics programs and then spliced and edited in some proprietary editor and/or positioned by hand crafted config file.
See https://winampheritage.com/skin for example. You can't go more original than these. :-D
I don't see a point why you would need web library for this.
Doesn’t mean you need electron to fix it, it can be done with a native UI. But bitmapped skins are generally not used anymore for a reason.
Yes, but with what price?
We (people outside of Microsoft, Apple and Google) cannot afford UIs nailed down to pixel grids and particular trends.
Years ago it was Skeumorphism, then it was flat UI as Metro, today people started speaking about Skeumorphism again. CSS is just a convenient tool to follow the trends.
And "yes" it "doesn’t mean you need electron" as there are other options :)
Take Sciter and forget about UI problems and "resource hogs" for years to come. HTML/CSS will be with us together with the Internet. And so are UI developers that can take care about it. And C++ developers in case you will need to fix something critical inside the Sciter.
it's not "grey box", it's "uses the native theme of the user's desktop". e.g. I use strawberry music player, if I am on a computer with a dark theme it's dark.
Qt definitely allows slack-like look though if the developer opts-in to it - e.g. Telegram Desktop (https://cdn2.nextinpact.com/images/bd/news/163843.jpeg) is made with Qt Widgets.
Ripcord is another Qt app which is a discord / slack client made by a single guy, which goes more for the native look'n'feel : https://cancel.fm/ripcord/
(contrast this with slack needing dozens of developers and being at their third rewrite of the app because of performance issue :-))
In the end I don't care how it's done as long as it works fine (which it does).
Telegram uses this non-native visual language which is very common in electron apps.
That aside, if the rest of my OS has a "grey boxes" look, I would like my software to have a "grey boxes" look.
Sure, your design may be pretty, but if it looks and works completely differently to my other applications and the OS itself, I consider that a pretty huge point against it.
The slack UI is a counter-example of a good UI. It's confusing, it's unpredictable, it's inaccessible. They made the application look like a fancy website instead of an application. That's a bad thing, not a good thing. There should be no attempt to replicate it. Using it as a benchmark to evaluate how flexible a UI framework is a non-starter.
Also, yeah, Qt is indeed fast and cross platform. But somehow every single mainstream Qt application tends to look visually terrible and not any more native than Electron. E.g. Ripcord posted above, or Calibre. Meanwhile, mainstream Electron apps may be hogs in terms of performance, but they look polished.
Finally, Qt’s weird and deceiving licensing is a major reason I would never touch it with a 10 foot pole. I am not a copyright lawyer and have no desire to figure out how I can comply with LGPL, when Electron is MIT.
you know that Electron uses Blink which is LGPL right ? It also ships by default with ffmpeg which is used by chromium for video rendering, which is also LGPL (https://source.chromium.org/chromium/chromium/src/+/master:t...).
See https://lists.gnu.org/archive/html/directory-discuss/2017-12... - and some LGPL-prefixed files from Blink's source code if you don't believe :-)
https://chromium.googlesource.com/chromium/blink/+/master/So...
I'll let you note the large irony of WebKit & thus Blink & Electron originally coming from KHTML, that is, a KDE project originally built with Qt - Lars Knoll at the top of that copyright header is currently CTO of The Qt Company.
I developed a number of WFP apps (starting with the earliest versions) and it was very very far from being easy compared to html. Debuggability, Stability, Performance were all sub-par.
> HTML/CSS based native interfaces are some of the hardest to use, least reliable, least accessible, least robust interfaces I encounter
This has nothing with HTML/CSS per se but rather questions to particular products. Same complain may apply to any UI.
> The best native apps look and behave natively;
"Native app" term these days is something almost non existent.
In these terms Microsoft Office is not a native app as they use custom UI framework for UI. Pretty much whole Window 10 UI now is not "native" in this sense. UWP is a custom UI layer that uses windowless DirectX based UI. There are some low level utilities left in dusted corners of Windows that can be classified as "native" but there are just few of them - no one cares.
Consider my https://html-notepad.com as an example (purely sciter app and so HTML/CSS UI), this application simply cannot use "native UI". No OS has needed components out of the box.
Yet pretty much any modern app must have one way to another to render and to produce HTML - we want our applications to be connected (read: interact with the Web).
Office is a bad example as well; that team is notorious for choosing new/different interface controls just to be different. They try to back it up with studies but the studies are flawed. Accordion and Ribbon come to mind, as does the silly fake shadow they had a few years ago.
Still to this day, the drab boring win32 applications are the best performing and easiest to use.
For example?
Is there anything with Electron-ish apps (Sciter is preferable it seems as it has less bloat)? I searched for instance for a desktop theme for Electron and only found a mac os x theme which indeed works like described above but I don't want everything to look like mac os x or windows or linux or ios or android; either it should look native-ish (nothing beats native though) on the platform it runs on , or it should look like something completely 'new'.
Not web/HTML though, uses native widgets directly (mostly).
In this regard even Visual Basic was far ahead of most of today's client tech. HTML/CSS/JS are not even close to be called a serious GUI stack for applications despite they are used for that as the Web ate the world.
It's very tiny (1200 lines single-header file).
I actually wouldn't be surprised if it used webview internally.
[1]: https://github.com/zserge/webview
The only place where I intersected with WebKit and Gecko teams is at WHATWG and then HTML WG at W3C in design of HTML5 specification and portions of CSS3.
Even if I am not sure it would be even legal to port that to iOS with Apple's restrictions on the Web Engines they accept in the Store.
For the moment it is available only as a static lib to be linked into an application.
I am trying to come up with a runtime model that will allow to build applications as simple as
> sciter-build /ui/res/folder -platform="xxx"
Even more, you can compile Sciter without them completely.
Sciter is a small company (single person ?) project, but the list of enterprise clients is an assurance.
Their flavor of Javascript (TIscript) diverged from ECMAScipt more than 10 years ago, so there would be syntax switching involved when developing in Sciter and doing normal web development in parallel. There are similar issues with the DOM and CSS. But the list of included libraries certainly look like it could compensate for some of that, with implementations that can mimic modern features like promises and CSS3 transitions. [1]
Also, as far as I can see it is not truly cross-platform, i.e. it can not easily be deployed to mobile.
Pricing (even if fair comparatively) and the closed source is also a roadblock (for me). There was a thread by the author on Reddit some time back that vented the idea of open-sourcing the library. That could tip the balance (for me). [2]
[0] https://news.ycombinator.com/item?id=13057526
[1] https://sciter.com/download/
[2] https://www.reddit.com/r/programming/comments/a8vkzm/scitern...
And this situation only gets worse over time, as you're decoupled from the improvements of the language. Especially once there are a bunch of changes in the dialect that conflict with later developments of the parent language. My experience is also that there is inevitably more friction than you might expect when integrating libraries from the parent language.
For me this would be an immediate dealbreaker, it's just not worth it to tie yourself to a small dialect like this.
What a remarkable piece of bullshit. QML and XAML have been designed from scratch right for UI mark-up, HTML is a legacy document mark-up language we are doomed to carry on together with gargantuan rendering engines and the whole pandemonium of frameworks while making UIs.
And so was XAML. Time is passing and now it takes significant excavation effort to find out a project that uses it. Git-for-desktop used to be a XAML app, now it is an Electron app. And so on.
QML is a palliative or compromise if you wish: let's take existing widget-tree-based UI and add some declarativeness to it at least to compete somehow with the web tech stack flexibility and explosion of ideas. Desperate move I would say.
As an C++ UI developer and then UI architect I was working on one project that transitioned from pure desktop VB + native application to pure Web based app. So "I've been there, seen that" and many times since then, all pro et contra of all these.
At some point I've asked myself the question: "Ok, what would you add to Web UI stack so it will be really useful on desktop?"
So I took C++ again and made the Sciter. It is a modern engine that works as on modern high-res monitors and GPU hardware as on ancient XP machines. It supports as retained UI as immediate ones a la ImGUI. As C++, Go, Rust, Delphi as script. As Angular (data bound UI) and React UI (vDOM,JSX) approaches as classic direct element tree composition from native code.
Yes, all this is using HTML/CSS vocabulary because it is a) convenient and flexible, b) 90% of UI developers are Web developers these days and c) HTML/CSS are here now and for generations to come.
And quickly uninstalled it. A supposed "enterprise" application that makes your whole machine unstable.
I loved creating iOS apps with autolayout. Some parts of it were a bit frustrating, sure, but you could do things that were pretty hard with css. Why don't we see any lib for "make an app just as if you were making it for native, but now it runs on the web!"
[1] http://www.gwtproject.org/
Couple of words about "native UI" and on statements like: "I (a hard-core software developer) prefer gray boxes".
You (as a software developer), is one of 1% of UI users. But rest of us (99%, sic!) consume UI in form of Web sites, right?
So "Native UI" these days shall look closer to default Bootstrap theme then to something that OS provides. My wife (as an example) has Windows notebook, iPhone and Android based book reader - "native UI" for her is meaningless at best.
About desktop applications in general...
There are two major types of applications:
a) the ones used time to time / rarely; b) and productive applications used 24/7 - parts of job workflow.
The ones that used time to time (what I name as "one big red button applications") must have descriptive UI - e.g. hot-keys don't work there - no one is bothered to remember them. So the UI shall be self descriptive, pictographic, etc. 1 second looking on window to make decision what to use.
Such applications must follow modern UI trends - who will trust antivirus if it looks as dinosaur from prehistoric times? That's why AV vendors prefer to use CSS, just to minimize maintenance costs, see: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...
Productive applications: MS Office, Adobe Suite, even IDEs like Visual Studio, JetBrain, SublimeText, VSCode, etc.
None of these are using "native UI" as you know. One of the reasons: "native UI" is not expressive enough. Another reason: these are complex UI systems with complex data model underneath and so complex update graphs. They prefer GC-able runtime environments for those reasons. Yet there are c), d) up until z) reasons why they do that, I can speak about that forever, e.g. Adobe Suite must be cross-platform, right?
So when you use "native UI" please take the above into consideration.
That's my impression too. I suspect that those "gray boxes" talks (a.k.a. buttons a la turrets of Panzerkampfwagen VI Tiger) are orthogonal to GUI in general.
Yet "memory and CPU usage" is also orthogonal to HTML/CSS per se. One of strict requirements of AntiVirus applications is to to consume as low memory and CPU as possible. And most of AVs are using HTML/CSS UI these days. And so Sciter code works on 600 mln PCs and Macs as a part of these applications.
In fact the main motivator why Sciter started using GPU for UI rendering was R&D director of Norton Antivirus when high-res monitors started to arrive. Retina monitors have 9 times more pixels to rasterize than old 96 ppi monitors. GPU is the only option for the GUI at post-Moore era.
If AV background and scanner processes use those then that's yet another reason to drop them like a bad habit. (The other reason being they increase the attack surface area.)
With the HackerNews crowd you should just lead with this. In fact, just answer every question and critique with this. Here’s an example:
HN commenter: “I’m a hard core software developer and I prefer gray boxes to native UI.”
c-smile: “Sciter Engine is a single, compact DLL of 5+ Mb in size. Application using it are 10+ times smaller than the ones built with Electron or Qt.”
HN commenter: “Oh hell yeah, I prefer native UI to gray boxes now. Where do I sign up?”
(I include myself in this satire as one of the HN commenters :D )
I found this https://sciter.com/developers/engine-architecture/ but it doesn't say if it's all written from scratch or using other libs.