5 ms·

I'm happy and grateful for any and all open source software, because it enriches everybody, well beyond the scope of its creators. But someone has to say it: E

by etatoby 10y ago

I'm happy and grateful for any and all open source software, because it enriches everybody, well beyond the scope of its creators. But someone has to say it: Electron is the cancer that is killing desktop computing. It all started years ago with Firefox, whose interface itself was built using web technologies, in a "brilliant stroke." DOM, CSS, Javascript... maybe not HTML per se, but an XML substitute, and so on. I dare anybody say that Firefox's interface has ever felt as fast as IE, Chrome, Opera, or Safari (on Mac.) It never did and still does not. Then someone at GitHub had the bright idea to take this "winning" concept and apply it to a developer's text editor, of all things! I still cannot fathom how Atom can have more than 3 users. Every time I've tried it, I've ditched it after 30 seconds. Slooooooooooow! Fast-forward to 2016: now I see new Electron apps popping up every other day. Even something as simple as a text-only WhatsApp IM client, which could be written in a dozen of C++ files, is a bloated monstrosity that eats RAM for breakfast and contains an entire Node.js interpreter and a Webkit layout engine. Cancer, I say! Kill it with fire!

oceanswave 10y ago
And this is only one example, there's NW.JS too, and Coherent Labs and Awesomium.. not to mention UWP apps... plus look at all the apps that leverage some sort of extensibility through JavaScript (Looking at you Creative Cloud and Office suites) Burn them all down BURRRRRRRNNNNNN!!! /s
tracker1 10y ago
I agree that Atom itself seems very slow, but VS Code tends to run great, and I really appreciate the feature set that it offers. As it stands, it's not a great use case for many types of applications, but I would say that it's good enough for most of them. Beyond this, people are building useful things with it quickly. Far more quickly than they would be able to if they were targeting a custom UI platform, or with a lower level language like C/C++ etc. All this with the ability to relatively easily build for Windows, OSX and Linux deployments. I don't mind people using XML based UI composition, as it works pretty well. Flex, XAML, and many other UI builders are XML based, simply because the structure corresponds well to the rendering hierarchy of components, and allows for easier understanding of their relative interactions. I am half surprised there isn't a path towards a ReactNative for Desktop (OSX, Windows, Linix) at this point, that is similar to Electron, Node/V8 core, but with a common/reduced component set that just works. It's worth mentioning that the underlying platform is C/C++ based with a very flexible UI kit (HTML) and a DSL (JavaScript + DOM) that is also flexible.
- mkhalil 10y ago
  There is ReactNative for Mac OSX. https://github.com/ptmt/react-native-desktop https://github.com/ptmt/react-native-desktop Not official though, but it's getting some use out there.
- WorldMaker 10y ago
  The recently announced React Native for the Universal Windows Platform would also support desktop.
marmaduke 10y ago
I heard people made the same complaints about emacs once. Emacs is.. lightning fast compared to these new web ui editors.
- JBReefer 10y ago
  Computers have gotten much faster since Emacs was born, but your point stands
jokoon 10y ago
I'm glad to read somebody else who also shares my view on that. HTML has been great to make the web great without microsoft attempt to monopolize it, but markup languages are useless as a file format you send across the internet. Why? Because parsing text is, and will ALWAYS be slow. So either pre-parse html and put this in an OPEN binary file format, or burn it with fire. Why can't investors and other developer take a damn hint that there is a reason smartphones use applications instead of web apps: html, dom, js, css all those things are slow and totally not well designed ! If you want to know more, start with that video that talks about the messy process that was HTML standardization https://www.youtube.com/watch?v=RH0o-QjnwDg https://www.youtube.com/watch?v=RH0o-QjnwDg HTML is not a strict language, meaning it's EVEN SLOWER to parse. Wake up sheeple (sorry that was unnecessary)
- deleted 10y ago
  [deleted]
