Hacker News new | past | comments | ask | show | jobs | submit login
Easily Review Comments in Atom – The GitHub Blog (github.blog)
35 points by vishnu_ks 8 days ago | hide | past | web | favorite | 23 comments





I still think it's a little bit bizarre that Microsoft now owns both Atom and VS Code. Surely it can't make sense in the long run to keep both of them going.

...what Microsoft really owns is Github! Each editor appeals to a different class of users. As long as they make sure they both integrate better with Github than with competition (GitLab, Butbucket etc.), then they bring and keep users to their GitHub platform!

But if some of Atom's "hackability spirit" would spill over to VSCode we'd appreciate it ;) It may be significantly more usable, but it lacks that "man, it feels just feels hackily good, like an Emacs for the 21st century" of Atom.


I find it so interesting that whenever there is a HN post about VS Code nobody mentions Atom but it's guaranteed that the top post for any Atom HN post references how Microsoft own s both.

It really shows how far VS Code has come in terms of developer mindshare.


It seems more like fear among Atom's users that Microsoft will decide to kill Atom or let it slowly slide into irrelevancy.

VS Code is slowly eating the classic Visual Studio userbase IMO.


Not just visual studio. There are definitely _tons_ of users who moved from Atom, Sublime, Brackets, or even Emacs/Vim to VS Code. I know all of the above.

Don’t know any VS users other than former professor, and he definitely hasn’t switched to VS Code.


I agree that it is strange.

I use VS Code for coding but my students apply their research to Atom plugins since it is much more hackable. If only they would open VS Code up a bit more...


Vscode is perfectly hackable and open, can you be more specific?

From what I have tried, VS Code doesn't allow access to the DOM or give much of an API to modify the visual layer. This makes it very difficult to draw visualizations on top of the editor. It also does not allow plugins to go beyond the standard tab-document metaphor.

For example, students of mine tried to re-implement Patchworks [1] as a VS Code plugin. Didn't seem feasible. They have been very successful in building it in Atom though. As another example, I tried to make a tool that displays a call graph visualization on top of the editor [2]. But again, this was easy in Atom but I couldn't figure it out in VS Code.

Please point me to any documentation or examples of how to implement features like those.

[1] https://youtu.be/GwcxDZT3pXE

[2] http://web.eecs.utk.edu/~azh/pubs/Henley2018bDissertation.pd... Figure 36


It's quite hackable but not like Atom or Emacs.

You can find some plugins that could make Atom seems completely different, but most of the VSCode image you can find on the internet remains similar.

Just like with Emacs you can rewrite Emacs itself. And all of the changes in Atom do not require restarting, while some of the VSCode plugins require to restart the code editor (but might explain a little bit why VSCode is faster).


Definitely a little bizarre, but I could justify it if needed:

Atom caters more to the lightweight editor crowd (along with Sublime)

VSCode will continue to deeply integrate with intellisense and typed languages to become a 'new' Visual Studio. It's more of an IDE (like RubyMine)

I find myself wanting VSCode for some specific tasks or projects, but I am not close to considering switching to it as my primary editor.


I have found Visual Studio Code to be more lightweight than Atom, resource-wise. Unless you are talking about lightweight in the sense of features?

Resource consumption is less of a concern to me than general 'snappiness'. Since I have a bunch of RAM, go ahead and use it all if I can have a good experience.

I don't actually use Atom, though I use Sublime full time. My biggest reason for not being able to use Visual Studio is that all functions, be it fuzzy search, regular text search, navigating tabs, even entering a character carries the load of the VSCode IDE. It must parse each character for chances to present additional information, which is great if that's what you want.

Subjectively, I find VSCode too laggy to work at my usual pace.


Atom is definitely NOT an improvement in that regard. Microsoft optimized the shit out of the parsing bits of VSCode, moving as much as they could into C++ Node extensions for speed and responsiveness. As Electron apps go, VSCode is tense nearly to the point of rupture. Atom has made great strides, but afaik is still not there yet.

VSCode does seem to fit that (increasingly less of a) niche for writing JS with IDE features, but it really feels out-of-place as a C++ IDE.

It's relatively good for Rust.

Yeah, I use Atom for JS and VSCode for Rust.

I wish we had found a way to integrate these review features in to git itself so this feature would work no matter where you hosted your git repo rather than having every text editor have to implement proprietary apis.

An ActivityPub federated service over-top Git might be an interesting avenue to investigate, allowing for a code review/issues/release/etc... system that could be VCS-agnostic.

I hear this a lot, and I still don't really get it - git is already decentralized! And not just federated, but truly decentralized where everyone has their own copy of the data. An issue tracker built on top of the git protocol, where issues/PRs/whatever arbitrary other rich text content you want lives inside the .git directory alongside the source code would be much more in the spirit of git. And you could build a pretty modern web interface on top of that!

Please help make this happen. A decentralized SCM platform built on IPFS or fully integrated into Git is my dream of the future.

Thats not needed. Just bundle the data in the same way that branches and other data is so I can do a git fetch and it pulls in everyones comments.

I want to add code reviews in git-bug at some point: https://github.com/MichaelMure/git-bug

For my workflow, this is great news. Less flipping about back and forth. Thanks, GitHub team!



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: