8 ms·

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

by Longhanks 9y ago

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
        nerdponx 9y ago
        Having that default to "true" is really silly. VSCode is OSS right? That seems like a mulligan pull request to me. I can't imagine anyone is relying on the default behavior as-is.
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.

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
        nerdponx 9y ago
        Having that default to "true" is really silly. VSCode is OSS right? That seems like a mulligan pull request to me. I can't imagine anyone is relying on the default behavior as-is.

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.