7 ms·

Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a f

Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron?

kemayo 9y ago
That's part of it. The other part is "write using tools which lots of developers are familiar with", i.e. the general browser stack. That still applies. For that matter, even if your app requires occasional core high-performance bits written into C, that's probably still a benefit to you. Similar to the standard Python argument, which advocates a very similar development pattern. After all, it's not like you're not compiling it on each platform anyway to get the native app you're distributing.
andyfleming 9y ago
I think with any technology like this, as long as the structure of the wrapper (Electron, in this case) allows for cleanly integrating into lower level components of code, it's fine. The point is that the majority is managed in a lighter-weight accessible language. The majority of the application is still based on web technologies that a larger audience can contribute to. If they need to write something lower level for a core part of the application to achieve performance, I think that's alright.
- pelhage 9y ago
  > If they need to write something lower level for a core part of the application to achieve performance, I think that's alright. Which is the idea behind WebAssembly and why we're seeing it discussed more often these days
usaphp 9y ago
Not every Electro app should have to deal with a huge dom tree like Atom does. I just think the Electron is a bad fit for this particular type of application, but it does not mean it can be a bad fit for other type of stuff.
- LeoNatan25 9y ago
  Electron is a bad fit for any kind of application.
  - bwat49 9y ago
    Hear, Hear!
- azinman2 9y ago
  VSCode doesn’t seem to have this problem and is electron.
moosingin3space 9y ago
Honestly I'm a little curious about whether compiling it to WebAssembly would have offered similar benefits. If so, that would make writing performance-critical parts of Electron apps in another language a more approachable proposition.
polpo 9y ago
I don't think the ability to put some of the heavy lifting in C++ code diminishes the value of Electron or Node.js any less than any other scripting language that lets you write modules in C or C++. The way Node.js C++ addons are written and built doesn't diminish the "write once, run on all platforms" nature unless you try really hard to write platform-specific code.
com2kid 9y ago
> Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron? C++ data models can be write once compile almost-everywhere (all desktop platforms at least) pretty easily. You can write C++ code that compiles on iOS, Android, Windows, and MacOS, and Linux, without any great difficulty. Making all the UI and system integration code cross platform is a more valuable service. Just dealing with something like the Clipboard on all the above mentioned platforms is a lot of boilerplate code. Not to even get to actual UI widgets!
- curiousess 9y ago
  This makes sense, but seems like a(n unspoken?) pivot...? Electron doesn't call itself a UI framework after all, but an application framework. I thought most of the excitement was about getting away from manual memory management into higher level languages and building something that works across the web and desktop, not just simplifying desktop busy work with native UIs. Their tagline is "Build cross platform desktop apps with JavaScript, HTML, and CSS"--if you need C++ to truly get the app you want, it seems like the value proposition is severely diminished.
  - LeoNatan25 9y ago
    If you are doing manual memory management in modern C++, you are doing it wrong in most cases.
    - SamReidHughes 9y ago
      No, manual memory management is what you do in C++.
      - LeoNatan25 9y ago
        Calling new and delete in this day and age of C++ is doing it wrong.
camus2 9y ago
> Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron? You are absolutely right and that's the biggest irony of all that, them going down to C++ . What they should have done is like Sublime Text. Write the GUI in C++ then use Javascript as the scripting layer for your apps (instead of Python).
maxbrunsfeld 9y ago
That's one good reason that you might choose to use Electron, but it's not the main reason that Atom uses it. One of the main goals of Atom is to be the most hackable text editor ever. Given that goal, Electron is the ideal platform for the app. Thanks to node's native module system, we can cleanly drop any component we want down to C++, while keeping our main application logic written in the most widely-known (and fastest-executing, thanks to V8) scripting language in existence. I'm happy with this architecture as opposed to starting in C++ and then bolting on some specific, limited scripting APIs. To be sure, Atom has performance issues that remain, but we're making steady progress on them, and Electron isn't standing in our way at all.

