4 ms·

Electron is Flash for the Desktop. History is repeating. Instead of investing into hard work and portability with programmers, the management decides to take t

Electron is Flash for the Desktop. History is repeating. Instead of investing into hard work and portability with programmers, the management decides to take the short part which looks cheap. The result are bloated, memory hungry applications which do not integrate well into the operating system and native toolkits. The last part is maybe not so much noticed on Windows but Linux and Mac users notice it. These companies save money with Electron and the customers have to pay with hardware, reliability and usability. In times of soldered main-memory the memory consumption is a huge issue for everyone. I recommend using native toolkits like Gtk, Qt or Win32 (currently maybe WinUI?) and using appropriate languages (language bindings for important languages are available). Some nice application developers actually store data locally, therefore the applications are working fast and self-reliant. Imaging a chat application which doesn't lag and doesn't repeatedly load the conversation from the server just because you're scrolling upwards. A little bit off-topic ;)

mavhc 5y ago
Imagine a chat application you had to install instead of just going to a website
- Nicksil 5y ago
  >Imagine a chat application you had to install instead of just going to a website This is a bit of a bizarre argument. When using a chat app on a web site, your browser downloads the source, unpacks it, then executes in a runtime on your machine. You're doing the same thing, otherwise the app wouldn't work. You also had to first download and install the web browser used to download and install the chat app.
- Brian_K_White 5y ago
  Imagine allowing a web site to be my gateway to chatting with people not on that web site. Imagine letting a web site decide what features I should have in my chat client.
  - mavhc 5y ago
    Well, that is the fundamental split between specifying a bunch of features and letting people write clients, vs closely linking the features and clients together. When I can update my web client every day with a new feature, the advantage of not having an open standard is higher, I can invent new features in days rather than the years it's taken IRC to add things
the_spacebyte 5y ago
> History is repeating. Instead of investing into hard work and portability with programmers, the management decides to take the short part which looks cheap. I agree with this point of view for bigger companies that do chat and music streaming apps. Nonetheless if you're a __much__ smaller company who needs to do cross-compat. applications and has problems hiring personnel (either due to lack of, or too expensive) technologies like Electron saves them a lot of trouble, money and time...
mrjin 5y ago
Well, I guess it's JavaScript to blame. But well, maybe it's unfair to blame JavaScript which was implemented in 10 days and not meant for large/serious applications. How much can you expect from 10 days worth of work of a single man? But the reality is that now almost everyone is trying to build something if not everything with JavaScript. The reason behind all this might be all the sudden, we have so much computing power to abuse.
- yunohn 5y ago
  > How much can you expect from 10 days worth of work of a single man? You are aware that ECMA exists? And that JS has been updated quite a bit to align with modern use cases.

mavhc 5y ago

Imagine a chat application you had to install instead of just going to a website

Nicksil 5y ago
>Imagine a chat application you had to install instead of just going to a website This is a bit of a bizarre argument. When using a chat app on a web site, your browser downloads the source, unpacks it, then executes in a runtime on your machine. You're doing the same thing, otherwise the app wouldn't work. You also had to first download and install the web browser used to download and install the chat app.
Brian_K_White 5y ago
Imagine allowing a web site to be my gateway to chatting with people not on that web site. Imagine letting a web site decide what features I should have in my chat client.
- mavhc 5y ago
  Well, that is the fundamental split between specifying a bunch of features and letting people write clients, vs closely linking the features and clients together. When I can update my web client every day with a new feature, the advantage of not having an open standard is higher, I can invent new features in days rather than the years it's taken IRC to add things

the_spacebyte 5y ago

> History is repeating. Instead of investing into hard work and portability with programmers, the management decides to take the short part which looks cheap. I agree with this point of view for bigger companies that do chat and music streaming apps. Nonetheless if you're a __much__ smaller company who needs to do cross-compat. applications and has problems hiring personnel (either due to lack of, or too expensive) technologies like Electron saves them a lot of trouble, money and time...

mrjin 5y ago

Well, I guess it's JavaScript to blame. But well, maybe it's unfair to blame JavaScript which was implemented in 10 days and not meant for large/serious applications. How much can you expect from 10 days worth of work of a single man? But the reality is that now almost everyone is trying to build something if not everything with JavaScript. The reason behind all this might be all the sudden, we have so much computing power to abuse.

yunohn 5y ago
> How much can you expect from 10 days worth of work of a single man? You are aware that ECMA exists? And that JS has been updated quite a bit to align with modern use cases.