7 ms·

This seems aimed squarely at VSCode. VSCode does a lot of this now out of the box (or with a few extensions). I think Atom is really just trying to keep up. I p

This seems aimed squarely at VSCode. VSCode does a lot of this now out of the box (or with a few extensions). I think Atom is really just trying to keep up. I personally do not believe they have the horsepower to compete with Microsoft here though. VSCode is a phenomenal product.

Longhanks 9y ago
Most importantly, VS Code does all this with a lot better performance and without Facebook.
- pritambaral 9y ago
  > and without Facebook Does Atom have any kind of Facebook integration?
  - shados 9y ago
    They're referring to how a lot of these plugins are features extracted from Nuclide and/or open sourced by Facebook.
- Pigo 9y ago
  I fought for Atom for a long time. But after browsing a node_modules folder in Code, I realized how much I'd just accepted poor performance. It also worked as good on my Linux devices as my work pc.
  - whipoodle 9y ago
    My impressions were the same. Unfortunately VS Code caused some data loss on the first day I tried it, so I chose to keep using Sublime, but it seems really good overall.
    - nerdponx 9y ago
      data loss Care to elaborate? Might be good to help others avoid the same problem.
      - whipoodle 9y ago
        Basically, it closed a buffer because the backing file disappeared when I checked out a different branch. So I guess the lesson is use your file system to retain data and never your editor, which sounds obvious and you could certainly argue the loss was my fault. But I do that all the time with Sublime and never had this problem once. In fact I could quit Sublime altogether and the data would still be there when Sublime reopened. Basically, I can see how the choice they made is a reasonable one, but my stance is a buffer should never close until I say so. If the backing file disappears, the last contents of the buffer should stay in there until I close it. I bet a lot of people will never get bit by this, but it's nasty enough that I think they should reconsider this decision. But for me it doesn't matter, I don't want to lose work because I trusted my editor to hold on to something and it didn't, so I'll likely never use it again.
        betenoire 9y ago
        I think every editor can probably configured to do this. I've set up my VIM to do this specifically (auto reload the buffer when the file is modified). I don't think that one's on VSCode.
        _tulpa 9y ago
        They're not configured to do that by default, most of them ask prompt you if a file changes. This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.
        bpasero 9y ago
        VS Code will never close a buffer that has changes (e.g. is dirty). In this case, the buffer was closed because the editor was not dirty. You can change this by configuring "workbench.editor.closeOnFileDelete": false
- krisdol 9y ago
  > and without Facebook And Atom does it without Microsoft. Seriously though, what kind of comment is that? Facebook develops open source plugins for the atom ecosystem, and somehow that's supposed to be the most important criticism?
  - thaiphanvevo 9y ago
    Facebook set a precedent in their open source licensing rules where users of their libraries aren't allowed to sue them for patent infringement.
    - bitmapbrother 9y ago
      And this is somehow worse than a company that has extorted money from and threatened companies for using Linux?
    - thewhitetulip 9y ago
      Why would the users of their libraries sue Facebook for patent infringement? I don't get it.
      - adamhepner 9y ago
        If I recall the argument against Facebook here, the point is: let's assume that you found a company, file for a patent and implement it using some open source tools/libraries, also backed by Facebook. Now somewhere down the line FB decides that your product is really great and they can make something similar work for their platform, so they pour resources into developing their version of your solution. You are pissed, and take them to court - but you yourself are now in breach of licence, so before you can take them to court, you need to invest (possibly a lot of) time and resources to move away from those libraries - and in the meantime their competetive product with their whole financial baking is probably giving your little one a pounding which you may not survive. If you hadn't had used any FB libraries in the first place and Facebook decided to copy your product, you would at least have a chance to make your case in court in a timely manner. But I'm also from Europe and may not understand all the intricacies of US justice system, so feel free to correct me if I'm wrong.
