13 ms·
Atom 1.29
- statictype 8y agoI 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?
- kapuru 8y agoSadly, no. I tried it out again a couple of days ago and the performance is still terrible. I'm in the same boat as you and switched to VS Code.
- galfarragem 8y agoI hope xray[1] catches up. I prefer atom's UX-UI to any other editor but I agree that performance is still an issue. MS taking over Github doesn't seem to bring to a bright future. I really hope I'm wrong. [1] https://github.com/atom/xray https://github.com/atom/xray
- OberstKrueger 8y agoWith xray focusing away from improving the editor experience and more on this new version control thing [1] for now, it doesn't seem like we'll be seeing a GitHub-provided alternative to Atom for some time. [1] https://github.com/atom/xray/blob/master/docs/updates/2018_07_10.md https://github.com/atom/xray/blob/master/docs/updates/2018_0...
- giancarlostoro 8y agoIn an AMA the future CTO said they would never get into text editor politics by merging the two or taking one away. Both editors will remain.
- akuji1993 8y agoWe'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 until it pretty much looks like Atom, but runs way faster.
- sdiq 8y agoI still use Atom mostly because of the default interface. Care to list the plugins that you used?
- akuji1993 8y agoOf course. The most useful ones are the following: - Bracket Pair Colorizer - EditorConfig for VS Code - ESLint - Git Blame - Material Icon Theme - Path Intellisense - Prettier - Code Formatter - SCSS IntelliSense - TSLInt - Winter is Coming Theme by John Papa
- Lordarminius 8y agoEmmet.
- akuji1993 8y agoI get why people use it, I just don't have any use case for it. I'd rather write my code myself instead. Just a personal preference though.
- deleted 8y ago[deleted]
- statictype 8y agoI don't find the code generation stuff that useful but I found it useful for its text manipulation features - like selecting all text within 2 nodes, editing a start and end tag at once.
- jy3 8y agoI have the same question. I've never bothered looking back extensively at Atom since using VS Code.
- kamilafsar 8y agoI'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.
- Kipters 8y agoFor 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)
- mraison 8y agoThe 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.
- pjmlp 8y agoWe just use Vim or Emacs over SSH in such cases, or if the connection is good enough over X/RDP.
- josteink 8y agoWith Emacs you use it locally and edit via tramp.
- giancarlostoro 8y agoOne of the main reasons I use Emacs whenever I do use Emacs. Though now I just do VS Code and X forwarding.
- pjmlp 8y agoI never heard of tramp, thanks.
- omaranto 8y agoYou might enjoy Mike Zamansky's blog post and short video about it: http://cestlaz.github.io/posts/using-emacs-25-tramp/#.W2HhPHXOXCI http://cestlaz.github.io/posts/using-emacs-25-tramp/#.W2HhPH... Also, the manual is pretty good. It comes with Emacs, of course, or can be read at https://www.gnu.org/software/tramp/ https://www.gnu.org/software/tramp/ My favorite thing about TRAMP is how well integrated it is. It's not just opening remote files, you can also open shells on remote systems, or do file management with dired (I have a bookmark pointing to dired on a remote system I use frequently, for example.)
- kennxfl 8y agoI had a similar experience with performance was an issue for me so I switched over. Never went to back to test any of their newer releases.
- Bahamut 8y agoI've bounced back and forth between Atom and VSCode - the main reason for me has been bugginess with prettier plugins. I've had more weird issues with the VSCode one, so I've leaned more on Atom. Perf for VSCode is definitely much better though.
- superplussed 8y agoIs this still true? I tried Vscode / Atom the other night and Atom performed better for me, at least for the time it took to render the syntax highlighting of each file.
- space_strudel 8y agoSimilar history with Atom, but I haven't looked back after switching to spacemacs :)
- deleted 8y ago[deleted]
- saagarjha 8y agoI 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?
- maxbrunsfeld 8y agoThe 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.
- saagarjha 8y agoOk, 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?
- 8y ago
- DC-3 8y agoHonest 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?
- saagarjha 8y agoI think the goal is adding a sense of lightheartedness and by humanizing code in general, which has historically had the perception of being dry.
- afraca 8y agoI 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.
- matt4077 8y agoI don't think it has an explicit "goal", as in someone wondering "How can my code appear more humanizing?" It's just that people somehow enjoy this new new dimension of expression in text-only media. It has long been pretty obvious that text lacks the subtlety of face-to-face or voice interactions, and that many problems stem from people misjudging the intended tone of writing. Emojis, while imperfect, may help ;)
- calv 8y agoAlso if your coding guidelines can use emojis in commit message to mean a certain thing if you all have a common lookup and it becomes natural to see what a change affects. e.g. :bug: for fixing bugs
- majewsky 8y agoYou can do that with plain ASCII, e.g. Github recognizes the phrase "Closes #123." in commit messages and autocloses that issue when the commit is merged into master. I've seen similar commit hooks in SVN over 10 yrs ago.
- glutamate 8y agoWill 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.
- helb 8y agoThe "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_future_ceo_of_github_ama/e0a235q/ https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman... HN discussion here: https://news.ycombinator.com/item?id=17258114 https://news.ycombinator.com/item?id=17258114
- the_duke 8y agoI just really hope they continue with this experiment: https://github.com/atom/xray https://github.com/atom/xray. It's reducing Electrons job to the view / plugin layer and have most processing done in a Rust backend.
- 013a 8y agoThere's also a similar project hosted by Google, Xi, which seems significantly more promising than xray. [1] https://github.com/google/xi-editor https://github.com/google/xi-editor
- ksec 8y agoSo Xi, is basically like an OpenSourced Version of Sublime Text in Rust? If that is case, why Google doesn't just acquire Sublime Text and open source it? Edit: Turns out Xi was burned out of Fuchsia, the next generation Android. So I guess Xi is tool for testing concept in Fuchsia. And it doesn't look like Xi will be amiable for general usage in the next 2 to 3 years time.
- the_duke 8y ago
- jokoon 8y agoIt's crazy that so fewer editors can fold code blocks in a compact manner, so that it hides line returns that are inside curly braces (might be a little trickier with python) including the ones which are just after and before those braces. So far only visual studio (not code) can do it properly, and one which name I forget. I posted issues everywhere about it. I'm still disappointed, or it might be difficult to implement.
- lainga 8y agoDon't vim foldmethods do this?
- paulclinger 8y agoScintilla (and scintilla-based editors) do this when `fold.compact` is set.
- gonmf 8y agoI wish I could use Atom but I work with very large files at time and it is very slow at some tasks (like selecting all selections of text and editing them all at once), forcing me to use Sublime Text. Can some kind user tell me if this latest version performs better now?
- cjohansson 8y agoUser-interface is still very laggy compared to Emacs but it opened large files much better than I expected, though it disabled syntax coloring for larger files and scrolling is really slow. I wonder how this compares to VS Code and Oni which are also built in Electron..
- gonmf 8y agoI've tested it myself as well. It is still as laggy as I remember, such a shame. I really want a simple graphical editor that can color the files that have been modified in Git.
- curiousgal 8y agolarge files aside, Sublime's startup time is what's keeping me.
- Klathmon 8y agoPlease don't take this the wrong way, but what do you need to do in very large files that requires a fancier editor? I know people will give me shit for this, but this is one of the reasons why I like to have multiple tools for multiple use cases. Atom is for development. It's for programming in source files and being basically an IDE that I have a lot of control and customization over. When I need to work with long logfiles or hunt through large compiled text files, I use something like Sublime. And if the files get absurdly large (like 5GB+) I start reaching for CLI tools. I completely understand that many don't want to work like that, and if it works for you then that's awesome! But I like my tools to be good at what they do, and if that means tradeoffs in areas that other tools are good at, then it's fine with me. Even if Atom could never open a file over 100kb, I'd still use it daily, because it's plugin ecosystem, customization, and the ease that you can write very custom plugins for it is unparalleled. And if atom ever starts giving those things up to be able to open larger files, i'm going to be quite upset.
- hartator 8y ago> ensuring that parsing can never impact the frame rate. This is exciting. Anyone has feedback anout how it actually impact performance?
- Klathmon 8y agoI've been using 1.29 for a while in the beta with the new tree-sitter syntaxes, and i've noticed some changes. It's not groundbreaking, but folding is definately better and more responsive, and using tons of cursors (which often happens from using a plugin that gives me sublime-style click-and-drag to place cursors ability) is improved by a noticeable amount. The new parsers do regress when it comes to opening minified files though, so a 300kb file with the whole file "on one line" will drop the editor to 1fps (interestingly it only happens when something syntax highlighted is on the screen, so if I'm scrolling through a minified file and hit a large enough string that's not highlighted, the FPS picks back up to 60!), but opening 500mb+ logfiles isn't really an issue any more (meaning as long as there are linebreaks at reasonable points, and you don't mind waiting a second for it to open, it's pretty consistently fast). I'm not sure if that was the tree-sitter parser or other updates made in the last year, but at some point it stopped slowing down with "logfile" style large files. Please keep in mind I have an... absurd... amount of plugins installed. I use this editor to do heavy javascript/flow development, as well as python and go and a bit of PHP, with a ton of "nice to have" plugins like automatic test runners, coverage reporters, "intellisense" style IDE stuff, and more for each language. It's also running on a pretty beefy 8-core 32GB machine. so interpret my experience through that lens.
- hartator 8y agoCool, I'll try again today, and try to update this thread.
- deleted 8y ago[deleted]
- welly 8y agoIs it still unbearably slow?
- mpolichette 8y agoI don't understand the desire for all the git integration into the editor. I mean, it might make sense because Atom is owned by Github, but why otherwise? I feel like a lot of their resources are being put towards git integration instead of improving the editor and performance... which are some of the primary reasons people leave for VSCode. Maybe I'm the odd man out though, since I like to use CLI git directly.
- NickBusey 8y agoI've been using PHPStorm's Git interface for a while now, and as a lover of CLI tools, I can definitively say I will never use command line git again. Hello `Smart Checkout` goodbye `git stash; git pull; git checkout branch-2; git stash pop`. Hello clicking one line and hitting revert on that one line, goodbye trying to revert that one line with `git diff` output or whatever. A good git interface really is a game changer and can speed up your workflow quite a bit, especially if you utilize feature branches/git flow.
- Smotko 8y agoI felt the same way as you do, I used the git CLI directly and could never use a git GUI. But then I figured out that Atom's git integration is actually quite neat and I started using it mostly to do `git add -i` as it makes staging files or parts of files really easy. I still don't trust it with pushing/pulling, switching branches etc. so I still drop to the command line for those, but the atom git integration is incredibly useful for seeing your changes and committing a particular part of them.
- dvlsg 8y agoI agree. I use the command line for everything but staging, and I often only stage parts of files while discarding a few leftover pieces I forgot about. I use sourcetree, but the concept is the same. GUI git is really nice for staging parts of changes. And then I usually commit via the GUI too, since I'm in there anyways.
- dkhenry 8y agoI have been swayed from using the CLI by emacs and magit. There are so many nice things like staging portions of a changeset, and the ability to get a quick visual diff of the changes before they are committed is really really nice. As to why they would work on it, the two main reasons I keep going back to emacs from Atom and VS Code is magit, and the ability to run in a console. to me Atom and VS Code are fast enough for my day to day work
- vorpalhex 8y agoWhat packages are folks using these days?