kemayo 9y ago

That's part of it. The other part is "write using tools which lots of developers are familiar with", i.e. the general browser stack. That still applies. For that matter, even if your app requires occasional core high-performance bits written into C, that's probably still a benefit to you. Similar to the standard Python argument, which advocates a very similar development pattern. After all, it's not like you're not compiling it on each platform anyway to get the native app you're distributing.

andyfleming 9y ago

I think with any technology like this, as long as the structure of the wrapper (Electron, in this case) allows for cleanly integrating into lower level components of code, it's fine. The point is that the majority is managed in a lighter-weight accessible language. The majority of the application is still based on web technologies that a larger audience can contribute to. If they need to write something lower level for a core part of the application to achieve performance, I think that's alright.

pelhage 9y ago
> If they need to write something lower level for a core part of the application to achieve performance, I think that's alright. Which is the idea behind WebAssembly and why we're seeing it discussed more often these days

usaphp 9y ago

Not every Electro app should have to deal with a huge dom tree like Atom does. I just think the Electron is a bad fit for this particular type of application, but it does not mean it can be a bad fit for other type of stuff.

LeoNatan25 9y ago
Electron is a bad fit for any kind of application.
- bwat49 9y ago
  Hear, Hear!
azinman2 9y ago
VSCode doesn’t seem to have this problem and is electron.

moosingin3space 9y ago

Honestly I'm a little curious about whether compiling it to WebAssembly would have offered similar benefits. If so, that would make writing performance-critical parts of Electron apps in another language a more approachable proposition.

polpo 9y ago

I don't think the ability to put some of the heavy lifting in C++ code diminishes the value of Electron or Node.js any less than any other scripting language that lets you write modules in C or C++. The way Node.js C++ addons are written and built doesn't diminish the "write once, run on all platforms" nature unless you try really hard to write platform-specific code.

com2kid 9y ago

> Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron? C++ data models can be write once compile almost-everywhere (all desktop platforms at least) pretty easily. You can write C++ code that compiles on iOS, Android, Windows, and MacOS, and Linux, without any great difficulty. Making all the UI and system integration code cross platform is a more valuable service. Just dealing with something like the Clipboard on all the above mentioned platforms is a lot of boilerplate code. Not to even get to actual UI widgets!

curiousess 9y ago
This makes sense, but seems like a(n unspoken?) pivot...? Electron doesn't call itself a UI framework after all, but an application framework. I thought most of the excitement was about getting away from manual memory management into higher level languages and building something that works across the web and desktop, not just simplifying desktop busy work with native UIs. Their tagline is "Build cross platform desktop apps with JavaScript, HTML, and CSS"--if you need C++ to truly get the app you want, it seems like the value proposition is severely diminished.
- LeoNatan25 9y ago
  If you are doing manual memory management in modern C++, you are doing it wrong in most cases.
  - SamReidHughes 9y ago
    No, manual memory management is what you do in C++.
    - LeoNatan25 9y ago
      Calling new and delete in this day and age of C++ is doing it wrong.

camus2 9y ago

> Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron? You are absolutely right and that's the biggest irony of all that, them going down to C++ . What they should have done is like Sublime Text. Write the GUI in C++ then use Javascript as the scripting layer for your apps (instead of Python).

maxbrunsfeld 9y ago

That's one good reason that you might choose to use Electron, but it's not the main reason that Atom uses it. One of the main goals of Atom is to be the most hackable text editor ever. Given that goal, Electron is the ideal platform for the app. Thanks to node's native module system, we can cleanly drop any component we want down to C++, while keeping our main application logic written in the most widely-known (and fastest-executing, thanks to V8) scripting language in existence. I'm happy with this architecture as opposed to starting in C++ and then bolting on some specific, limited scripting APIs. To be sure, Atom has performance issues that remain, but we're making steady progress on them, and Electron isn't standing in our way at all.