Electron 2.0.0 beta(electronjs.org)
electronjs.org
Electron 2.0.0 beta
https://electronjs.org/releases#2.0.0-beta.1
434 comments
The problem I see with Electron (and probably one of the reasons HN hates it) is that it leverages the advances in chip making to work as well as an app from 20 years ago, but is multi platform.
It is a huge productivity boost for programmers at the expense of making computers slow. On my work computer I am used to run many apps, and with each Electron app added I feel it slowing down. (latest one to switch was Skype for me). What is the point of having such powerful computers when they feel like slugs crawling through a bog?
It is a huge productivity boost for programmers at the expense of making computers slow. On my work computer I am used to run many apps, and with each Electron app added I feel it slowing down. (latest one to switch was Skype for me). What is the point of having such powerful computers when they feel like slugs crawling through a bog?
> It is a huge productivity boost for programmers at the expense of making computers slow.
It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.
It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.
Users benefit from it too since the alternative to Electron often is not .NET or Qt but no app at all, especially on Linux.
I would rather run something in wine or run nothing at all than have to run an electron app. It's that bad.
Well, I'm a Linux user and I strongly disagree. Looks like opinions are indeed like a certain posterior orifice.
How bad is it to run Electron apps on Linux?
Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while but now I'm just leaving a Slack tab open in my browser. Its exactly the same functionality-wise.
Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.
Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.
Comments like this make me wonder what's going on exactly. Surely your browser tab should now be using ~2GB of Ram and ~10% CPU, since it's the browser, HTML and JS part of Electron that's causing all that?
To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.
To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.
My guess is that a lot of memory in the browser is shared.
Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.
Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.
That could certainly account for some of the memory usage. I'm still confused about why there would be a 10% cpu usage on one, and not on the browser version (especially if they are equivalent, or even share underlying code).
VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable.
[1] https://twitter.com/id_aa_carmack/status/695013979807047680?...
VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable.
[1] https://twitter.com/id_aa_carmack/status/695013979807047680?...
My theory on Slack's ridiculous CPU use is animated graphics. If some of those are on the screen the CPU use is at least 10%.
My theory is that their code is shit. It shouldn't be surprising given that their Chief Architect wrote a Medium post (Oct 2016) in which he cited concurrency as one of the primary benefits of PHP, and advocated for "curl'ing to localhost" to achieve parallelism.
On my laptop running Slack Linux 3.0.5 with 3 workspaces & several dozen channels, it idles at 0% CPU and ~550MB RAM (see screenshot [1]).
[1] https://i.imgur.com/juQbGW7.png
[1] https://i.imgur.com/juQbGW7.png
That's also roughly what I see on Windows for my Electron app [0]. 0% idle CPU and about 200MB of RAM. That's large but acceptable compared with other non-Electron apps running, like Sublime Text (170MB) or Thunderbird (320 MB).
[0] https://imgur.com/tMhEwtp.png
[0] https://imgur.com/tMhEwtp.png
You have some choice native apps - Sublime is Python, which is rather horrible with memory usage and Thunderbird essentially embeds a browser just like Electron apps.
Compare VSCode or Atom with Emacs or Gvim for something more native.
To pick some apps off my desktop right now:
- Emacs with a pile of extensions, 22 MB
- SpeedCrunch, 13 MB
- SumatraPDF, 19 MB
- MS Word, 101 MB
Compare VSCode or Atom with Emacs or Gvim for something more native.
To pick some apps off my desktop right now:
- Emacs with a pile of extensions, 22 MB
- SpeedCrunch, 13 MB
- SumatraPDF, 19 MB
- MS Word, 101 MB
Uhh sublime is written in C++ with it's own custom UI the toolkit iirc. It only uses python for scripting.
In my list of applications that are always active, Firefox and ConEmu are also over 500MB too. The exception is Total Commander (amazingly, still compatible with Windows 3.1), which is only 20MB but it's more the exception than the rule.
Haven't been using it since ~ 2 years. My data might be out of date.
As far as I'm concerned, I'd rather have no app at all (and use an alternative) than have an Electron app suck users away from the potential native alternative.
So don't use it and use the web version.
A potential native app is of no interest to me compared to an actual full featured Electron app.
In some alternate reality, reasonable resource usage is considered a feature.
Meanwhile, in our universe, it's somehow considered reasonable to expend nearly six gigawatts (= 51 TWh per year) on a number-guessing game that will totally revolutionize global finance some day.
Meanwhile, in our universe, it's somehow considered reasonable to expend nearly six gigawatts (= 51 TWh per year) on a number-guessing game that will totally revolutionize global finance some day.
Resource usage in this reality will only become reasonable when there will be a noticeable penalty involved in unreasonable usage, but I guess it boils down to what you define as reasonable: If a noticeable penalty is measured by the end user then - sorry, enough users just don't care, which enables this technology to continue to gain popularity. If there was a law that companies need to pay a percentage of the energy their applications use then you'd quickly see everybody moving not only to native apps, but to the most efficient native apps.
In the meantime, the invisible hand is doing it's thing. Time will tell what it's thing will look like.
In the meantime, the invisible hand is doing it's thing. Time will tell what it's thing will look like.
I think a brief look at the wiki page for 'Anthropocene' tells us exactly what the invisible hand is up to.
If the Electron app exists, there's a lot less incentive to write the native one.
See Slack. If Slack were still some plucky startup, I can understand it using Electron. But it's been around for a while now, and a more performant native application doesn't seem to be coming anytime soon.
Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated. The truth is, even for huge companies like Microsoft, the cost of doing a Linux-specific app is not worth it given the small user base, but with Electron they get this for free so they do it.
This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.
This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.
Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated.
And now Mac users get the same terrible Electron app. The problem is that companies are not just making Electron apps for Linux users. They are replacing native well-integrated Mac and Windows applications by Electron apps (Skype) or do not consider writing native apps (Slack).
So, we had nicely integrated applications with Automator workflows, consistent shortcuts, consistent look and consistent feel. And we are replacing them by things that do not fit into the platform at all. No thanks.
And now Mac users get the same terrible Electron app. The problem is that companies are not just making Electron apps for Linux users. They are replacing native well-integrated Mac and Windows applications by Electron apps (Skype) or do not consider writing native apps (Slack).
So, we had nicely integrated applications with Automator workflows, consistent shortcuts, consistent look and consistent feel. And we are replacing them by things that do not fit into the platform at all. No thanks.
Now I've heard it all - a company with a seven hundred billion dollar market cap can't afford it. Come on. They can absolutely afford to do native Windows / MacOS / Linux cross platform. They're lazy/don't want to.
> Now I've heard it all - a company with a seven hundred billion dollar market cap can't afford it. Come on. They can absolutely afford to do native Windows / MacOS / Linux cross platform. They're lazy/don't want to.
That’s a straw man argument. The parent said that Linux development might not be worth the cost. They didn’t say anything about the ability to pay.
That’s a straw man argument. The parent said that Linux development might not be worth the cost. They didn’t say anything about the ability to pay.
So we, linux users, actively promoting alternatives for Skype, to increase cost of ignoring us.
«Team, M$ killed Skype for linux, I cannot use it anymore, let switch to something else, like Slack.»
«Team, M$ killed Skype for linux, I cannot use it anymore, let switch to something else, like Slack.»
They can afford it. They can also afford to put a man on the moon, but it isn't necessarily financially reasonable for them to do so. Think of Microsoft as a collection of teams, each team can't afford to spend "Microsoft" money on its project unless its strategically important. The fact that we don't have native app probably indicates that Microsoft thinks Skype is past its peak of popularity. Thinking of many competing products I understand why.
They can do it but if it's not profitable, they won't. It's not being lazy, it's being smart in the capitalist sense.
I'm fine with that, just call it like it is. This is what Microsoft truly thinks of developing a 1st class open-source solution - not worth their time because it's not profitable enough. So they'll give you a second class solution with the assumption you'd rather have that then nothing.
Skype used to have a small, snappy and useful app for Linux. Now that MS converted it to Electron, I no longer use it. Qt makes multiplatform apps trivial. Even I, as a hobbyist free software developer, can provide binaries for Linux, Windows and Mac.
A lot of people, myself included, actually preferred the Linux version of Skype.
But to be honest, I'd rather have no GUI app on Mac/Linux at all than have it basically be a requirement to waste resources on Slack or whatever other crap and to have developer energy tied up in an editor as shitty as Atom.
But to be honest, I'd rather have no GUI app on Mac/Linux at all than have it basically be a requirement to waste resources on Slack or whatever other crap and to have developer energy tied up in an editor as shitty as Atom.
I'm working on a native client for Slack, Skype, Twitter etc.
It's only 90 KB (!)
https://eul.im
It's only 90 KB (!)
https://eul.im
How you do this? Probably some of us could guess, but maybe will help people that only know electron :)
Cocoa on macOS, WinAPI on Windows, GTK on Linux.
Is this the one that uses OpenGL or something to render everything (ie nonnative text controls etc)?
Not any more. Now it uses native controls.
Oh nice, I need to check this out then!
Nice joke. Repository is empty. Source archives are empty. Binary release for Linux: 404.
Is it 90kb installer or complete app? Also what are using to build the interface?
It's the complete app. Cocoa on macos, WinAPI on Windows, GTK on Linux.
Luckily Slack has the IRC and XMPP bridges. can't imagine any other protocols with a wealth of highly performant clients to choose from.
Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin.
I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.
Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin.
I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.
Sadly, Slack also happily breaks the protocols in their bridges, e.g. producing invalid IRC usernames. So even though our Slack has the bridge enabled, I can't login to it since it wants me to put a dot in my nick.
If the Electron app exists, often the alternative is no app at all.
If it's a .NET app on Linux, you just run Wine, and you're all set.
This is the weird elitist argument again. I've done my share of native UI development, and it's total pain compared to HTML/CSS/JS. The tools are crap, the compile cycles too long, the languages to restrictive, the APIs too ad-hoc, the layout engines too crappy, the technology support (eg. multimedia) lagging too many years etc etc.
The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.
The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.
> It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.
You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available.
But also if your logic were correct, we'd all still be writing C.
You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available.
But also if your logic were correct, we'd all still be writing C.
Yep, I totally get this.
There's a world in which Electron (or rather, "web views as apps") don't exist and Slack is native. Though perhaps it wouldn't have ever happened.
I feel like _many_ of the big apps simply wouldn't have existed in the old model. Native app development has become extremely niche, and each OS has its own quirks. And on the other side of the fence, stuff like Salesforce exist in the browser pretty well.
It's hard to get the causal arrows right on this. But I bet if React Native-style solutions can work well, people would be willing to put in the effort to use it. But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.
There's a world in which Electron (or rather, "web views as apps") don't exist and Slack is native. Though perhaps it wouldn't have ever happened.
I feel like _many_ of the big apps simply wouldn't have existed in the old model. Native app development has become extremely niche, and each OS has its own quirks. And on the other side of the fence, stuff like Salesforce exist in the browser pretty well.
It's hard to get the causal arrows right on this. But I bet if React Native-style solutions can work well, people would be willing to put in the effort to use it. But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.
> But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.
Is it really easier for developers, or do people learn web development first, so it's easier to use the same skills on the desktop than learn new ones?
If find it hard to believe React etc. are easier than .Net, for instance.
Is it really easier for developers, or do people learn web development first, so it's easier to use the same skills on the desktop than learn new ones?
If find it hard to believe React etc. are easier than .Net, for instance.
Reactive UI is easier to reason about I'd say. One thing I'd like to see is a native reactive UI framework that would be thought as such from the ground up. So far react on web is a whole bunch of hacks and react native also wraps classic UI elements.
UI debugging tools in the web are amazing. I can inspect the entire DOM, add code to test some new concepts, edit layout and get instant results.
To my knowledge, almost no native UI libraries have good support for CSS-style selectors. Being able to write out selection rules like "odd elements in this kind of list of elements" is extremely useful.
This is going to sound silly, but almost no native UI toolkit has a good "screenshots" section on its website. Meanwhile you go over to Bootstrap and you see stuff you actually recognize. This is important! It proves that you can actually make nice looking things.
Stuff like interface designers shipped by MSFT are pretty great though.
To my knowledge, almost no native UI libraries have good support for CSS-style selectors. Being able to write out selection rules like "odd elements in this kind of list of elements" is extremely useful.
This is going to sound silly, but almost no native UI toolkit has a good "screenshots" section on its website. Meanwhile you go over to Bootstrap and you see stuff you actually recognize. This is important! It proves that you can actually make nice looking things.
Stuff like interface designers shipped by MSFT are pretty great though.
UI tools for the web are amazaingly horrible. I can’t imagine anyone who thinks the chrome debugger is better than debugging .net in visual studios, while, if you want, XAML has most of the things that CSS has (but I do mostly canvas on both platforms).
Programming for the web makes me feel like I’m back in the 90s, no even Java/Swing was easier. I get making the sacrifice if it means I can run in the browser, but not otherwise.
Programming for the web makes me feel like I’m back in the 90s, no even Java/Swing was easier. I get making the sacrifice if it means I can run in the browser, but not otherwise.
I didn't do that much Swing, but the feedback loop for UI design in the web definitely felt a lot easier.
I have fond memories of debugging C# with Msft tools, but I also suffered a decent amount on the debugging cycle in C/C++. Being able to just patch in some new code without going through a whole compile/set up the environment again is very useful.
I can understand thinking that the foundation of the web is bad, therefore web development is bad. But I would take the chrome debugger experience over C/PHP/Java debugging experience most days of the week.
(That being said, I could simply be unaware of some debugging tools in that space that make things nicer)
I have fond memories of debugging C# with Msft tools, but I also suffered a decent amount on the debugging cycle in C/C++. Being able to just patch in some new code without going through a whole compile/set up the environment again is very useful.
I can understand thinking that the foundation of the web is bad, therefore web development is bad. But I would take the chrome debugger experience over C/PHP/Java debugging experience most days of the week.
(That being said, I could simply be unaware of some debugging tools in that space that make things nicer)
Java supported hot code replacement since 2000 or so, they actually had/have a fairly decent implementation (better than .net). But since they didn’t have a declarative DOM representation, it would be hard pressed to use it to add or remove elements. JavaFX fixed that, but that effort failed completely.
Doing UI in C/C++ sucks, but that was also true in the 90s.
Chrome is a horrible debugger from a UI design perspective. Debugging through VSCode is better, but I still miss simple things like auto toString displays. Surely the tools could get much better, that they haven’t is depressing.
Doing UI in C/C++ sucks, but that was also true in the 90s.
Chrome is a horrible debugger from a UI design perspective. Debugging through VSCode is better, but I still miss simple things like auto toString displays. Surely the tools could get much better, that they haven’t is depressing.
CSS is so crappy that I wouldn't be able to get anything done without the devtools. On the other hand with most native GUI libraries I've never had a problem to get the layout I wanted.
Every time I have to frig around with debugging a new-fangled JS SPA UI, it makes me want to hurt whoever is responsible for bringing the industry to this state. It was easier in VB6. It's miles easier to but something decent together, that actually works, in .net WinForms.
imo React and Css rocks hard, I don't like .NET because Visual Studio, and I love js, css, html because Visual Code.
Also metatags are what user interface design should have been since always, and there is nothing better for that than html and react. Yes sure, you have wpf and uwp (both using xaml), but they are no near as good.
I don't think it is a matter of being easier for developers. The common case simply is that something starts as a web app to get to a wider range of users, then they leverage Electron for more specialized features and/or convenience made possible due to more control and freedom on the desktop app.
I fear the long term problem is that "programmers" gets further and further mentally removed from the hardware that their code will ultimately run on.
There was already the problem of them using massively more powerful hardware than their customers, in particular in the consumer segment, but now more and more they seem to not even understand what a "computer" by the looks of it.
With "cloud services" they do not need to think about the servers sitting in racks doing the computing.
And with Electron, this kind of mental distance is making its way onto the desktop.
There was already the problem of them using massively more powerful hardware than their customers, in particular in the consumer segment, but now more and more they seem to not even understand what a "computer" by the looks of it.
With "cloud services" they do not need to think about the servers sitting in racks doing the computing.
And with Electron, this kind of mental distance is making its way onto the desktop.
Pretty sure your fear is the same that assembler programmers had when C programmers appear.
Pretty sure you don’t know what you’re talking about. Assembler programmers in the 50’s didn’t “fear” anything, much less C, which wasn’t even a spark in DMR’s eye, they just didn’t believe that a high-level language would be as efficient. Fortran with its 57 (?) optimization passes during compilation proved everyone wrong. But there was never “fear”. There is fear today though, and it’s very justified.
No, there is not fear in the industry. It is just people that refuse to learn js/html/css ecosystem that get outraged when see a electron app. Will you seriously think that a company like Skype didnt think and weight every option before doing their electron app? Sure enough they are not as efficient as native apps, and sure enough there are a lot of apps that thinks everyone have an i7 and 16 gb of ram, but the same problems had Java 20 years ago, pretty much with the same promises than Electron (Write Once, Run Anywhere), and it did pretty good.
"It is just people that refuse to learn js/html/css ecosystem"
Can't I just as easily say that the JS/HTML/CSS people are the ones refusing to learn a new ecosystem?
Can't I just as easily say that the JS/HTML/CSS people are the ones refusing to learn a new ecosystem?
> It is just people that refuse to learn js/html/css ecosystem that get outraged when see a electron app.
I was once really into frontend web dev, and learned JS/HTML/CSS. Then I realized it mostly sucked, and went to school for EE. Now I get more upset than anyone I know about Electron apps.
It only takes one counter example.
I was once really into frontend web dev, and learned JS/HTML/CSS. Then I realized it mostly sucked, and went to school for EE. Now I get more upset than anyone I know about Electron apps.
It only takes one counter example.
Java's run as desktop/web application platform, is nowhere good. It thrived on server, where WORA had limited appeal.
As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux.
I also don't notice my machine slowing down with Electron apps.
I also don't notice my machine slowing down with Electron apps.
> As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux.
That's not true. There are native cross-platform GUI toolkits, such as Qt. There's just as much reason for a Qt app to run on Linux as an Electron app.
That's not true. There are native cross-platform GUI toolkits, such as Qt. There's just as much reason for a Qt app to run on Linux as an Electron app.
I think the guy you're replying to's point is that Qt versions of the apps he uses don't exist - the Electron ones do.
The alternative to many Electron apps isn't a native app in another framework, it would simply be no app (on linux).
The alternative to many Electron apps isn't a native app in another framework, it would simply be no app (on linux).
Usually the alternative to many electron apps is the web version which lacks 5% of the features but is 10 times more efficient.
Native and Electron apps have two advantages over web though. Fist one is, that they do have access to the file system. This makes a whole range of applications (like Git Kraken) possible. The other is that an application has an icon in the taskbar/dock. When somebody pings me on slack I know where to go to read it. When somebody calls me in hangouts, I have to go fishing for the tab or window with the site open.
Yup.
Is there not one engineer on this whole planet with the skill and motivation to make a cross-platform typescript+GUI thing that is efficient from the ground up? I'm often baffled by the seemingly obvious gaps that exist in this profession.
Noob question. What makes electron apps slow? The electron framework or the web apps that it wraps?
Electron apps are basically a Chrome window with a webpage loaded. This means that, for example, they use HTML to display the UI. HTML/CSS is complex and very dynamic, this makes it resource intensive to parse and load. Then, the whole application is written in JavaScript which is a language that is "far from the metal" (although this is getting better due to a massive investment of web browser developers).
There is also a more hidden problem, which is that Electron app developers often come from a web background, which is a field with little concern for proper resource management and performance. If a webpage has a memory leak, just refresh it. If it takes too much memory, some other inactive tabs will get killed and be refreshed. VS Code is a good example of an Electron application made by people who are concerned by performance. However, developing a performant application using Electron seems to be harder than actually doing it in another language/framework.
There is also a more hidden problem, which is that Electron app developers often come from a web background, which is a field with little concern for proper resource management and performance. If a webpage has a memory leak, just refresh it. If it takes too much memory, some other inactive tabs will get killed and be refreshed. VS Code is a good example of an Electron application made by people who are concerned by performance. However, developing a performant application using Electron seems to be harder than actually doing it in another language/framework.
Well, you have a choice, so I don't understand the hate.
Okay, maybe you have to use Slack or Discord at work.
Life and engineering are about trade-offs. That people use Electron apps despite the downsides just shows that these apps are delivering value to the world. Value that might not have existed had Electron not made it that much easier for people to get into desktop software.
The complaining on HN reminds me of how my users get mad at me for not spending more of my free time developing the forum software. Like I'm trying to spite them. As if I just need to pull some knobs and levels.
What's happening is that software is getting more and more accessible to people. Beginners are making games in Unity and iOS. Cultural channels into tech like Twitch and cryptocurrencies have been opening up. I watch my cousins' children open up the browser's console to delete annoying DOM nodes.
What I suspect is that more and more people are getting into tech, so there are more and more people for you to disagree with about trade-offs.
Okay, maybe you have to use Slack or Discord at work.
Life and engineering are about trade-offs. That people use Electron apps despite the downsides just shows that these apps are delivering value to the world. Value that might not have existed had Electron not made it that much easier for people to get into desktop software.
The complaining on HN reminds me of how my users get mad at me for not spending more of my free time developing the forum software. Like I'm trying to spite them. As if I just need to pull some knobs and levels.
What's happening is that software is getting more and more accessible to people. Beginners are making games in Unity and iOS. Cultural channels into tech like Twitch and cryptocurrencies have been opening up. I watch my cousins' children open up the browser's console to delete annoying DOM nodes.
What I suspect is that more and more people are getting into tech, so there are more and more people for you to disagree with about trade-offs.
>Life and engineering are about trade-offs.
Electron is not a sensible trade off. It is not necessary to accept that level of inefficiency to get that productivity boost. It only has happened that way because our industry has been so web focused for so many years, that very little brain power has gone into cross platform desktop apps for a long time.
And we end up with a ridiculous Frankenstein solution that is fractally wrong. But it is "Easy" because 90% of programmers are used to HTML,CSS,Javascript and so they can suddenly make 'desktop' apps now.
And no, we don't have a choice when almost every desktop application being made now is being made in electron. Its just awful, and you should quit dismissing the people telling you how much they hate the situation, its real.
And of course those of us that hate it should be aiming to help fix the situation, but of course it is difficult, since anything you propose that is not HTML/CSS/Javascript seems alien to so many modern programmers that they reject it out of hand.
Electron is not a sensible trade off. It is not necessary to accept that level of inefficiency to get that productivity boost. It only has happened that way because our industry has been so web focused for so many years, that very little brain power has gone into cross platform desktop apps for a long time.
And we end up with a ridiculous Frankenstein solution that is fractally wrong. But it is "Easy" because 90% of programmers are used to HTML,CSS,Javascript and so they can suddenly make 'desktop' apps now.
And no, we don't have a choice when almost every desktop application being made now is being made in electron. Its just awful, and you should quit dismissing the people telling you how much they hate the situation, its real.
And of course those of us that hate it should be aiming to help fix the situation, but of course it is difficult, since anything you propose that is not HTML/CSS/Javascript seems alien to so many modern programmers that they reject it out of hand.
Claiming that everyone is worse off because electron apps consume more resources then they would had they been written in a "native" language is only true if the only value you get from an app is low resource consumption.
(I use native in quotation marks because we can probably not even agree on what that is.)
This attitude seems to be common here but everyone hating on electron seems to ignore any positive aspects of it and only focuses on the fact that it is slower and/or more resource intensive then had it been written in <native-language-of-choice>.
You can dislike Electron on a technical or principal level, that's fair, but until there is an alternative that would be considered better by most things will simply not change.
Until then, repeating the negatives over and over again only serves to de-value the efforts of those actually producing and shipping code and the only possible outcome is another "tabs vs spaces" holy war.
(I use native in quotation marks because we can probably not even agree on what that is.)
This attitude seems to be common here but everyone hating on electron seems to ignore any positive aspects of it and only focuses on the fact that it is slower and/or more resource intensive then had it been written in <native-language-of-choice>.
You can dislike Electron on a technical or principal level, that's fair, but until there is an alternative that would be considered better by most things will simply not change.
Until then, repeating the negatives over and over again only serves to de-value the efforts of those actually producing and shipping code and the only possible outcome is another "tabs vs spaces" holy war.
As an industry forum for engineers and people developing products, this is a great place to share positive and negative opinions about technology and how it impacts product quality. That’s good conversation.
Generic reactions to negativity, saying there are two sides to every coin, do not really contribute to the discussion, IMO, so I disagree.
Generic reactions to negativity, saying there are two sides to every coin, do not really contribute to the discussion, IMO, so I disagree.
> It only has happened that way because our industry has been so web focused for so many years, that very little brain power has gone into cross platform desktop apps for a long time.
While there is an ongoing trend to move towards web apps, I think you are mixing up the causality here a little bit. The main reason why developers are increasingly choosing to move towards web technologies for UI is the sheer pain of doing any kind of cross-platform development on the desktop.
Most of the nice desktop development frameworks (like the ones in C# or Swift) are not cross platform. Meanwhile, we have a decent cross-platform UI framework in Qt, but this requires dealing with C++, which doesn’t even have a good package manager behind it. You could also use GTK+, wxWidgets, FLTK, but these don’t provide a good look and feel and non-Linux OSes.
Basically if you want to easy-to-use cross-platform desktop UI development, your choices boil down to Electron, and maybe pyQt.
Desktop developers have years to make this a better situation by perhaps promoting cross-platform UI standards or building better tooling, but nothing good has really gained much traction, so more developers are justifiably moving to Electron for now.
While there is an ongoing trend to move towards web apps, I think you are mixing up the causality here a little bit. The main reason why developers are increasingly choosing to move towards web technologies for UI is the sheer pain of doing any kind of cross-platform development on the desktop.
Most of the nice desktop development frameworks (like the ones in C# or Swift) are not cross platform. Meanwhile, we have a decent cross-platform UI framework in Qt, but this requires dealing with C++, which doesn’t even have a good package manager behind it. You could also use GTK+, wxWidgets, FLTK, but these don’t provide a good look and feel and non-Linux OSes.
Basically if you want to easy-to-use cross-platform desktop UI development, your choices boil down to Electron, and maybe pyQt.
Desktop developers have years to make this a better situation by perhaps promoting cross-platform UI standards or building better tooling, but nothing good has really gained much traction, so more developers are justifiably moving to Electron for now.
Java FX is a decent solution as well. It's just not cool.
>You could also use GTK+, wxWidgets, FLTK, but these don’t provide a good look and feel and non-Linux OSes.
Wx is using native widgets on every platform.
Wx is using native widgets on every platform.
The reason the causality sounds backwards is the GP is talking about secondary effects of what you are talking about — the other half of a vicious cycle.
We are already a decade into neglecting native app technologies in favor of web app technologies, because web apps were much easier to write and deliver than cross-platform native apps (and largely still are). It’s to the point where even big companies with lots of resources are hiring web programmers and web designers to build their UIs.
It’s interesting to me that mobile changes the trade-offs. The quality gulf between web and native apps is greater. The web sucks more on mobile, and expectations for native apps (animations, touch, etc) are higher. Mobile OSes also make it much easier for users to install and manage native apps than it is on desktop (because of the app store, no custom installers, no users locked out of installing apps by their employers as far as I know). I’m excited about React Native for addressing the cross-platform part.
We’ve learned since Java that even if you don’t have “write once, run anywhere,” you can still have “learn once, write anywhere,” a la React. Also, we expect apps to come with their own systems of UI widgets these days, not necessarily “native look and feel.” It really changes the game.
We are already a decade into neglecting native app technologies in favor of web app technologies, because web apps were much easier to write and deliver than cross-platform native apps (and largely still are). It’s to the point where even big companies with lots of resources are hiring web programmers and web designers to build their UIs.
It’s interesting to me that mobile changes the trade-offs. The quality gulf between web and native apps is greater. The web sucks more on mobile, and expectations for native apps (animations, touch, etc) are higher. Mobile OSes also make it much easier for users to install and manage native apps than it is on desktop (because of the app store, no custom installers, no users locked out of installing apps by their employers as far as I know). I’m excited about React Native for addressing the cross-platform part.
We’ve learned since Java that even if you don’t have “write once, run anywhere,” you can still have “learn once, write anywhere,” a la React. Also, we expect apps to come with their own systems of UI widgets these days, not necessarily “native look and feel.” It really changes the game.
It's a sensible trade off when you're a single person needing to deliver a web, Windows, and MacOS application.
You can criticize something even if it does not directly affect you though. For example, I can live with Slack & Skype eating half of my ram but I really wish I would not have to.
I really like Git Kraken, in theory, but if I imagine it as a native app it would be so much better.
I see the appeal of Electron, and to be fair we also use it at work. However our application is destined to be running on a dedicated hardware which runs it and nothing else.
Ultimately I'd like to see products like Slack starting with an Electron app and when the means permit it migrate to a native application. Not the other way around.
I really like Git Kraken, in theory, but if I imagine it as a native app it would be so much better.
I see the appeal of Electron, and to be fair we also use it at work. However our application is destined to be running on a dedicated hardware which runs it and nothing else.
Ultimately I'd like to see products like Slack starting with an Electron app and when the means permit it migrate to a native application. Not the other way around.
If you consider that the browser is where most Electron app users actually begin using the app, you can only expect Electron to be replaced by some native app that runs the same code as the browser. This is the killer feature of Electron.
Having a web app + native app means a huge leap in cost.
Having no web app + native app means a huge loss in user reach.
The only viable replacement would be something like Electron but with a stripped down browser fit to purpose instead of the huge surface-area of Chrome.
Having a web app + native app means a huge leap in cost.
Having no web app + native app means a huge loss in user reach.
The only viable replacement would be something like Electron but with a stripped down browser fit to purpose instead of the huge surface-area of Chrome.
The replacement is react native. Same web developer friendly environment with practically native performance. And yes, it’s available for desktop as well as mobile.
Just curious can you give a link to desktop app made with React Native or an example / tutorial for this?
I see a few attempts -
https://github.com/Microsoft/react-native-windows
and http://reactdesktop.js.org/
The Windows one is from Microsoft, but is single platform. Nothing officially supported by react devs as far as I can tell.
https://github.com/Microsoft/react-native-windows
and http://reactdesktop.js.org/
The Windows one is from Microsoft, but is single platform. Nothing officially supported by react devs as far as I can tell.
I see. Thanks.
turbo pascal ide and compiler are 600KB
at one point I don't care about multilayer super cute guis
btw turbo pascal had shadowed windows in TUI
at one point I don't care about multilayer super cute guis
btw turbo pascal had shadowed windows in TUI
And don’t forget Free Pascal and Lazarus. I opened it up the other day on a whim and made a hello world app.
Everything about the thing felt 1990s... in the best way. The IDE was clearly designed not for initial discovery by a novice, but for someone who they ultimately expect to become proficient and thus able to capitalize on the expert-friendly UI.
The reasulting binary felt like the 1990s too: A single small executable with instant load times :-)
Everything about the thing felt 1990s... in the best way. The IDE was clearly designed not for initial discovery by a novice, but for someone who they ultimately expect to become proficient and thus able to capitalize on the expert-friendly UI.
The reasulting binary felt like the 1990s too: A single small executable with instant load times :-)
The sick thing it's a smaller download to write your app in Turbo Pascal and distribute a virtual machine running DOS than an electron app.
If you want to make Electron obsolete, make a cross platform UI toolkit that mixes UI and document-style content as good as HTML/CSS does.
End user expectations are for complex layouts, flexible typography, rich media embedding, animated interactions, and so on. I've yet to see a QT app come close to what e.g. Slack has managed to shoehorn in.
It'd be great if we could get desktop level robustness out of it too, instead of being limited to scrolling three or four screens up before it has to start paging out content.
Web UI is bad in many ways, but many desktop adherents seem willfully oblivious about why there is such a desire for this. The only native OS that has evolved to compete is MacOS, with its multi touch driven interactions genuinely making most web stuff feel like the janky lowest common denominator that it is.
End user expectations are for complex layouts, flexible typography, rich media embedding, animated interactions, and so on. I've yet to see a QT app come close to what e.g. Slack has managed to shoehorn in.
It'd be great if we could get desktop level robustness out of it too, instead of being limited to scrolling three or four screens up before it has to start paging out content.
Web UI is bad in many ways, but many desktop adherents seem willfully oblivious about why there is such a desire for this. The only native OS that has evolved to compete is MacOS, with its multi touch driven interactions genuinely making most web stuff feel like the janky lowest common denominator that it is.
What you want is all available in Qt via QtQuick, where you can use QML to define you interface declaratively (in a better way than html+css) and JS for logic with the option of dropping down to C++ or another language with bindings.
If you think that, you don't understand the nature of what is being done with HTML nowadays. It's not about declarative markup, it's about efficient updating of a UI whose shape is completely decoupled from the shape of the state it is representing.
I'm a professional web developer, I'd like to think I know what I'm doing. And I believe you contradicted yourself, leveraging a Virtual DOM to update the DOM (which has an imperative API) from the changes that exist in two sets of data —both products of (an ideally) pure transformation from high-level data— is very much declarative programming.
Meanwhile QML provides you with the same kind of programming paradigm except that you do not have a DOM, you have the QtQuick Scene Graph which calculates how to render your new state in the most efficient way; and, worth mentioning, in a much more efficient way than a standard browser stack would be able to under regular circumstances.
Meanwhile QML provides you with the same kind of programming paradigm except that you do not have a DOM, you have the QtQuick Scene Graph which calculates how to render your new state in the most efficient way; and, worth mentioning, in a much more efficient way than a standard browser stack would be able to under regular circumstances.
In my experience (with apps like spotify, the signal client and a couple of others) it's only marginally better than running a Windows app through wine as far as the user experience is concerned. It doesn't integrate very well, it uses a shameful amount of RAM etc...
I'd much prefer if these companies used open APIs (some do) and let the FLOSS crowd make clients if they cared for them. I've replaced the spotify application with librespot lately and it works very well, although it lacks a UI so I have to use my phone as a remote. I'm also currently using the signal electron client which works okay but uses an order of magnitude more RAM after a few minutes of runtime than my irssi that's been running for months. It also doesn't have better usability if you don't like clicking everywhere and prefer keyboard control.
I don't hate electron, it's just "okay". It's a symptom of the webification of the world as web technologies make a foray into the desktop and server space. I think a framework like Qt is objectively superior, both from a developer and user perspective but I'm sure these days it's probably easier and cheaper to find webdevs than Qt devs and it's all that matters.
I'd much prefer if these companies used open APIs (some do) and let the FLOSS crowd make clients if they cared for them. I've replaced the spotify application with librespot lately and it works very well, although it lacks a UI so I have to use my phone as a remote. I'm also currently using the signal electron client which works okay but uses an order of magnitude more RAM after a few minutes of runtime than my irssi that's been running for months. It also doesn't have better usability if you don't like clicking everywhere and prefer keyboard control.
I don't hate electron, it's just "okay". It's a symptom of the webification of the world as web technologies make a foray into the desktop and server space. I think a framework like Qt is objectively superior, both from a developer and user perspective but I'm sure these days it's probably easier and cheaper to find webdevs than Qt devs and it's all that matters.
I think making clients died when Twitter shuttered their APIs; companies want to keep control over how their users work with their stuff.
I've looked into alternative Slack clients for example which seem to be doable, but the only ones I saw were dead and/or looked terrible.
I've looked into alternative Slack clients for example which seem to be doable, but the only ones I saw were dead and/or looked terrible.
This one seems nice enough https://eul.im/
I saw it wasn't open source, they say it's like the subline development model and to click here[1] for more details. Well..
1. https://eul.im/development
1. https://eul.im/development
> let the FLOSS crowd make clients if they cared for them.
I've yet to see FLOSS crowd come up with a remotely useful client for anything. Event in the days of much simpler APIs and apps like IRC FOSS apps were universally meh.
I've yet to see FLOSS crowd come up with a remotely useful client for anything. Event in the days of much simpler APIs and apps like IRC FOSS apps were universally meh.
I'll take weechat/irssi over the signal client every second of every minute of every day.
Super small footprint, I can do everything with the keyboard, I can script it, I can run it on a server in SSH, I can customize it any way I want.
Meanwhile on my large screen I can barely see 10 messages in the backlog of the signal desktop client because it feels the need to emulate an SMS UI (you can even select if you want it to emulate the Android or iOS UI, how cool is that?), I still haven't figured out if you can create groups in the desktop interface (given the very small number of options available I don't see how I could miss it, maybe it's simply not possible). The input box has english spell checking enabled by default which is pretty distracting when I'm typing an other language since everything gets underlined, I haven't found a way to disable it or change the language.
The other day I had to use the Discord webapp for something, what a joke. On my pre-quantum Firefox it was laggy as hell, there was a noticeable delay sometimes while I was typing text. Maybe you'll blame Firefox for being too slow but we're talking about an actual text chat here.
It does look better than a terminal window though, I grant you that. Maybe I should print it and frame it somewhere in my office.
Super small footprint, I can do everything with the keyboard, I can script it, I can run it on a server in SSH, I can customize it any way I want.
Meanwhile on my large screen I can barely see 10 messages in the backlog of the signal desktop client because it feels the need to emulate an SMS UI (you can even select if you want it to emulate the Android or iOS UI, how cool is that?), I still haven't figured out if you can create groups in the desktop interface (given the very small number of options available I don't see how I could miss it, maybe it's simply not possible). The input box has english spell checking enabled by default which is pretty distracting when I'm typing an other language since everything gets underlined, I haven't found a way to disable it or change the language.
The other day I had to use the Discord webapp for something, what a joke. On my pre-quantum Firefox it was laggy as hell, there was a noticeable delay sometimes while I was typing text. Maybe you'll blame Firefox for being too slow but we're talking about an actual text chat here.
It does look better than a terminal window though, I grant you that. Maybe I should print it and frame it somewhere in my office.
Interestingly I have the exact opposite experience, especially since the rise of github. High quality floss software is everywhere, and closed proprietary crap is suffering if only because without github they still rely on forums or email for users to report bugs or feature requests.
9 times out of 10, a github project fixes my bug report very quickly.
Half the time I'll send an email to a closed source project and never hear back about it.
FOSS is also doing well in an era where proprietary clients mean crappy electron clients. That's a low bar to beat.
9 times out of 10, a github project fixes my bug report very quickly.
Half the time I'll send an email to a closed source project and never hear back about it.
FOSS is also doing well in an era where proprietary clients mean crappy electron clients. That's a low bar to beat.
Spotify actually uses the Chromium Embedded Framework, but it's pretty bad nonetheless.
I'm glad to see this at the top. I do wish though that more Electron threads on here and r/programming would talk about the actual developments happening instead of the constant memory usage complaints back and forth.
It's funny, I try Vim and I like it. HN convinces me to try Emacs and I like it. I'm not supposed to like Electron apps but I try VS Code on my 4+ year old chromebook with 2gb of ram and it runs just fine and I like it. Same goes with Slack. Seems pretty damn good to me. This all repeats itself when it comes to programming language debates too.
Is something wrong with me if I'm interested in vim, emacs, vs code, python, js, elm, go(!), haskell, rust, and racket? Am I just too inexperienced? Will I develop to have only one true religion or is there just something HN and r/programming brings out in people for these constant "one true correct way" debates.
It's funny, I try Vim and I like it. HN convinces me to try Emacs and I like it. I'm not supposed to like Electron apps but I try VS Code on my 4+ year old chromebook with 2gb of ram and it runs just fine and I like it. Same goes with Slack. Seems pretty damn good to me. This all repeats itself when it comes to programming language debates too.
Is something wrong with me if I'm interested in vim, emacs, vs code, python, js, elm, go(!), haskell, rust, and racket? Am I just too inexperienced? Will I develop to have only one true religion or is there just something HN and r/programming brings out in people for these constant "one true correct way" debates.
> I try VS Code on my 4+ year old chromebook with 2gb of ram and it runs just fine
It probably does, if it's the only thing you're running. I know developers think their app is the best thing in the world but they have to realise it's not the only thing running on my machine. RAM is a scarce resource on my dev box.
It probably does, if it's the only thing you're running. I know developers think their app is the best thing in the world but they have to realise it's not the only thing running on my machine. RAM is a scarce resource on my dev box.
No, this is good. Don't get caught up in the Vim-Emacs wars or any of the language wars - they are mostly a waste of time. Recognize that languages have "areas of expertise," but these often overlap.
I get mad about Electron because it seems that we should be able to solve the problem without running a web browser for every app. It's unfortunate that Electron is so much more appealing than more efficient alternatives. I wish we could end this trend of software efficiency declining to compensate for hardware improvements.
I get mad about Electron because it seems that we should be able to solve the problem without running a web browser for every app. It's unfortunate that Electron is so much more appealing than more efficient alternatives. I wish we could end this trend of software efficiency declining to compensate for hardware improvements.
> I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem
Really ? Because rendering HTML/CSS is an extremely complex way to render a UI, and it was clearly never designed for it. HTML was intended to add markup to documents, not build user interfaces. It lacks the most basic layout primitives you want to use in a UI and a lot of behaviour is either not well defined or not well understood, mainly because it's unreasonably complex. It's easily the most complicated way to build a UI we have right now, which is why we need all those stupid frameworks built on top of it to make it somewhat usable.
HTML is and has alway been a huge mistake for building UI's.
Really ? Because rendering HTML/CSS is an extremely complex way to render a UI, and it was clearly never designed for it. HTML was intended to add markup to documents, not build user interfaces. It lacks the most basic layout primitives you want to use in a UI and a lot of behaviour is either not well defined or not well understood, mainly because it's unreasonably complex. It's easily the most complicated way to build a UI we have right now, which is why we need all those stupid frameworks built on top of it to make it somewhat usable.
HTML is and has alway been a huge mistake for building UI's.
It's easy to learn, easy to make and easy to distribute, (at least in the beginning) which is why a disproportionate number of new developers start with web technologies.
> It's easy to learn, easy to make
I disagree completely. It's easy to get a 'hello world' type thing working in HTML, sure, but it's very hard to make something behave like you want. Traditional UI toolkits are much simpler and easier to understand.
I disagree completely. It's easy to get a 'hello world' type thing working in HTML, sure, but it's very hard to make something behave like you want. Traditional UI toolkits are much simpler and easier to understand.
Exhibit A: CSS centering.
Exhibit B: The so-called "Holy Grail" layout. [^1]
[^1]: https://en.wikipedia.org/wiki/Holy_grail_(web_design)
[^1]: https://en.wikipedia.org/wiki/Holy_grail_(web_design)
This is really out of date. Even IE11 supports flexbox. It is trivial to center things both vertically and horizontally, and easy to make a “Holy Grail” layout.
If you don't need to support IE11 you can use CSS Grid and do the entire layout in one or two CSS properties.
If you don't need to support IE11 you can use CSS Grid and do the entire layout in one or two CSS properties.
> one of the best things to happen on desktop, especially on linux desktop ironically
Not by a long shot. It's one of the worst things to happen on the desktop, because people who would have built a proper desktop application just wrap their web app in Electron instead.
It's particularly bad for the Linux desktop, where people are used to small binaries that use the system-wide Qt or GTK so they load fast, and use little RAM.
Not by a long shot. It's one of the worst things to happen on the desktop, because people who would have built a proper desktop application just wrap their web app in Electron instead.
It's particularly bad for the Linux desktop, where people are used to small binaries that use the system-wide Qt or GTK so they load fast, and use little RAM.
Most companies would never build a Linux app.
One notable example is Skype: their Linux client sucked so much it was unusable until their Electron version made the Linux version just as good and modern-looking as the rest.
One notable example is Skype: their Linux client sucked so much it was unusable until their Electron version made the Linux version just as good and modern-looking as the rest.
I think the idea is that most developers would not make a proper desktop app, and without electron there would just be not app at all. But I think that Electron is a short term good which will cause a lot of long term "bad".
> I think the idea is that most developers would not make a proper desktop app, and without electron there would just be not app at all.
Precisely, people will just use something else. The proliferation of Electron apps splits the user base, so there's less incentive to develop a proper desktop application.
Precisely, people will just use something else. The proliferation of Electron apps splits the user base, so there's less incentive to develop a proper desktop application.
When you look at the Linux desktop software stack, I can't condemn anyone for choosing js+html+css over what's available.
There's no consistency between the dozen "toolkits", each one with its own way of doing things and a lack of interoperability. If you ever had to work with X11's concepts of drag'n'drop, windows, input etc. you probably know what I'm talking about. Dozens of toolkits, few of them talk to each other. It's a mess. Electron just works.
People who would have built a proper desktop application simply don't because the tooling, the environments, the standards (and lack thereof) are awful.
The whole concept of "toolkits" is what makes the situation a complete mess.
There's no consistency between the dozen "toolkits", each one with its own way of doing things and a lack of interoperability. If you ever had to work with X11's concepts of drag'n'drop, windows, input etc. you probably know what I'm talking about. Dozens of toolkits, few of them talk to each other. It's a mess. Electron just works.
People who would have built a proper desktop application simply don't because the tooling, the environments, the standards (and lack thereof) are awful.
The whole concept of "toolkits" is what makes the situation a complete mess.
Admittedly (as a Plasma user) I'm a little biased here, but the answer is to just use Qt (Widgets) and move on. QGnomePlatform and QGTKStyle means Qt works just fine in a GTK-based desktop, while the reverse just isn't true.
Unless you have a good reason (in which case, you'll know), you can just ignore everything other that Qt and GTK.
Unless you have a good reason (in which case, you'll know), you can just ignore everything other that Qt and GTK.
It's not just about development, there are numerous applications built in different toolkits which many of us use everyday. Some of these apps are closed source, so suggesting a rewrite in Qt is out of question.
Don't get me wrong, it would be awesome if we could compromise on any given toolkit, but do you honestly see any of them waving the white flag?
Meanwhile, on Windows for example, there's a standard way to write GUI apps, standardized, well-known and consistent APIs to deal with GDI's toolkit etc. It's awful to write GTK apps just as it's painful to write in pure WINAPI GDI, but GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days.
Then comes the community: we have 20+ years of GUI programming happening on Windows, most people simply stick to GDI + self-made custom controls. The outcome is a huge knowledge base that helps get anything and everything done on Windows. Here in the UNIX world over the same time period the GUI developers are spread among different toolkits, so we have many "ok" people in a dozen toolkits and few experts on each one.
Don't get me wrong, it would be awesome if we could compromise on any given toolkit, but do you honestly see any of them waving the white flag?
Meanwhile, on Windows for example, there's a standard way to write GUI apps, standardized, well-known and consistent APIs to deal with GDI's toolkit etc. It's awful to write GTK apps just as it's painful to write in pure WINAPI GDI, but GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days.
Then comes the community: we have 20+ years of GUI programming happening on Windows, most people simply stick to GDI + self-made custom controls. The outcome is a huge knowledge base that helps get anything and everything done on Windows. Here in the UNIX world over the same time period the GUI developers are spread among different toolkits, so we have many "ok" people in a dozen toolkits and few experts on each one.
> Some of these apps are closed source, so suggesting a rewrite in Qt is out of question.
Qt is LGPL. So long as you dynamically link to Qt, it doesn't matter what license your app is under. If you don't dynamically link, you lose the integration benefits anyway, so there's no downside, really (Qt is backwards compatible within each major release, so just build against the earliest version of Qt 5 your app works with).
> GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days
History means we have two defaults on Linux: Qt and GTK. Qt integrates well in a GTK desktop though, so you can just use Qt.
Qt is LGPL. So long as you dynamically link to Qt, it doesn't matter what license your app is under. If you don't dynamically link, you lose the integration benefits anyway, so there's no downside, really (Qt is backwards compatible within each major release, so just build against the earliest version of Qt 5 your app works with).
> GDI has the advantage of being the default, so that "native look" is consistent across most applications since the 3.1 days
History means we have two defaults on Linux: Qt and GTK. Qt integrates well in a GTK desktop though, so you can just use Qt.
> Don't get me wrong, it would be awesome if we could compromise on any given toolkit, but do you honestly see any of them waving the white flag?
No doubt it will be years before everything moves over, but at this point Qt is the clear winner: it's always looked better, its licensing issues are now solved, it's the only option that has remotely decent bindings for a remotely decent language. A month or so ago there was a new release of Wx and the comments here were universally "that still exists?"; GTK will go the same way.
There are other options, there are people who really like those options, but Qt has the momentum and has the knowledge base. Just use Qt and you'll be fine, or at least you'll be no less fine that you were with GDI on windows.
No doubt it will be years before everything moves over, but at this point Qt is the clear winner: it's always looked better, its licensing issues are now solved, it's the only option that has remotely decent bindings for a remotely decent language. A month or so ago there was a new release of Wx and the comments here were universally "that still exists?"; GTK will go the same way.
There are other options, there are people who really like those options, but Qt has the momentum and has the knowledge base. Just use Qt and you'll be fine, or at least you'll be no less fine that you were with GDI on windows.
Have you built a desktop application on Linux?
What are these dozens of toolkits you are talking about?
Just use Qt.. or GTK. They work and aren't difficult to use. Qt stuff works nicely on windows as well.
Just use Qt.. or GTK. They work and aren't difficult to use. Qt stuff works nicely on windows as well.
Sure I can use Qt. And deal with C++ and the MOC. Well, by C++ I mean whatever dialect of it Qt chose to support to be backwards compatible with apps from 1995, certainly not C++14 or even C++11 last time I looked and oh yeah - have to use their smart pointers and string/container classes, and learn yet another build system, Qmake was it? And use their “interface builder” and cheap looking Visual Studio knock-off?
Orrrrrrrr - JavaScript/Typescript with the amazing Chrome debugger and get my work done in half the time?
You’re really really not selling Qt at all, least of all to people who might have NodeJS (lots of those) experience and want to get something done quickly.
Yes I’m also aware of Qt’s 200 language bindings and funnily enough, a lot of shitty, slow, crash Qt apps on my Ubuntu desktop are Python with the PyQT bindings. Because even those guys want to get their job done quick.
So, basically - Electron seems like a really nice default choice.
Orrrrrrrr - JavaScript/Typescript with the amazing Chrome debugger and get my work done in half the time?
You’re really really not selling Qt at all, least of all to people who might have NodeJS (lots of those) experience and want to get something done quickly.
Yes I’m also aware of Qt’s 200 language bindings and funnily enough, a lot of shitty, slow, crash Qt apps on my Ubuntu desktop are Python with the PyQT bindings. Because even those guys want to get their job done quick.
So, basically - Electron seems like a really nice default choice.
Moc integrates beautifully with cmake and "all" other build tools. There is no need for the interface builder (though I hear people seem to like it, barely tried it myself).
No need to use their smart pointers either, I certainly never have. Never saw any reason to since C++11.
No issue at all mixing with C++11+.
No need to use their smart pointers either, I certainly never have. Never saw any reason to since C++11.
No issue at all mixing with C++11+.
I hate Javascript and web tech and he didn't sell Qt to me either.
> Yes I’m also aware of Qt’s 200 language bindings and funnily enough, a lot of shitty, slow, crash Qt apps on my Ubuntu desktop are Python with the PyQT bindings.
So much like Electron then?
Use Qt, use Python, and get on with your life. Or use Electron if you prefer, that's fine too. But don't make out like it's the only reasonable option and everything else is too confusing. If you ask 10 developers the right way to do a simple GUI application on Linux, 9 of them will tell you: do it with Qt and Python.
So much like Electron then?
Use Qt, use Python, and get on with your life. Or use Electron if you prefer, that's fine too. But don't make out like it's the only reasonable option and everything else is too confusing. If you ask 10 developers the right way to do a simple GUI application on Linux, 9 of them will tell you: do it with Qt and Python.
Yes, I have. Here's some to name a few: GTK, Qt, wx, Fox, fltk...
Yes, I agree, Qt just works. My initial point was and still is about interoperability. They don't all speak well with each other and there are many good, useful applications in toolkits other than Qt or GTK.
Yes, I agree, Qt just works. My initial point was and still is about interoperability. They don't all speak well with each other and there are many good, useful applications in toolkits other than Qt or GTK.
That's hardly a point, since even some of those toolkits you mentioned are also available on Windows and macOS.
We're talking about proper toolkits vs. Electron here. Good luck making Electron look native, yet alone "talk" with anything :P
We're talking about proper toolkits vs. Electron here. Good luck making Electron look native, yet alone "talk" with anything :P
What do you even mean by "they don't all speak with each other", what are they, and what can't they do (that electron can do?).
With Qt I can use the clipboard, sockets, and so on, set an icon for the application. Linux applications have standards to follow, as long as they do they look the same to the desktop environment.
Are electron apps magically able to speak with other electron apps, in a simpler way (to implement) than Qt applications? I don't think so.
With Qt I can use the clipboard, sockets, and so on, set an icon for the application. Linux applications have standards to follow, as long as they do they look the same to the desktop environment.
Are electron apps magically able to speak with other electron apps, in a simpler way (to implement) than Qt applications? I don't think so.
> There's no consistency between the dozen "toolkits"
Frankly this is a complete bullshit argument. Qt in particular can be used with little to no code change across the platforms.
And some of the most successful programs on Windows have basically gone their own way in terms of look and feel.
Frankly this is a complete bullshit argument. Qt in particular can be used with little to no code change across the platforms.
And some of the most successful programs on Windows have basically gone their own way in terms of look and feel.
That's not what i'm talking about. Qt is cross-platform after all. I'm saying there's no consistency in the concepts, how things are built. A Listview in GTK is very different from a Listview in Qt or wx, for example. They fire different events at different points of their cycles, they have different properties, different ways to be customized etc.
You can't, for example, simply fire Spy++ and check what a given widget is doing, as you can with GDI. The lack of a basic widget building block in X11 makes each one implement the very basics their own different way. And when they need to talk to each other, it's at the very least an unpleasant ordeal.
You can't, for example, simply fire Spy++ and check what a given widget is doing, as you can with GDI. The lack of a basic widget building block in X11 makes each one implement the very basics their own different way. And when they need to talk to each other, it's at the very least an unpleasant ordeal.
Can you point to a solid Qt or GTK tutorial for newbies?
Qt has very good documentation (http://doc.qt.io/). Go through the getting started guides, and focus on Widgets if you're developing for desktop.
People who built proper desktop applications didn't build them for linux. Even microsoft are releasing their electron things on linux (skype and VS code). I very much doubt that would have happened if they built native apps.
I much prefer the ability to running a slightly inefficient program over not having that program at all.
I much prefer the ability to running a slightly inefficient program over not having that program at all.
> because people who would have built a proper desktop application just wrap their web app in Electron instead.
Except no-one would have built clients for the linux desktop. Go back before Electron and count how many official clients for Linux there were from major software vendors, hell I'll even take massively feature incomplete answers like "Skype" just to help you.
Except no-one would have built clients for the linux desktop. Go back before Electron and count how many official clients for Linux there were from major software vendors, hell I'll even take massively feature incomplete answers like "Skype" just to help you.
> As much as HN hates Electron
It's not that "HN hates Electron", but some competent programmers, especially ones who have experience creating desktop apps, point out that Electron apps are huge resource hogs. It's not about having an opinion, rather stating a fact.
It's not that "HN hates Electron", but some competent programmers, especially ones who have experience creating desktop apps, point out that Electron apps are huge resource hogs. It's not about having an opinion, rather stating a fact.
This means nothing.
Native apps cost 10 times more and take a lot longer to build since you have to build 3 versions instead of 1.
So..?
Native apps cost 10 times more and take a lot longer to build since you have to build 3 versions instead of 1.
So..?
Yeah, and Electron programmers and users are incompetent. Very constructive.
Maybe these competent developers don't realize that lots of users don't care if their app use 100-200mo on an 8Go laptop. Nor do they realize that memory usage is one indicator among a few others that are as or more relevant to the various contexts: productivity, talent pool, cost, maintenance, etc. Trade-offs have to be made, Electron is one.
Maybe these competent developers don't realize that lots of users don't care if their app use 100-200mo on an 8Go laptop. Nor do they realize that memory usage is one indicator among a few others that are as or more relevant to the various contexts: productivity, talent pool, cost, maintenance, etc. Trade-offs have to be made, Electron is one.
It's not that users don't care. They just stop using it at some point. Most people don't know about memory or processor speed but that doesn't mean they will keep using a program that slows down everything on the computer.
In the work environment (non-tech) I experienced several times that people complained about bad usability and apps slowing down the computer. More often than not, those were Electron apps. But the standard corporate solution is to just upgrade computers to 32gb ram and even faster processors. Not sure if the faster development speed in Electron still saves money then.
Don't get me wrong, I think Electron is generally a great idea. VSCode works great. Similar to websites, slow performance is rarely a fault of the underlying technology, it's a result of programmers not caring about performance.
In the work environment (non-tech) I experienced several times that people complained about bad usability and apps slowing down the computer. More often than not, those were Electron apps. But the standard corporate solution is to just upgrade computers to 32gb ram and even faster processors. Not sure if the faster development speed in Electron still saves money then.
Don't get me wrong, I think Electron is generally a great idea. VSCode works great. Similar to websites, slow performance is rarely a fault of the underlying technology, it's a result of programmers not caring about performance.
And this is why front end/electron devs should do at least half of their work on low spec/5+ yo machines. If your product is aimed at the average end consumer, you’re locking out or making life hard for quite a number of users if you approach resource consumption in such a nonchalant manner. Not everybody has 8GB+ quad core machines! There are lots of dual core machines with RAM somewhere south of 4GB still in active use every day.
Funny enough, I've got a 2013 (?) Mac Mini with 8GB of RAM and a 2560xwhatever monitor. It's good enough for the vast majority of the development work I do, whether it's HTML/JS/CSS stuff, or iOS stuff, or Elixir projects, or C/C++ projects, or whatever.
Unless I've got Slack, Keybase, Spotify, etc open. Those just cripple the machine. Also Outlook, but I recently replaced it with Thunderbird and it seems to run much better. I find that my complaints are mostly met with accusations of being an old man (I'm 34...).
Unless I've got Slack, Keybase, Spotify, etc open. Those just cripple the machine. Also Outlook, but I recently replaced it with Thunderbird and it seems to run much better. I find that my complaints are mostly met with accusations of being an old man (I'm 34...).
One of the best thing to happen on desktop?
I can't think of anything good that has come out of electron. Seriously. Maybe slack (haven't used it) but that is probably about the worst use case for electron imaginable and would be utterly trivial to implement in a proper language natively.
I can't think of anything good that has come out of electron. Seriously. Maybe slack (haven't used it) but that is probably about the worst use case for electron imaginable and would be utterly trivial to implement in a proper language natively.
Apps that work just as well across Mac/Windows/Linux.
Among terminal emulators for example, Hyper is the only one I can think of.
Among terminal emulators for example, Hyper is the only one I can think of.
For multi-platform to be worth anything it has to be good for something. Why would I care that an app I don't want to use can be executed on several platforms?
You're not representative of the development world as a whole. You not wanting to use anything electron related is irelevant to its actual success.
Don't forget HN is a bubble : Electron is very much appreciated outside of this particular community.
Don't forget HN is a bubble : Electron is very much appreciated outside of this particular community.
And what particular javascript-centric bubble are you part of? Again, what electron-apps do people appreciate?
There might be tons, I just haven't seen anything usable.
There might be tons, I just haven't seen anything usable.
VSCode has been cited dozens of times on this thread only, and is probably one of the best Electron apps. I personally like Insomnia, Postman, Nylas, Discord, Git Kraken.
Not seeing "anything usable" is pure bad faith.
Not seeing "anything usable" is pure bad faith.
VSCode is currently mentioned three times (including your comment) in the entire discussion here, of which one predates my comment. You said something about bad faith?
But yes, VSCode is probably the exception. But they have had to spend a truly impressive effort to combat the shortfalls of electron and are to my knowledge the only ones that might have succeeded in making something relatively performant.
If that is what is required to make electron decent then few arguments in favor of it remains.
But yes, VSCode is probably the exception. But they have had to spend a truly impressive effort to combat the shortfalls of electron and are to my knowledge the only ones that might have succeeded in making something relatively performant.
If that is what is required to make electron decent then few arguments in favor of it remains.
[deleted]
[citation needed]
I wonder how many outside HN bubble even know what electron is.
I think quite a lot of Electron app users see value in being able to use the desktop app on their work pc and switch to a web version in their travel laptop. Also there is a lot of value in being able to just register on the web and start using the app until you find that you need a feature that is only available on the desktop, because of fewer restrictions, and only then switch, lowering the barrier to entry considerably.
Electron apps are good because they are as bad as a web site?
Yes I get that different sets of features on different platforms is an issue. But often that is half the point, if everything could be done on a website there is in the vast majority of cases no need for an electron "app".
Yes I get that different sets of features on different platforms is an issue. But often that is half the point, if everything could be done on a website there is in the vast majority of cases no need for an electron "app".
Why wouldn't I just run the desktop app on my work laptop?
> would be utterly trivial to implement in a proper language natively.
Have you tried to develop a cross-platform app for Windows, macOS and Linux recently recently? I do not know what you mean by "trivial", but using HTML/CSS/JS is the fastest way to develop UIs, and so, apps/programs. No contest. (about performances or resources management, that's a whole other story).
And using different techs for each platform to have a native app is not what I call trivial for developers in terms of complexity.
Have you tried to develop a cross-platform app for Windows, macOS and Linux recently recently? I do not know what you mean by "trivial", but using HTML/CSS/JS is the fastest way to develop UIs, and so, apps/programs. No contest. (about performances or resources management, that's a whole other story).
And using different techs for each platform to have a native app is not what I call trivial for developers in terms of complexity.
It is the fastest yes, and it is by far the worst.
With javacript you have to constantly fight the language, the frameworks the performance etc. This will actually end up taking more time and effort than doing it properly in native languages once you get past the proof-of-concept stage.
Having a cross-platform core and then doing a platform specific GUI for each platform is a bit of work up front but hardly a big hurdle all things considered.
The advantages are that you actually get an app that looks and behaves the way it is intended on each platform. And an app that actually can be user friendly. Did we all just stop and say, hey, users suck. Why should we care about them? Let's give them an ugly mess that doesn't perform.
That by itself is a tragedy, but what is astonishing is that it is done for no good reasons.
With javacript you have to constantly fight the language, the frameworks the performance etc. This will actually end up taking more time and effort than doing it properly in native languages once you get past the proof-of-concept stage.
Having a cross-platform core and then doing a platform specific GUI for each platform is a bit of work up front but hardly a big hurdle all things considered.
The advantages are that you actually get an app that looks and behaves the way it is intended on each platform. And an app that actually can be user friendly. Did we all just stop and say, hey, users suck. Why should we care about them? Let's give them an ugly mess that doesn't perform.
That by itself is a tragedy, but what is astonishing is that it is done for no good reasons.
I have high hopes webassembly will allows us to move away from javascript while keeping the cross platform bit. Not convinced it will address the complaints about electron which I understand rather come from the use of chrome/html/css in term of resources.
I agree that webassembly could make the situation much better.
Some of the appeal of electron is code-reuse and being able to use something other than javascript will make it easier to share code with native software rather than web pages. That would be a huge benefit in my eyes.
Some of the appeal of electron is code-reuse and being able to use something other than javascript will make it easier to share code with native software rather than web pages. That would be a huge benefit in my eyes.
It comes down to, do you care more about development, or do you care more about your users, and the app's ability to fit in with their chosen desktop, follow that desktop's paradigms, etc?
Have you seen cross platform app loved by users for its UI?
Yes. Atom for example (which is built using electron).
Ah, Atom, exhibit A in why electron apps can be resource hogs if you're not paying attention
https://github.com/atom/atom/issues/4378
https://github.com/atom/atom/issues/4378
Intellij IDEA?
It may be the fastest way to develop UIs, but it's the slowest and least efficient way to run code.
This makes it useless for any non-trivial app that is CPU bound - including, games, audio, video, 3D, and many many more.
Just because it's easy to build a house with Lego doesn't mean it's a good idea, or that it's going to compete with professional building materials.
This makes it useless for any non-trivial app that is CPU bound - including, games, audio, video, 3D, and many many more.
Just because it's easy to build a house with Lego doesn't mean it's a good idea, or that it's going to compete with professional building materials.
So they should do what?
1. Use current dev team to develop only the web version?
2. Hire X teams to develop for X platforms? (there goes your linux support)
3. Hire 2nd team to work on a cross platform native desktop client?
4. Open APIs and leave it to the wolves?
Everyone on here is acting like a few hundred meg of ram and barely 0.5% CPU usage is the end of the fucking world.
1. Use current dev team to develop only the web version?
2. Hire X teams to develop for X platforms? (there goes your linux support)
3. Hire 2nd team to work on a cross platform native desktop client?
4. Open APIs and leave it to the wolves?
Everyone on here is acting like a few hundred meg of ram and barely 0.5% CPU usage is the end of the fucking world.
#4 please! The days of GAIM/Pidgin felt like the golden age of chat apps, at least as far as the user experience was concerned. Just one centralized app could manage all the disparate protocols without ads or millions of analytic scripts tracking every mouse movement. And it barely took up system resources.
Also, you'd be surprised how fast 4gb gets used up by the time the OS, the browser, and various Electron apps take their cut. I can't browse the web while having Slack and Spotify open or things start thrashing. I think it's past the point of ridiculousness when a simple chat app takes more memory than a full featured IDE like IDEA.
Also, you'd be surprised how fast 4gb gets used up by the time the OS, the browser, and various Electron apps take their cut. I can't browse the web while having Slack and Spotify open or things start thrashing. I think it's past the point of ridiculousness when a simple chat app takes more memory than a full featured IDE like IDEA.
VSCode
Electron has really raised the bar for how easy it should be to package and publish a cross-platform native-enough app.
If something like Slack is "utterly trivial to implement in a proper language natively", why was Skype so awful for so long, to the point that they've now switched to Electron?
If something like Slack is "utterly trivial to implement in a proper language natively", why was Skype so awful for so long, to the point that they've now switched to Electron?
"the closest thing to THE solution to the UI problem."
The problem is that it isn't the solution to the UI problem. It's just yet another way in which developers can mindlessly fragment it even further.
For example, take Slack, Riot, Atom, VS Code, Keybase, etc. Not one of them makes an attempt to look like the host operating system. They don't use the native UI toolkit of the host platform. They don't even make any attempt to follow design conventions of the host platform.
Let's take macOS. In just about any text field in any application, you can right-click and get access to spell checking, substitutions and transformations. You can get macOS to read out the text you highlight by speech synthesis. Except for in Electron apps. Why? Because the text entry fields in Electron apps aren't typically native text entry fields. They're merely imitations and bad ones at that.
Also none of these Electron apps look or behave like each other either. Every developer has taken it upon themselves to play UI designer (almost always badly too) and to create their own buttons and their own sidebars and their own menus and their own controls and not a single one of them looks or feels like a first-class citizen in my operating system.
So the learned behaviour I've collected from 15 years of using Macs is now suddenly useless in Electron applications. Why? Because either developers want to cut corners, or some incompetent project manager wants 3 platforms supported by last week, and by the way, fuck your users, I need this done.
As with everything web-based, design and function are too closely intertwined and the result is consistently mediocre (if not terrible) user experience.
The problem is that it isn't the solution to the UI problem. It's just yet another way in which developers can mindlessly fragment it even further.
For example, take Slack, Riot, Atom, VS Code, Keybase, etc. Not one of them makes an attempt to look like the host operating system. They don't use the native UI toolkit of the host platform. They don't even make any attempt to follow design conventions of the host platform.
Let's take macOS. In just about any text field in any application, you can right-click and get access to spell checking, substitutions and transformations. You can get macOS to read out the text you highlight by speech synthesis. Except for in Electron apps. Why? Because the text entry fields in Electron apps aren't typically native text entry fields. They're merely imitations and bad ones at that.
Also none of these Electron apps look or behave like each other either. Every developer has taken it upon themselves to play UI designer (almost always badly too) and to create their own buttons and their own sidebars and their own menus and their own controls and not a single one of them looks or feels like a first-class citizen in my operating system.
So the learned behaviour I've collected from 15 years of using Macs is now suddenly useless in Electron applications. Why? Because either developers want to cut corners, or some incompetent project manager wants 3 platforms supported by last week, and by the way, fuck your users, I need this done.
As with everything web-based, design and function are too closely intertwined and the result is consistently mediocre (if not terrible) user experience.
I agree it works quite alright - not perfect, but nothing's perfect, right?
Of course there are some poor implementations (Slack) and some really good one's (VSCode). Criticism of the platform for the deficiencies of an implementation feels a bit lazy.
Of course there are some poor implementations (Slack) and some really good one's (VSCode). Criticism of the platform for the deficiencies of an implementation feels a bit lazy.
> it's beautiful
Beautiful is in the eye of the beholder. I much prefer consistent UI look and feel and Electron, may come close, it has it's nuances. It's probably my number one gripe. I'm on macOS though, so it could be different on your Linux desktop environment of choice or Windows. I still prefer TextMate 2.
Beautiful is in the eye of the beholder. I much prefer consistent UI look and feel and Electron, may come close, it has it's nuances. It's probably my number one gripe. I'm on macOS though, so it could be different on your Linux desktop environment of choice or Windows. I still prefer TextMate 2.
Can you expand on why you believe so?
Also, what other solutions have you tried (beyond "Hello, World!”)?
The reason I ask: I have 20 years experience with the web tech (and yes, that includes current stack) and almost ten years experience with iOS and eveytime someone says how good web stuff is for apps I just want to shake my head in disbelief.
>I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem.
If it is then we have failed horribly as an industry. We can do so much better, and we should strive to.
If it is then we have failed horribly as an industry. We can do so much better, and we should strive to.
>best things to happen on desktop, especially on linux desktop ironically.
No, the best thing was flash.
No, the best thing was flash.
I've been saying this the past few days among coworkers. The one thing Electron proves is that GUI programming is still not where it could be all these years of innovation later, if that were not the case it wouldn't be used as often as it has by as many companies who build their products around it. The reality is that Electron provides solutions to problems that the browser has had to solve for quite a while now: cross-platform development, and gives you a way to write code that already accounts for most of it taking away many of the cross-platform pain points.
I once wrote something along those lines on /r/linux. I got downvoted to hell and decided to delete that comment.
I'm not a system programmer by any means, but I consider myself well-rounded enough to be able to appreciate useful technology.
CSS grids and responsive @media, e.g. [1], are a useful addition to native applications design.
[1] https://github.com/MartijnCuppens/rfs
I'm not a system programmer by any means, but I consider myself well-rounded enough to be able to appreciate useful technology.
CSS grids and responsive @media, e.g. [1], are a useful addition to native applications design.
[1] https://github.com/MartijnCuppens/rfs
Maybe it is. But bundling everything still seems wasteful. A react native equivalent for desktops would in my mind help.
The Linux irony hurts.
Mobile has react-native. What about desktop? I see this: https://github.com/Microsoft/react-native-windows for Windows. I wonder if something like that could be done for Qt?
> especially on linux desktop ironically
I don’t know what the goals of the electron team are (unless they have shares in power companies and thus want CPU’s running at 100% everywhere) but I doubt their goal was making “desktop apps that aren’t available on linux”.
That’s the only way this would be irony.
I don’t know what the goals of the electron team are (unless they have shares in power companies and thus want CPU’s running at 100% everywhere) but I doubt their goal was making “desktop apps that aren’t available on linux”.
That’s the only way this would be irony.
[deleted]
To me it's like the junk food of software. Convenient, but it's hard to make an argument for it beyond that IMO.
Does anyone else feel that there's a huge hole in the UI world?
I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.
I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.
I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.
I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.
Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it.
Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming.
And no, I would rather not have an interpreted (or dynamic) language if I can help it.
Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.
Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming.
And no, I would rather not have an interpreted (or dynamic) language if I can help it.
Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.
There is a void because OS vendors are actively hostile to top-notch cross platform UI toolkits. They learned their lesson from software companies of the 80's and 90's: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions.
I feel that there's a catch-22 somewhere here :)
Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions.
I feel that there's a catch-22 somewhere here :)
But isn't web browser currently is a de-facto cross platform UI toolkit for displaying web pages it is just that we managed to make web pages look and behave more like apps.
So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink.
Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.
So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink.
Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.
The browser is a cross platform UI, yes.
But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input?
The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5).
Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.
But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input?
The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5).
Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.
Native offerings kinda suck too I don't know any standardized one. Swing, QT, GTK all look different depending on the OS.
Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.
Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.
"Swing, QT, GTK all look different depending on the OS."
They're supposed to. They're fitting in with the OS's native look and feel. And that's a GOOD THING.
They're supposed to. They're fitting in with the OS's native look and feel. And that's a GOOD THING.
Exactly, and building a UI framework as powerful as the web tech is very hard.
It took decades of development and an immense amount of resources - the current web engine we all use is the work of dozens of developers from KDE, Apple and Google. If we could've got those all to collaborate on a native UI toolkit you could probably have got something equally good, but such a joint Apple-Google project would probably have been politically impossible at both companies.
Sorry if I go OT, but I wouldn't know where else to ask this since the question comes from the article you linked.
So, by the logic of making your complements a commodity, what is FogCreek trying to make a commodity of with Glitch? Are they trying to make "building apps" (and thus "getting into programming") a commodity so they get more users to StackOverflow?
Also, does anyone have any good material to suggest on this topic? I'd like to learn more about it and learn how to be able to recognize the things for what they are: complements or products.
So, by the logic of making your complements a commodity, what is FogCreek trying to make a commodity of with Glitch? Are they trying to make "building apps" (and thus "getting into programming") a commodity so they get more users to StackOverflow?
Also, does anyone have any good material to suggest on this topic? I'd like to learn more about it and learn how to be able to recognize the things for what they are: complements or products.
Well, as I think Joel says in the article, you want some sort of Econ 101 textbook. Regarding FogCreek, you need to be aware of the whole picture: when Joel's talking about strategy, especially at that level, he's talking about big companies. Fog Creek doesn't have the kind of pull necessary to really care about complements or substitutes. Their strategy is probably: "fill whichever niche we deem free" :)
Oh yeah, I was thinking of something more specific, but I'll look into that too.
Well but then there's a big missed opportunity there, isn't it? I mean, it sounds like a principle like that would apply to most scenarios, unless you are too small to even think of making an impact on your complements markets with your financial power. In that case, sure.
Well but then there's a big missed opportunity there, isn't it? I mean, it sounds like a principle like that would apply to most scenarios, unless you are too small to even think of making an impact on your complements markets with your financial power. In that case, sure.
It's interesting that you mention that GTK is not native enough, but do not mention that for Electron. It looks like (and I feel this way) GTK hits the uncanny valley, whereas Electron is different enough (and applications written in it are used to spending effort on looks) to not run into that problem.
I find this inconsistency interesting as well. It's like if you used a "flat" GTK theme and avoided traditional UI elements like MDIs, menus, and toolbars, you'd be divorced enough from native to leave that criticism behind (granted there are others). I think this is what makes QML, JavaFX, and HTML+CSS more popular recently...desktop-like expectations are out the window (per se) before you start.
otoh, I think that with Electron, people are sufficiently acclimatized to web apps for them to feel at home with it. GTK feels like a java app.
Yup. The default interface for almost every normal users these days is a web interface. Yes, there are mobile apps, but even on mobiles, users will need to use websites, despite the best efforts of vendors at lock-in into their walled app gardens.
Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...
Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...
With Java 9 jigsaw and jlink you can now build fairly light JavaFX apps. The entire jre no longer has to be bundled. Only the pieces you're using.
Looks like that's about 45 MB [1]. For comparison, Electron is about 80 MB. Qt starts at 50 MB depending on what you need, but a few years ago I got it down to 16 MB with UPX and a customized ICU. Gtk starts at ~20 MB and compresses to about half that with UPX. You could probably get those a bit smaller if your license permits static linking, but then you have to write C++.
[1] https://steveperkins.com/using-java-9-modularization-to-ship...
[1] https://steveperkins.com/using-java-9-modularization-to-ship...
I recently started experimenting with JavaFX. I was pleasantly surprised how nice it is, and how easy it is to package application bundles.
Unfortunately JavaFX still does not support Wayland, just like most Java GUI things (except for SWT which seems to have some support https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841)
Given the progress of Wayland's adoption, I don't see it as a major issue.
Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.
In many times bindings are:
* incomplete
* immature
* not up to date
and definitely out-of-tree, aka not maintained by the folks that make the original toolkit.
Would you bet your company on those bindings?
* incomplete
* immature
* not up to date
and definitely out-of-tree, aka not maintained by the folks that make the original toolkit.
Would you bet your company on those bindings?
Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.
Yes, but some of them are of very high quality, such as wxPython or PyQt.
And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember.
Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.
And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember.
Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.
There are bindings and there are bindings. I'd bet my company on PyQt - if anything I'd say bugs get fixed there quicker than in Electron. But part of the reason for that is that PyQt is a commercial (dual license) project with a dedicated company behind it.
>Also, in case AOT compiler comes to Java
What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10.
> java --list-modules | grep aot
> jdk.aot@9-Debian
What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10.
> java --list-modules | grep aot
> jdk.aot@9-Debian
I'm not in Java world, but I remember there were talks about future AOT awhile ago - is this a thing now? i.e. you don't have to ship the whole JVM, and no more bytecode, just a native executable?
If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
Because of the crowd that doesn't want to pay for AOT compilers.
The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT.
Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).
The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT.
Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).
>I remember there were talks about future AOT awhile ago - is this a thing now?
Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship...
>If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.
Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship...
>If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.
I think part of the UI problem is more fundamental than UI.
The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.
The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.
> JVM AOT...we're waiting, we know it's coming.
https://www.excelsiorjet.com/
https://www.excelsiorjet.com/
It might as well not exist in this day and age: https://www.excelsiorjet.com/#pricing
Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way.
Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.
Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way.
Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.
That was only one example, and I explicitly mentioned Excelsior instead of other alternatives, because it is free for open source projects.
Fun aside, I once wrote a JVM AOT [0]. Instead of compiling to low level code and building my own GC and runtime, I just transpiled to Go. And it worked, but the Go compiler couldn't handle it well[1] so I started trimming identifier names and shortcutting JRE libs to use Go versions. It became tedious so I gave up. I should revisit that project one day, heh.
0 - https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602
0 - https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602
I agree with you, and I tried my best to change things.
A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil.
https://github.com/zserge/anvil
Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI.
I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look.
https://github.com/zserge/webview
A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil.
https://github.com/zserge/anvil
Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI.
I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look.
https://github.com/zserge/webview
Been enjoying your library webview for some small home projects. Thanks!
I'm not the biggest fan of this sed reinvention of PostScript we call the browser stack, but my main problem with Electron and the like isn't this, but their design target: Making desktop apps look and feel like web apps.
We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true.
I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true.
I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
You just dropped that comment about UX in at the end, but I think I know what you're hinting at.
What I see from UX/UI people is that consistency means an app has the same look and feel across OS platforms and the web, and it matches the corporate house style/identity.
The idea that apps should be consistent with the platform they are running on is completely dead. Even the OS platforms themselves don't have a consistent look and feel in any given version. Not to mention that that metaphorical fish has been flipped in the pan so many times that it has just disintegrated.
No one cares about consistency with OS platforms except us nerds on forums like this.
What I see from UX/UI people is that consistency means an app has the same look and feel across OS platforms and the web, and it matches the corporate house style/identity.
The idea that apps should be consistent with the platform they are running on is completely dead. Even the OS platforms themselves don't have a consistent look and feel in any given version. Not to mention that that metaphorical fish has been flipped in the pan so many times that it has just disintegrated.
No one cares about consistency with OS platforms except us nerds on forums like this.
> I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody.
Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines.
And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody.
Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines.
And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
DevOps as a practice isn't wrong, of course. Sysadmins scripted and programmed since the dawn of the silicon Pleistocene. But if every small company hires someone with that specific job description, well, you have to spend your 80+ startup hours somewhere.
Making desktop apps look and feel like web apps.Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.
UX is not some evil witchcraft, it is an accumulation of best practices that are not based on hunches that solo developers conjured up out of thin air, but resulted from measuring user feedback.
We used to call that "usability", and it was mostly done on the OS/API level (cf. Tog's work at Apple). In the web space, I see way too many individual practices (as what's "best" in the long run across all domains might not be the "best" at funnelling people through your web app).
Never mind that if it's your sole job, you have to demonstrate value and that often leads away from generic solutions.
Never mind that if it's your sole job, you have to demonstrate value and that often leads away from generic solutions.
But you cant solve this on OS level, really.
People read New York Times differently when compared to how they shop and want to checkout.
People browse Stack Overflow and hacker news differently too. There is no set of rules that are generic AND usable in all these cases.
And you do not read a Medium.com article the same way you set something up with your goverment in a goverment website, browsing through hundreds of options.
People browse Stack Overflow and hacker news differently too. There is no set of rules that are generic AND usable in all these cases.
And you do not read a Medium.com article the same way you set something up with your goverment in a goverment website, browsing through hundreds of options.
But why bring this misery to desktop apps? A lot of this arose out of the lack of standards and (initial) widgets in a browser.
Not that I believe that the amount of different interaction patterns is justified on the web; the lack of almost any kind of standard widgets just made this a free-for-all bikeshedding design space. In the long run, I doubt that your measurably superior solution to editing an entry in a grid is better than using the same pattern in every data grid.
Quite often I'm reminded of readability tests using different fonts, where the one people liked best often wasn't the one with the best reading comprehension. If you're picking a font for your OS, there was little choice and the customer probably bought it already. On the web, they can go to <rival product #341> because that uses Helvetica Neue and not Akzidenz Grotesk.
Not that I believe that the amount of different interaction patterns is justified on the web; the lack of almost any kind of standard widgets just made this a free-for-all bikeshedding design space. In the long run, I doubt that your measurably superior solution to editing an entry in a grid is better than using the same pattern in every data grid.
Quite often I'm reminded of readability tests using different fonts, where the one people liked best often wasn't the one with the best reading comprehension. If you're picking a font for your OS, there was little choice and the customer probably bought it already. On the web, they can go to <rival product #341> because that uses Helvetica Neue and not Akzidenz Grotesk.
It's not that simple. You can go three routes:
1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users.
2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently.
3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model.
So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.
1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users.
2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently.
3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model.
So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.
Alien would be okay, were it not ugly.
Swing is unusable and ugly.
Just look at and try to use a Swing file picker.
...
Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings.
And thus any glorified WebView reigns supreme.
Swing is unusable and ugly.
Just look at and try to use a Swing file picker.
...
Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings.
And thus any glorified WebView reigns supreme.
Yeah, I agree - C/C++ are the reasons why Qt is not popular.
I have no problem with things feeling alien, so that would be my preference.
For example I love the Telegram desktop app.
For example I love the Telegram desktop app.
Telegram looks native on Windows 10 though. It was designed to look like a flat modern app and it excels at that, hamburger menu and all.
Hmm, the header bar doesnt look native to me (it looks amazing)
No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS.
As funny anecdote, CSS Grid was originally proposed by XAML team.
Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
As funny anecdote, CSS Grid was originally proposed by XAML team.
Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet).
Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean.
QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms.
Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms.
Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS.
Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
"While your Electron app will be tweaked to make a Cordova app that runs on iOS."
And be incredibly shitty.
If you care about your users and their experience, you won't write apps in JS to begin with.
And be incredibly shitty.
If you care about your users and their experience, you won't write apps in JS to begin with.
My point of view is that if it is to be done with the Web stack, then by all means it should be delivered to whatever browser the user likes to use on their platform.
Anything else should take advantage of the native UI/UX tooling.
Anything else should take advantage of the native UI/UX tooling.
JavaFX surely runs on iOS, just not for the "I want everything for free" crowd.
http://gluonhq.com/products/mobile/
> XAML is not 100% the same everywhere, anyway.
Hence XAML Standard,
https://github.com/Microsoft/xaml-standard
http://gluonhq.com/products/mobile/
> XAML is not 100% the same everywhere, anyway.
Hence XAML Standard,
https://github.com/Microsoft/xaml-standard
>last time I tried C++ with mingw on Windows I had a horrible time installing libraries
msys2 (http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
msys2 (http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
Web technologies have some unique non-technical qualities which trump the technical arguments:
* Standards based with no single entity or company "owning" it.
* Multiple mature competing implementations.
* Massive support across the industry and a huge ecosystem.
* Standards based with no single entity or company "owning" it.
* Multiple mature competing implementations.
* Massive support across the industry and a huge ecosystem.
You mean like those "Works in IE/Chrome" standards?
I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.
I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.
You have to actively ignore the web's landscape in the past 5-6 years to state something like this.
Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.
Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.
Really?
https://ishoudinireadyyet.com/
https://www.webcomponents.org/
https://hangouts.google.com/
Also, to use those standards, one needs to have access to latest browser versions, which never happens beyond controlled environments.
So typical web development always needs Modernizr, Babel, Polyfills (when possible) around.
https://ishoudinireadyyet.com/
https://www.webcomponents.org/
https://hangouts.google.com/
Also, to use those standards, one needs to have access to latest browser versions, which never happens beyond controlled environments.
So typical web development always needs Modernizr, Babel, Polyfills (when possible) around.
The vast majority of current web development project don't need to go anywhere near the bleeding edge "still in development" browser APIs.
Your argument makes no sense in the year 2018.
Your argument makes no sense in the year 2018.
Depends, if they are trying to compete with native apps or not.
Of course if they just stick with the ideal model of hypertext documents, with a little bit of JS, it doesn't make sense.
As for web apps, I am ok with them, provided they run on the browser I have already installed, instead of faking native apps.
Of course if they just stick with the ideal model of hypertext documents, with a little bit of JS, it doesn't make sense.
As for web apps, I am ok with them, provided they run on the browser I have already installed, instead of faking native apps.
Hey, some of us are still out here having to support IE 7... Glaciers move faster these days than some corporate clients.
And yet, I still frequently run into web applications that only run in Chrome. Mostly COTS enterprise products.
You have extra word in your second point. There is norhing mature. If anything webtech rushes implementation of some feature just so the checkbox “we can do it too” is ticked and that’s it.
Do you know of a Qt app that looks and feels fully native on macOS and Windows and maybe iOS and Android?
I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform.
I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.
I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform.
I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.
Having done a lot of React development (in TypeScript), and recently dealing more with Android, I disagree.
Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited.
Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.
Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited.
Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.
If they were "much better", devs wouldn't be flocking to Electron. If there's something amiss, claiming there isn't with hand-waves brushes whatever issues there are under the carpet.
You also have to consider where the users are coming from. If you only have experience in web dev, obviously you are going to choose the framework that lets you do what you always did and get a desktop app in the end.
If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron.
And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort.
[1] https://github.com/chriskiehl/Gooey
If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron.
And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort.
[1] https://github.com/chriskiehl/Gooey
I bet the majority of those devs are web devs without any experience in native frameworks.
Devs aren't flocking to Electron. JS developers are.
Really, I agree that there are probably better markup options, but still, there's a reason people choose Electron over the alternatives. For me, personally, that reason is the ease of prototyping - the time it takes for me to have something in front of me that looks good and works easily is so much less using something like Electron.
Ok, but from an engineering standpoint I see this as a bit shortsighted.
I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development?
I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?
I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development?
I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?
They don't know better.
Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.
Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.
Or maybe the other way around: what if a browser was modular down to the feature level? Don't use CSS/JS/HTML feature X/Y/Z? It's removed from the engine at compile time. That way you're only shipping what you're using, not a mini-OS.
Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.
Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.
One big problem with Electron apps today IMO is that different apps cannot share memory, even though 90% of them is the same (Chrome/V8 etc).
That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO)
It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO)
It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
I'm not sure you would save that much memory. It would be a similar situation to having Chrome open with a bunch of tabs (those are separate processes as well) - it's the tabs themselves that consume most of the memory, compared to "bare" Chrome.
On my computer, "bare" Chrome with 0 tabs open still uses ~100MB of memory. If Electron would just use 100MB for the base compared to 100 * number of open Electron apps, that's still a pretty big win in my book.
I am sorry, but I honestly do not think that PYTHON of all the things would be the solution to a "UI-problem".
To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance.
I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve.
We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.
To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance.
I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve.
We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.
Are the options the best they could be? Heck no, not even close. Html is semantic enough to be tedious but not enough yo be useful. Css makes the easy things hard and people have entire philosophies around minimizing the "cascading" part. Js is at best stuck with warts to try and maintain backwards compatibility.
Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain.
The less said about the security complexity the better.
And I'm saying all of that as someone that uses these daily and enjoys it.
BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not.
Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base.
It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood.
Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good.
This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.
Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain.
The less said about the security complexity the better.
And I'm saying all of that as someone that uses these daily and enjoys it.
BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not.
Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base.
It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood.
Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good.
This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.
I very much hope Red finally takes off. Currently the GUI frontend works only on Windows and macOS, not on Linux yet. But once it does, we'll finally have a truly multiplatform tool for creating simple apps (such as the ones Electron is used for). As for more complex apps, this might well be possible as well, but I haven't seen anything really complex created in Red yet.
It sounds like you're just describing React Native (which, for example, has a UWP target, although it's still janky). React Native doesn't have a "web stack".
But is HTML/CSS/JS really the best we can do for desktop and mobile applications? [...] I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack.
QML?
Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc.
There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).
QML?
Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc.
There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).
>Small independent development companies have done applications across multiple platforms by using their native toolkits for decades
Really? How many programs supported Linux before electron?
Really? How many programs supported Linux before electron?
Usually these companies supported macOS and Windows. I am sure they would have also supported Linux if it had a desktop penetration of more than 1% and if the Linux community was less hostile to closed-source applications.
Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?
Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?
You will most likely come up with a sub-par rendering engine that is better implemented by Mozilla and Google. My hope is in Servo.
It is amazing that React and friends work as well as they do, and for certain applications they make a lot of sense. But there is a fundamental disconnect using web technologies for native apps.
The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.
The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.
Microsoft is serious on the WebAssembly part.
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
I thought it was just a poor winforms clone on macOS.
Sounds like what Red language http://www.red-lang.org/ is trying to achieve. It is still in Alpha, but already has cross platform GUI for Windows and OS X (with Androind arriving in next release). And without the web stack bloat, it's just single ~1 MB executable.
I feel the same way. I even tried starting a library like that (in Kotlin JVM and Native), but never got past a very early stage (https://github.com/peterholak/mogul). Hopefully one day I'll have enough time to work on it.
You just described Adobe AIR
eg. "something that has consistent, cross platform (desktop and mobile [...]), responsive ui, without the huge web stack"
I've been working in UI for almost 20 years. I've done flash, native desktop, games, web, mobile, etc, and I think HTML+CSS+JS is still the best abstraction for UI IMO.
It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there.
Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross...
It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there.
Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross...
> "I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack."
There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML:
https://en.wikipedia.org/wiki/QML
There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML:
https://en.wikipedia.org/wiki/QML
Flutter has the potential once it ported to desktop and even web(with WASM).
I think it'll only be ported to desktop once Fuchsia comes closer to release (which could be several years). They really seem focused on mobile only at the moment. Agree it could be a great solution.
Looks like it has started (MacOS for now)
https://github.com/google/flutter-desktop-embedding
I really don't mind the HTML / CSS part with new developments such as CSS grid. If you're running it in a controlled environment (embedded browser), you could cut out a bunch of legacy crap, leaving a much leaner engine. Similar cleanup could be done on the DOM API, I guess.
There is something to be said about html being too basic for developping apps efficiently. There is no menu control, contextual menu control, if you want to handle dragging and dropping UI items or creating an overlay modal window you need to do all sorts of hacks. On a desktop UI framework these are often a single line of code and it’s hard to get it wrong. I don’t think html/css is really comparable to the major native UI frameworks in term of productivity and correctness of apps produced.
I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc.
Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc.
Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
HTML and CSS are languages. Languages do not have one line components. Frameworks like Ant-Design and material-ui (based on react and/or Vue) have components that are nothing more than single line.
They have components, they have tables, datepickers, buttons, etc.
Have you seen a built in HTML date picker? It's horrible and is exactly the kind of built-in uncustomizeable frameworky misfeature that I don't want in HTML / CSS.
Tables are just unstyled boxes with an alignment rule. Not very high level.
Buttons are provided by the host OS, HTML and CSS have nothing to do with their default style or behaviour, and if you start styling them you basically revert to working from unstyled boxes.
Tables are just unstyled boxes with an alignment rule. Not very high level.
Buttons are provided by the host OS, HTML and CSS have nothing to do with their default style or behaviour, and if you start styling them you basically revert to working from unstyled boxes.
Absolutely, I agree that it sucks. And that's why UI developers are building all sorts of DIY components, too many of which fail. But that's exactly my point.
Being relatively low level is a feature. HTML / CSS / JS are languages, not frameworks. One liner modals are not a feature a language should have.
If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice.
Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice.
Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
Why do you call html and css a language? To me it’s a UI framework very much like winform, wpf & al.
Because it's a markup language, and a style definition language respectively, so HTML / CSS lack the high level features and components found in desktop UI frameworks such as Cocoa (standard buttons, lists, file explorers, image grids and such). Building a HTML / CSS UI is done from the ground up with basically nothing more than completely unstyled boxes, in contrast to composing higher level components.
On the web the role of desktop UI frameworks is distributed between third party frameworks such as Bootstrap which is great because those are optional.
I haven't worked with the windows frameworks you mention to compare directly to them.
On the web the role of desktop UI frameworks is distributed between third party frameworks such as Bootstrap which is great because those are optional.
I haven't worked with the windows frameworks you mention to compare directly to them.
> I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.
React Native doesn't use HTML/CSS at all for rendering.
React Native doesn't use HTML/CSS at all for rendering.
I'm starting a project with a strong need of build the UI in multiple targets (iOS, Android mainly).
I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :)
----
I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI):
We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly:
- Layout (the big one, IMHO) with something like https://yogalayout.com
- The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls.
- Dispatching, events and similar stuff, that is not visual.
Then finally, the rest can be fully native:
- Controls
- Drawing
- Animations
- Call to native libs
----
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 http://elementscompiler.com
Wish to have a coding partner to do this :)
I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :)
----
I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI):
We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly:
- Layout (the big one, IMHO) with something like https://yogalayout.com
- The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls.
- Dispatching, events and similar stuff, that is not visual.
Then finally, the rest can be fully native:
- Controls
- Drawing
- Animations
- Call to native libs
----
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 http://elementscompiler.com
Wish to have a coding partner to do this :)
TCL/TK runs on literally everything except the iPhone.
Yes. I'd like to see a stripped down embeddable browser engine - https://news.ycombinator.com/item?id=9914925
Also there are existing projects like https://github.com/ptmt/react-native-macos
Also there are existing projects like https://github.com/ptmt/react-native-macos
Like Sciter?
https://sciter.com/
I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
That's almost exactly what I was thinking of. There does look to be a big caveat with it though - instead of JS, it has an ECMAScript variant called TIScript. I'm sure this was a good choice when it was made, but javascript libraries and tooling are a lot to miss out on now.
[deleted]
Look up QML (Qt Quick) on Qt, its the easiest UI building experience I've ever had
Funny that QML looks alot like the JavaFX script that was abandoned
Funny that QML looks alot like the JavaFX script that was abandoned
I wouldn't get my hopes up. Javascript is the only runtime allowed on ios. Desktop is no longer worth innovating for. Meanwhile web ui frameworks are going gangbusters with innovation. That leaves a fairly slim line for any real ui innovation outside of the HTML css js triumvirate.
Sadly the biggest problems with Electron are not yet solved:
1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app.
2) Electron has an autoUpdater API, but since Electron doesn't solve the installation/updates problem e2e (packager + installer + updates server) it's really a half baked solution. This is specially bad in Windows since Squirrel for Windows is in my experience a disaster.
I have a number of Electron apps in production, internally and for our customers, and for our next desktop project we won't be using Electron.
The idea of using web technologies for the UI is still very valid IMO, but considering the 2 previous problems it's way less of a headache to just make our own native wrapper in C# and Swift (sorry Linux) and finally distribute the app via the official stores. At least for our use case.
1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app.
2) Electron has an autoUpdater API, but since Electron doesn't solve the installation/updates problem e2e (packager + installer + updates server) it's really a half baked solution. This is specially bad in Windows since Squirrel for Windows is in my experience a disaster.
I have a number of Electron apps in production, internally and for our customers, and for our next desktop project we won't be using Electron.
The idea of using web technologies for the UI is still very valid IMO, but considering the 2 previous problems it's way less of a headache to just make our own native wrapper in C# and Swift (sorry Linux) and finally distribute the app via the official stores. At least for our use case.
Sadly all of this was solved years ago with Adobe Air (single engine, real automated updates, plus a more sane Javascript syntax with AS3). I haven't used it in years but I just took a quick look and the last release was today - https://labs.adobe.com/downloads/air.html
I know there is a lot of Flash hate out there but Air+Flex(+FlashDevelop) was a pretty nice solution for building , debugging and distributing cross platform apps.
I know there is a lot of Flash hate out there but Air+Flex(+FlashDevelop) was a pretty nice solution for building , debugging and distributing cross platform apps.
I was a Flash dev for years, and then kept on doing Adobe Air apps for museums and mobile. Adobe dropped the ball on it pretty quick once HTML5 went mainstream. New features and bug fixes take ages.
I still think AS3 is one of the best languages I've ever used. It was really ahead of its time.
I still think AS3 is one of the best languages I've ever used. It was really ahead of its time.
"New features and bug fixes take ages."
ORLY?
It has been many years that Adobe AIR is updated on a quarterly basis, every March, June, September and December
https://www.adobe.com/devnet/articles/flashplayer-air-featur...
ORLY?
It has been many years that Adobe AIR is updated on a quarterly basis, every March, June, September and December
https://www.adobe.com/devnet/articles/flashplayer-air-featur...
So?
Major features are the ones that matter. It took Adobe like 3-4 years to bring concurrency to iOS. AS4 was killed after years of promises. Etc.
Major features are the ones that matter. It took Adobe like 3-4 years to bring concurrency to iOS. AS4 was killed after years of promises. Etc.
Maybe I’m remembering this wrong, but doesn’t Adobe Air work on Windows and macOS only?
I was trying to install an Adobe Air app on a Linux machine a while back and ran into this problem.
I was trying to install an Adobe Air app on a Linux machine a while back and ran into this problem.
They stopped Linux support in 2011 - https://helpx.adobe.com/air/kb/install-air-2-64-bit.html
support has stopped true but it does not prevent to publish on Linux desktop targeting AIR 2.6
ironically you can also embed Flash into an Electron app to use the latest v28 runtime
other workaround exists with the latest NPAPI that you can embed in a C++ app (like good old WxWidgets)
ironically you can also embed Flash into an Electron app to use the latest v28 runtime
other workaround exists with the latest NPAPI that you can embed in a C++ app (like good old WxWidgets)
I've been using the Sciter bindings for Rust, lately. It might be worth a look if you want a more performant option for a HTML/CSS GUI. The documentation is pretty rough, though.
https://sciter.com/
https://github.com/sciter-sdk/rust-sciter
https://sciter.com/
https://github.com/sciter-sdk/rust-sciter
I appreciate you sharing that more for their shared-source licensing model than anything else. I don't have many examples of paid source to draw on in those discussions.
Interesting. Any indication of why Sciter seems to be the go-to UI framework for antivirus software?
> 1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app.
I'm really curious (as a non-Electron developer) why that's a problem at all, let alone a big problem. You have to provide the entire package, but you have control over what the user gets and ultimately, what you'll have to support.
I'm really curious (as a non-Electron developer) why that's a problem at all, let alone a big problem. You have to provide the entire package, but you have control over what the user gets and ultimately, what you'll have to support.
What's old is new again. Same problem shared libraries solve:
1. Disk space. Electron, node, shared dependencies, that adds up. 300-500mb/app is not reasonable. 10 apps installed? 5 gigabytes! Wtf?
2. Security updates. Security issue in blink/v8? You need to update 10 apps instead of 1 lib. And I sure hope those apps are responsible enough to update themselves.
3. Bonus: CPU&RAM. Want to run 3 apps? Well, have fun with your 3 instances of chrome running. It adds up. I have 16GB of ram, I used to think it would last me forever and then the electron craze started to seriously limit me in the amount of concurrency I can have on my desktop.
Like GP said, Electron for UI is a valid pattern that has some pretty extreme issues preventing it from being a straight up good pattern. My bet is that an electron server on the desktop solves all this.
1. Disk space. Electron, node, shared dependencies, that adds up. 300-500mb/app is not reasonable. 10 apps installed? 5 gigabytes! Wtf?
2. Security updates. Security issue in blink/v8? You need to update 10 apps instead of 1 lib. And I sure hope those apps are responsible enough to update themselves.
3. Bonus: CPU&RAM. Want to run 3 apps? Well, have fun with your 3 instances of chrome running. It adds up. I have 16GB of ram, I used to think it would last me forever and then the electron craze started to seriously limit me in the amount of concurrency I can have on my desktop.
Like GP said, Electron for UI is a valid pattern that has some pretty extreme issues preventing it from being a straight up good pattern. My bet is that an electron server on the desktop solves all this.
Re: disk space
Just glanced at my Applications folder on OSX. Slack's looks to weigh in at 180 MB and VS Code at 160 MB. Am I missing something?
Just glanced at my Applications folder on OSX. Slack's looks to weigh in at 180 MB and VS Code at 160 MB. Am I missing something?
It means a lot of extra space. You are duplicating installations of Chrome and Node for each Electron app that is installed, instead of having one install and each app using the common dependency.
So yes, the developer gets complete control over which version of Chrome and Node is used, but you end up with a 150 MB text editor, a 150 MB chat app, and a 150 MB music streaming app, when you could probably get all three done with 152 MB using common dependencies.
So yes, the developer gets complete control over which version of Chrome and Node is used, but you end up with a 150 MB text editor, a 150 MB chat app, and a 150 MB music streaming app, when you could probably get all three done with 152 MB using common dependencies.
Is storage space really that big of a concern, with many multiple terabyte drives being commonplace? Out of all of the issues with electron, I don't think wasting 150MB is one of them.
Those are common, but small SSD are just as (if not more) common, so yes it matters.
It's also a matter of RAM, which is not as abundant as disk space
OP is talking about wasting 300MB for each Electron-based app you install.
With many of the lower-end laptops, price-wise, having ~128GB of SSD space, yes, it's a concern.
[deleted]
I'm not sure that would fix the problem since the common dependencies would still be having to store different versions of Chrome.
I think it worked pretty well for NPM where there was the high possibility of duplication between the modules you depend on and the additional modules required by them.
Since you're doing .NET have you looked at https://github.com/AvaloniaUI/Avalonia for cross platform UIs? I haven't messed with it, but it just hit beta and I was hoping for some insights.
AvaloniaUI is only in alpha right now. Also, until there is integration with the native menu bar on macOS, it’s a non-starter for Mac apps[0].
[0]: Judging solely on the screenshots provided, which show a menu bar inside the app window on macOS. I’m sure things will improve with time.
[0]: Judging solely on the screenshots provided, which show a menu bar inside the app window on macOS. I’m sure things will improve with time.
>AvaloniaUI is only in alpha right now
Beta was released a week ago, actually - http://avaloniaui.net/blog/2018-02-18-avalonia-beta1.html
Beta was released a week ago, actually - http://avaloniaui.net/blog/2018-02-18-avalonia-beta1.html
Or release it as a web application and let the user use chrome's "add do desktop" ...
I don't like that you're dropping Linux compatibility, but understand the the reasoning.
We've done that on mobile, but most of users don't even know that feature exists and another big chunk still don't trust a website vs an app.
I've never seen this feature in desktop.
Closes thing I know are these "hosted web app" in Windows 10. https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-cre...
I've never seen this feature in desktop.
Closes thing I know are these "hosted web app" in Windows 10. https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-cre...
The feature is only available in the Windows and Linux versions of Chrome.
https://www.lifewire.com/create-shortcuts-in-google-chrome-f...
https://www.lifewire.com/create-shortcuts-in-google-chrome-f...
I agree with all the complaints about electron performance, but the thing that really gets me is how horribly developers fail at responsive design, with a toolset that is probably the most suited for responsive design since terminals.
How the hell do slack, discord, and gitter STILL not collapse their sidebars when you resize the containing window to be tall and narrow? It makes them unusable in a tiling WM, and it's generally disrespectful of screen real estate in any WM.
This is the price of easily accessible development. We're doomed to relive past mistakes in UI, as new developers are blissfully unaware of lessons learned by existing frameworks.
Many people here are saying electron is popular because of a lack of sane, consistent toolkits across each OS. There's also security to think of too. Electron is likely very insecure relative to native software, but the responsibility is purely on the electron devs: freeing the app developer of that burdon. Electron rose in an environment with no competition in that regard. But now, Windows has UWP, and Mac has their own app platform. I sincerely hope we see these more universally leveraged, such that developers will stop abusing the web for app development.
And I guess Linux will just have to make a WINE for UWP, I can't imagine the Linux community coming together to create something like that for themselves.
How the hell do slack, discord, and gitter STILL not collapse their sidebars when you resize the containing window to be tall and narrow? It makes them unusable in a tiling WM, and it's generally disrespectful of screen real estate in any WM.
This is the price of easily accessible development. We're doomed to relive past mistakes in UI, as new developers are blissfully unaware of lessons learned by existing frameworks.
Many people here are saying electron is popular because of a lack of sane, consistent toolkits across each OS. There's also security to think of too. Electron is likely very insecure relative to native software, but the responsibility is purely on the electron devs: freeing the app developer of that burdon. Electron rose in an environment with no competition in that regard. But now, Windows has UWP, and Mac has their own app platform. I sincerely hope we see these more universally leveraged, such that developers will stop abusing the web for app development.
And I guess Linux will just have to make a WINE for UWP, I can't imagine the Linux community coming together to create something like that for themselves.
> And I guess Linux will just have to make a WINE for UWP
I might be wrong, but isn't that literally Snap Packages?
https://www.ubuntu.com/desktop/snappy
I might be wrong, but isn't that literally Snap Packages?
https://www.ubuntu.com/desktop/snappy
It's really sad that in spite of the main glaring problem of Electron apps they didn't as much as even mention any work done on performance optimization in 2.0.0. The changes mentioned are just make up when compared to the real problem.
Electron’s performance is fairly tied to Chromium’s - the Electron changelog references a Chromium version bump and you’ll need to look there for perf improvements (which isn’t ideal - I wish they’d pulled in some highlights!)
To be honest, people using Electron are doing it because of huge business / process wins and worse performance is a generally acceptable downside. Performance is improving as Chromium improves, but it isn’t a huge focus in the Electron community.
To be honest, people using Electron are doing it because of huge business / process wins and worse performance is a generally acceptable downside. Performance is improving as Chromium improves, but it isn’t a huge focus in the Electron community.
I see it the other way round. The people and community who chose electron at this point probably don't care about performance as much as we do. Improving performance would probably make us (people who care about performance, capable of writing lower level code) happy, but that's not their target user. Their community are people who write web apps, who don't want to learn native but want to make something.
Is there anything they could even do in that area? (other than improving Chromium itself)
this looks likes an internal dev oriented page, not a public announcement type of deal.
What do you find lacking in Electron's performance? Compared to all competing UI frameworks it isn't really any different, except it allows for faster and easier development and deployment.
It wastes tons of memory.
I don't think 100-150MB is a "ton",and I don't think it's "wasted". It's actually as much as a single tab of a browser. If it takes much more, it's not Electron's fault, it's the program's developer's - memory leaks are not uncommon in javascript SPAs.
First of all, it's not 100-150. If it stopped at that, nobody would even care to mention this huge problem. What you get in real life is something like 800 MB for memory alone, and CPU usage can be similarly high. There are legitimate reasons to use that much resources, just not by the GUI.
Really, it's as if all this fundamental computer science, O(n), finding the shortest path, all these efforts in optimization that we do at universities - as if all this just went down the drain and the moment you leave the CS department you say, "Ah, screw all this, I'll just allocate all I can, just in case". This is just so wasteful and it really makes me sad that so few people care.
Really, it's as if all this fundamental computer science, O(n), finding the shortest path, all these efforts in optimization that we do at universities - as if all this just went down the drain and the moment you leave the CS department you say, "Ah, screw all this, I'll just allocate all I can, just in case". This is just so wasteful and it really makes me sad that so few people care.
I just launched Discord, the heaviest Electron app I have installed, and it idles at 135 MB of memory. I'm not seeing anything close to 800 MB being used.
Make sure to add all of the helper processes together. Slack plus all of its helpers is currently using 1.2GB of RAM on my MBP. Each Slack group I'm a part of adds 300-500MB to that total.
The 135 MB was the total of all sub-processes.
https://i.imgur.com/1ZEffk6.png
https://i.imgur.com/1ZEffk6.png
It's more that all the optimizations and strategies which apply to a browser built to hold many open tabs at once, support many standards and protocols and quirks etc. must be loaded into memory for a simple application that is not a browser.
You get all the tradeoffs of Chrome (e.g. cache everything you come by) outside of Chrome proper.
You get all the tradeoffs of Chrome (e.g. cache everything you come by) outside of Chrome proper.
A browser (or Electron) does not allocate as much memory as it can on a whim, every byte of that memory is used to bring you features, caching, and so on. What program have you seen that takes 800 MB of memory? And why would a modern GUI program not utilise memory if it's available and it's free in order to cache data, requests, build an in-memory database, and so on? Browser programming is a lot more than finding the shortest path in a graph. It's commonplace to have 4-10GB of free memory at any given time and it should be utilised if it's available instead of being wasted by being unused.
> It's commonplace to have 4-10GB of free memory at any given time and it should be utilised if it's available instead of being wasted by being unused.
I'm not sure when this became the new normal, but I was taught the exact opposite. How about trying to squeeze that into 200 MB rather than allocating 4-10 GB just because it happens to be available at that moment?
I'm not sure when this became the new normal, but I was taught the exact opposite. How about trying to squeeze that into 200 MB rather than allocating 4-10 GB just because it happens to be available at that moment?
For some purposes, you can't "squeeze that into 200 MB", especially for caching. If you have memory that's lying around empty, what is the point of having it at all if it's wasted 99% of the time? Is it a virtue in itself to under-utilize resources you have available?
Is it good if a company employs a 100 people but only 15 of them do work and the rest is idle?
Is it good if a company employs a 100 people but only 15 of them do work and the rest is idle?
First of all, yes you can, even easily - provided that you use a different GUI toolkit. 200 MB is a huge amount of memory anyway, in many cases you can do much better. Electron fans like to talk about caching, but really, that's a browser issue, it has nothing to do with GUIs, at least not with traditional ones. Why should you need to cache any GUI elements if you can (re)create a thousand dialogs in a blink of an eye? Maybe you can cache the _data_ in those windows, but that's a completely different thing, and the memory used is usually some orders of magnitude lower.
Now, as for using all available memory: that's exactly the reasoning that causes so much problems for users, and that's why after so many years of hardware upgrades our machines still feel sluggish: using all resources for your app, only because they happen to be free at that moment, is not OK.
First of all, they are free now, but they might not be a moment later (because another brilliant app author has the same idea and tries to allocate everything). Second, the resources should be used in a reasonable way. If a piece software doing extremely simple computation is suddenly allocating a few gigs of RAM and takes over all cores, my thought isn't "Oh, what an efficient app, it's using all these resources I don't need", but I wonder what went wrong! What is perfectly OK for, say, a 3D rendering node, is completely wrong for an app that could do the same thing with 10x lower resource usage.
I'm not sure if I am able to explain it in more clear terms.
Now, as for using all available memory: that's exactly the reasoning that causes so much problems for users, and that's why after so many years of hardware upgrades our machines still feel sluggish: using all resources for your app, only because they happen to be free at that moment, is not OK.
First of all, they are free now, but they might not be a moment later (because another brilliant app author has the same idea and tries to allocate everything). Second, the resources should be used in a reasonable way. If a piece software doing extremely simple computation is suddenly allocating a few gigs of RAM and takes over all cores, my thought isn't "Oh, what an efficient app, it's using all these resources I don't need", but I wonder what went wrong! What is perfectly OK for, say, a 3D rendering node, is completely wrong for an app that could do the same thing with 10x lower resource usage.
I'm not sure if I am able to explain it in more clear terms.
So you're saying increased resource usage is ok for node, but did you know that node is exactly what electron is running on? 200 MB of memory is nothing for a GUI app - and most Electron apps don't even take 100. They need that memory for all these amazing features the framework offers, like running javascript, processing css stylesheets, async execution, etc.
No, by "3D rendering node" I don't mean Node.js but a node (like in a cluster) of a 3D rendering engine.
> For some purposes, you can't "squeeze that into 200 MB", especially for caching
The thing is native apps can do that, and more in less memory. The baseline here is set by "how much is needed", not "how much memory is available".
>Is it good if a company employs a 100 people but only 15 of them do work and the rest is idle?
Yes, if 15 can do the job. then rest can moved for other profitable purposes, or laid off.
The thing is native apps can do that, and more in less memory. The baseline here is set by "how much is needed", not "how much memory is available".
>Is it good if a company employs a 100 people but only 15 of them do work and the rest is idle?
Yes, if 15 can do the job. then rest can moved for other profitable purposes, or laid off.
You hired those 100 employees for a reason: future growth. If you decide to employ them as subsistence farmers you're not only lacking employees in the future you're also bleeding money left and right.
That's an extremely terrible strategy.
It's the OS's job to use the free memory for caching the filesystem. If you have special workloads that benefit from more memory you usually change an entry in a config file to the appropriate value or change a settings in the GUI. That's it. No you don't just try to consume as much memory as possible for no reason. You're messing with the OS's ability to use the memory optimally. It's not wasted, you're the one who's wasting it.
It's the OS's job to use the free memory for caching the filesystem. If you have special workloads that benefit from more memory you usually change an entry in a config file to the appropriate value or change a settings in the GUI. That's it. No you don't just try to consume as much memory as possible for no reason. You're messing with the OS's ability to use the memory optimally. It's not wasted, you're the one who's wasting it.
> It's commonplace to have 4-10GB of free memory at any given time
An entry-level computer nowadays has 4GB of memory. Not free memory, total memory. That 4GB has to be shared between the operating system, all running apps, and the disk cache.
> and it should be utilised if it's available instead of being wasted by being unused.
If it's available, any modern operating system will use it for the disk cache, instead of leaving it unused.
An entry-level computer nowadays has 4GB of memory. Not free memory, total memory. That 4GB has to be shared between the operating system, all running apps, and the disk cache.
> and it should be utilised if it's available instead of being wasted by being unused.
If it's available, any modern operating system will use it for the disk cache, instead of leaving it unused.
I use firefox and according to about:memory gitter uses about 20MB per tab and rocketchat about 50MB. Those at are the biggest memory hogs. The average tab with a static page uses around 4-5MB. On the other hand I see a lot of "fixed" cost
These values may not be accurate because they don't include images but they are still very far away from a blanket statement like "150MB per tab".
Clearly we can see that electron has a lot of room for potential and if they fix these flaws there would be no need to critize it, yet they don't even give the slightest damn about it.
These values may not be accurate because they don't include images but they are still very far away from a blanket statement like "150MB per tab".
Clearly we can see that electron has a lot of room for potential and if they fix these flaws there would be no need to critize it, yet they don't even give the slightest damn about it.
So if it uses up to 150MB, it is not wasted and if it uses more then it's the user's (dev building on electron) fault. Got it. Electron is never at fault.
scanned the changelog for any mention of performance or memory footprint optimizations. nothing.
Updated V8, Node, and Chrome? That's the performance gain...
I wonder if it would be possible to change the electron build process so it builds 2 outputs: 1 "big" package with full Chrome inside and 1 "light" package that just contains the application code.
The light package could then be offered as an alternative download on the website to run on a specific "electron-runner" that can run multiple electron apps side by side.
I know that I just described a regular browser with tabs or windows but hey, Electron is what we have right now and it is not going away soon. This might be a solution for people running multiple Electron apps side by side.
The light package could then be offered as an alternative download on the website to run on a specific "electron-runner" that can run multiple electron apps side by side.
I know that I just described a regular browser with tabs or windows but hey, Electron is what we have right now and it is not going away soon. This might be a solution for people running multiple Electron apps side by side.
A project with that idea is Electrino: https://github.com/pojala/electrino It provides an electron-like API but uses the OS version of safari. It doesn't seem to be actively developed anymore though.
Reminds me of XULRunner from Mozilla.
If you don't need the APIs that interact with the local system, you can already build for Electron and for the browser easily. If you need those APIs, however, there's no other possibility because of the browser sandbox.
It's possible to have a native (node?) app for the local side, which talks to a browser extension. This way you don't have to run multiple instances of the browser runtime. There's someone writing a full-featured, Patchwork-like SSB client in Firefox this way, but unfortunately I can't remember the name.
Since it’s something I’ve been paying attention to for a while: this (beta, sure, but soon to be full. Probably would work fine for doing some dev work) release of Electron finally bundles the version of Chrome that implemented SharedArrayBuffer support. This means that developers can now spawn web workers (real parallelism) and communicate with them much faster than previously with message passing. So there could be some big wins for things like developing games in Electron since you’ll be able to do some big number crunching off the UI “thread” and hand the results back to the UI with little performance penalty. (Especially if there are a lot of results, such as a theoretical fully-updated scene graph worth of matrices in an array) Hooray for less jank on the renderer!
Notably, `SharedArrayBuffer` was disabled (starting Jan 5 2018) due to Spectre.
Nevertheless, it is going to be re-enabled so it is worth reading up on shared memory in JavaScript -- more to the point, Atomics.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I know a lot of people scoff at the Node/browser runtimes, which is warranted and totally unrelated to the language known as JavaScript, but performance is improving.
Nevertheless, it is going to be re-enabled so it is worth reading up on shared memory in JavaScript -- more to the point, Atomics.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I know a lot of people scoff at the Node/browser runtimes, which is warranted and totally unrelated to the language known as JavaScript, but performance is improving.
Is it disabled in the version of Chrome shipping with Electron? Considering they’re usually some number of versions behind, and this is a tool to make a desktop app, it would seem to be desirable to have it enabled regardless of Spectre since a desktop app can own your computer anyway if it wants. (It does make sense to have it disabled in a general purpose browser until mitigation’s are in place)
You can already experiment with SAB in electron 1.7.9 with flags.
Since I'm not seeing an obvious flag from a quick search (it seems like you need to do something with a harmony flag?), could you put the exact flag necessary to enable SharedArrayBuffers in 1.7.9? Preferably in the format that would be used to commonly run Electron. (I think you usually use npm to start the Electron process? Been a while since I did something with Electron since I've been waiting for the SAB feature to land)
EDIT: Found that the correct flag is "--harmony-sharedarraybuffer". If directly running electron, then you would use "electron --js-flags="--harmony-sharedarraybuffer" index.html" (or "." instead of "index.html"). If using the electron quick start repository, you can add the flag above to package.json.
EDIT: Found that the correct flag is "--harmony-sharedarraybuffer". If directly running electron, then you would use "electron --js-flags="--harmony-sharedarraybuffer" index.html" (or "." instead of "index.html"). If using the electron quick start repository, you can add the flag above to package.json.
People not satisfied with Electron's performance might be interested in fbs [1]. It makes it very easy to create desktop apps with Python and Qt. It was in the #1 spot here two weeks ago [2]. (I'm the author.)
[1]: https://github.com/mherrmann/fbs
[2]: https://news.ycombinator.com/item?id=16318677
[1]: https://github.com/mherrmann/fbs
[2]: https://news.ycombinator.com/item?id=16318677
What would be interacting is an electron like environment with a pared down JS/CSS engine which only let "modern JS/CSS" (maybe something like Servo). It can be optimized for that, and you don't really have to render electron apps from the 90s anyways.
Another idea is that when wasm will be able to interface with DOM, you'd be able to write GUI code in any language which compiles to wasm. So you won't _need_ Rust (or Go, or Haskell, or D, or your up and coming toy language) bindings for win32, Qt, GTK, etc. Just waste a few hundred megs (only partially /s) and you've got a full ui.
Another idea is that when wasm will be able to interface with DOM, you'd be able to write GUI code in any language which compiles to wasm. So you won't _need_ Rust (or Go, or Haskell, or D, or your up and coming toy language) bindings for win32, Qt, GTK, etc. Just waste a few hundred megs (only partially /s) and you've got a full ui.
MS seems to be on the way to support PWA directly in Win 10. If other systems would do this as well we won't have to ship a full runtime like Electron.
https://blogs.windows.com/msedgedev/2018/02/06/welcoming-pro...
https://blogs.windows.com/msedgedev/2018/02/06/welcoming-pro...
What happened here?
"macOS Changed a macOS thing. #123
Windows Changed a Windows thing. #123"
"macOS Changed a macOS thing. #123
Windows Changed a Windows thing. #123"
I guess that's the template text for releases and they forgot to remove it.
They linked to a GitHub issue explaining a feature request [1]:
> We should use the icon of exe as window's icon, and we also need to add a default icon for atom-shell on Windows.
[1] https://github.com/electron/electron/issues/123
> We should use the icon of exe as window's icon, and we also need to add a default icon for atom-shell on Windows.
[1] https://github.com/electron/electron/issues/123
[deleted]
We have been using Electron for https://tradedash.io (our crypto currency trading platform) for some time now. There are some minor issues with the platform itself but there are a lot of good things too.
The JS ecosystem as a whole needs to improve but as far as Electron goes, I must say that I am pleasantly surprised with how well it has been doing even though we are handling data from multiple exchanges at a rate that is not so trivial.
The JS ecosystem as a whole needs to improve but as far as Electron goes, I must say that I am pleasantly surprised with how well it has been doing even though we are handling data from multiple exchanges at a rate that is not so trivial.
why is this a "native" app and not just a new tab in chrome ?
You can use React and js to build native desktop apps without electron today. Use https://proton-native.js.org/ (based on libui).
While that is certainly a promising library to watch for in the future, I wouldn't say its ready to go today. Its based on libui which is in alpha and was stagnant for quite awhile. The developer just recently (this week) started working on it again so there is potential.
I wonder why there is no runtime package for all your electron applications, so you only have to install the runtime once and every app can depend on this runtime. This would greatly reduce download sizes of individual applications.
I assume because it would defeat the intention of electron, since the entire point is to "magically" make your webapp into a standalone application with no dependencies. Just download and start it up, like any application.
Whether this is wise is another question.
Whether this is wise is another question.
... and with this sort of magic, I expect that all of the applications that I download are going to have completely different versions of all of the dependencies, so, ... there's no sharing anyway.
This will open a new can of worms. A new electron app uses some new feature that updates your runtime. But unfortunately the runtime update to make one app work breaks some other app.
The current model isolates the runtime to every app. The download size may be big but I have a guarantee that my app will work without interference from others. Honestly, that guarantee justifies the binary size for me.
The current model isolates the runtime to every app. The download size may be big but I have a guarantee that my app will work without interference from others. Honestly, that guarantee justifies the binary size for me.
Or electron runtime can do the sane thing and be backward compatible for a few version numbers. It's basic API stability.
Because the market-proven reality is most end users don’t care about 100MB download sizes, and they do care about simplicity.
100 MB is nothing. My electron program is only 35 MB in size. Most people have multiple 1TB disks now.
Most people? At the bottom of the windows laptop barrel you now see laptops with 32/64gb of EMMC storage and the guts of an Intel bay trail tablet.
These are acceptable for people who use their computer as a Facebook machine but "modern" software really taxes them.
These are acceptable for people who use their computer as a Facebook machine but "modern" software really taxes them.
Or people have laptops and because they don't waste it on bloated crap like Windows and instead use linux a single 256NVMe SSD is enough. I use 50GB right now for the Linux installation with everything I could possibly need for work and another 50GB for two empty Windows VMs with nothing in them except a browser.
Each runtime can be a different electron version and have different combination of npm packages.
It's the Wild West, without a standard library and tons of options for the same problems.
It's the Wild West, without a standard library and tons of options for the same problems.
But if they could at least share the Chrome and Node bulk? They'd still have to have their own copy in their address-space so you'll not save RAM but you might save a chunk of disk space (handy when working on a tablet or small laptop with a small eMMC drive) and download time.
Of course versioning will be an issue so you might still need multiple versions for compatibility reasons. You might need a copy of 1.6.16, 1.6.17, 1.8.0, 1.8.2, and 2.0.0 to server your collection of apps. How to solve that problem would require some thought. When a user starts an app, if the version it is built against (or one it is otherwise marked as compatible with) isn't present do you warn the user and refuse to run, warn the user but run with the next best thing as it might just work, or automatically kick off a download? For systems where people are used to having a package manager this can be relatively transparent (apt install myElectronApp, pulls a versioned electron package if needed at the same time) but less so on Windows.
Perhaps it would be to complex (so potentially bug ridden) for the savings involved. Filesystem block-level deduplication might help the space issue, though not the download issue.
Of course versioning will be an issue so you might still need multiple versions for compatibility reasons. You might need a copy of 1.6.16, 1.6.17, 1.8.0, 1.8.2, and 2.0.0 to server your collection of apps. How to solve that problem would require some thought. When a user starts an app, if the version it is built against (or one it is otherwise marked as compatible with) isn't present do you warn the user and refuse to run, warn the user but run with the next best thing as it might just work, or automatically kick off a download? For systems where people are used to having a package manager this can be relatively transparent (apt install myElectronApp, pulls a versioned electron package if needed at the same time) but less so on Windows.
Perhaps it would be to complex (so potentially bug ridden) for the savings involved. Filesystem block-level deduplication might help the space issue, though not the download issue.
What is the stack behind RStudio? It isn't electron, but it is an HTML app, run by a browser (safari on my macbook pro, wonder if it is IE on windows)
It doesn't feel as heavy as electron apps.
It doesn't feel as heavy as electron apps.
I have only a very cursory look at Electron, but I find two things problematic: Lack of support for legacy systems, and the complicated build process of apps built with Electron, most can't successfully build unless you download a ton of stuff from npm. The kind of place where I am with many many older machines, never connected to the internet, Electron hardly makes any sense.
Never really heard of Electron before I tried using KeyBase on Windows. It seems electron is the reason that it doesn't work on my machine.
Ran into this last night. https://github.com/keybase/keybase-issues/issues/2813
Ran into this last night. https://github.com/keybase/keybase-issues/issues/2813
Does anyone know if there has been any work on bringing the work from “headless chrome” to electron?
It would be awesome to be able to use the full node.js environment with a headless browser natively.(headless chrome with puppeteer is good but electron would be better)
It would be awesome to be able to use the full node.js environment with a headless browser natively.(headless chrome with puppeteer is good but electron would be better)
Why not upgrade to the most recent version of chromium? (64 instead of 61)
Because it takes longer than the chromium release cycle to do an electron/chromium upgrade. I think they only tend to do the upgrade a few times a year. Chrome 61 will have been current when they started the upgrade process.
Nothing in this seems worthy of a major version bump to be honest.
See https://electronjs.org/blog/electron-2-semantic-boogaloo.
As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.
Major Version Increments
* Chromium version updates
* Node.js major version updates
* Electron breaking API changes
As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.
Major Version Increments
* Chromium version updates
* Node.js major version updates
* Electron breaking API changes
Sounds a bit like angular and we might get electron 3 and 4 very soon if they feel a need to update Chromium or Node.
A major version bump is for introducing breaking API changes. That’s all it means.
If they're following semantic versioning, then they bump the major version number whenever they make breaking changes.
Can anyone explain for me: WHY is electron such a resource hog? Is it just because chrome is a resource hog? Could it be trivially re-engineered to wrap quantum instead?
Waiting eagerly for VS Code to upgrade. As far as I understand, this fixes the "precision touchpad" bug on Windows..
How long before the Electron APIs are aped by OS extensions and managed more effectively than Blink?
Is Electron still single threaded like Node?
With all the GUI crap going on in software development, I am starting to miss MFC and BCG libraries, I know it is not feasable for most developers to code in c++ but at that time the GUI, even if run over RDP, was fast, responsive, now I having a feeling like 386 was faster than todays i7+. And to cirmuvent obvious incapability of RAD to provide decent user expirience, they are changing our UI percepction from trendy perspective, leveling everything to flat and extremly simple, like ncurses on graphical desktop. =/
Just a reminder to everyone who says there's no way to write cross platform apps:
TCL/TK is still a thing and MacOSX still ships with wish, it even runs on android. The one platform you can't use it for is the iPhone.
TCL/TK is still a thing and MacOSX still ships with wish, it even runs on android. The one platform you can't use it for is the iPhone.
If you're willing to not support the iphone you have plenty of good options. Unfortunately for many people iphone is a requirement.
One thing I don't understand about Electron is, why not share a single Chrome process (or if anything one per Chrome version if needed)
It works, it's beautiful, it's easy to use, and unlike many people here, I believe the HTML/CSS/TypeScript/React is rock solid and the closest thing to THE solution to the UI problem.