- nilliams 10y ago
  Sorry, this is just wrong. The time to parse CSS + HTML is negligible and isn't a reason native is better. Native apps have a better foothold currently because mobile platforms had better support for their own native languages, than for sophisticated web runtimes like V8 at release.
  - millstone 10y ago
    The runtime isn't what matters, the touch-first UI toolkit and OS integration story is. The web came to mobile with lots of desktop baggage: scrolling, hover, "px", CPU-driven animations, etc. That's what makes it awkward on mobile.
    - deleted 10y ago
      [deleted]
  - jokoon 10y ago
    The problem is "sophisticated". You can't have speed with "sophisticated" if that platform you are releasing software on is "sophisticated". At its base, the system must be simple enough. If AT LEAST html would be a strict language like xml is, maybe that'd be better. But XML is not even human readable. YAML is.
msoad 10y ago
I run Slack, VSCode, my development server in Node.js and Chrome on my machine. Now count how many copies of Node.js and WebKit or Blink I have on my machine. A shared browser engine could replace all of Electron apps (wink wink Chrome desktop apps) only if we had it right when we started.
gnuvince 10y ago
Recently in a lobste.rs discussion thread, I wondered how people would react to programmers using PDF as an application platform: use a scripting language to update the content of the PDF file on the fly and in response to user events. I'm quite certain that most, if not all, users would shun these applications as they would be slow, unresponsive and ultimately trying to use a technology for static documents to develop dynamic and interactive content (i.e. wrong tool for the job). I feel that this is exactly what is happening with web applications and projects like Electron. And then a user pointed out that Acrobat Reader can actually do that already [1]. [1] http://www.adobe.com/devnet/acrobat/javascript.html http://www.adobe.com/devnet/acrobat/javascript.html
- thisisdave 10y ago
  Not a great example. Apple's graphics layer on OS X is very closely tied to PDF, and basically uses the Adobe Imaging Model that PDF is based on. It actually does include a PDF-based scripting language for drawing and updating shapes on the screen.
nilliams 10y ago
This attitude seems ignorant of the facts and the unfortunate state of desktop development. Perhaps the cancer is the fact the desktop development community has had decades to settle on a decent cross-platform 'native' toolkit and completely failed. Perhaps the cancer is 'native' developers spouting 'native is better' hyperbole, ignorant of the fact these supposedly better 'native' toolkits have been web-influenced for a long time. - XAML from C#/WPF land being strongly influenced by HTML and CSS. - Android XML being strongly influenced by HTML and CSS. - Qt Quick being strongly influenced by JS and CSS. - GTK+ embracing JS and CSS3. - Everything else being awful procedural C++. Good luck maintaining that. And all have massively inferior developer tools than Chrome devtools and/or far worse abstractions for the scene-graph/tree of elements than the much-derided yet very powerful DOM. Native desktop is a mess. I'm glad we're seeing Electron expose it for the joke that it is. You can hate web dev tech, but you can't claim that native desktop options are better. I won't be building apps 3 times or using any of these useless 'cross-platform' dev kits anytime soon, when I can build the same thing in Electron in a fraction of the time, and leverage the undeniably huge JS and CSS communities. Also very tired of seeing devs use weasel-words like 'bloat' and neglect to put it into any context, like the fact that on the desktop 1. it ain't bloat if filesize is cheap, and 2. said filesize is comparable to the most capable cross-plat options you're supposedly arguing for (see Qt Quick). Edit: Softened, expanded.
- wslh 10y ago
  > Perhaps the cancer is the fact the desktop development community has had decades to settle on a decent cross-platform 'native' toolkit and completely failed. Probably you are underestimating how complex is to build a GUI for different platforms and also underestimating how much browser technologies have been improved integrating zillion of years of experience. Also, you can't compare how easy is to develop a desktop UI with Windows Forms in Visual Studio to how difficult is to build an HTML UI.
  - nilliams 10y ago
    >> Probably you are underestimating how complex is to build a GUI for different platforms Presumably you're getting at platform-specific differences. I'd suggest these are no longer as important as once deemed. Pretty much all desktop platforms are currently looking dated with respect to their mobile counterparts. So anything that looks 'modern' across all of them (e.g. good design + Electron) actually feels like sweet relief. (If you meant something else, please correct me). >> ... and also underestimating how much browser technologies have been improved integrating zillion of years of experience. No, that's absolutely the point that I'm making. I'm suggesting browser tech is superior, largely due to the insane amount of engineering effort piled into it by Google et al. >> Also, you can't compare how easy is to develop a desktop UI with Windows Forms in Visual Studio to how difficult is to build an HTML UI. Yes I can, having done both :)
Guzba 10y ago
For those that agree with this, I have a simple question. If not Electron, how should one build a desktop app for Windows today? It seems the correct way is to use .NET and WPF if you want to take Microsoft's word for it. I've done this and it's installed on on 100k+ machines. In my experience, WPF is horrifically slow for users and uses just as much or more memory than Electron. With that in mind, I don't really see how Electron has any downsides at least on Windows, and has plenty of upsides: build apps that respond to input much faster using a more familiar set of tools (JS, HTML, CSS). No .NET dependency that makes the install process a nightmare. No need for a custom update component (always very complicated, even for a super simple one) since Electron can just load remote resources. No need to worry about Admin privileges. Better support for monitor densities. Much better text rendering. So many things. I think Electron is saving Windows desktop app development, not killing it.
- mwcampbell 10y ago
  There's no reason your choices have to be limited to the Microsoft-blessed solutions (Windows Forms, WPF) or Electron. You could use Qt or wxWidgets, and also potentially support other platforms.
  - ntauthority 10y ago
    I used to deride Qt for making application distributions 'bloated' due to shared library size, but with the habit nowadays to ship over 70 MB+ of Chromium in an installer bundle, Qt makes a lot more sense nowadays...
- WorldMaker 10y ago
  First of all, in my experience from many, many WPF and Silverlight enterprise applications: WPF is only horrifically slow when you don't properly thread your application. Classic Win32 (aka the million year old components System.Windows.Forms is built on) papers over a lot of mistakes in asynchronous threading and lets you get away with entirely synchronous code in places where it really shouldn't. WPF is a lot less tolerant of your code working in the wrong thread. Modern C# makes this a lot easier to work with given the async/await keywords, and ReactiveX is a joy to work with along WPF (say with ReactiveUI) if you get over the learning hump. All of that said, even WPF has been superseded by the Universal Windows Platform. If all I planned to target was desktop apps on Windows 10+ I'd use the UWP these days. UWP has very similar advantages to Electron. (I really like Electron, though.) You can use familiar sets of tools, whether it's HTML/JS/CSS or XAML/C# or even XAML/C++. (UWP XAML is somewhat faster than WPF, but still just as sensitive to making sure you have your application properly threaded.) If you can take advantage of the Windows Store or the Windows Store for Business (yes, that is a thing for enterprises to take advantage of) you get incredibly easy installation and upgrade. Even if you can't use either sort of Windows Store, since the Windows 10 November Update, installs and updates are simply a matter of double-clicking an app package (.appx file). Users get a UAC-like prompt about the install, but don't need Admin privileges. UWP has really good support for monitor densities and text rendering as it's meant to support nearly every combination of monitor densities you can possibly imagine, including the "Continuum" example of running an application on one's mobile device, miracasting the mobile device to a nearby screen to get a "full desktop" and moving the app to that screen. The present of Windows desktop app development is the UWP. I'd still use Electron for cross-platform apps, but as a developer I like the UWP too. (My Electron apps I'm building for code sharing with Cordova hosts as well, so in essence I'm in a "Why not both?" situation and expecting to release both Electron and UWP options. I could even see encouraging people to use the UWP app on Windows over Electron. That said, I'd love a little better convergence between Electron and Cordova and could even see a more Electron-like API for UWP JS...)
eagsalazar2 10y ago
Your entire rant is completely undermined by glaring factual errors. You should try Atom again (on a computer made in the last 10 years) and the try your rant again without that error as the centerpiece of your argument.
keybits 10y ago
Quip show how it can be done better with their OS X app: https://medium.com/@btaylor/react-with-c-building-the-quip-mac-and-windows-apps-c63155c1531b#.9lv3nsand https://medium.com/@btaylor/react-with-c-building-the-quip-m... It's fast as hell.
gcb0 10y ago
you are not very wrong. but still wrong. desktop is hell. if I have to choose between wasting your memory or giving in to apple or android excruciating and closed developtment cycle, I will kil your memory anytime.
zem 10y ago
i'm writing a desktop app right now. it's < 1500 lines of ocaml and gtk, compiles to a reasonably small native executable (3M after running upx), and is fast and responsive. it also has a grand total of one user, because i quail at the thought of getting it compiling on windows, and have no way to even know if it will run on a mac. had i written it in electron it would be trivially cross-platform from day one. i have not done so because i actually agree with you that desktop apps built on a browser are a pretty sad end-user experience, but the lure of honest-to-goodness "write once, deploy anywhere" is hard to deny.
SimeVidas 10y ago
There is another web-based option. Browsers will soon allow users to install (“progressive”) web apps on the desktop. It can already be tested in pre-release versions of Chrome (see this video https://twitter.com/simevidas/status/712473786910646277 https://twitter.com/simevidas/status/712473786910646277).
justncase80 10y ago
I think its beautiful and fast enough for nearly anything one would want to throw at it. Also, unbelievably faster in terms of developer time.

by etatoby 10y ago

oceanswave 10y ago

And this is only one example, there's NW.JS too, and Coherent Labs and Awesomium.. not to mention UWP apps... plus look at all the apps that leverage some sort of extensibility through JavaScript (Looking at you Creative Cloud and Office suites) Burn them all down BURRRRRRRNNNNNN!!! /s

tracker1 10y ago

I agree that Atom itself seems very slow, but VS Code tends to run great, and I really appreciate the feature set that it offers. As it stands, it's not a great use case for many types of applications, but I would say that it's good enough for most of them. Beyond this, people are building useful things with it quickly. Far more quickly than they would be able to if they were targeting a custom UI platform, or with a lower level language like C/C++ etc. All this with the ability to relatively easily build for Windows, OSX and Linux deployments. I don't mind people using XML based UI composition, as it works pretty well. Flex, XAML, and many other UI builders are XML based, simply because the structure corresponds well to the rendering hierarchy of components, and allows for easier understanding of their relative interactions. I am half surprised there isn't a path towards a ReactNative for Desktop (OSX, Windows, Linix) at this point, that is similar to Electron, Node/V8 core, but with a common/reduced component set that just works. It's worth mentioning that the underlying platform is C/C++ based with a very flexible UI kit (HTML) and a DSL (JavaScript + DOM) that is also flexible.

mkhalil 10y ago
There is ReactNative for Mac OSX. https://github.com/ptmt/react-native-desktop https://github.com/ptmt/react-native-desktop Not official though, but it's getting some use out there.
WorldMaker 10y ago
The recently announced React Native for the Universal Windows Platform would also support desktop.

marmaduke 10y ago

I heard people made the same complaints about emacs once. Emacs is.. lightning fast compared to these new web ui editors.

JBReefer 10y ago
Computers have gotten much faster since Emacs was born, but your point stands

jokoon 10y ago

I'm glad to read somebody else who also shares my view on that. HTML has been great to make the web great without microsoft attempt to monopolize it, but markup languages are useless as a file format you send across the internet. Why? Because parsing text is, and will ALWAYS be slow. So either pre-parse html and put this in an OPEN binary file format, or burn it with fire. Why can't investors and other developer take a damn hint that there is a reason smartphones use applications instead of web apps: html, dom, js, css all those things are slow and totally not well designed ! If you want to know more, start with that video that talks about the messy process that was HTML standardization https://www.youtube.com/watch?v=RH0o-QjnwDg https://www.youtube.com/watch?v=RH0o-QjnwDg HTML is not a strict language, meaning it's EVEN SLOWER to parse. Wake up sheeple (sorry that was unnecessary)

deleted 10y ago
[deleted]
nilliams 10y ago
Sorry, this is just wrong. The time to parse CSS + HTML is negligible and isn't a reason native is better. Native apps have a better foothold currently because mobile platforms had better support for their own native languages, than for sophisticated web runtimes like V8 at release.
- millstone 10y ago
  The runtime isn't what matters, the touch-first UI toolkit and OS integration story is. The web came to mobile with lots of desktop baggage: scrolling, hover, "px", CPU-driven animations, etc. That's what makes it awkward on mobile.
  - deleted 10y ago
    [deleted]
- jokoon 10y ago
  The problem is "sophisticated". You can't have speed with "sophisticated" if that platform you are releasing software on is "sophisticated". At its base, the system must be simple enough. If AT LEAST html would be a strict language like xml is, maybe that'd be better. But XML is not even human readable. YAML is.

msoad 10y ago

I run Slack, VSCode, my development server in Node.js and Chrome on my machine. Now count how many copies of Node.js and WebKit or Blink I have on my machine. A shared browser engine could replace all of Electron apps (wink wink Chrome desktop apps) only if we had it right when we started.

gnuvince 10y ago

Recently in a lobste.rs discussion thread, I wondered how people would react to programmers using PDF as an application platform: use a scripting language to update the content of the PDF file on the fly and in response to user events. I'm quite certain that most, if not all, users would shun these applications as they would be slow, unresponsive and ultimately trying to use a technology for static documents to develop dynamic and interactive content (i.e. wrong tool for the job). I feel that this is exactly what is happening with web applications and projects like Electron. And then a user pointed out that Acrobat Reader can actually do that already [1]. [1] http://www.adobe.com/devnet/acrobat/javascript.html http://www.adobe.com/devnet/acrobat/javascript.html

thisisdave 10y ago
Not a great example. Apple's graphics layer on OS X is very closely tied to PDF, and basically uses the Adobe Imaging Model that PDF is based on. It actually does include a PDF-based scripting language for drawing and updating shapes on the screen.

nilliams 10y ago

This attitude seems ignorant of the facts and the unfortunate state of desktop development. Perhaps the cancer is the fact the desktop development community has had decades to settle on a decent cross-platform 'native' toolkit and completely failed. Perhaps the cancer is 'native' developers spouting 'native is better' hyperbole, ignorant of the fact these supposedly better 'native' toolkits have been web-influenced for a long time. - XAML from C#/WPF land being strongly influenced by HTML and CSS. - Android XML being strongly influenced by HTML and CSS. - Qt Quick being strongly influenced by JS and CSS. - GTK+ embracing JS and CSS3. - Everything else being awful procedural C++. Good luck maintaining that. And all have massively inferior developer tools than Chrome devtools and/or far worse abstractions for the scene-graph/tree of elements than the much-derided yet very powerful DOM. Native desktop is a mess. I'm glad we're seeing Electron expose it for the joke that it is. You can hate web dev tech, but you can't claim that native desktop options are better. I won't be building apps 3 times or using any of these useless 'cross-platform' dev kits anytime soon, when I can build the same thing in Electron in a fraction of the time, and leverage the undeniably huge JS and CSS communities. Also very tired of seeing devs use weasel-words like 'bloat' and neglect to put it into any context, like the fact that on the desktop 1. it ain't bloat if filesize is cheap, and 2. said filesize is comparable to the most capable cross-plat options you're supposedly arguing for (see Qt Quick). Edit: Softened, expanded.

wslh 10y ago
> Perhaps the cancer is the fact the desktop development community has had decades to settle on a decent cross-platform 'native' toolkit and completely failed. Probably you are underestimating how complex is to build a GUI for different platforms and also underestimating how much browser technologies have been improved integrating zillion of years of experience. Also, you can't compare how easy is to develop a desktop UI with Windows Forms in Visual Studio to how difficult is to build an HTML UI.
- nilliams 10y ago
  >> Probably you are underestimating how complex is to build a GUI for different platforms Presumably you're getting at platform-specific differences. I'd suggest these are no longer as important as once deemed. Pretty much all desktop platforms are currently looking dated with respect to their mobile counterparts. So anything that looks 'modern' across all of them (e.g. good design + Electron) actually feels like sweet relief. (If you meant something else, please correct me). >> ... and also underestimating how much browser technologies have been improved integrating zillion of years of experience. No, that's absolutely the point that I'm making. I'm suggesting browser tech is superior, largely due to the insane amount of engineering effort piled into it by Google et al. >> Also, you can't compare how easy is to develop a desktop UI with Windows Forms in Visual Studio to how difficult is to build an HTML UI. Yes I can, having done both :)

