It can't be just me, that demo is so janky - exactly how I expect most electron apps to turn out.
Portal Windows for Electron
41–50 of 52 posts
Re: Portal Windows for Electron
#42Earlier quoted context omitted.
Disagree fully. As an app I feel Discord is slow (on an Intel 9700K), clunky, and not really intuitive. Just the text input delay is noticeably slower than example Word or Sublime text. I'm only member of 6 channels and have maybe only that many private messages open at a time, maybe it becomes more intuitive it there are more? But I don't understand how that would be. One thing that is extra annoying is that the set…
Over-100-server lurker here. I majoritarily use servers, not DMs, and could see why people that use a lot of DMs would find the layout inconvenient. I think the UI mostly makes sense, it has a hierarchy from left to right, so it is essentially a amped-up tree-view. You could argue for actually using a tree view (a la TeamSpeak), at least on desktop, and I wouldn't disagree, but it kind of makes sense given parity wit…
> It uses 156 megabytes of memory even on this high-volume scenario, so I would say that while baseline performance is low, it doesn't get slower, which is good.
no ! it's not good ! this mindset is why everything sucks :( at no point one should have to accept that "baseline performance is low" for a software developed by a multi-hundred-million-dollar company that was almost bought by MS for a few billions
Re: Portal Windows for Electron
#43Earlier quoted context omitted.
Because it's cheaper, quicker and the vast majority of users are fine with it. I'm not excusing it, I curse Slack every day I have to use their Electron app (though mostly just use it in a browser tab now) but we have this exact same conversation every time anything about Electron is posted on HN. None of the parameters for making the choice have changed since the last time we did.
The real reason is that the people making electron apps don't know how to make stuff in C++ and don't want to try. This might be a little more excusable before C++11 or if trying to avoid MFC and/or doing everything with win32, but modern C++ and GUI libraries like FLTK, Juce, Qt, etc. are a pretty great way to make something. A FLTK program can start at 100KB without dependencies.
In what world is building an application in a language like C++ when the rest of your tech is built on javascript/java/go ever economical or excusable for a business?
And don't tell me development time will be remotely similar either.
Re: Portal Windows for Electron
#44Earlier quoted context omitted.
- you want to make sure that people respect the importance of your app by not running it along with everything else because it needs 10x the amount of resources a native app would
Users don't care anymore. Phones have 12GB of RAM. A $500 laptop will have plenty of RAM, CPU power, and storage for the average user to not even notice anything. HN and reddit are the only ones who can't seem to grasp the idea that it's not 1995 anymore, and apps taking even 1-2 GB of RAM isn't that big of a deal for the average user. Do I want my CAD software as an electron app. Obviously not, but for most applicat…
> and apps taking even 1-2 GB of RAM isn't that big of a deal for the average user.
I live in France, a first world country, just checked Amazon, the N°1 best seller laptop currently has 4GB of RAM, a 64GB SSD, and a 1366x768 screen and a dual-core Intel Celeron CPU which does not even reach 3Ghz: https://www.amazon.fr/HP-14s-dq0000sf-Ultraportable-Microsof...
this is what the average user looks like (and will still look like in a few years, if people buy a laptop today it's generally to keep it 5 years). I have never ever ever seen anyone say "hey, my computer is fast" it's always "do you think you could look at it, it's super slow / it has viruses / ..."
Re: Portal Windows for Electron
#45Earlier quoted context omitted.
The real reason is that the people making electron apps don't know how to make stuff in C++ and don't want to try. This might be a little more excusable before C++11 or if trying to avoid MFC and/or doing everything with win32, but modern C++ and GUI libraries like FLTK, Juce, Qt, etc. are a pretty great way to make something. A FLTK program can start at 100KB without dependencies.
In what world is building an application in a language like C++ when the rest of your tech is built on javascript/java/go ever economical or excusable for a business? And don't tell me development time will be remotely similar either.
> when the rest of your tech is built on javascript/java/go
Where does this come from? This is a program being distributed to other people.
> And don't tell me development time will be remotely similar either.
It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need. There is no memory management to be found, just moving variables when returning them from an inner scope.
Then you have a single binary that is incredibly fast on any modern computer and even many that aren't so modern any more.
Re: Portal Windows for Electron
#46I do so enjoy observing the 'birth & death' of javascript unfolding
Re: Portal Windows for Electron
#47Earlier quoted context omitted.
In what world is building an application in a language like C++ when the rest of your tech is built on javascript/java/go ever economical or excusable for a business? And don't tell me development time will be remotely similar either.
> when the rest of your tech is built on javascript/java/go Where does this come from? This is a program being distributed to other people . > And don't tell me development time will be remotely similar either. It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need. There is no memory management to be found, just…
> This is a program being distributed to other people
What does this have to do with anything? Everyone in the company works on 3 languages. Introducing a new language, with new runtimes and build tools and domain expertise introduces a ton of overhead.
> It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need.
Every tool set has its own set of idiosyncrasies and bugs and general bs that has to be learned. Saying that introducing a new set of tools is cost free is a stupid lie.
Re: Portal Windows for Electron
#48Why not just write a native application?
Here's a few very valid reasons imo - Easy cross platform support - Singular language/framework (typescript/react) for everything you're doing - Can share a lot of components/logic with mobile apps if you use React Native
Yea, these are poor reasons imho. Relying on mommy Chrome and the hellscape of ECMA transpilers seems like the opposite of "cross platform" since you rely on a much more unstable foundation...
Re: Portal Windows for Electron
#49Earlier quoted context omitted.
> when the rest of your tech is built on javascript/java/go Where does this come from? This is a program being distributed to other people . > And don't tell me development time will be remotely similar either. It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need. There is no memory management to be found, just…
> This is a program being distributed to other people What does this have to do with anything? Everyone in the company works on 3 languages. Introducing a new language, with new runtimes and build tools and domain expertise introduces a ton of overhead. > It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need. Eve…
You moved the goalposts so far you are saying exactly what I said in my first message. People don't make native programs because they don't know how and don't want to learn, even though it is what people want.
Re: Portal Windows for Electron
#50Earlier quoted context omitted.
Over-100-server lurker here. I majoritarily use servers, not DMs, and could see why people that use a lot of DMs would find the layout inconvenient. I think the UI mostly makes sense, it has a hierarchy from left to right, so it is essentially a amped-up tree-view. You could argue for actually using a tree view (a la TeamSpeak), at least on desktop, and I wouldn't disagree, but it kind of makes sense given parity wit…
> It uses 156 megabytes of memory even on this high-volume scenario, so I would say that while baseline performance is low, it doesn't get slower, which is good. no ! it's not good ! this mindset is why everything sucks :( at no point one should have to accept that "baseline performance is low" for a software developed by a multi-hundred-million-dollar company that was almost bought by MS for a few billions
I agree in principle, but I find the program extremely useful and the performance is totally acceptable for my use-case.
I want a chat program that is: - Tolerable to use - Does not require, incessant fiddling to get to work right (it's OK if it could allow so to get it to work even better) - Has some sort of rich-text formatting - Good, low-latency voice - Tolerable video or screen sharing - I can onboard people easily - Is group-oriented, not 1-to-1-oriented - Bonus points if it has reasonable moderation tools for guests or similar
If not for Discord, I would be using something like Slack (which somehow manages to have concurrency issues when typing and some jank occurs, uses 3x the memory, and does not scale nearly as well for multiple workspaces), TeamSpeak (which has very obscure UX, requires self-hosting, and doesn't provide a reasonable rich-text-chat), Matrix (I have to either pick an equally-bloated Electron client or one of the many incomplete native clients), or something else.
The fact is that raw performance itself is rather low in my list of priorities, as long as it a) doesn't stop my train of thought and b) does not overburden my system unnecessarily when idle.
As you can see all of that is very much subjective, I'm not saying you are wrong to demand utmost performance. I also try to strive for it in the programs I write, but when consuming I prioritize stability and features.