Comment by slumpt_
5 years ago
You can build snappy UIs with Electron. It’s easy to conflate organizational bloat’s consequences with something intrinsic to Electron.
Edit:
Upset downvoters care to elaborate? Or just huffing into the void?
5 years ago
You can build snappy UIs with Electron. It’s easy to conflate organizational bloat’s consequences with something intrinsic to Electron.
Edit:
Upset downvoters care to elaborate? Or just huffing into the void?
Didn't downvote, but can you name a couple of Electron apps that are sna...,hell,.. not sluggish?
People usually point to VSCode...If that is the epitome of a responsive, lag-free software then I claim Electron defenders haven't seen snappy application.
Do people even remember Winamp?
I built an Electron app Video Hub App and it's fast:
https://github.com/whyboris/Video-Hub-App
Electron is overkill for a todo app that you want users to open/close many times per day. But if it's an app that's used for 90% while it's open and is used a few times per week, who cares if it takes 2 seconds to start?
I don't understand what everyone is moaning about with Electron. My app uses 130mb of RAM -- is that too much to ask for, for a dedicated video browser?
ps - here's also a file renamer I built with Electron: https://github.com/whyboris/Simplest-File-Renamer
In my experience, my VSCode setup responds just as fast as my fully extended VIM does.
Are you remoting into your vim on a satellite link or some really far away box somewhere?
I see no other rational explanation here
Somethings wrong with your vim setup then.
I barely have released the return key after typing mvim and the macvim window is already there. Even Sublime is not that fast.
Aside from the initial load that all Electron apps suffer from, Insomnia feels pretty snappy to me. Granted, I only have a few dozens of API that load 20KB of JSON max.
https://insomnia.rest/
I love Insomnia and usually recommend it to others.
But I remember a few months ago I was developing a basic API and testing it through Insomnia. At first, I almost had a heart attack seeing the time it took to answer, between clicking "send" and getting a response back. All this running on localhost, on an old but fairly powerful box (i7-3930k, 64 GB ram). My first reaction was I must have had some sleep() lying around.
Then I looked at the details, and the actual time taken handling the call, etc, as reported by Insomnia was a few ms, all the rest was... I don't know what.
But I do agree than other than that, when interacting with the app itself (switch requests, type, etc) it feels snappy enough. I usually use it alongside IntelliJ, which while fairly fast, isn't terminal-level instantaneous.
Maybe try elaborating yourself? The constant criticism of Electron Apps is that they're bloated and slow, you're claiming otherwise but missed the part providing any presumption of evidence to the contrary.
I've yet to experience any Electron App that's close to the snappiness and UX of the original native Spotify client, I'd like to hear about good examples of Electron Apps comparable to it.
Electron adds no more overhead than Chrome does. Any snappy web app can be packaged as an Electron app and be equally snappy. So if there are no snappy Electron apps it's because of the web, not Electron.
> So if there are no snappy Electron apps it's because of the web, not Electron.
That is, indeed, the argument, except without the "if" part.
The web is filled with bloated and slow web applications. This is nothing new. Electron is taking the fall for existing on a popular platform that lots of fast moving companies are using and unfortunately gumming up with feature creep and poor architectural design.
I don’t care to share details of my past employers but I have absolutely worked on web apps that ran 60 Hz on mobile and looked beautiful to boot.
It was a team of senior devs though, and it was a small shop. We didn’t suffer from the same organizational issues at the time but as we grew, sure enough - the web application slowed as the need to move quickly and cut corners arose.
The point is that the web offers you a vast array of performance footguns that anyone on a tight schedule is going to wind up firing off at one time or another. Electron isn’t to blame. It’s architecture and code practices.
But the web is easy to hate, and by association Electron is going to take a ton of flack.
Right, so still no evidence despite continuing to claim otherwise. Lets start off easy, what's the best example of a publicly downloadable Electron App that has the snappiest UX?
Having experienced the original Spotify App myself and having used many Electron Apps daily for years I'd posit that it's naive to claim the responsiveness and snappiness of the original Spotify App could ever be reimplemented in Electron. You're claiming it is, so lets hear about some examples we can actually use?
8 replies →
It doesn't matter if that rotating loading indicator icon is rendered at 120hz or how fancy the boot animation is presenting latest commodities of the company shop...
When I open a software, I did so for a purpose, and I expect to actually do the thing as fast as possible and be done with UI...that's the reason why TUI apps are popular with power-users
6 replies →
Web technologies are default-slow while native (except Java on Android) is typically default-fast. One needs to go out of their way to create a slow native app, even if it's of course possible.
Slowness is the natural state of web applications and creating a fast web application is much more difficult and requires a senior team with knowledge about browser implementation in order to avoid or work around the performance pitfalls.
I also have the feeling that such performance comparisons are done with the assumption that the apps under test are almost the only thing running on the machine. If every applications were to start 10 processes taking 1 GB of RAM things would get uncomfortably slow.
3 replies →
Up-voted for the same reason as the edit - I'd love to hear some fact based arguments why this comment should be down voted (why it's not possible to build performant applications with Electron)
Op did not provide a single example of an Electron app that competes with native performance. When pushed, they became indignant and said that they have personally worked on several snappy Electron apps, which, however are secret. Also, there are apparently no other examples of Electron apps readily at hand.
So we end up where we were, with VsCode as singular example, and in turn, with the distinctive suspicion that the inability of anyone to point to even one decently performing Electron app may just simply be because Electron is not very good.
The downvotes then probably arise from the fact that this argument has been replayed on HN hundreds of times.
It’s nothing to do with Electron specifically and everything to do with the web as a platform and the requisite work to make performant apps.
It’s certainly an easy fall-person for their performance issues, but it seems just as reasonable to blame an ever-expanding feature set, including advertisements and all of the analytics to go with, along with a great deal of just… age? Spotify isn’t a young company anymore, and they’ve been maintaining their shop for long enough that the kitchen sink is undoubtedly strapped to their app by now.
Can it send e-mails?