8 ms·

Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff

Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff you don't have to make, don't do it. Atom and VSCode have made that tradeoff. I don't know what rehashing this can possibly accomplish.

hartator 10y ago
It's a bit the same issue then something like rails. Easy in the short run, but when you starting doing advance optimization - likw those - you wonder why not rewrite in a more performance oriented language.
- Klathmon 10y ago
  Because the whole point of the editor is the web stack. The fact that it's built on web technologies, and web developers can make plugins easily and quickly and can hack on the core code is the entire reason for it's existence, and why it's so popular. If you rewrite it in another stack, you basically just created an entirely new editor which isn't compatible in just about every way with atom.
- Touche 10y ago
  Great comparison. In both cases choosing the language that helps you launch quickly is almost always the right decision. You can always scale later. Better to find out if your app is even going to be a success, first.
ruleabidinguser 10y ago
I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.
- chickenfries 10y ago
  It's a benefit if your engineers already know JavaScript, obviously. Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.
  - ruleabidinguser 10y ago
    I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer. Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.
    - deleted 10y ago
      [deleted]
    - coldtea 10y ago
      >In my experience all languages are essentially the same. That's the problem: you don't seem to have enough experience.
      - ruleabidinguser 10y ago
        I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive? So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.
        coldtea 10y ago
        >So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. That's because you either used the languages superficially, or use only very similar languages, probably of the Algol family (e.g. Ruby, Python, PHP, JS, etc). You won't get very far with Haskell "over the course of a week". Or APL. Or Idris. Or Erlang. Or Lisp -- or any other language that's not a mere Algol derivative with some different bells and whistles. And even those have their idioms, of course, that one needs much more than a week to get competent with, but, it gets worse when we expand languages to not be "mainstream Algol derivatives". One would only be using languages like Smalltalk, OcamL, Scheme, Scala, Self, etc, superficially without getting into their idioms and nuance, which wont happen in a week (and can take years to really master).
coldtea 10y ago
>Must every thread about VSCode and Atom start the same way If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with. >It's a trade off: performance for a cross platform JavaScript app development. It's an unnecessary tradeoff. If a single developer can create ST from scratch for Windows, OS X and Linux, then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++, wrap them, and have the rest of the development (plugins etc) happen in JS (to keep the familiar language, easy access to npm modules, etc).
- dstaley 10y ago
  If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
  - jen20 10y ago
    IntelliJ does a good job of it without resorting to Electron.
    - dstaley 10y ago
      IntelliJ doesn't use native UI components though. Furthermore, Atom can open a single file in 3s, whereas opening the same file in IntelliJ takes 11s (these numbers are from cold starts). This is with clean installs of both IDEs on a 2016 MacBook Pro.
    - cwyers 10y ago
      No, it just resorts to the freaking JVM, which is not any more lightweight or native than Electron apps.
      - Veratyr 10y ago
        I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.html https://benchmarksgame.alioth.debian.org/u64q/javascript.htm... Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ And yes, there are many Java apps that like to eat memory but I don't believe it's as bad or worse than V8/Electron and I don't believe Java is as inherently memory hungry as V8/Electron.

hartator 10y ago

It's a bit the same issue then something like rails. Easy in the short run, but when you starting doing advance optimization - likw those - you wonder why not rewrite in a more performance oriented language.

Klathmon 10y ago
Because the whole point of the editor is the web stack. The fact that it's built on web technologies, and web developers can make plugins easily and quickly and can hack on the core code is the entire reason for it's existence, and why it's so popular. If you rewrite it in another stack, you basically just created an entirely new editor which isn't compatible in just about every way with atom.
Touche 10y ago
Great comparison. In both cases choosing the language that helps you launch quickly is almost always the right decision. You can always scale later. Better to find out if your app is even going to be a success, first.

ruleabidinguser 10y ago

I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.

chickenfries 10y ago
It's a benefit if your engineers already know JavaScript, obviously. Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.
- ruleabidinguser 10y ago
  I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer. Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.
  - deleted 10y ago
    [deleted]
  - coldtea 10y ago
    >In my experience all languages are essentially the same. That's the problem: you don't seem to have enough experience.
    - ruleabidinguser 10y ago
      I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive? So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.
      - coldtea 10y ago
        >So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. That's because you either used the languages superficially, or use only very similar languages, probably of the Algol family (e.g. Ruby, Python, PHP, JS, etc). You won't get very far with Haskell "over the course of a week". Or APL. Or Idris. Or Erlang. Or Lisp -- or any other language that's not a mere Algol derivative with some different bells and whistles. And even those have their idioms, of course, that one needs much more than a week to get competent with, but, it gets worse when we expand languages to not be "mainstream Algol derivatives". One would only be using languages like Smalltalk, OcamL, Scheme, Scala, Self, etc, superficially without getting into their idioms and nuance, which wont happen in a week (and can take years to really master).

coldtea 10y ago

>Must every thread about VSCode and Atom start the same way If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with. >It's a trade off: performance for a cross platform JavaScript app development. It's an unnecessary tradeoff. If a single developer can create ST from scratch for Windows, OS X and Linux, then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++, wrap them, and have the rest of the development (plugins etc) happen in JS (to keep the familiar language, easy access to npm modules, etc).

dstaley 10y ago
If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
- jen20 10y ago
  IntelliJ does a good job of it without resorting to Electron.
  - dstaley 10y ago
    IntelliJ doesn't use native UI components though. Furthermore, Atom can open a single file in 3s, whereas opening the same file in IntelliJ takes 11s (these numbers are from cold starts). This is with clean installs of both IDEs on a 2016 MacBook Pro.
  - cwyers 10y ago
    No, it just resorts to the freaking JVM, which is not any more lightweight or native than Electron apps.
    - Veratyr 10y ago
      I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.html https://benchmarksgame.alioth.debian.org/u64q/javascript.htm... Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ And yes, there are many Java apps that like to eat memory but I don't believe it's as bad or worse than V8/Electron and I don't believe Java is as inherently memory hungry as V8/Electron.