Guzba 10y ago

For those that agree with this, I have a simple question. If not Electron, how should one build a desktop app for Windows today? It seems the correct way is to use .NET and WPF if you want to take Microsoft's word for it. I've done this and it's installed on on 100k+ machines. In my experience, WPF is horrifically slow for users and uses just as much or more memory than Electron. With that in mind, I don't really see how Electron has any downsides at least on Windows, and has plenty of upsides: build apps that respond to input much faster using a more familiar set of tools (JS, HTML, CSS). No .NET dependency that makes the install process a nightmare. No need for a custom update component (always very complicated, even for a super simple one) since Electron can just load remote resources. No need to worry about Admin privileges. Better support for monitor densities. Much better text rendering. So many things. I think Electron is saving Windows desktop app development, not killing it.

mwcampbell 10y ago
There's no reason your choices have to be limited to the Microsoft-blessed solutions (Windows Forms, WPF) or Electron. You could use Qt or wxWidgets, and also potentially support other platforms.
- ntauthority 10y ago
  I used to deride Qt for making application distributions 'bloated' due to shared library size, but with the habit nowadays to ship over 70 MB+ of Chromium in an installer bundle, Qt makes a lot more sense nowadays...
WorldMaker 10y ago
First of all, in my experience from many, many WPF and Silverlight enterprise applications: WPF is only horrifically slow when you don't properly thread your application. Classic Win32 (aka the million year old components System.Windows.Forms is built on) papers over a lot of mistakes in asynchronous threading and lets you get away with entirely synchronous code in places where it really shouldn't. WPF is a lot less tolerant of your code working in the wrong thread. Modern C# makes this a lot easier to work with given the async/await keywords, and ReactiveX is a joy to work with along WPF (say with ReactiveUI) if you get over the learning hump. All of that said, even WPF has been superseded by the Universal Windows Platform. If all I planned to target was desktop apps on Windows 10+ I'd use the UWP these days. UWP has very similar advantages to Electron. (I really like Electron, though.) You can use familiar sets of tools, whether it's HTML/JS/CSS or XAML/C# or even XAML/C++. (UWP XAML is somewhat faster than WPF, but still just as sensitive to making sure you have your application properly threaded.) If you can take advantage of the Windows Store or the Windows Store for Business (yes, that is a thing for enterprises to take advantage of) you get incredibly easy installation and upgrade. Even if you can't use either sort of Windows Store, since the Windows 10 November Update, installs and updates are simply a matter of double-clicking an app package (.appx file). Users get a UAC-like prompt about the install, but don't need Admin privileges. UWP has really good support for monitor densities and text rendering as it's meant to support nearly every combination of monitor densities you can possibly imagine, including the "Continuum" example of running an application on one's mobile device, miracasting the mobile device to a nearby screen to get a "full desktop" and moving the app to that screen. The present of Windows desktop app development is the UWP. I'd still use Electron for cross-platform apps, but as a developer I like the UWP too. (My Electron apps I'm building for code sharing with Cordova hosts as well, so in essence I'm in a "Why not both?" situation and expecting to release both Electron and UWP options. I could even see encouraging people to use the UWP app on Windows over Electron. That said, I'd love a little better convergence between Electron and Cordova and could even see a more Electron-like API for UWP JS...)