vorpalhex 9y ago
I've always chosen Atom over VSCode because I don't want these features. Autocomplete even on really expensive IDEs runs way to slow, clever auto formatting and it's ilk tend to not work well for me at all, and I dislike the overbearing project management features in most IDEs. I want a text editor that vaguely understands code with some simple file browsing and plug and play extensions. Atom trying to become VSCode isn't beneficial here at all.
- komali2 9y ago
  >I want a text editor that vaguely understands code with some simple file browsing and plug and play extensions This is my config of vscode. I disabled all autocomplete because it seemed shitty and non-functional to me (for example, I'm in an HTML file and type "<d," I see now "dialog," followed by "div." Figuring out how many times I need to press "tab" is a lot worse UX for me than just typing "<div>" every time). With all that autocomplete, pop-up dropdown menu BS disabled, it's nice and smooth.
- mrnaught 9y ago
  > Autocomplete even on really expensive IDEs runs way to slow.. Not true for jetbrains ones. Autocomplete speed is One of the reasons for me to go for their toolbox subscription
  - vorpalhex 9y ago
    Even with a fully unlocked enterprise license on it, autocomplete was lagging far behind me on a high end macbook pro. Maybe I just type too fast or the libraries I use are poorly laid out, but it was not working.
    - romanovcode 9y ago
      Java.
  - krisdol 9y ago
    I recently fired up WebStorm and found typing to be slower than atom for most files. I wouldn't open a large file in atom, sure, but it's been getting better in that regard and generally most of my code files are < 400 lines anyway.

Longhanks 9y ago

Most importantly, VS Code does all this with a lot better performance and without Facebook.

pritambaral 9y ago
> and without Facebook Does Atom have any kind of Facebook integration?
- shados 9y ago
  They're referring to how a lot of these plugins are features extracted from Nuclide and/or open sourced by Facebook.
Pigo 9y ago
I fought for Atom for a long time. But after browsing a node_modules folder in Code, I realized how much I'd just accepted poor performance. It also worked as good on my Linux devices as my work pc.
- whipoodle 9y ago
  My impressions were the same. Unfortunately VS Code caused some data loss on the first day I tried it, so I chose to keep using Sublime, but it seems really good overall.
  - nerdponx 9y ago
    data loss Care to elaborate? Might be good to help others avoid the same problem.
    - whipoodle 9y ago
      Basically, it closed a buffer because the backing file disappeared when I checked out a different branch. So I guess the lesson is use your file system to retain data and never your editor, which sounds obvious and you could certainly argue the loss was my fault. But I do that all the time with Sublime and never had this problem once. In fact I could quit Sublime altogether and the data would still be there when Sublime reopened. Basically, I can see how the choice they made is a reasonable one, but my stance is a buffer should never close until I say so. If the backing file disappears, the last contents of the buffer should stay in there until I close it. I bet a lot of people will never get bit by this, but it's nasty enough that I think they should reconsider this decision. But for me it doesn't matter, I don't want to lose work because I trusted my editor to hold on to something and it didn't, so I'll likely never use it again.
      - betenoire 9y ago
        I think every editor can probably configured to do this. I've set up my VIM to do this specifically (auto reload the buffer when the file is modified). I don't think that one's on VSCode.
        _tulpa 9y ago
        They're not configured to do that by default, most of them ask prompt you if a file changes. This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.
        bpasero 9y ago
        VS Code will never close a buffer that has changes (e.g. is dirty). In this case, the buffer was closed because the editor was not dirty. You can change this by configuring "workbench.editor.closeOnFileDelete": false
krisdol 9y ago
> and without Facebook And Atom does it without Microsoft. Seriously though, what kind of comment is that? Facebook develops open source plugins for the atom ecosystem, and somehow that's supposed to be the most important criticism?
- thaiphanvevo 9y ago
  Facebook set a precedent in their open source licensing rules where users of their libraries aren't allowed to sue them for patent infringement.
  - bitmapbrother 9y ago
    And this is somehow worse than a company that has extorted money from and threatened companies for using Linux?
  - thewhitetulip 9y ago
    Why would the users of their libraries sue Facebook for patent infringement? I don't get it.
    - adamhepner 9y ago
      If I recall the argument against Facebook here, the point is: let's assume that you found a company, file for a patent and implement it using some open source tools/libraries, also backed by Facebook. Now somewhere down the line FB decides that your product is really great and they can make something similar work for their platform, so they pour resources into developing their version of your solution. You are pissed, and take them to court - but you yourself are now in breach of licence, so before you can take them to court, you need to invest (possibly a lot of) time and resources to move away from those libraries - and in the meantime their competetive product with their whole financial baking is probably giving your little one a pounding which you may not survive. If you hadn't had used any FB libraries in the first place and Facebook decided to copy your product, you would at least have a chance to make your case in court in a timely manner. But I'm also from Europe and may not understand all the intricacies of US justice system, so feel free to correct me if I'm wrong.

vorpalhex 9y ago

I've always chosen Atom over VSCode because I don't want these features. Autocomplete even on really expensive IDEs runs way to slow, clever auto formatting and it's ilk tend to not work well for me at all, and I dislike the overbearing project management features in most IDEs. I want a text editor that vaguely understands code with some simple file browsing and plug and play extensions. Atom trying to become VSCode isn't beneficial here at all.

komali2 9y ago
>I want a text editor that vaguely understands code with some simple file browsing and plug and play extensions This is my config of vscode. I disabled all autocomplete because it seemed shitty and non-functional to me (for example, I'm in an HTML file and type "<d," I see now "dialog," followed by "div." Figuring out how many times I need to press "tab" is a lot worse UX for me than just typing "<div>" every time). With all that autocomplete, pop-up dropdown menu BS disabled, it's nice and smooth.
mrnaught 9y ago
> Autocomplete even on really expensive IDEs runs way to slow.. Not true for jetbrains ones. Autocomplete speed is One of the reasons for me to go for their toolbox subscription
- vorpalhex 9y ago
  Even with a fully unlocked enterprise license on it, autocomplete was lagging far behind me on a high end macbook pro. Maybe I just type too fast or the libraries I use are poorly laid out, but it was not working.
  - romanovcode 9y ago
    Java.
- krisdol 9y ago
  I recently fired up WebStorm and found typing to be slower than atom for most files. I wouldn't open a large file in atom, sure, but it's been getting better in that regard and generally most of my code files are < 400 lines anyway.