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?

> 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!

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.

If you are doing manual memory management in modern C++, you are doing it wrong in most cases.

> 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.

> 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.

> As you do in any language.

Most GC languages force the issue for you. Everything on the heap. That said, I'd love it if more GC'd languages were smart enough to know when they can stack alloc. :)

> Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age.

They become a problem with any long lived application that throws around large chunks of data. From video games to productivity apps. Soon as interactive runtimes become multi-hour, life gets harder.

> There is also a quantifiable performance penalty to GC’d languages and defragmentation.

Depends on usage. Destructor chains can take up large amounts of time as well, and from the programmer's POV, are about as deterministic as GC pauses. On the plus side, they typically only pause one thread instead of the entire world. :) (Not much help if it is the app's main thread, or UI thread, heh)

> 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.

And they also prevent a lot of those same issues. It is a trade off. But I'd say that for 90% of coding, the cognitive load from GC is lower than from using C++. A brand new C++ codebase written by people who are all strictly following the Right Way to do things will look good, but the majority of code is old. The majority of libraries being used were not written in accordance with the latest C++ spec, every single third party library doesn't use unique and shared pointers, leading to natural conflicts at interfaces between libraries.

Pick a mature (has libraries written in it) GC'd language and that all goes away.

> But I'd say that for 90% of coding, the cognitive load from GC is lower than from using C++. A brand new C++ codebase written by people who are all strictly following the Right Way to do things will look good, but the majority of code is old.

Don’t forget we are speaking about a new component written in Atom, or a new project being started. Legacy code is legacy code; it is almost certainly a pain (even in Java). But when starting a new project and following some basic guidelines, C++ has become somewhat pleasant to work with, something that has not been the case in the past (for me at least).

> But when starting a new project and following some basic guidelines, C++ has become somewhat pleasant to work with

I can agree with this, with the caveat that old libraries, still in popular use, are all over the place. For one thing, a lot of OS interop relies upon these libraries, although C++17 is aiming to standardize a lot of what used to be OS level functionality.

No, manual memory management is what you do in C++.

Calling new and delete in this day and age of C++ is doing it wrong.

Using RAII is manual.

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.

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.

> 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

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.

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.

> 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).

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.

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.

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.

VSCode doesn’t seem to have this problem and is electron.

Electron is a bad fit for any kind of application.

Hear, Hear!

Anybody knows how come VSC is so more responsive than Atom? Is having parts in C++ a trick that VSC also does, or is it something else?

I think vscode was built with performance in mind from the ground up. Atom on the other hand was focussed on hackability. Down to actual reason, I haven't scanned the source code but have noticed vscode delegates lots of processing to separate child processes that could prevent potential freezing/lockups in the main process/window.

It's not magic by VSCode, other web-based editing components such as the ACE editor are also lightning fast. There are two main reasons:

- VSCode is rendering in the DOM what you see, not what you scroll to.

- VSCode is using the correct datastructures, so an insert of a line at the top, doesn't require updating/relayouting all lines below it, but more likely something like log(n) lines.

And these two reasons you can summarize as the difference between old skool engineers with proper training in datastructures, cache behavior and algorithmic complexity -vs- new skool "full-stack developers" that rely on a billion lines of code they haven't written (or understand) and who mainly script a bit in between. The (wrong) assumption in the recent decade was we don't need to train engineers to understand the algorithmic complexity of their code because 'computers will continue to become faster'. That was never true and never will be true, because an exponentially slow algorithm simply won't ever be fast enough regardless of the amount of transistors. And making something like a simple text editor (without syntax highlighting and all of that -- just being able to edit the code), is actually an easy test to distinguish between the two wildly different skillsets.

I dont see any C++

https://github.com/Microsoft/vscode

VSCode pulls in all sorts of precompiled dependencies during build. e.g. the search is done via RipGrep which is just a binary.

But I agree that it is mostly typescript through and through, they just have implemented basically everything as a non-blocking promise.

And most importantly, the extension system cannot block the UI. It runs in a completely different process also.

The honest answer -- Microsoft has a lot of people with experience in building these things, so they aren't making the typical mistakes that Atom made with their architecture. For example: Atom was rendering dom nodes for your whole file -- not just the parts that were visible. Using the DOM as a stateful container of all that could be visible does not scale really well.

Compare to something like the ACE editor (an OSS editing component that you can plug into any website) which is lightning fast -- it only renders what you see though -- but the filesize is not at all relevant to the performance.

These are all techniques that people who ever wrote complex UI toolkits are incredible aware of. I don't think that describes anybody who worked on ATOM ever, which means they just have to relearn and re invent this stuff until they get it right.

Generally, these days a lot of developers get a lot of experience combining existing technologies. Proper engineering skills, or even being aware of the data structures you are using and their algorithmic complexity, how cache friendly it is -- all of this is prioritized much less now.

So Atom answers a simply question. Has hardware become significantly fast to not care about proper engineering? No, not really and it never will. If your datastructure is structured in a such a way that inserting a line all the way at the top requires a relayout of every line below that, for example, you will run into real limits.

VSC streamlines the data it needs to load, doing the least amount possible in hot paths as far as I know. They also multi-thread on startup so it is perceived as being quicker to boot up.

Honestly I use both often and just the startup makes it seem faster. Just the startup alone makes such a large difference to perception.

I've been waiting this for a while.

They seemed to have a lot more beta releases than other versions. Perhaps because there were a lot more changes..?