I have access to a lot of stuff on Linux that I wouldn’t otherwise…and a lot of RAM.
Same here, I have 32gb RAM but I checked few times and it seems my Atom is not as memory hungry as mentioned by others.
On the other hand its OS support and extendability are really cool. Not being a fan of JS I can’t ignore that it has the most UI tools today and one can consider Desktop as just another front end, so the whole idea of using JS to develop it is not that weird.
Eh, I actually spend most of my time in consoles, I LOVE terminal apps, terminal chat apps, terminal browser (mostly elinks), etc… I hate electron in most of my time. ^.^;
That really sounds like some bad C++ programming, first of all WAY too many programmers, like what the frick I have to ask?! o.O
I’d bet the programmer count alone was the primary contributer to what went wrong there. Second is that the QT API is even easier in C++ than in Python (I say anyway, it catches most communication bugs where the python versions do not except at runtime). QT is really easy, I think it’s API has some issues, but it is one of the if not the best multi-platform GUI’s (even maybe of non-multi-platform) out. A fantastic mix of power and speed both (though that moc tool needs to die off already, there is no point to it anymore…).
Java is not a bad multi-platform decently-fast language either, the huge runtime that you have to install sucks, but at least it is done once unlike electron apps, and JavaFX (the GUI system in modern Java’s) is actually pretty awesome! ^.^
I just consider those that do not want to advanced and learn (even outside of work) as those not worth working with, though I may be biased as I do teacher’y things in real life… >.>
OgodsIFeelForYou…
I prefer to break up C++ apps into more smaller dependencies (and use CMake’s Hunter.sh Dependency Management System to bring it all together). That size alone would make me rip it into pieces as quick as I could… >.>
Uh, what?
In Windows here at work right now at this very moment:
Slack: 553,616 KB
Discord: 201,220 KB
Windows Calculator Application: 32176 KB (the heck for a calculator app, stupid .NET programs…)
Chrome: Over 7 gigs
Atom: I’m not loading this right now, not enough free RAM… >.>
I’m thinking you did not look at the committed memory to things like Slack and so forth, you appear to be WAY off…
Electron honestly is not ‘that’ bad, just most javascript programmers are not good programmers and do not know more of the details of the system they are programming for.
I’d use QT, for native GUI’s I do not consider that there are really any other options, QT is just awesome, and there are TONS of language bindings (I’ve even seen javascript ones somewhere), or just use QTQuick2+ (part of QT) that is basically javascript scripting of the GUI’s (bound to another language’s components though).
Like egads GTK-anything sucks. I really really dislike the GTK GUI kit, it is a model of misdesign in so many ways… >.>
I still don’t see what is native about react native, it still seems it is running in a javascript sandbox, which is quite the opposite of native…
Kotlin has some great interfaces to JavaFX!
That’s it, I bet they did not calculate it properly.
It’s not that it is actually compressed, but rather it is unloaded (paged out, in addition to being compressed).
I’ve seen one for QT somewhere as I recall, forget where. Or just use QTQuick2+ straight for the raw-GUI part (using a better language for the actual work).
That’s the problem, you should use the windows performance, er, whatever it’s called, it gets you more information.
Electron is basically Chrome(ium) you do know yes? Just restricted to one tab. And Chrome(ium) is an engine that hosts a javascript sandbox, crazy-complex (overly so) rendering engine, etc…
Sure they could use native languages. Any developer worth anything at all can pick up any other language with relative ease, it is the API’s that take up most of the learning time, not the concepts, and if you know, say, QT, then it has a similar API in a dozen languages it works with.
Seem pretty easy to me, could just use PyQT to whip up things even faster than Electron even. ^.^
Hmm, I think you’d prefer to learn Haxe then. It compiles to more languages than about any other that I’ve ever heard of, including it can compile to C++, Java, Javascript, and over a dozen other things. You could use it as the front-end language to compile to tons of other things, and Haxe has been around for over a decade and has a rather large community with tons of bindings.
Yeah like I keep trying IntelliJ, but it is just so memory hungry and has *so*many* freezes that I just keep going back to KDevelop for my C++ work. KDevelop is a fantastic C++ IDE and I wish more language IDE’s were like it.
I don’t, I only have 16 gigs at home and my motherboard is maxed out… >.>
So… yeah I have a LOT of running things on my desktop computer… I’m also using 12.9G out of 16G(15.7G) of RAM and 13.2G of 16G of Swp… >.>
Most of it is Chrome… Though I do have about 15-20 apps I routinely use in a given hour, sometimes more.
Actually you probably would. The BEAM is actually quite well optimized because it is a more limited language than javascript (not less capable, just limited dynamism, which allows it to be quite faster for a lot of work).
And there are GUI programs written on the BEAM, other than built-in ones like Observer, there are also standalone programs like the free 3D Modeler (yes, a 3D Modeler written in Erlang) called Wings3D.
I feel a twinge of horror when I see another electron app because that means it is not going to be using my native GUI’s, native GUI coloring, native notifications, will not have a commandline interface (it’s possible to do it, but I’ve not seen any electron app actually do it yet), etc…
It’s just reskinned Chrome(ium).
Uh what? I’ve never had such issues in QT. That sounds like the developers had no clue what they were doing, not at all ‘competent’ by any stretch.
Qt actually has some fantastic threading primitives, workers, etc… Again, what?! o.O
Qt actually does a lot to make more code ‘faster’ than the equivalent native OS calls that most people would write. Again this sounds like the programmers did not know what they were doing…
Atom is only eating ~200megs here right now. I notice it tends to really fail over bad when opening big files with lots of, say, syntax coloring or so, then it get eat multiple gigs pretty easily. That is more of a fault of it being an embedded web browser and using a costly DOM than really the coding fault in this case though (VSCode has similar issues).
Except that ‘Javascript The Language’ is bad in general, though that is the place for another thread/rant.
Ending…
However, overall I don’t think electron itself is bad, just that, hmm, 99% of the code written on top of it is utter crap, and although javascript helps and encourages developers to write bad code instead of good code, you don’t have to write bad code in javascript, just that most coders are not knowledgeable enough to write half-decent code (‘ooo let’s copy-paste this from stack overflow, yay done!’).
yes, I agree here, I also think it’s bad. My point is that this bad language already got many good tools to build UIs that better languages will not have any time soon
Agree with just about everything said, except QT although it is indeed very easy especially with QT quick, is expenseive if going to release as a solo developer (last time I checked license fee was like 500 a month or something, pretty big overhead for a lone dev). So, I’d preface that with if we are talking about Open Source
Their license structure is a bit confusing so I may have got that wrong… (Hopefully I am wrong , please correct me if I am)
And one thing I remembered now, somehow all those Electron apps installers, when on windows, try to kill my small SSD system drive They won’t let me choose where do I want to install it, and they put themselves into C:\Users\__USER__\AppData\Local\__APP_NAME__. How the hell we came back from times when every windows app asked you where do you want to install it, to some bullshit “one-click-I-kill-your-system-drive-installers”? That really pisses me off. Even Steam ask you where to install before every game installation.
Not to ask where to install is the fault of the installers, not having moved Users to a magnetic drive is yours… Its commonly a high frequent write folder and as such has nothing to search on an SSD… At least thats my opinion…
There seems to be a certain obsession with one-click installers in the Electron community. Not only the officially supported/suggested Squirrel installer goes that route, also a community-supported NSIS-based alternative does that.
After changing my computer, I have only one slow big magnetic drive for daily backups. Why would I move any of my frequently used programs/files/whatever move to this slow drive?
I think there is a big contradiction in this sentence. If its frequently used folder (it’s not only frequently written, but also frequently read) it’s place is especially on fast drive, so you have quick access to it.
I’m not saying you have to, but if you have some spare time, try to run few programs, preferably with lot of config/work data, once having this config/data on fast SSD, and second time on a 7200 RPM HDD. And tell me you’re not seeing noticeable difference.
On a side note, having fast sdd with config on it makes going through uefi/bios POST routine slower than the actual system boot, and manually starting Firefox with dozen of tabs from last session.
You told they were busting your small SSD by not asking where to install, now you are telling you do not even have an alternative place to put them but your SSD? So even if they were assking you, you were only able to change the place from which they were busting your SSD…
I’ve learnt it were best to not ever write on an SSD after installation because of limited write cycles. And even though I think thats exaggerated a lot, it does tell some truth, since the number of writes is limited.
Personally I am still tied to spinning/magnetic drives, since they are affordable and give me terrabytes of space…
My small SSD system drive. I have small, but very fast NVMe m.2 drive. And there’s huge difference between fast m.2 drive, and slow sata ssd drive (maybe not so much perceivable as between SSD and HDD, but in terms of raw speed it’s much bigger). I simply don’t want to pollute my system drive with immutable read once in run cycle data. The same way you want your /home directory on faster drive than the rest of your Linux installation.
I urge you to read how much data can be written on SSD drives. This is fine example of an endurance test.: The SSD Endurance Experiment: They're all dead - The Tech Report in short out of many 240gb drives tested one that died earliest written 700TB of data. Even if the lifespan of SDD’s was only 100TB, to kill it in a year you’d have to write 27 GB daily, to kill it in thee years you’d have to write ~10 GB daily.
Same as on Windows I guess. They have internal counter Wear_Leveling_Count and it’s… behold… percentage 100% meaning we’re good, 0% we starting to really die, but we should be perfectly safe before we actually hit 0%, as 0% does not mean the actual death, but rather only reaching what was guaranteed by manufacturer.
So actually it’s different ID in different drives. In your case I assume it’s
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
202 Percent_Lifetime_Used 0x0031 084 084 000 Pre-fail Offline - 16
And this Samsung of mine was was serving me as system drive daily for at least last 5 years. First as my home windows system drive, then as my home system linux drive, now at my workplace as linux system drive. Funny thing, my ~7 years desktop has way more performance than the last year Macbook Air my company has given me It’s weight way more though
It looks ancient on other platforms, doesn’t look native anywhere (it does its ‘own’ rendering), missing a lot of features, has concurrency issues that I’ve ran in to repeatedly, in addition to what @wmnnd said among much much more. It is one of those things that I could rant about. ^.^;