Just a bit of a rant here, only tangentially related. The article mentions Flash one time: I'm sorry, this is a stupid comparison. I was a developer of both Shockwave and Flash apps. Flash was...
Just a bit of a rant here, only tangentially related. The article mentions Flash one time:
That way lies the return of shockwave flash, of warm phones in our pockets which are mysteriously flat when we want to use them.
I'm sorry, this is a stupid comparison. I was a developer of both Shockwave and Flash apps. Flash was incredibly lightweight. It replaced Shockwave/Director/Lingo - which had some pretty stupid overhead for its time (but of course, Java applets were the shitty low bar at the time), and the replacement was in large part directly concerned with keeping the overhead low. Flash's native video and pdf-style documents came later, and in all respects they were lighter than what they were replacing (oh God, the RealVideo pain remains with me even to this day). The problem with Flash was its ubiquity driving poor practice (a-la-php) and its innate security flaws, NOT its weight.
So here we have a great article with a distracting crap (and just plain wrong) title, and everyone nods their heads because they remember Flash being the shit it was at the end, not how shit everything was before Flash came along. Flash originally made everyone's life 100% better. I mean, I guess the point of Electron is write once, run anywhere - but Flash was brilliant at that, not shit. So again, not a good comparison.
Flash was good. Really, it was a nice platform. The biggest downside of it was that it was used excessively and that it was a proprietary add-on. If it was just another subsytem the browser could...
Flash was good. Really, it was a nice platform. The biggest downside of it was that it was used excessively and that it was a proprietary add-on. If it was just another subsytem the browser could include and had a standard and was open source, it wouldn't have been murdered like it was. It would be better integrated and have had less security issues.
People hate it because of the proprietary and cumbersome nature of it, especially getting it to work on Linux w/ Firefox was troublesome; and also because there was so much negative propaganda that people went from disliking it for reasons to purely hating it because it was something you had to hate and hating it was/is cool. A bit like immigrants versus the right, really. And Apple has a fair share in this, they pushed hard for HTML5/CSS3 replacing it. And now, HTML/JS/CSS are trying to become Flash.
I wish there was something like POSIX for GUI interfaces. There is a serious platform bloat w.r.t. portable and open source UI toolkits, i.e. it is not the framework or libraries that are numerous, but the entire platforms (GTK+, QT, WxWindows, etc. don't have almost anything in common, whereas with Electron you have a common platform onto which you can build with your tools, and you don't add burden for yourself or on the users). I used VSCode out of curiosity, and performance was good (and I use a 10yo shitty laptop). Spotify is slow, but their apps are baad: they know what people come for, and they know that we'll tollerate their BS for the music they provide... Decent apps can be built with Electron. But it is a mediocre solution to an easy problem that is complicated because people.
Honestly, I remember the real biggest downside for flash was the security vulnerabilities. Flash became ubiquitous, which meant it became a giant target for black-hat hackers. Couple this with...
Honestly, I remember the real biggest downside for flash was the security vulnerabilities. Flash became ubiquitous, which meant it became a giant target for black-hat hackers. Couple this with Macromedia/Adobe never coming up with a background upgrade system for Windows and Mac meant it irritated users by constantly bugging them to upgrade.
Imagine a world where adobe was open sourced. Tech companies took the fastest route to screwing users by implementing adobe's business model. People bitch about Android as they should, without a...
Imagine a world where adobe was open sourced. Tech companies took the fastest route to screwing users by implementing adobe's business model.
People bitch about Android as they should, without a thought to the fact you have a choice.
I applaud apple, for protecting their users. But it is a child's toy so they can maintain their walled garden. If that's your thing go for it. If you want innovation, open source is all we got.
This is a really good point, and definitely something the article should've clarified. I think a better summary of the article's comparison would be "Flash (Electron) had it's problems, but it got...
This is a really good point, and definitely something the article should've clarified. I think a better summary of the article's comparison would be "Flash (Electron) had it's problems, but it got the job done very well, until HTML5 ($electron_replacement) came along to supersede it."
I don't think the article was trying to compare performance of Electron vs Flash, but rather show that, like Flash, Electron has drawbacks, but the article doesn't make that very clear.
I’ve been thinking a lot about the state of desktop apps recently, the speed and ease of development with different tools, the tradeoffs of development time vs usability, and the ecosystem around...
I’ve been thinking a lot about the state of desktop apps recently, the speed and ease of development with different tools, the tradeoffs of development time vs usability, and the ecosystem around different languages and frameworks.
I think this article has the right idea. I’m not a fan of Electron, and I feel that, while overall it’s impact may have been positive, allowing apps to be made and be cross-platform that otherwise wouldn’t exist, I think it’s also created lasting consequences to the desktop app ecosystem, and it’s made me think about the standards to which we hold modern software.
To me this seems incredibly short sighted. For decades developers have wished for the holy grail of writing a program once and having it run everywhere. Browsers are realizing that dream. But oh...
To me this seems incredibly short sighted. For decades developers have wished for the holy grail of writing a program once and having it run everywhere. Browsers are realizing that dream. But oh no a 6 year old desktop wrapper isn't as performant as native apps! We better boycott the entire thing!
Electron is fine, it will develop along with the web and likely become much more refined with time.
Sure, Electron may become great. But that article is from 2016 and is still relevant. I’ll be happy to change my mind whenever Electron apps fulfill my needs. I understand it makes life easy for...
Exemplary
Sure, Electron may become great. But that article is from 2016 and is still relevant. I’ll be happy to change my mind whenever Electron apps fulfill my needs. I understand it makes life easy for developers. But currently, from this user point of view, that is just not the case.
If you use Linux, then it is likely already fulfilling your needs. Apps like Slack, Discord, and Code would almost certainly not exist on Linux if Electron didn't make it so easy for the developer.
If you use Linux, then it is likely already fulfilling your needs. Apps like Slack, Discord, and Code would almost certainly not exist on Linux if Electron didn't make it so easy for the developer.
That's irrelevant. Not supporting Linux is another way to make the job easier on the development side without properly servicing the users. The same argument stands.
That's irrelevant. Not supporting Linux is another way to make the job easier on the development side without properly servicing the users. The same argument stands.
Let me preface this with the fact that I am not a user of Slack or Discord. But I know they already have a working web interface. Does having an application that duplicates that behavior exactly...
Let me preface this with the fact that I am not a user of Slack or Discord. But I know they already have a working web interface. Does having an application that duplicates that behavior exactly in a manner that would realistically drain more resources than normal really benefit users? I assume most users will have a browser open most of the time, after all.
I don't believe that Code is a good example of software that would not exist on Linux if it were not developed with Electron. Knowing Microsoft, they would have used .NET, which runs on Linux thanks to Mono.
Beyond that, the number of programs that work on Linux does not directly link to the benefit of users. There has to be a benefit to using the application, and it has to be something that stands out from other apps. If Slack on Electron is the same as Slack on the browser of my choice, why would I install the Electron version?
These are some more tangible reasons to discuss. They do, but Slack and Discord also offer additional functionality via installation. First, both integrate with system notifications rather than...
These are some more tangible reasons to discuss.
But I know they already have a working web interface.
They do, but Slack and Discord also offer additional functionality via installation. First, both integrate with system notifications rather than using browser toasts. This offers better system integration (eg. supporting "do not disturb" modes). Second, APIs that aren't yet available in the browser can be built in node. One example is that Discord only supports true push-to-talk in the application version (as switching browser tabs breaks input detection).
I don't believe that Code is a good example of software that would not exist on Linux if it were not developed with Electron. Knowing Microsoft, they would have used .NET, which runs on Linux thanks to Mono.
That's possible, and you might be right. Though .NET on Linux wasn't as far along when Code was first published (or when development started) so there's some speculation there. We don't have enough info to say if they'd have chosen to still support Linux or not.
Beyond that, the number of programs that work on Linux does not directly link to the benefit of users. There has to be a benefit to using the application, and it has to be something that stands out from other apps.
This I can't agree with. Even if there's a tool that does the same or a similar job, it's still beneficial to have options. For example Code is very similar to Sublime Text but it offers a different extension ecosystem that might change your workflow. I was using its excellent Live Share extension just recently.
I presume you're speaking from an idealistic position - and that's okay - but most people aren't that interested in software licensing. They are more interested in being able to easily talk to...
I presume you're speaking from an idealistic position - and that's okay - but most people aren't that interested in software licensing. They are more interested in being able to easily talk to their friends and peers.
The example above was Linux users, but Electron works equally well across web or mobile (where "normal users" are more likely to be). In that respect a ubiquitous product is advantageous for all.
Your argument was that more software = net good. That's not strictly true, given that it increases the vulnerability of Linux systems, which harms the people using the software. Especially given...
I presume you're speaking from an idealistic position - and that's okay - but most people aren't that interested in software licensing. They are more interested in being able to easily talk to their friends and peers.
The example above was Linux users, but Electron works equally well across web or mobile (where "normal users" are more likely to be). In that respect a ubiquitous product is advantageous for all.
Your argument was that more software = net good. That's not strictly true, given that it increases the vulnerability of Linux systems, which harms the people using the software.
Especially given that, as per the Discord CTO, they gleefully ship Discord with a process logger that by-default opts-in to using your data for advertising, which is, by most understandings of the term, "malware."
This is really well-cited article, though obviously you shouldn't trust a neocities site at first-glance:
Programs like this are in no way a benefit to users. (I say this as someone who uses it (though not its proprietary, Electron-based client) on a daily basis.)
This is literally the selling point of Java, decades ago when it was still new. There are many other development frameworks that give you the same flexibility as well, namely qt and .NET.
For decades developers have wished for the holy grail of writing a program once and having it run everywhere.
This is literally the selling point of Java, decades ago when it was still new.
There are many other development frameworks that give you the same flexibility as well, namely qt and .NET.
Both qt and .NET are giant frameworks with many parts to them. I know for sure that there are many web applications built on .NET. What I'm trying to say is that web technologies aren't...
Both qt and .NET are giant frameworks with many parts to them. I know for sure that there are many web applications built on .NET.
What I'm trying to say is that web technologies aren't automatically the best tool for every application.
Wasn't .net supposed to be super development friendly and super net deployable? Hence the name. It was supposed to replace html "coding" and offer a WASM alternative. Then the weirdo what you see...
Wasn't .net supposed to be super development friendly and super net deployable? Hence the name. It was supposed to replace html "coding" and offer a WASM alternative. Then the weirdo what you see is what you get markup applications.
Neither Electron apps. Electron includes interfaces to OS APIs that can't be used in browser so I doubt the same app can be used in both Electron and the browser (and if that was possible, there...
Neither Electron apps. Electron includes interfaces to OS APIs that can't be used in browser so I doubt the same app can be used in both Electron and the browser (and if that was possible, there wouldn't really be a point for Electron given the web browser itself would suffice).
My experience with Java programs is not very positive. Using IDEA IDEs is very cumbersome on i3wm. I cannot make the Alt key work for the life of me, and the cursor disappears all the time if I...
My experience with Java programs is not very positive. Using IDEA IDEs is very cumbersome on i3wm. I cannot make the Alt key work for the life of me, and the cursor disappears all the time if I set focus to follow mouse. Java programs completely ignore system wide themes and don’t blend well with theme, and the windows identifiers are some cryptic mumbo jumbo that makes it impossible to set specific rules for them. All my programs play nice with the window manager, but Java is too busy doing its own thing.
Electron certainly doesn't fare any better with matching your themes; every electron application I've ever seen follows it's own style guide. I can't tell you how to solve the problems you are...
Electron certainly doesn't fare any better with matching your themes; every electron application I've ever seen follows it's own style guide.
I can't tell you how to solve the problems you are having with Java applications, but given that I use Jetbrains IDEs on my Linux system without a problem, I would venture to guess that your problem with the ALT key is in regards to how you have your system configured.
I haven't seen the problem you are having with window identifiers before either, but then again that's not a detail I ever really pay much attention to.
Swing, the UI toolkit that Jetbrains uses for all of their products, has always behaved it's own way by default. But Swing is not the only UI toolkit for Java, and I believe that the latest version of Java has actually removed it from the JDK - it's been depreciated for a while now.
I actually tried Jetbrains on i3 without any keyboard configuration whatsoever (besides the ones from i3 - and I don’t use Alt in any of my mappings) - same results :(
I actually tried Jetbrains on i3 without any keyboard configuration whatsoever (besides the ones from i3 - and I don’t use Alt in any of my mappings) - same results :(
Do you use Alt for your WM commands? I prefer Super for that function (set $mod Mod4 in your i3/config) because Alt is used in many apps. You can also try setting up a Hyper key (this sources this...
Do you use Alt for your WM commands? I prefer Super for that function (set $mod Mod4 in your i3/config) because Alt is used in many apps. You can also try setting up a Hyper key (this sources this which runs this; my dots are a bit complex, you can just use the commands in menu-as-hyper.xmodmap to make it work), but IIRC I couldn't get it to work with i3.
Electron is definitely not the holy grail of cross platform development, and I don't believe that it will ever be. It's not just slightly worse performance, it is disastrously worse. On my windows...
But oh no a 6 year old desktop wrapper isn't as performant as native apps!
Electron is definitely not the holy grail of cross platform development, and I don't believe that it will ever be. It's not just slightly worse performance, it is disastrously worse. On my windows machine, if I open this file in vscode with the Vim, Path Intellisense, and Haskell Syntax Highlighting extensions installed it uses >400MB of ram, but if I open the file (and solution) in Visual Studio it only uses ~360MB of ram. Visual Studio has many more features for C++ development, including intellisense, and it still uses less ram (and also seemingly CPU, but I am not 100% about that). If I open this file in kakoune on my linux machine kakoune + my terminal emulator uses ~60MB of ram (~15MB for kakoune, ~40MB for kitty) . Saying "isn't as performant" is just misleading, electron has terrible performance.
15MB for a non-graphical text editor? Christ. Though a Haskell user arguably doesn't have much room to talk when it comes to Electron's memory usage, given how notorious GHC is for being awful in...
15MB for a non-graphical text editor? Christ.
Though a Haskell user arguably doesn't have much room to talk when it comes to Electron's memory usage, given how notorious GHC is for being awful in that regard, and that even simple applications like pandoc are needlessly heavy.
That's less than nvim for me, unless I read the memory usage wrong. I also haven't used Haskell to make anything, that was just what I had downloaded when I opened vscode on a machine I hadn't...
That's less than nvim for me, unless I read the memory usage wrong.
I also haven't used Haskell to make anything, that was just what I had downloaded when I opened vscode on a machine I hadn't used for dev stuff in a little over a year.
But it will never be as fast or efficient as a native app, making it hell for your laptop battery. When your laptop only lasts 3 hours on battery and needs 16 gigs of RAM just to play music, run a...
But it will never be as fast or efficient as a native app, making it hell for your laptop battery. When your laptop only lasts 3 hours on battery and needs 16 gigs of RAM just to play music, run a browser, and have your email messaging clients open, that's a problem.
What Electron might become doesn't really matter. The problem is that it makes life shittier for users right now, and without users, us developers don't have a job. A big reason I haven't hopped on the music streaming bandwagon is because every single desktop music streaming app feels like a colossal piece of shit compared to foobar2000.
I wonder if Flutter will become the next Electron. From a developer point of view, it's a little bit painful to get started and get used to the nested widgets hell that you have to write, but once...
I wonder if Flutter will become the next Electron. From a developer point of view, it's a little bit painful to get started and get used to the nested widgets hell that you have to write, but once you get used to it the same code base can be use to build native code for web, mobile and desktop at the same time, and that could be huge.
I'm still curious to see specifically how performant this could be, but I guess we need to wait for a "big" popular program to appear to really see if the Dart compiler is any good for building any type of apps as they claim. But they are targeting mobile and web first specifically, so we may have to wait for a while.
As someone who wrote a (proprietary, sorry) mobile app in Flutter, I can say that unless I was doing something really stupid(1) it was as fast as I would expect of a native app. It was even...
As someone who wrote a (proprietary, sorry) mobile app in Flutter, I can say that unless I was doing something really stupid(1) it was as fast as I would expect of a native app. It was even passably fast in debug mode (which is JIT, with all the Debug stuff)
1: This happened a few times, but, it was for clear reasons that were sometimes even linted for. Like, there were a few times when the code had Opacity(Text('...'), opacity: 0.5) or something when it really should've just changed the text color (Opacity is slow when it isn't 0 or 1, since at those levels it can just pretend to be its child or be an empty box the size of its child)
Personally, I find Flutter to be a lot nicer than any other front-end framework in existence, but that isn't related to the above.
Electron is easily avoidable, I just use the web versions of everything in Chrome that’s already open anyway. Besides, it’s weird using these desktop-websites without Vimium. And as an Emacs user...
Electron is easily avoidable, I just use the web versions of everything in Chrome that’s already open anyway. Besides, it’s weird using these desktop-websites without Vimium. And as an Emacs user I can proudly ignore all the fanfare around VS Code. If Microsoft made it native it would be a harder choice.
Just a bit of a rant here, only tangentially related. The article mentions Flash one time:
I'm sorry, this is a stupid comparison. I was a developer of both Shockwave and Flash apps. Flash was incredibly lightweight. It replaced Shockwave/Director/Lingo - which had some pretty stupid overhead for its time (but of course, Java applets were the shitty low bar at the time), and the replacement was in large part directly concerned with keeping the overhead low. Flash's native video and pdf-style documents came later, and in all respects they were lighter than what they were replacing (oh God, the RealVideo pain remains with me even to this day). The problem with Flash was its ubiquity driving poor practice (a-la-php) and its innate security flaws, NOT its weight.
So here we have a great article with a distracting crap (and just plain wrong) title, and everyone nods their heads because they remember Flash being the shit it was at the end, not how shit everything was before Flash came along. Flash originally made everyone's life 100% better. I mean, I guess the point of Electron is write once, run anywhere - but Flash was brilliant at that, not shit. So again, not a good comparison.
Flash was good. Really, it was a nice platform. The biggest downside of it was that it was used excessively and that it was a proprietary add-on. If it was just another subsytem the browser could include and had a standard and was open source, it wouldn't have been murdered like it was. It would be better integrated and have had less security issues.
People hate it because of the proprietary and cumbersome nature of it, especially getting it to work on Linux w/ Firefox was troublesome; and also because there was so much negative propaganda that people went from disliking it for reasons to purely hating it because it was something you had to hate and hating it was/is cool. A bit like immigrants versus the right, really. And Apple has a fair share in this, they pushed hard for HTML5/CSS3 replacing it. And now, HTML/JS/CSS are trying to become Flash.
I wish there was something like POSIX for GUI interfaces. There is a serious platform bloat w.r.t. portable and open source UI toolkits, i.e. it is not the framework or libraries that are numerous, but the entire platforms (GTK+, QT, WxWindows, etc. don't have almost anything in common, whereas with Electron you have a common platform onto which you can build with your tools, and you don't add burden for yourself or on the users). I used VSCode out of curiosity, and performance was good (and I use a 10yo shitty laptop). Spotify is slow, but their apps are baad: they know what people come for, and they know that we'll tollerate their BS for the music they provide... Decent apps can be built with Electron. But it is a mediocre solution to an easy problem that is complicated because people.
Honestly, I remember the real biggest downside for flash was the security vulnerabilities. Flash became ubiquitous, which meant it became a giant target for black-hat hackers. Couple this with Macromedia/Adobe never coming up with a background upgrade system for Windows and Mac meant it irritated users by constantly bugging them to upgrade.
Imagine a world where adobe was open sourced. Tech companies took the fastest route to screwing users by implementing adobe's business model.
People bitch about Android as they should, without a thought to the fact you have a choice.
I applaud apple, for protecting their users. But it is a child's toy so they can maintain their walled garden. If that's your thing go for it. If you want innovation, open source is all we got.
This is a really good point, and definitely something the article should've clarified. I think a better summary of the article's comparison would be "Flash (Electron) had it's problems, but it got the job done very well, until HTML5 ($electron_replacement) came along to supersede it."
I don't think the article was trying to compare performance of Electron vs Flash, but rather show that, like Flash, Electron has drawbacks, but the article doesn't make that very clear.
I’ve been thinking a lot about the state of desktop apps recently, the speed and ease of development with different tools, the tradeoffs of development time vs usability, and the ecosystem around different languages and frameworks.
I think this article has the right idea. I’m not a fan of Electron, and I feel that, while overall it’s impact may have been positive, allowing apps to be made and be cross-platform that otherwise wouldn’t exist, I think it’s also created lasting consequences to the desktop app ecosystem, and it’s made me think about the standards to which we hold modern software.
I’m kind of rambling, but tldr: decent article :)
To me this seems incredibly short sighted. For decades developers have wished for the holy grail of writing a program once and having it run everywhere. Browsers are realizing that dream. But oh no a 6 year old desktop wrapper isn't as performant as native apps! We better boycott the entire thing!
Electron is fine, it will develop along with the web and likely become much more refined with time.
Sure, Electron may become great. But that article is from 2016 and is still relevant. I’ll be happy to change my mind whenever Electron apps fulfill my needs. I understand it makes life easy for developers. But currently, from this user point of view, that is just not the case.
If you use Linux, then it is likely already fulfilling your needs. Apps like Slack, Discord, and Code would almost certainly not exist on Linux if Electron didn't make it so easy for the developer.
That's irrelevant. Not supporting Linux is another way to make the job easier on the development side without properly servicing the users. The same argument stands.
More apps working on Linux benefits users. The question was how this benefits users over developers. So how is that possibly irrelevant?
Let me preface this with the fact that I am not a user of Slack or Discord. But I know they already have a working web interface. Does having an application that duplicates that behavior exactly in a manner that would realistically drain more resources than normal really benefit users? I assume most users will have a browser open most of the time, after all.
I don't believe that Code is a good example of software that would not exist on Linux if it were not developed with Electron. Knowing Microsoft, they would have used .NET, which runs on Linux thanks to Mono.
Beyond that, the number of programs that work on Linux does not directly link to the benefit of users. There has to be a benefit to using the application, and it has to be something that stands out from other apps. If Slack on Electron is the same as Slack on the browser of my choice, why would I install the Electron version?
These are some more tangible reasons to discuss.
They do, but Slack and Discord also offer additional functionality via installation. First, both integrate with system notifications rather than using browser toasts. This offers better system integration (eg. supporting "do not disturb" modes). Second, APIs that aren't yet available in the browser can be built in node. One example is that Discord only supports true push-to-talk in the application version (as switching browser tabs breaks input detection).
That's possible, and you might be right. Though .NET on Linux wasn't as far along when Code was first published (or when development started) so there's some speculation there. We don't have enough info to say if they'd have chosen to still support Linux or not.
This I can't agree with. Even if there's a tool that does the same or a similar job, it's still beneficial to have options. For example Code is very similar to Sublime Text but it offers a different extension ecosystem that might change your workflow. I was using its excellent Live Share extension just recently.
Not necessarily; Discord and Slack are both proprietary, so they end up harming users more than anything.
I presume you're speaking from an idealistic position - and that's okay - but most people aren't that interested in software licensing. They are more interested in being able to easily talk to their friends and peers.
The example above was Linux users, but Electron works equally well across web or mobile (where "normal users" are more likely to be). In that respect a ubiquitous product is advantageous for all.
Your argument was that more software = net good. That's not strictly true, given that it increases the vulnerability of Linux systems, which harms the people using the software.
Especially given that, as per the Discord CTO, they gleefully ship Discord with a process logger that by-default opts-in to using your data for advertising, which is, by most understandings of the term, "malware."
This is really well-cited article, though obviously you shouldn't trust a neocities site at first-glance:
https://spyware.neocities.org/articles/discord.html
Programs like this are in no way a benefit to users. (I say this as someone who uses it (though not its proprietary, Electron-based client) on a daily basis.)
A program needs more to fulfill my needs than simply existing.
I avoid all of those apps, because they are electron.
This is literally the selling point of Java, decades ago when it was still new.
There are many other development frameworks that give you the same flexibility as well, namely qt and .NET.
Maybe I'm mistaken but I don't believe a program written in QT or .NET can be accessed through the internet.
Both qt and .NET are giant frameworks with many parts to them. I know for sure that there are many web applications built on .NET.
What I'm trying to say is that web technologies aren't automatically the best tool for every application.
Wasn't .net supposed to be super development friendly and super net deployable? Hence the name. It was supposed to replace html "coding" and offer a WASM alternative. Then the weirdo what you see is what you get markup applications.
Neither Electron apps. Electron includes interfaces to OS APIs that can't be used in browser so I doubt the same app can be used in both Electron and the browser (and if that was possible, there wouldn't really be a point for Electron given the web browser itself would suffice).
My experience with Java programs is not very positive. Using IDEA IDEs is very cumbersome on i3wm. I cannot make the
Altkey work for the life of me, and the cursor disappears all the time if I set focus to follow mouse. Java programs completely ignore system wide themes and don’t blend well with theme, and the windows identifiers are some cryptic mumbo jumbo that makes it impossible to set specific rules for them. All my programs play nice with the window manager, but Java is too busy doing its own thing.Electron certainly doesn't fare any better with matching your themes; every electron application I've ever seen follows it's own style guide.
I can't tell you how to solve the problems you are having with Java applications, but given that I use Jetbrains IDEs on my Linux system without a problem, I would venture to guess that your problem with the ALT key is in regards to how you have your system configured.
I haven't seen the problem you are having with window identifiers before either, but then again that's not a detail I ever really pay much attention to.
Swing, the UI toolkit that Jetbrains uses for all of their products, has always behaved it's own way by default. But Swing is not the only UI toolkit for Java, and I believe that the latest version of Java has actually removed it from the JDK - it's been depreciated for a while now.
I actually tried Jetbrains on i3 without any keyboard configuration whatsoever (besides the ones from i3 - and I don’t use Alt in any of my mappings) - same results :(
Do you use
Altfor your WM commands? I preferSuperfor that function (set $mod Mod4in youri3/config) becauseAltis used in many apps. You can also try setting up aHyperkey (this sources this which runs this; my dots are a bit complex, you can just use the commands inmenu-as-hyper.xmodmapto make it work), but IIRC I couldn't get it to work with i3.You should bind
alttometaon i3-alike tiling wms.I only use the Super key as a modifier on i3. No Alt key whatsoever.
Electron is definitely not the holy grail of cross platform development, and I don't believe that it will ever be. It's not just slightly worse performance, it is disastrously worse. On my windows machine, if I open this file in vscode with the Vim, Path Intellisense, and Haskell Syntax Highlighting extensions installed it uses >400MB of ram, but if I open the file (and solution) in Visual Studio it only uses ~360MB of ram. Visual Studio has many more features for C++ development, including intellisense, and it still uses less ram (and also seemingly CPU, but I am not 100% about that). If I open this file in kakoune on my linux machine kakoune + my terminal emulator uses ~60MB of ram (~15MB for kakoune, ~40MB for kitty) . Saying "isn't as performant" is just misleading, electron has terrible performance.
Was it supposed to be?
The original comment seemed to imply that.
15MB for a non-graphical text editor? Christ.
Though a Haskell user arguably doesn't have much room to talk when it comes to Electron's memory usage, given how notorious GHC is for being awful in that regard, and that even simple applications like
pandocare needlessly heavy.That's less than nvim for me, unless I read the memory usage wrong.
I also haven't used Haskell to make anything, that was just what I had downloaded when I opened vscode on a machine I hadn't used for dev stuff in a little over a year.
But it will never be as fast or efficient as a native app, making it hell for your laptop battery. When your laptop only lasts 3 hours on battery and needs 16 gigs of RAM just to play music, run a browser, and have your email messaging clients open, that's a problem.
What Electron might become doesn't really matter. The problem is that it makes life shittier for users right now, and without users, us developers don't have a job. A big reason I haven't hopped on the music streaming bandwagon is because every single desktop music streaming app feels like a colossal piece of shit compared to foobar2000.
15 million uncommented lines of code? Why? Do they scrub comments before release?
My problem is why wrap a browser, like, at all?
Just run it in a browser...
I wonder if Flutter will become the next Electron. From a developer point of view, it's a little bit painful to get started and get used to the nested widgets hell that you have to write, but once you get used to it the same code base can be use to build native code for web, mobile and desktop at the same time, and that could be huge.
I'm still curious to see specifically how performant this could be, but I guess we need to wait for a "big" popular program to appear to really see if the Dart compiler is any good for building any type of apps as they claim. But they are targeting mobile and web first specifically, so we may have to wait for a while.
As someone who wrote a (proprietary, sorry) mobile app in Flutter, I can say that unless I was doing something really stupid(1) it was as fast as I would expect of a native app. It was even passably fast in debug mode (which is JIT, with all the Debug stuff)
1: This happened a few times, but, it was for clear reasons that were sometimes even linted for. Like, there were a few times when the code had
Opacity(Text('...'), opacity: 0.5)or something when it really should've just changed the text color (Opacityis slow when it isn't 0 or 1, since at those levels it can just pretend to be itschildor be an empty box the size of itschild)Personally, I find Flutter to be a lot nicer than any other front-end framework in existence, but that isn't related to the above.
I have my eyes on Revery. It's looking really nice so far.
https://github.com/revery-ui/revery
Electron is easily avoidable, I just use the web versions of everything in Chrome that’s already open anyway. Besides, it’s weird using these desktop-websites without Vimium. And as an Emacs user I can proudly ignore all the fanfare around VS Code. If Microsoft made it native it would be a harder choice.
For now I’m happily Electron free.
hahaha
Sorry. I'm a vimium user too, but to say "weird" ...
using Vimium is weird.
It’s my normal! Hahaha