6 ms·

Love this comment and don't want my more serious commentary to override how good this turn of phrase is. That said: I think we should. Electron is problematic

Love this comment and don't want my more serious commentary to override how good this turn of phrase is. That said: I think we should. Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. Still - at some point if you want to build an app that has a UI users interact with, connects to the internet to get data via HTTP requests, and then stores some data in a database: at some point you should just be able to write that no matter where the end delivery will be. I'm not sure how we're going to get there, but it seems like things like Electron and React Native will at least be part of the path. Eventually they'll hit a critical mass of performance and will become the default, then we'll have to deal with that from there.

StavrosK 10y ago
I don't know, I understand the need to build things, but I can't say I agree with the conclusion. Maybe sometimes we should spend time crafting something nice, rather than scraping something together out of mud.
- dualogy 10y ago
  True enough, if there's budget/schedule scope for crafting, we certainly should. In the short-medium term Electron apps will probably hit that ole VisualBasic sort of sweet spot: for learners to write xcopy-distributable (I'd hope?!) "apps" to share with peers, and for day-to-day hackers writing the "messy no-performance-required" one-off tools that need a tad more visualization than can be effected with quick custom CLI println tools. I too fail to see "a programmer's text editor" as the "killer app" for Electron of course ;)
  - StavrosK 10y ago
    My problem with Electron isn't with Electron itself, it's with needing a whole operating system (nee "browser") to work. Visual Basic apps were at least moderately sleek and didn't consume too many resources. I don't want to have each app take up hundreds of megabytes of RAM, things are already bloated enough everywhere :(
    - dualogy 10y ago
      Sure, though consider VB apps weren't that sleek considering that typical RAM in the late 90s ranged from 32-128 MB commonly: http://www.tomshardware.co.uk/forum/266641-28-average-1998-computer-specs http://www.tomshardware.co.uk/forum/266641-28-average-1998-c... And of course in the early 00s the VB crowd largely moved to the, at first, much more resource-intensive (all-in) .NET.. Electron apps certainly seem quite wasteful and probably should be short-running one-off tools for now, rather than long-running major LoB or productivity apps.. config editors or media tweak things or such. Of course if it takes 500MB out of my 32GB RAM that's not cool (but kinda in range with ~1/64MB), but if I run it and close it after 10 mins it's also not the end of the world if it performed a job that needed doing. What the embedded browser provides is of course both a GUI toolkit and a runtime framework, so just in-place-of a .NET or a JVM or some custom combo of (C++ std shared objects + Gtk/Qt/Etc libs). YES: this sort of "browser as runtime framework" isn't currently optimized for the Electron use case. But if efforts were invested in such optimizations, it would probably benefit browsers as well. And though it is unlikely, it is slightly likelier as the younguns adopt Electron for much/most of their hackery. Consider: I think there's countless native app developers who sometimes yearn for the great design freedoms afforded by the infinitely mallable HTML+CSS. It is only for efficiency reasons that native still wins. That being the case, if Electron etc (embedded html/css renderer and runtime via JS) approaches were as fast-as-.net/jvm-bytecode, it would easily become the prime choice. So maybe it's just too early to discount entirely.
dualogy 10y ago
> That said: I think we should. Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. Is this intrinsic to Electron architecture --- or just the current realities of the sort of JS people tend to write, thrown at the JS engine that Electron wraps? What I mean, if the final executable is actually some sort of embedded Python interpreter and "Electron" is a bunch of shoddy Python scripts messing with WebKit and Gtk/Tk/Qt/whatever then I'd steer clear. But if the non-3rd-party parts are solidly high-perf-engineered, I'll remain interested..
johnny22 10y ago
the performance is terrible in vs code? not that I've seen.
- jorvi 10y ago
  Compared to what, Atom? In raw performance: Vim > Emacs* > Sublime > VS Code > Atom In UI performance:; Sublime > VS Code > Atom > Vim > Emacs* *I don't use Emacs regularly, so not entirely certain of this Honestly, download Sublime and try to use it for a day or two (if your workflow can bear it) and then switch back to VS Code. You'll notice all sorts of small delays that, while not breaking, are certainly annoying.
  - johnny22 10y ago
    That doesn't make it terrible, just not quite as good. I get better performance out of VS Code than I do with vim with various plugins though. Still too many non async plugins out there.
    - jorvi 10y ago
      Which plugins are you using? NeoComplete -> Async autocomplete for both NeoVim and Vim 8 NeoMake -> Async linting and make for both Neovim and Vim 8 Those are the only two I can think of that really benefit from async. Vim-airline, Easymotion, Ctrl-P, UndoTree etc. all don't need async, and you can just lazily load them on start if you use Vim-plug.
xkxx 10y ago
> Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. Have you tried the open-source Brave browser? https://brave.com/ https://brave.com/ Its GUI is created with Muon (which is a fork of Electron). The browser doesn't seem very slow, at least to me. Also, Firefox have used XUL for a long time to create its interface. XUL is not much different from what Electron is: XML-like markup to design your interface and JS to manipulate it.
- StavrosK 10y ago
  > Also, Firefox have used XUL for a long time to create its interface. XUL is not much different from what Electron is: XML-like markup to design your interface and JS to manipulate it. Yes, and XUL is terrible too. Firefox is very resource-intensive and quite slow, and I'm a Firefox user. I wish we could get the values of Firefox with the performance of Chrome...
  - johnny22 10y ago
    but is the poor performance related to XUL? Doubtful.
- cozzyd 10y ago
  Naming your framework after an unstable particle (with a mass 200 times larger than an electron) seems like a poor choice to me. I would have gone with neutrino-- lighter, equally stable, and can even change flavors!
- jayeshsalvi 10y ago
  It's not Electron that has performance issues, but the apps aren't probably coded properly. I've been developing my app using electron for a year now and haven't seen it hog cpu/memory unless it's a bug in my application.
geraldcombs 10y ago
> Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. I can tell an Electron app when I see it because it clobbers other windows on my Windows 7 VM: https://github.com/electron/electron/issues/1821 https://github.com/electron/electron/issues/1821 . I really wish they'd fix this since it makes VS Code much less usable.
- johnny22 10y ago
  does this hit Windows 10 in any cases? Can composition even be disabled? I don't know enough about Windows since XP to know :(.
Bombthecat 10y ago
I feel like going back to Java (swing) would be a better choice...

StavrosK 10y ago

I don't know, I understand the need to build things, but I can't say I agree with the conclusion. Maybe sometimes we should spend time crafting something nice, rather than scraping something together out of mud.

dualogy 10y ago
True enough, if there's budget/schedule scope for crafting, we certainly should. In the short-medium term Electron apps will probably hit that ole VisualBasic sort of sweet spot: for learners to write xcopy-distributable (I'd hope?!) "apps" to share with peers, and for day-to-day hackers writing the "messy no-performance-required" one-off tools that need a tad more visualization than can be effected with quick custom CLI println tools. I too fail to see "a programmer's text editor" as the "killer app" for Electron of course ;)
- StavrosK 10y ago
  My problem with Electron isn't with Electron itself, it's with needing a whole operating system (nee "browser") to work. Visual Basic apps were at least moderately sleek and didn't consume too many resources. I don't want to have each app take up hundreds of megabytes of RAM, things are already bloated enough everywhere :(
  - dualogy 10y ago
    Sure, though consider VB apps weren't that sleek considering that typical RAM in the late 90s ranged from 32-128 MB commonly: http://www.tomshardware.co.uk/forum/266641-28-average-1998-computer-specs http://www.tomshardware.co.uk/forum/266641-28-average-1998-c... And of course in the early 00s the VB crowd largely moved to the, at first, much more resource-intensive (all-in) .NET.. Electron apps certainly seem quite wasteful and probably should be short-running one-off tools for now, rather than long-running major LoB or productivity apps.. config editors or media tweak things or such. Of course if it takes 500MB out of my 32GB RAM that's not cool (but kinda in range with ~1/64MB), but if I run it and close it after 10 mins it's also not the end of the world if it performed a job that needed doing. What the embedded browser provides is of course both a GUI toolkit and a runtime framework, so just in-place-of a .NET or a JVM or some custom combo of (C++ std shared objects + Gtk/Qt/Etc libs). YES: this sort of "browser as runtime framework" isn't currently optimized for the Electron use case. But if efforts were invested in such optimizations, it would probably benefit browsers as well. And though it is unlikely, it is slightly likelier as the younguns adopt Electron for much/most of their hackery. Consider: I think there's countless native app developers who sometimes yearn for the great design freedoms afforded by the infinitely mallable HTML+CSS. It is only for efficiency reasons that native still wins. That being the case, if Electron etc (embedded html/css renderer and runtime via JS) approaches were as fast-as-.net/jvm-bytecode, it would easily become the prime choice. So maybe it's just too early to discount entirely.

dualogy 10y ago

> That said: I think we should. Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. Is this intrinsic to Electron architecture --- or just the current realities of the sort of JS people tend to write, thrown at the JS engine that Electron wraps? What I mean, if the final executable is actually some sort of embedded Python interpreter and "Electron" is a bunch of shoddy Python scripts messing with WebKit and Gtk/Tk/Qt/whatever then I'd steer clear. But if the non-3rd-party parts are solidly high-perf-engineered, I'll remain interested..

johnny22 10y ago

the performance is terrible in vs code? not that I've seen.

jorvi 10y ago
Compared to what, Atom? In raw performance: Vim > Emacs* > Sublime > VS Code > Atom In UI performance:; Sublime > VS Code > Atom > Vim > Emacs* *I don't use Emacs regularly, so not entirely certain of this Honestly, download Sublime and try to use it for a day or two (if your workflow can bear it) and then switch back to VS Code. You'll notice all sorts of small delays that, while not breaking, are certainly annoying.
- johnny22 10y ago
  That doesn't make it terrible, just not quite as good. I get better performance out of VS Code than I do with vim with various plugins though. Still too many non async plugins out there.
  - jorvi 10y ago
    Which plugins are you using? NeoComplete -> Async autocomplete for both NeoVim and Vim 8 NeoMake -> Async linting and make for both Neovim and Vim 8 Those are the only two I can think of that really benefit from async. Vim-airline, Easymotion, Ctrl-P, UndoTree etc. all don't need async, and you can just lazily load them on start if you use Vim-plug.

xkxx 10y ago

> Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. Have you tried the open-source Brave browser? https://brave.com/ https://brave.com/ Its GUI is created with Muon (which is a fork of Electron). The browser doesn't seem very slow, at least to me. Also, Firefox have used XUL for a long time to create its interface. XUL is not much different from what Electron is: XML-like markup to design your interface and JS to manipulate it.

StavrosK 10y ago
> Also, Firefox have used XUL for a long time to create its interface. XUL is not much different from what Electron is: XML-like markup to design your interface and JS to manipulate it. Yes, and XUL is terrible too. Firefox is very resource-intensive and quite slow, and I'm a Firefox user. I wish we could get the values of Firefox with the performance of Chrome...
- johnny22 10y ago
  but is the poor performance related to XUL? Doubtful.
cozzyd 10y ago
Naming your framework after an unstable particle (with a mass 200 times larger than an electron) seems like a poor choice to me. I would have gone with neutrino-- lighter, equally stable, and can even change flavors!
jayeshsalvi 10y ago
It's not Electron that has performance issues, but the apps aren't probably coded properly. I've been developing my app using electron for a year now and haven't seen it hog cpu/memory unless it's a bug in my application.

geraldcombs 10y ago

> Electron is problematic and you can always tell an Electron app when you see it because the performance is so terrible. I can tell an Electron app when I see it because it clobbers other windows on my Windows 7 VM: https://github.com/electron/electron/issues/1821 https://github.com/electron/electron/issues/1821 . I really wish they'd fix this since it makes VS Code much less usable.

johnny22 10y ago
does this hit Windows 10 in any cases? Can composition even be disabled? I don't know enough about Windows since XP to know :(.

Bombthecat 10y ago

I feel like going back to Java (swing) would be a better choice...