Atom 1.34

https://blog.atom.io/2019/01/08/atom-1-34.html

by tosh • 8 years ago

47 32 8 years ago

blog.atom.io

tosh• 8 years ago

commit previews: https://github.com/atom/github/pull/1767

maxyme• 8 years ago

These features are all great but Atom has some big issues to fix that have been around for years. Things like the finder reindexing files every time the window loses focus: https://github.com/atom/fuzzy-finder/issues/88

Additionally the Atom-IDE packages and what will happen with them, many of them have PRs that have been merged in to fix bugs but never published to the package (for about a year now). Although Facebook dropped support for Atom-IDE it still has nearly 1 million downloads and largely works well but can no longer be contributed to since the repo is archived and the packages aren't up to date.

bhhaskin• 8 years ago

It seems like all of these changes are related to being able to use git inside of atom, but I use the terminal for that and have zero desire to use clunky GUI. The last few release haven't addressed any of the issues or really progressed the editor forward.

justapassenger• 8 years ago

I’m old school vim person, so don’t have much clue. Is atom still relevant or is vscode taking over everything?

edoceo2• 8 years ago

Our shop has 4 devs, one on VSCode, unlikely to convert, three on Atom. I was the last covert to Atom here - after 15+ years on jEdit.

d3sandoval• 8 years ago

For a second there, I thought I finally found the other person on the internet who was a jEdit zealot. But then I realized it's the same person I've known for years ;)

What makes you stick to Atom? I switched to VSCode due to Atom's terrible performance when opening huge files.

pjmlp4• 8 years ago

VSCode is the only Electron app that I care to have on my computer, mostly due to TypeScript and Rust.

Interesting how Microsoft manages to do in TypeScript stuff that Github not even with C++ managed to (according to the interwebs), regarding performance.

Now that they are also part of Microsoft, maybe they could share some information among them.

quaunaut• 8 years ago

At the same time, on a giant project, I'm finding VSCode's performance starts to fall apart completely where Atom performs the exact same as before.

For example- it's not uncommon for Vim mode in VSCode to just stop functioning for 5-10 seconds on large projects while other addons continue operating.

I keep switching back and forth, primarily because VSCode's performance wins are so deceptive- it will feel amazing and look cool on some things, then in completely unexpected places just absolutely shit the bed. So I hop back and forth, and have even started working on building my own plugins for VSCode to do the things no one's added to it yet that Atom has addons for.

superdaniel• 8 years ago

For merges and other finicky git actions I’ve been increasingly turning to Atom instead of the commandline. I like how it auto-formats my commit messages to line wrap and how it makes highlighting merge conflicts easy.

For everything else these days I use VSCode.

alexandernst2• 8 years ago

I was a big fan of Atom, but it's constant performance problems combined with the fact that even after Atom's team rewriting huge parts of the project in C++, doing witchcraft and what not, made me switch to VSCode.

I'm still really not sure how/why VSCode feels so responsive and performant compared to Atom, which, according to Atom's devs lengthy blog posts, went through a pile of refactoring, focused exclusively on performance.

Edit: Also, staying with Atom isn't really viable at this point, since development was pretty much halted, in favor of X-Ray (aka Atom 2.0?). The only significant changes that are being made are the GitHub-integration related features.

Klathmon5• 8 years ago

Do you have any more info on active development stopping on Atom?

alexandernst2• 8 years ago

I'm saying this based on the decrease of activity in Atom's repo (publicly visible in the "Insights" tab in their repo) and the fact that the last few releases haven't had any significant changes, expect the GitHub integration.

brad0• 8 years ago

I know this is not a popular opinion but I feel that atom never had the right priorities for a project.

A text editor’s primary goal is to be fast and responsive.

Atom uses a rendering layer that makes no sense in the context of a text editor.

Using a DOM introduces all this cruft that takes away from actually editing text files.

scotty792• 8 years ago

It's very popular opinion and it's demonstrably wrong. Atom was carving out niche from all the fast and responsive text editors by being open source editor with plugins that are easy to write, inspect and fix when they are buggy. Only dangerous competition for atom is vs code because it does exactly the same only a bit faster.

What you are saying is similar to that the Firefox never had priorities right because instead making itself faster and more responsive it made possibles all those script and DOM based extensions.

Being able to extend your tools without messing with binaries or learning dialect of lisp and some weird gui toolkit is a huge feature that Atom brought to editor market.

pjmlp4• 8 years ago

Nah, I remember being able to do all of that with Windows commercial editors like SlickEdit.

So those Atom "innovations" are only relevant on a market where developers refuse to buy their tools.

Klathmon5• 8 years ago

But your wants and needs aren't universal.

My perfect editor needs to be as configurable and customizable as possible, and I couldn't give a rats ass about startup performance or large file rendering performance.

For me, an editor where I can't display inline images alongside text which is in multiple languages (including some RTL languages) while linting and providing IDE level features all while displaying inline test coverage results is worse than an editor that starts instantly.

From that perspective, a browser is the perfect abstraction.

It's okay if Atoms priorities aren't for you, but saying they are wrong is like saying trains are wrong because they can't do 0 to 60 in 4 seconds.

zozbot123• 8 years ago

For me, an editor where I can't display inline images alongside text which is in multiple languages (including some RTL languages) while linting and providing IDE level features all while displaying inline test coverage results is worse than an editor that starts instantly.

Emacs does provide these features, and it's not too slow at startup either. It's a really nice operating system "abstraction"... too bad that they haven't gotten around to making a good editor for it.

pjmlp4• 8 years ago

SlickEdit does all of that while being native, fast and handling big data sets.

haolez• 8 years ago

I was an Atom user until 1.30 or so and I really like its UI, but sometimes it would just max the CPU usage in my Linux box until I closed it and opened it up again. I don't like VSCode as much, especially its clunky Git interface, but it is more stable than Atom and I'm sticking with it for now.

h1d• 8 years ago

Will Electron's development slow down when Atom has other strong competitors and lose traction?

Atom 1.34

Related Stories