eagsalazar2 10y ago

Your entire rant is completely undermined by glaring factual errors. You should try Atom again (on a computer made in the last 10 years) and the try your rant again without that error as the centerpiece of your argument.

keybits 10y ago

Quip show how it can be done better with their OS X app: https://medium.com/@btaylor/react-with-c-building-the-quip-mac-and-windows-apps-c63155c1531b#.9lv3nsand https://medium.com/@btaylor/react-with-c-building-the-quip-m... It's fast as hell.

gcb0 10y ago

you are not very wrong. but still wrong. desktop is hell. if I have to choose between wasting your memory or giving in to apple or android excruciating and closed developtment cycle, I will kil your memory anytime.

zem 10y ago

i'm writing a desktop app right now. it's < 1500 lines of ocaml and gtk, compiles to a reasonably small native executable (3M after running upx), and is fast and responsive. it also has a grand total of one user, because i quail at the thought of getting it compiling on windows, and have no way to even know if it will run on a mac. had i written it in electron it would be trivially cross-platform from day one. i have not done so because i actually agree with you that desktop apps built on a browser are a pretty sad end-user experience, but the lure of honest-to-goodness "write once, deploy anywhere" is hard to deny.

SimeVidas 10y ago

There is another web-based option. Browsers will soon allow users to install (“progressive”) web apps on the desktop. It can already be tested in pre-release versions of Chrome (see this video https://twitter.com/simevidas/status/712473786910646277 https://twitter.com/simevidas/status/712473786910646277).

justncase80 10y ago

I think its beautiful and fast enough for nearly anything one would want to throw at it. Also, unbelievably faster in terms of developer time.