Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom 1.29

blog.atom.io

Post reply on HN
Print view View original

11–20 of 120 posts

Re: Atom 1.29

#11

Post by Kipters »

kamilafsar wrote: post #10
statictype wrote: post #2

I haven't used Atom for at least an year and a half now - After trying out Visual Studio Code I haven't looked back. Has the performance improved? Is it at the level of VS Code?

I've a similar story and several teams at our company have switched to VS Code independently. There are some Atom "believers" though. I hope github is going to continue working on Atom independently from MSFT. Competition is a good thing. But since both products target the same audience, from Microsoft's perspective I'd understand if they'd bring those brilliant minds together in one team.

For what is worth, in an AmA Nat Friedman stated that development of Atom will continue "as long as there's people using it", and they will probably share some code between vscode and atom (they already do)

Re: Atom 1.29

#12

Post by glutamate »

Will Atom and Visual Studio Code merge into one project now that Microsoft bought GitHub? Or at least stop sharing extensions?

I would vote yes! I would love to see better GitHub integration in VS Code.

Re: Atom 1.29

#13

Post by maxbrunsfeld »

saagarjha wrote: post #7

I see a GIF of someone going deleting a couple lines of code, with a meter showing that the application is maintaining 60 FPS. Was this not something Atom could do before? It seems to me that the bare minimum should be maintaining 60 FPS while performing basic editing tasks…is there some nuance here I'm missing?

The GIF is just intended to represent an idea - that parsing (for the purpose of syntax highlighting and other code analysis) can no longer impact the app's frame rate, because it has been offloaded onto a background thread. The actual operations depicted in the recording are not a performance breakthrough.

Re: Atom 1.29

#14

Post by saagarjha »

DC-3 wrote: post #9

Honest question: can someone explain why everyone loves emoji these days, especially with regards to 'modern' programming communities such as those around JS and Rust? Is it just a celebration of the fact that we have Unicode support everywhere now?

I think the goal is adding a sense of lightheartedness and by humanizing code in general, which has historically had the perception of being dry.

Re: Atom 1.29

#15

Post by mraison »

statictype wrote: post #2

I haven't used Atom for at least an year and a half now - After trying out Visual Studio Code I haven't looked back. Has the performance improved? Is it at the level of VS Code?

The one reason I'm still using Atom is because of the remote editing experience with Nuclide + Watchman server-side. No other editor that I've tried comes even close (the connection drops, files get out of sync, new files don't show up, etc, etc)

Given the huge number of people who work on remote servers, I find it surprising that proper solutions are still so hard to find. A "file system provider API" for VSCode is in the works so I'm hopeful for the future.

Re: Atom 1.29

#16

Post by saagarjha »

maxbrunsfeld wrote: post #13
saagarjha wrote: post #7

I see a GIF of someone going deleting a couple lines of code, with a meter showing that the application is maintaining 60 FPS. Was this not something Atom could do before? It seems to me that the bare minimum should be maintaining 60 FPS while performing basic editing tasks…is there some nuance here I'm missing?

The GIF is just intended to represent an idea - that parsing (for the purpose of syntax highlighting and other code analysis) can no longer impact the app's frame rate, because it has been offloaded onto a background thread. The actual operations depicted in the recording are not a performance breakthrough.

Ok, that's nice to know. I know my initial comment probably came off as the stereotypical Hacker News sneer, but in my defense the picture, at least to me (having not used Atom for more than four years due to its poor performance when I tried it in the beta) makes it look like Atom was having issues maintaining a decent frame rate for the editing task shown, and is now able to provide this.

Or, to put it another way: your depiction in the article really makes it easy for those who have reservations about using Atom to come to the wrong conclusion, and it's not one that paints it in a good light. Might I suggest replacing it with a GIF that showcases the actual issue that this release was supposed to fix?

Re: Atom 1.29

#17

Post by helb »

glutamate wrote: post #12

Will Atom and Visual Studio Code merge into one project now that Microsoft bought GitHub? Or at least stop sharing extensions? I would vote yes! I would love to see better GitHub integration in VS Code.

The "future CEO of GitHub" said they will continue to develop and support both VSCode and Atom: https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...

HN discussion here: https://news.ycombinator.com/item?id=17258114

Re: Atom 1.29

#18

Post by Luc »

saagarjha wrote: post #16
maxbrunsfeld wrote: post #13

Earlier quoted context omitted.

The GIF is just intended to represent an idea - that parsing (for the purpose of syntax highlighting and other code analysis) can no longer impact the app's frame rate, because it has been offloaded onto a background thread. The actual operations depicted in the recording are not a performance breakthrough.

Ok, that's nice to know. I know my initial comment probably came off as the stereotypical Hacker News sneer, but in my defense the picture, at least to me (having not used Atom for more than four years due to its poor performance when I tried it in the beta) makes it look like Atom was having issues maintaining a decent frame rate for the editing task shown, and is now able to provide this. Or, to put it another way:…

This is a perfect 'LOL hn' comment if I ever saw one.

Re: Atom 1.29

#19

Post by sdiq »

akuji1993 wrote: post #5
statictype wrote: post #2

I haven't used Atom for at least an year and a half now - After trying out Visual Studio Code I haven't looked back. Has the performance improved? Is it at the level of VS Code?

We've also been in the same boat as you guys. Starting to just look into VSCode as an alternative, then immediately switching to it after realising the performance difference is like night and day. Since Atom doesn't provide anything that we can't install in VSCode as a plugin, there really is no reason to use Atom right now. The only problem I had with VSCode was the default interface, that I modified with plugins u…

I still use Atom mostly because of the default interface. Care to list the plugins that you used?

Re: Atom 1.29

#20

Post by afraca »

saagarjha wrote: post #14
DC-3 wrote: post #9

Honest question: can someone explain why everyone loves emoji these days, especially with regards to 'modern' programming communities such as those around JS and Rust? Is it just a celebration of the fact that we have Unicode support everywhere now?

I think the goal is adding a sense of lightheartedness and by humanizing code in general, which has historically had the perception of being dry.

I don't mind it being used in some (mostly) 'closed off' service, but given how commit messages from git will show up on several locations it seems a bad idea to allow users to use `:art:` in a commit message IMHO.
Post reply on HN