4 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

> 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.
      - SamReidHughes 9y ago
        Using RAII is manual.
  - com2kid 9y ago
    > If you are doing manual memory management in modern C++, you are doing it wrong in most cases. You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime. You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!) And memory is still being fragmented, especially if the data model is complex. In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues. Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language.
    - LeoNatan25 9y ago
      > You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime. As you do in any language. > You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!) In the case of modern C++, Swift, even ObjC–by “you”, you mean the runtime? Following relatively simple rules does not create a huge cognitive burden on developers, I think. > And memory is still being fragmented, especially if the data model is complex. Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age. > In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues. Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language. There is also a quantifiable performance penalty to GC’d languages and defragmentation. And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
- fny 9y ago
  But you still don't need C++ to "truly get the app you want." Only when you cross a certain performance threshold do you need to look elsewhere. Most electron apps perform well enough despite the rampant RAM and battery consumption.

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.
    - SamReidHughes 9y ago
      Using RAII is manual.
- com2kid 9y ago
  > If you are doing manual memory management in modern C++, you are doing it wrong in most cases. You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime. You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!) And memory is still being fragmented, especially if the data model is complex. In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues. Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language.
  - LeoNatan25 9y ago
    > You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime. As you do in any language. > You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!) In the case of modern C++, Swift, even ObjC–by “you”, you mean the runtime? Following relatively simple rules does not create a huge cognitive burden on developers, I think. > And memory is still being fragmented, especially if the data model is complex. Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age. > In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues. Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language. There is also a quantifiable performance penalty to GC’d languages and defragmentation. And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
fny 9y ago
But you still don't need C++ to "truly get the app you want." Only when you cross a certain performance threshold do you need to look elsewhere. Most electron apps perform well enough despite the rampant RAM and battery consumption.