6 ms·

I'm tentatively excited about this release. It claims to fix the biggest complaint about atom: speed of editing and memory usage of edited files. They did it

by kjksf 9y ago

I'm tentatively excited about this release. It claims to fix the biggest complaint about atom: speed of editing and memory usage of edited files. They did it by re-writing backing store for documents from JavaScript to C++.

noncoml 9y ago
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?
- hacker_9 9y ago
  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.
  - pducks32 9y ago
    Honestly I use both often and just the startup makes it seem faster. Just the startup alone makes such a large difference to perception.
- murukesh_s 9y ago
  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.
  - ralfn 9y ago
    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.
- systems 9y ago
  I dont see any C++ https://github.com/Microsoft/vscode https://github.com/Microsoft/vscode
  - 0xcoffee 9y ago
    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.
- ralfn 9y ago
  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.
curiousess 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?
- 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.
nkkollaw 9y ago
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..?

by kjksf 9y ago

noncoml 9y ago

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?

hacker_9 9y ago
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.
- pducks32 9y ago
  Honestly I use both often and just the startup makes it seem faster. Just the startup alone makes such a large difference to perception.
murukesh_s 9y ago
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.
- ralfn 9y ago
  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.
systems 9y ago
I dont see any C++ https://github.com/Microsoft/vscode https://github.com/Microsoft/vscode
- 0xcoffee 9y ago
  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.
ralfn 9y ago
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.

curiousess 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?

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.

nkkollaw 9y ago

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