Sunsetting Atom

https://github.blog/2022-06-08-sunsetting-atom/

by ewired • 4 years ago

1320 853 4 years ago

jstx1• 4 years ago

It's what kickstarted Electron which eventually gave us VSCode, Slack, and lots of HN comments about memory usage. It also had the sweetest default theme of any code editor. RIP.

antileet• 4 years ago

Electron was originally known as "Atom Shell"!

davidkunz• 4 years ago

Ha, that makes sense from a physics perspective as electrons orbit the nucleus.

faizshah• 4 years ago

Does anyone remember brackets? I cant remember if brackets or atom came first but I remember switching from sublime to brackets to atom. Good times, I heard DHH is still using TextMate.

solarkraft• 4 years ago

I do, it was quite cool! What stuck most with me is the CSS color picker.

ketzo• 4 years ago

Did my first ever paid programming work in Brackets, helping some friends build a Wordpress blog. Good times.

throw_m2393392• 4 years ago

Brackets came first.

whywhywhywhy• 4 years ago

I still use Textmate, think it's actually excellent these days and still updated a few times a year.

Spellcheck always works, nothing ever crashes and acts weird I run it for 10+ months without issue. VSCode on my PC the spell check is inconsistent and weird and on a long enough timeline it actually crashes the whole operating system if you leave it open.

ngc248• 4 years ago

I am still using brackets on the mac and I have to say very satisfied with it. I came from windows where notepad++ is unbeatable.

IncRnd8• 4 years ago

I've used TextMate for a long time. It works great.

mjmsmith• 4 years ago

I still use TextMate, mainly for the excellent search & replace preview.

dangoor2• 4 years ago

I worked on Brackets full time at Adobe. It came before Atom and had a bit of a different target (designers-who-code vs. developers in general). Brackets was great fun, but it too ultimately needed to be sunsetted.

Brackets was the foundation of Adobe Edge Code, which was part of Creative Cloud, so there were some bigger plans there.

zikani_03• 4 years ago

Brackets was cool and will always be in my memory; made a close friend (who we eventually hired to become a co-worker) because I mentioned that I was working on a Brackets extension on a Facebook group.

skohan7• 4 years ago

Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms.

One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.

Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to support multiple platforms, or you need to target minified javascript of all things, and run your software on top of a large, arcane compatibility layer.

dijit• 4 years ago

I still think of these inefficient things as being great multipliers of potential, even if wasteful.

FWIW: I'm probably one of the most "IT Conservative" people on this site, I still believe in sysadmins, dislike systemd, hate electron etc;

But there is something to be said about developer productivity: if you can build a prototype in 10 days when it would have taken 10 weeks that can be a huge differentiator between companies; it means you can make 6x more prototypes in the same time window, or work through different iterations of the same idea.

That's hugely beneficial.

I think if you treat inefficient things this way (I consider Ruby/Python in the same way) then we all benefit, test your ideas then go for gold on a more efficient platform.

vdnkh• 4 years ago

One could imagine a world where strong standards have been established w

And yet this didn't happen and Electron did. The "free market" of FOSS development settled on Electron as the winner for cross-platform development.

matthewmacleod2• 4 years ago

This is the most sensible take in my mind too.

Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.

zackmorris• 4 years ago

I feel that we were well on our way to a cross-platform, web-based future before mobile smartphones arrived around 2007. Also CSS and frameworks like Angular and React really derailed browser progress because they convinced everyone to use recycler views by hand instead of just making tables and the DOM itself more performant and memory-efficient in the browser itself.

I may be wrong in the moment, but I base my arguments on trends. Processing power, storage costs and bandwidth are always improving. So human productivity should always take priority over efficiency as time progresses.

I'd vote for a real Web 3.0 based on first principles like declarative and data-driven programming, idempotence, immutability, one-shot scripting (perhaps even a Turing-INcomplete DSL) for initial render without side effects (like CSS variables but for HTML), dynamic element loading with something like HTMX, secure server-side includes, distributed databases using Paxos/Raft, even distributed computing with a real Docker that provides an actual secure sandbox and repeatable builds of untrusted secure/private code (maybe with something like homomorphic encryption). I can go on and on about what real (not phantom) tech looks like. And it looks nothing like SPAs.

Also I think a lot of people recognize the need for this stuff, so ideas aren't the problem. The problem is, always has been, and always will be funding. In fact, my single greatest disappointment about the modern web is that stuff like advertising and eBay got coopted so there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001. The closest things we have are Uber and donating plasma. So we have a generation of highly-effective programmers spending the most productive years of their lives at a day job making rent, which is why rent increases. Hustling without understanding that the hustle itself is the failure when viewed through this lens.

Blah I dunno why I write this obvious stuff anymore. It just ain't never gonna happen. It may as well be impossible. Or I should say, it may take another 20 years to get here, and I just don't think we have that long anymore.

danuker2• 4 years ago

One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.

Here is a unified binary format that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS.

But it doesn't support GUIs (yet?).

https://justine.lol/ape.html

llllllllllll92• 4 years ago

one could imagine many things ...

shp0ngle5• 4 years ago

I am honestly not sure why do people minify javascript in electron apps.

It doesn’t really bring any advantage? You need to package whole Chrome with your app, the few MB you save with minification does not matter??

But people here can enlighten me.

shp0ngle5• 4 years ago

By the way “write once, run anywhere” was the original promise of Java. Back in the 90s! Before JavaScript was even a thing!!!

People wrote Java applets that were supposed to be same everywhere. It even had GUI.

Nobody expected that not Java, but _JavaScript_ will be the actual write once-run everywhere.

vlunkr3• 4 years ago

Agreed. I know Electron isn't ideal, but as a Linux user, I have a pretty hard time complaining. In the pre-electron world, something like Slack for linux either wouldn't exist, or would be several versions behind other platforms and have some goofy UI that didn't match the rest of your desktop. At least we have it and it works.

santiagobasulto• 4 years ago

I'm wondering how viable a for-profit electron replacement (with native support) would be? Like Unity (similar business model), but exclusively thought for apps.

doliveira2• 4 years ago

I'd describe it, together with Docker, as good solutions for problems we shouldn't have anymore

marricks2• 4 years ago

Also all have the same magnitude of latency and lag. At least you know if one of them bugs you, they all will.

dewey2• 4 years ago

There's a bunch of Electron powered apps that feel really snappy, definitely faster and snappier than some default apps Apple ships on macOS these days.

Examples for me would be: VSCode and Linear

niutech4• 4 years ago

Before Electron (f.k.a. Atom-Shell), there was Node-Webkit (l.k.a. NW.js), which also was a foundation for plenty of apps: https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companie...

rvz• 4 years ago

Translation: 'Extinguishing Atom Text Editor'.

Really expected and unsurprising.

bm5k• 4 years ago

It took longer than I expected.

mproud• 4 years ago

What recommendations do you all have for alternatives?

kevinwang• 4 years ago

I think the reason it's unused these days is because it's largely been replaced by vscode

Grazester• 4 years ago

Visual Studio Code is the most obvious. I actually forgot Atom existed. I move from it to VSC because Atom was just such a resource hog.

Night_Thastus2• 4 years ago

VSCode seems to be the go-to for most.

shusaku2• 4 years ago

Sublime I guess. I made the switch awhile back because if just how much snappier it is, but it’s sad to see Atom go with all its nice add-ons…

mtkd• 4 years ago

I moved from Sublime to Atom ...

"Atom community involvement has declined significantly"

Probably because it works well enough, some tools don't need endless enhancing

sph3• 4 years ago

    vim -> Sublime -> Emacs -> VSCode -> Emacs
                                         ^^^^^ I am here.

ollien2• 4 years ago

and then vim again. It will come full circle :)

rgoulter2• 4 years ago

If you're retaining vim on your workstation for quick editing of files, I'd encourage you to keep an eye on the Helix editor. https://helix-editor.com/

There are three nice things about it: it flips vim's <verb><motion> into a <motion><verb> (like kakoune); it's got tree-sitter support out of the box (including for navigation); it's got LSP support out of the box.

Its keybinding is perhaps in "uncanny valley" of vim's. Overall, it still feels well thought out.

akagusu5• 4 years ago

My path:

Sublime -> Atom -> Vim -> Emacs -> Emacs -> Emacs -> Emacs

ARandomerDude• 4 years ago

    vim -> Sublime -> vim -> Emacs -> vim -> VSCode -> vim
                                                       ^^^ I am here.

Nicksil• 4 years ago

Sublime Text

https://www.sublimetext.com/

jlduan• 4 years ago

VSCodium

bitwize5• 4 years ago

Honestly? Emacs. Gonna be around for at least as long as RMS is still alive. I'd accept Vim as a runner-up; I'm conversant in it and can see where people might prefer it (though honestly, those people should probably enable evil-mode in emacs).

But realistically? A significant majority of developers use Visual Studio Code; Atom is still only being used by absolute diehards. Visual Studio Code's complete supplantation of Atom (with which it competes for resources in the same organization) is why we're having this discussion.

pantulis• 4 years ago

I used to say that investing some time in becoming proficient with Emacs (the One True Editor!) or vim will deliver returns over a lifetime-spanning career. But Visual Studio Code has already joined them and it is a pretty sensible editor platform to learn.

Also totally subject for discussion: I suspect VS Code will see more innovation in years to come.

natrys• 4 years ago

RMS hadn't been involved with any technical contribution or project level decision making for a while. I would say people like Eli Zaretskii are far more important. While there is no shortage of people willing to hack on elisp, I get the feeling that people who can hack on the C core, and possessing deep knowledge of core subsystems is slowly dwindling.

But I do think Emacs will be fine. I don't think VSCode is an existential threat to Emacs in the same way Toyota is not a threat to Lamborghini. VSCode boasts impressive numbers, but it does so by consolidating in a target demography that was never a stronghold for Emacs to begin with - partly due to some level of indifference on its part. On the other hand, there are things Emacs is uniquely suited for, and for that reason it will continue to attract a particular type. I think in terms of absolute numbers Emacs userbase is still increasing, and I think falling numbers in terms of total percentage doesn't mean much for its survival.

philliphaydon3• 4 years ago

I like brackets but always ends up in VSCode due to extensions.

tristan9572• 4 years ago

Brackets in nearing end of life or is already at that point. Adobe announced it a while ago.

SenHeng2• 4 years ago

Another Brackets user! There must be dozens of us!

I used Brackets too back then and tried Atom a few times but it was always too slow and laggy. I was so glad when VSCode came out and that it was actually good. I was in the midst of switching to VIM but it was just too much of a bother.

corrral2• 4 years ago

It's a very dumb reason to stick with an editor, but I have trouble going back to Sublime after VSCode despite preferring most things about Sublime, because I always forget how to manage packages using Sublime's command prompt and have to screw around with it for a while each time, while VSCode has a GUI for that so the memorization required is zero, and can easily browse available packages without bouncing out to a browser, and it often prompts me to install relevant plugins so it's just a matter of clicking "OK".

Every time I try to go back to Sublime, this annoys me right off the bat and I'm back in VSCode by the end of the day.

wly_cdgr4• 4 years ago

WebStorm and the rest of the IntelliJ suite

ghshephard5• 4 years ago

There are a couple credible alternatives that get a lot of maintenance (I use them both for 3+ hours a day):

If you are coding: Unless you are using IntelliJ (which a ton of of my colleagues do, and love) - it's a vscode world. Everyone at every company I've seen bangs away using that. It's kind of amazing how much inertia it's picked up (currently).

If you are working with text: 90% of the time if I have a couple gigabytes of text I need to do a lot of work with - it's Sublime Text. Actively Developed. A really solid text plugin architecture. The other 10% of the time I still use vim - mostly because it's in my finger DNA. Emacs is the obvious alternative which lots of smart people I know use.

I'd be interested in knowing if there are people who have used all five of these for > 100 hours that would recommend something else - (I haven't used Emacs that much - but I have well over a couple hundred hours on each of intelliJ/vscode/vim/Sublime. Probably close to 1000+ hours on the last three). (okay, small fib - close to 5,000+ hours on Sublime. I spend almost as much time in that tool as I do bash).

acwan93• 4 years ago

I really wanted to use Coda (now Nova [1]) from Panic, but I kept coming back to VSCode. VSCode seems to be the path of least resistance.

I think I’ll try it again after seeing the news about Atom.

[1] https://nova.app/

trinsic23• 4 years ago

Isn't this for MacOS only? Sorry, [I just left Windows](https://www.scottrlarson.com/publications/publication-transi...) recently for it's anti-customer changes in Windows 11, Apple is way worse than Microsoft regarding its anti-choice position on all its products.

drcongo• 4 years ago

I bought and really wanted to love Nova, but I just didn't. It's so clunky compared to ST.

derbOac• 4 years ago

I've used many text editors back and forth and keep going back to Kate. It's what I use now. I'm not sure I'd say it's the best choice for everyone but it's what works for me the best it seems.

forgingahead• 4 years ago

BBEdit.

wsc9813• 4 years ago

I’ve used Sublime Text for many many years now and it’s still my favorite text editor. I mainly use it for writing small reminders as well as Lua / LÖVE dev.

ilrwbwrkhv• 4 years ago

I don't know why anyone would ever move away from Sublime Text in the first place.

adregan3• 4 years ago

Sublime Text came pretty close to dying during the Sublime Text 2 years. I recall development slowed down substantially (it was a solo dev, IIRC), and it being pretty surprising when Sublime Text 3 came out.

wiseowise7• 4 years ago

Proprietary? Lack of quality plugins?

adregan3• 4 years ago

~10 years ago I was a Sublime 2 user surrounded by sad TextMate users—sad because TextMate had stagnated and was clearly on its way out and "everyone" had jumped to Sublime. When Atom was released, Sublime became the editor in decline.

It seemed to me that there would always be an endless cycle of boom and bust with editors. It was a cycle with more in common with fashion than craft, and I wondered if I might end up wasting an inordinate amount of time switching editors throughout my career without any upside. So rather than switch to Atom, only to switch again a few years later, I set about with adopting Vim.

The choice seems to have been correct as there will always be a new editor (that's more or less the same as the old editor) that catches hold, but I wanted stability. Vim gives me stability, and the only other editor I'd consider would be Emacs for similar reasons.

akagusu5• 4 years ago

Just buy a license for Sublime Text or any intelliJ IDE.

If you use your text editor professionally, they more than worth the investment.

And if you want to build a text editor for your own needs, Emacs and Neovim are your friends.

ghishadow• 4 years ago

https://github.com/lapce/lapce is slowly becoming my favourite editor specially for writing Rust.

curiousmindz• 4 years ago

I think the writing was on the wall for a long time.

Since it is only happening in 6 months, I wonder if the community will try to transition/fork it.

Do you know if there is still enough interest?

franciscop2• 4 years ago

I don't think so, even if I use Atom as my primary editor there's a bunch of other great open source ones and even some non-OSS, and migration is trivial, so there's likely no need.

Doctor_Fegg• 4 years ago

“Sunsetting” an open source project seems… unfitting? Hand it off to the community, look for new maintainers, donate it to the Apache Retirement Home for Veteran Projects, sure.

But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.

civilized2• 4 years ago

GitHub is owned by Microsoft, the company that invented "Embrace, Extend, Extinguish".

We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

red_phone• 4 years ago

I’m not sure the term has ever been applied to Microsoft’s own products…

tediousdemise2• 4 years ago

When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block).

Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.

jaywalk4• 4 years ago

VS Code Pro already exists. It's called Visual Studio.

babypuncher2• 4 years ago

"VS Code Pro" came out in 1997

reaperducer• 4 years ago

I'll go Nova before I go VS Code Pro.

alxlaz• 4 years ago

VS Code "Pro" is very 1998.

My money is on VS Code 365.

chipotle_coyote5• 4 years ago

I know that perception of Microsoft will never go away in the open source community, and maybe it shouldn’t, although I’m not convinced Microsoft of 2022 is particularly worse (or particularly better) than most other companies operating simultaneously in open source and proprietary spaces.

The context of “embrace, extend and extinguish” has kind of been diffused over the years, though; it never meant “buy a product and kill it,” but rather meant adopting open standards and adding proprietary (not necessarily closed, which is not the same thing) extensions to them that end up becoming de facto standards, so your product is perceived as better at the task then the fully standards-compliant original. What happened with Visual Studio Code and Atom isn’t an example of this at all. For a start, they’re just two products that are competing in the same space; they’ve never had the same extension standards, so the idea of “embracing and extending” just isn’t relevant here.

Secondly, Microsoft obviously didn’t buy GitHub to shut Atom down. I’ve seen the arguments that once Microsoft did buy GitHub, Atom was doomed, but Code was already arguably more popular than Atom when Microsoft bought GitHub in 2018: Stack Overflow’s developer survey showed VSCode as far more popular among surveyed users (34.9% to Atom’s 18.9%). If those numbers had been reversed—if Code never made a real dent and Atom kept growing—then I have little doubt Atom would be the one continuing.

Lastly, I suspect the runaway popularity of Visual Studio Code is pretty good insurance against a hypothetical “Visual Studio Code Pro” replacing the existing VS Code. This would almost certainly cause a fork (or more than one!) to be created, and it’s highly likely such a fork would get immediate backing and support from one or more technology companies willing to pay for continued open source development.

However, I don’t think that’s likely, because I don’t think that’s how Microsoft is interested in monetizing Code. It’s not a source of income in and of itself. It doesn’t have to be. If it just so happens to have great GitHub integration, maybe your company will pay for GitHub enterprise features. If you’re used to using it, you may be more likely to pay for GitHub Codespaces. If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure. And so on.

cookiengineer• 4 years ago

Note that this will lead to unmaintained Electron Apps until at least 2032.

We're basically fucked.

naikrovek• 4 years ago

Like when they sunset the closed-source .net framework and created the open source .net core?

Or when they sunset the closed-source PowerShell and created the open-source PowerShell Core?

Like those?

jaywalk4• 4 years ago

If the community actually cares enough, they can fork it and continue on with development.

wrycoder• 4 years ago

Probably under a new name - I’d expect MS to be in control of the “Atom” trademark and branding, and they would stop further use.

cedilla• 4 years ago

I agree in principle, but I find it hard to imagine that there's enough interest to find someone who is willing to maintain the software and the package registry.

Speaking of packages - of the six featured packages I get offered on atom.io, only one had a release in the last two years, and half have been unchanged for half a decade. Atom's already dead.

mauvehaus• 4 years ago

A lack of releases could mean dead, but it could also mean finished. As in, complete: not in need of more features, and having no bugs of sufficient severity to bother fixing.

Finished is a state more software should aspire to reach. Sadly, with the advent of connectivity in everything, it's getting rare for even firmware to be finished.

mumblemumble5• 4 years ago

The code isn't being sunsetted, and anyone who wants to take it and keep working on it is free to do so.

But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it is, indeed, an end of sorts. "The community" is almost never large and organized enough to keep a project like this vital. At best, they can only slow its descent into obscurity.

frostwarrior2• 4 years ago

I agree.

Correct me if I'm wrong, but most projects started by some form of organization end up being dead after handing them off to the community. That is, unless they make their code from the ground up to be as most readable and modular as possible.

I remember many projects made by Sun Microsystems that just died when Oracle took over, even if the code is still there.

xbar• 4 years ago

Precisely.

This is a responsible way to handle the ceasing of maintenance while allowing any and all interested members of the Atom community to fork and maintain versions.

I have a much more optimistic view of development communities than you do, and I expect to see Atom endure in some forms.

MatthiasPortzel• 4 years ago

There had been at least one attempt to fork and revive Atom since, as the post mentions, Atom hasn’t seen feature additions in many years.

The problem, as I understand it, is that Atom’s relationship with electron makes it very difficult to work on the core of the editor. Namely, while VS Code is downstream from Electron, and can get feature benefits just by updating their Electron version, Atom is upstream from Electron, and new Electron features needed to be more manually integrated.

noobermin• 4 years ago

Then why did they say they are sunsetting it!? It's in the freaking article

tinco4• 4 years ago

No it's perfectly reasonable. That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit. And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase, they're the same sort of project serving the same sort of market, and the community is much better off with only one of them.

Instead of letting it slowly bleed out and randomly catching stragglers with outdated marketing materials lingering on the web, they give it a swift death. Atom can go into the history books as an open source project that defined the industry for a decade.

blackoil• 4 years ago

VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase

It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.

IncRnd8• 4 years ago

And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase

Atom and VSCode projects have always been separate projects. Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.

mixmastamyk4• 4 years ago

I’ve never seen anyone actually using atom, so would hardly say it defined anything much less than the whole industry.

wildmanx• 4 years ago

That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit.

One should make a difference between (1) access to the source code to look, find bugs, make minor adjustments and (2) everybody with that access to be able to actively participate in the development.

In the sense of (1), open source is "some part of a commons". That's what the license gives you.

In the sense of (2), open source may or not be open to a community approach. It's fully legitimate for some company or other group of maintainers to provide (1) but deny anything related to (2). You are free to fork and make your own community, but there is nothing that guarantees you that your pull requests are accepted or even looked at, bug reports reacted to or anybody listening to wishes, concerns or other opinions about the project. It's nice if that's provided, and one could argue that some part of the spirit of open source is to enable a community, which in turn helps the original creators (and could be a major motivation to open source something), but nobody should be upset if maintainers choose otherwise.

It's nice if it's clearly communicated how maintainers see this though.

travisgriggs• 4 years ago

I actually prefer what they're doing. Consider most open source projects. Our involvement with them goes something like:

1. I need feature X

2. I find library WeLoveX

3. Is WeLoveX a good investment for my larger product?

4. Ambiguity happens here

The ambiguity happens because I have one prominent indicator: release activity. If it's changing lots, does that mean it's active and a solid foundation? Or does it mean it's actually probably not quite ready for prime time yet and hasn't found stability? On the flip, if there's very little release activity, does that mean it's dead, the developers have moved on and maybe there's something better out there? Or does it mean it just does its job really really well and doesn't need a constant stream of tweaks?

It's nice to have a general statement of disposition towards the product by the original authors.

dustinmoris• 4 years ago

something that Github, of all companies, should understand

It’s not GitHub anymore though. It’s Microsoft and Microsoft must advance the Visual Studio brand.

jopsen• 4 years ago

"sunsetting" is better than corp-speak saying "handing it off to community maintenance"

Especially, if there isn't a dedicated community to maintain it.

I'll take honesty over corp-speak any day.

That said we probably only get honesty, because they want us using vscode instead.

kodah• 4 years ago

Corporate speak involves blatant ambiguity and kafkaesque messaging. "Sunsetting" has a very direct meaning for GitHub, whether it gets supported by the community is something else.

quadrifoliate• 4 years ago

Apache Retirement Home for Veteran Projects

Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat.

I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding foundations like the ASF.

bitwize5• 4 years ago

Not everything in ASF is dead. OpenOffice probably is, but NetBeans is still being actively developed. Good thing, too, alongside IntelliJ it was probably the IDE most oriented toward getting people started writing Java code, rather than as a portal into the vast and confusing plugin ecosystem (looking at you, Eclipse).

gunnarmorling• 4 years ago

I think this conflates several concerns which are unrelated. In particular, for a project to be under ASF stewardship does not mean it doesn't have large companies backing it. Look at projects like Kafka, Pulsar, Camel, Arrow, Spark, Flink, Pinot, Superset, Druid, etc. pp., they are all thriving and have strong funding.

AtlasBarfed• 4 years ago

It's only a retirement if no releases happen afterward.

tonymet• 4 years ago

the code is only one of many artifacts within a project . you have multiple support channels for bugs and features, builds, distribution , monitoring / ops (crash and perf reports), developer apis and a dozen more – each requiring time, attention, people and effort .

fork the code and start a new project with resources to take care of those and many other artifacts if you are so inclined . you have the license to do so

thaway2839• 4 years ago

Most people using Atom or any other open source project, would likely have based their decision at least partly on the organization backing the project, especially in a professional setting.

For the most part, when a different organization picks up the development of the project (if one does) it's a completely new project at this point (there are exceptions, such as a backing organization continuing to back the project, but deciding that it's better supported by an independent trust, and therefore building a transition plan for that).

The best example of this is looking at any Apache supported project today. There are very few projects that were handed over to the Apache foundation that people would want to continue using in their post Apache handover date, even if they were amongst the lucky few that still have active development (OpenOffice, for example).

Sunsetting is absolutely the right term/approach to use.

trasz3• 4 years ago

It's not an open source project - it never was, it's commercial, corporate project releasing code licensed as Open Source.

Beltalowda3• 4 years ago

"It's not open source, it's code licensed as open source". Hmkay... I find it impressive how concisely you're contradicting yourself in that sentence.

winwhiz• 4 years ago

All of the id Software code was release to open source essentially sunsett'ed. That was never a problem.

hatware• 4 years ago

GitHub has been sh*tting the bed left and right. I audibly laughed when I saw this article.

I don't know if it started when MS bought them, but it's when I think the decline became very apparent.

sneak• 4 years ago

Microsoft has never understood open source. This is why they bought GitHub and npm, and paid Docker to make it work on Windows, and why GitHub and the most important parts of VS Code are proprietary software.

They use open source as a marketing buzzword, not as a philosophy, and it shows.

I think perhaps TypeScript is the only counterexample.

oaiey2• 4 years ago

I think they understand open source (and show it by many projects) but like you said, it is not their core philosophy.

They are a proprietary software and cloud vendor super house. They are very successful like that. Open Source is 3-4 level down to their main strategy.

seaman1921• 4 years ago

just fork it, no one is stopping ;)

jillesvangurp• 4 years ago

The whole point of github is that anyone can fork the project and continue working on it. The code isn't going away, it's going to get archived.

The point of MS/Github announcing that they are sunsetting the project is that they are basically no longer spending time and money on the project. Projects this size have a lot of things that need attention like security fixes, legal stuff, trademarks/branding, etc. Basically, they do the right thing here by giving people some time to deal with this in whatever form they care to do that before pulling the plug.

Anyone interested in taking ownership of atom now has six months to get organized; I'm sure if somebody steps up, Github would end up doing the right thing and e.g. support them by e.g. transferring domain names, and other things they control. But somebody would need to step up for that to happen.

Apache taking ownership of a project would require that there is some community still there to work on it. They have an incubation process for this kind of thing. But there's also a thing called the attic in Apache where dead projects go after they stop being maintained.

Night_Thastus2• 4 years ago

It's a shame. Atom was my first love, taking me away from the pain of using GEdit to write code for my college courses. I loved finding new packages and tuning and tweaking it all just right. I'll miss it.

shusaku2• 4 years ago

First love is a great description. I was 100% a vim guy for most of my career, but I tried out Atom and it ignited my love for the GUI

Arubis• 4 years ago

Atom was great, but I'll admit that I'd forgotten about it entirely.

maxpert• 4 years ago

Sad day! But VSCode ate it up. Whatever one might say this had a huge hand in making Electron mainstream.

jaywalk4• 4 years ago

Atom did much more than help make Electron mainstream. Electron was actually born out of it: https://www.electronjs.org/blog/electron/

yeq• 4 years ago

I really liked Atom for non-code editing as it is usually much faster than VS Code, so this is quite unfortunate news

vorpalhex2• 4 years ago

If you are working in markdown, there are a good bundle of other options too.

jonathaneunice• 4 years ago

I like Atom and use it occasionally. But I use VS Code day-in and day-out. The decision makes sense.

If VS Code were not exceptionally good, Atom might have had more of an opportunity. But "yet another good option" is not enough to drive investment, sustain a community, and spin an ecosystem.

edgyquant6• 4 years ago

Maybe I’m misremembering but didn’t VSCode begin as a fork/skin of atom?

wiseowise7• 4 years ago

No? It did use Electron though (Atom Shell).

nobodywasishere• 4 years ago

Atom created Electron, VS Code is built on Electron

jacobmischka2• 4 years ago

Atom predated VS Code and was the impetus for Electron, which VS Code uses. You may know this, but this comment makes it seem like they tried and didn't have an opportunity. They literally invented what the majority of new "desktop" apps uses to render UIs, they just couldn't compete with Microsoft (before they were bought out, after which of course Microsoft wasn't going to invest seriously in it).

Edit: Fixed typo (thanks torstenvl!).

torstenvl• 4 years ago

impotence means powerlessness or inability; the state of lacking potency. It's usually used to refer politely to erectile dysfunction.

Perhaps you meant impetus?

https://www.merriam-webster.com/dictionary/impetus

dchest• 4 years ago

While Electron had a huge impact, before Atom team developed atom-shell (which became Electron), there was NodeWebkit (now nw.js). I actually shipped a Windows app written with it and Angular.js, without using Windows for development or building.

Dave3of52• 4 years ago

I remember this being released and this was a concern at the time that the project would be abandoned. If I remember this it was mostly a concern as Github as a company should focus on their main product which is not an editor and that there are many existing editor that do it better.

I suspect that what actually killed this is the acquisition of Github by Microsoft and the fact that Microsoft are pushing VSCode very hard. Dev tooling is something Microsoft had a lot of experience (and failures) in and it was always an uphill battle.

hackernewds• 4 years ago

What other editors are better and could be recommended? I guess I'm replacing Atom today

bogwog4• 4 years ago

Sublime Text gets my vote. Pretty hard to go back to anything else after using it.

It’s not free, but if you’re really strapped for cash you can use it like most people use Winrar, at least until the guilt overcomes you.

Dave3of52• 4 years ago

Vim, emacs, sublime, vscode, notepad++ there are lots.

edgyquant6• 4 years ago

Eh VSCode killer atom long ago.

Atreiden• 4 years ago

Called this ~4 years ago when they were acquired by M$.

But it's still really sad to see. I use it because it was trivial to CSS style it to match my Desktop. It's comfortable to me in a way that other editors thus far have not been.

Are there other editors with this level of customizability? I know VSCode and Sublime support theming but from what I can tell it involves installing pre-packaged themes.

piefayth• 4 years ago

Well, if you just want a custom VSCode theme, you can try Theme Studio for VSCode: https://themes.vscode.one/. Login/signup required, though. No affiliation.

aordano• 4 years ago

there is an extension that lets you set arbitrary css in VSCode, albeit it's a bit cumbersome to use.

https://marketplace.visualstudio.com/items?itemName=be5invis...

rgoulter2• 4 years ago

If level of customizability is your main metric:

Emacs can go from this: https://emacshints.files.wordpress.com/2013/09/spash1.png

to this: https://github.com/rougier/nano-emacs

whiskey142• 4 years ago

+1 for nano-emacs

brundolf10• 4 years ago

You can do a lot of customization in VSCode. Not as much as Atom, but way more than the average editor. I'm not positive whether or not it would be enough to serve your case

wiseowise7• 4 years ago

VSCode killed Atom long before GitHub acquisition.

WorldMaker3• 4 years ago

You can override any color you want in VS Code with a couple easy settings in your settings.json file: workbench.colorCustomizations and editor.tokenColorCustomizations

https://code.visualstudio.com/docs/getstarted/themes#_custom...

You have to package it if you want to make it easy for other people to install, but if you just want to play with it, just open settings.json and start feeding it colors.

jw143• 4 years ago

I've made extensive use of this and it is a killer feature of VS code for me. Still, I wish it supported all of CSS like Atom did.

haolez• 4 years ago

I still prefer Atom's UX design over VSCode and I can't explain why. Amazing job on that front! I hope it gets traction with community support.

ehayes2• 4 years ago

Me too. Even if you have a great theme in VSC you're still stuck with the sidebar and the bad Microsoft-y typography choices everywhere.

bckr4• 4 years ago

I was able to make VSCode look pretty great with a bit of work by following the ebook Make VSCode Awesome: https://makevscodeawesome.com/

great fonts, minimal visual clutter etc

eating555• 4 years ago

Same here. I've tried VSCode multiple times but still switched back to atom. Just FEELS RIGHT.

brundolf10• 4 years ago

It feels a little more natural/human. VSCode's default theme looks like Tron. Both are valid, but I can see how Atom's is more "cozy". It also had some fun "squishy" animations that were nice

For the colors at least, there are VSCode themes that will try to mimic it for you

imbnwa2• 4 years ago

Yeah, have the same relationship, wish a UX expert could explain why my psychology is different with Atom vs VSCode

ehayes2• 4 years ago

Over the past year I've tried a few times to switch from Atom to VS Code, but there's always a little thing that brings me back. With effort most of the functionality could be reproduced in VSC, but the stupid MS typography can't be themed away.

imbnwa2• 4 years ago

Yeah, overall UX of VSC bothers me next to Atom and I can't explain why

joshstrange13• 4 years ago

I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?

I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you find/configure plugins.

I understand that vscode is very powerful and infinitely extendable but I feel like I shouldn't have needed to try 4-5 different vscode plugins (all configured via json) before I found one that worked and did what I needed.

At least 2 of the top downloaded plugins when searching for "SFTP" were read-only/archived on GitHub, the top one had a "reloaded" version which was also discontinued from what I could tell.

I'm comparing this experience to IDEA which has this built in (including support for deploying to multiple servers at the same time) and all configurable in the GUI.

Maybe I'm just getting old and cranky but vscode seems to get unwieldy very quickly (plugin conflicts, not being able to tell what's doing what, writing almost all config in json). The plugin ecosystem seems to be much lower quality that I what I see in the Intellij product line. I guess I'm just not interested in "building my own IDE" and forever tweaking it, I'd much rather buy a product that does almost everything I need in a sane way.

colordrops2• 4 years ago

Totally agree, if I'm gonna put effort into building my IDE it's gonna be vim or emacs. I use nvim most of the time and intellij on occasion for debugging.

johnchristopher• 4 years ago

Oh, I do the same. Coding in vim and debugging in vscode. The GUI and mouse support is a better experience.

vultour• 4 years ago

Ah, a fellow full-time vim user. There are dozens of us!

stefanos822• 4 years ago

lol, I jump between Vim and NetBeans almost on a daily basis! So it seems I'm not the only one who follows a similar pattern after all.

datalopers2• 4 years ago

https://code.visualstudio.com/docs/remote/remote-overview

far better and faster than sftp

joshstrange13• 4 years ago

I looked into that plugin but we don't run any special daemon/server for editing on our servers (nor do we want to).

bckr4• 4 years ago

setup deploys to a dev server from vscode

What does this mean? Setting it up so you can deploy through GUI?

joshstrange13• 4 years ago

On save, deploy the file out to a dev server(s) that runs the full stack (1 or more server per developer that only they use).

hombre_fatal• 4 years ago

I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?

Everyone who uses VSCode has surely used an IDE before. It just turns out they aren’t better in every way, and possibly not in the ways that matter.

VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.

indymike2• 4 years ago

Everyone who uses VSCode has surely used an IDE before. It just turns out they aren’t better in every way, and possibly not in the ways that matter.

Almost every junior I hire has only used Atom, Sublime or VS Code, especially JavaScript developers.

VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.

The reason to switch to an IDE from something more flexible like VSCode or Emacs is the amount of time spent keeping the editor working.

joshstrange13• 4 years ago

Everyone who uses VSCode has surely used an IDE before.

I would expect the opposite to be true. I could be wrong but it seems like the free editor that's mentioned in lots of tutorials would be the one newer developers gravitate to over a paid tool like IDEA.

csours• 4 years ago

I use IDEA and VS Code and Notepad++ and ...

I'm kind of surprised you did a deploy from VS Code. I would have assumed there was another tool for that. I do most of my git and ssh/scp stuff from the command line because I'm never quite sure what the tool will try to do to "help me out"

joshstrange13• 4 years ago

For myself it's all about reducing the delay between "writing code" and "seeing the results". Dropping down to scp or run a script to deploy files seems like an unnecessary delay/break in my development process that I don't like adding in.

If you can develop 100% locally this isn't an issue but we can't (or haven't taken the time to do so). Think of the dev server as just a VM running locally and it might make more sense.

rychco• 4 years ago

I personally use CLion for all my C/C++ work, even preferring it over Visual Studio proper. It handles the environments, builds, build systems, etc for me a so I can focus on programming. VSCode is what I use for everything else (mostly Python, Golang, Web stuff) when I don't need the IDE overhead.

tomca32• 4 years ago

I switch back and forth between IntelliJ products and VSCode.

As a pure editor I prefer VSCode. It's fast and has a great plugin ecosystem. Another great feature is that it's config is just a JSON file that I can put into git and push it to my dotfiles repo making it easy to share config on all of my machines.

However, there's just some functionality in IntelliJ that I miss in VSCode like running tests. Of course there are plugins but they are all clunky and don't give you the great UX that IntelliJ does. I want the IDE to figure out where all the tests are and give me an easy way to run a single test/file/suite/feature. IMHO this is the killer IntelliJ feature for me.

dingleberry4203• 4 years ago

I'm cautiously optimistic for https://www.jetbrains.com/fleet/

brundolf10• 4 years ago

Depending on the language (I've seen it in Rust and Deno), VSCode has inline buttons that appear over individual tests to run them

tetraca• 4 years ago

I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?

I know a few people like this. More or less, they all got burned by some technical issue that made IDEA unusable for them one day, so they quickly cobbled together a bunch of extensions in VS Code just to get their work done and stayed.

burlesona2• 4 years ago

It's just the NPM problem. The barrier to entry being low means the ecosystem is gargantuan which means there's tons of bike shedding duplication and lots and lots of abandonware. So it's good that you have tons of options, but bad that curation is needed and tailoring your environment takes a lot of work.

goodoldneon2• 4 years ago

You're deploying via VS Code? If so, that's a weird pattern.

I've been using VS Code for years to write JavaScript/TypeScript, Python, Go, Terraform, and CSS. My settings file is 60 lines, 42 of which are "for file extension X use autoformatter Y" configs.

When I first switched to VS Code I was frustrated trying to make it conform to random expectations I had. Eventually I learned that it's easier to embrace VS Code's defaults for 99% of things. I just want an IDE that works well (nearly) out-of-the-box and VS Code gives me that

joshstrange13• 4 years ago

You're deploying via VS Code? If so, that's a weird pattern.

I don't think it's a weird pattern, maybe a slightly legacy one but not out of the ordinary. I've seen this pattern used at multiple places (not implement by me). It makes sense if you have special use-cases where you need to use physical hardware and/or a local stack is too heavy or complicated to run.

roflyear• 4 years ago

Yeah almost an anti pattern.

throw_m2393392• 4 years ago

For Java dev, VSCode just can't compete with IDEA. For JS/Typescript/PHP, VScode is fine, but it doesn't beat PHPStorm intellisense and code quality tools.

But one is free, the other is paid...

brundolf10• 4 years ago

Can't stand IDEA if there's a decent VSCode plugin for the language I'm working with (which there generally is). It's way too sluggish, I avoid it as much as possible

I used it for a year or so around 2015. It was a huge improvement over Eclipse, which is what I'd been using since this was at a Java shop, but even then I knew it was sluggish. I just assumed back then that you couldn't have IDE features without sluggishness. Now I know better

(To be clear I have no idea how VSCode's Java experience, specifically, compares with IDEA these days; I haven't written Java since 2015)

qsort• 4 years ago

I use both pycharm professional and vscode; vscode's remote is much better and it makes it way easier to work on projects that use multiple programming languages.

Also the default editor of the IDEA family is just unbearable (but there's the vim plugin for that, I guess), while Monaco is fine.

The only area where vscode is downright embarassing is interfacing with databases. In pycharm I can have a complete view of the database I'm connected to, run queries, get warnings and errors from inline SQL, and so on. Vscode has... strings?

If the remote capabilities get better, though, I'd admittedly have no reason to stay in the vscode camp.

lmarcos• 4 years ago

I cannot stand the "dancing" sidebar in VS Code. It's used for showing the directory tree, search results, plugins, etc. I like Jetbrain IDEs (at least on my machine they load and feel fast).

mikewhy• 4 years ago

FYI you can drag anything from the sidebar to the bottom pane. It's not much, but can help with the overloaded sidebar.

andjd• 4 years ago

I have used both, and use both working daily. If I could get away with doing everything in VSCode, I would. Part of this is how the community treats tools. VSCode is an editor, with some plugin support that lets it work as a bit of an IDE. But these are almost always optional. Code ecosystems and communities built around an IDE tend to only support working in that IDE, so there's typically only one way to do things, good or bad.

saghm• 4 years ago

I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?

Yep, I've tried Intellij several times over the past 5-6 years, but I've never really had an experience I liked. It's interesting that you mention SFTP and remote server deploys as a pain point for you in VS Code, because I've actually had a huge amount of frustration trying to do development over SSH in Intellij.. As of Intellij 2021 edition, I was completely unable to get ssh working from my work laptop to an EC2 instance; it could not parse my `~/.ssh/config`, and manually putting in the username, hostname, path to the private key, and even port 22 (because it literally required putting the port manually rather than defaulting to 22 unless stated otherwise), it would just say it failed to connect. The 2022 version has a "remote ssh" beta feature which also required manually putting in info that I felt like it should just be able to parse from my ssh config file, but it did connect and work for a week or two. One day it randomly started disconnecting a few seconds into loading a file continuously, which made it impossible to even scroll down into the file before it just zoomed me back up to the top. I gave up on it and just decided to stick with VS code for everything rather than try to get Intellij to work for the small amount of Java code I occasionally have to write.

Setting up ssh development with VS Code, on the other hand, was a breeze. The first plugin that came up when I searched "ssh" was Microsoft's own for ssh development, and running the command to connect to a server after installing it popped up with a list of my servers parsed from my ~/.ssh/config, which I could just select and it would connect (or prompt for a password if the ssh key required one). From there, I could easily open any project on my remote server, and VS Code even was able to detect which plugins I had installed for use with the project needed to be installed server-side rather than locally (e.g. the `rust-analyzer` plugin was installed remotely since it needed to run the daemon on the machine where the code existed). When I close my VS code window, shut down my laptop, and then the next day boot it up and open VS code, it still has the same files opened to the exact same spot (compared to Intellij's "scroll to the top of a file on connection" I mentioned before). I'm sure there are ways to get Intellij to work like I'd want, and I'm by no means a fan of Microsoft in general (I avoid Windows whenever possible and overall have a pretty negative opinion of them), but VS Code just absolutely nails the UX I want in an editor without needing that much custom configuration compared to what I've tried in the past with emacs/vim.

forgetfulness• 4 years ago

It's trite to say "the best tool for the job", but language support can vary drastically from one editor platform to another.

So I end up using IDEA if I'm working with Scala and Java at a job, Emacs if using Clojure, vim for those tasks that are kind of like using sed and awk but not quite, and for everything else, like Terraform, Python, shell, SQL, there's VS Code.

reitanqild• 4 years ago

I use and have used both a lot.

I was about to give up WebStorm the other day, but eventually got around it.

Jetbrains products are very good, but they feel a little "French" just like Macs: beautiful, but be aware that on some models the handbrake is on the same side as the door so you might end up tearing up your pants or bruising your thigh until you learn to be careful :-/

VS Code by comparison is very straightforward, but not always as sophisticated.

Personally I'd use NetBeans for backend and VS Code for frontend but because of Kotlin (which is great) I'm stuck with IntelliJ anyways.

likortera3• 4 years ago

I've tried too many times already to use the Jetbrains IDEs, because I know they're great, specially about the IntelliSense stuff, autocompletion, suggestions, etc.

But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it sooooo much, to the point I think it is even better than IDEA at suggesting stuff.

Also, working mostly with JavaScript and Typescript makes the difference go away (for me at least) as it is damn good at it.

Being free and open source also is a big plus for using it. And I love also how easy it is to configure... just a JSON with autocompletion for any setting you want to tweak. So much easier than having to mess with a ton of tabs and sections and search for settings, etc, etc.

But, if your language is not well supported in vscode, I agree Jetbrain's IDES are great and probably the best option out there. Specially IntelliJ if you're doing Java/Kotlin etc...

joshstrange13• 4 years ago

Muscle memory is a powerful motivator for sure. I was configuring vscode locally on my box so I could then send instructions to this other developer and my hotkeys not working was enraging. I use GitHub Copilot on IDEA and have quite enjoyed it as well.

It's funny how we have such opposite feelings on config (you enjoying the json config and me preferring UI). I have nothing against vscode and I'm glad it exists, likewise I've very glad IDEA/Intellij exists for my own uses. Thanks for the feedback.

rimunroe• 4 years ago

Does VS Code support more refactoring and code generation now? I last used it heavily over a year ago, and at the time it seemed like anything beyond moving files and renaming things wasn't really doable. Meanwhile, in JetBrains's software I can extract and inline variables and functions, change signatures, split things out into other files, and more. I think I tried a plugin or two which were supposed to handle those things, but they either just didn't work at all or weren't reliable.

TameAntelope4• 4 years ago

I come from an era where the more fully featured your IDE, the less likely you were to truly understand what was going on under the hood.

I strongly recommend everyone spend their first ~5 years coding in vim or some other basic text editor (preferably through the terminal), before leaning on an IDE to solve their problems for them.

That said, VSCode is now my go-to IDE, and I haven't opened WebStorm in probably ~6 months. It's lighter weight than the IDEA suite of IDEs, and gives me ~80% of the functionality, so it's been a pretty good tradeoff.

999900000999• 4 years ago

Would you even do that with C# ?

I actually dislike computer science classes which won't let me just use an IDE.

No one can memorize the .net 7 API

bbkane2• 4 years ago

Honestly, I don't think VSCode hides much of what's going on from you. Generally I use it to edit code and then run "go run ." on the side.

kllrnohj2• 4 years ago

There are languages, like C#, Java, and Kotlin, where the language design basically assumes an IDE is being used. It's just not practical or useful to deal with imports and their structure. Sure you can look them up on javadocs and copy/paste the import path. But at that point why not just use an ide? Why learn a skill you'll basically never use or need?

pornel• 4 years ago

I use Sublime Text, but it has its own issues with Python fragility and needing tweaks to plug-in's config files more than I'd like, so I'll probably switch to VSCode eventually.

Java IDEs seem to be living in their own world, but for everything else VSCode works well thanks to LSP. For example rust-analyzer works best with VSCode, and this makes VSCode the best Rust IDE.

Mo3• 4 years ago

Same here, was a very happy Sublime Text user for years - much faster and less memory intensive than VSCode, but recently switched over because of all the tweaking required.

bastardoperator3• 4 years ago

I purchased pycharm, couldn't stand it, logged bugs that are still open from over 5 years ago coupled with the fact I didn't see any immediate benefits coming from vim and vscode. I would never deploy from an ide, and I'm willing to make a small investment when it comes to my tools and productivity.

Also, as of lately, copilot is saving me an insane amount of time especially when it comes to boilerplate and testing.

shp0ngle5• 4 years ago

I went from GoLand (their go thing) back to vscode.

With gopls, vscode is MUCH faster than goland, especially on big repos, and I don’t need to watch the dreaded “Indexing…” all the time.

It misses some features, but honestly it’s so much snappier, so that wins for me.

Starlevel001• 4 years ago

I use IntelliJ for the bulk of my programming (which is nearly all Kotlin/Java) and begrudgingly switch to VSCode for other languages (i.e. Rust). It's hard going from something that seems to magically understand my code to an editor where everything, even supposedly core functionality, is a second-class citizen.

syspec• 4 years ago

You're a brave man for asking this question!

bfelbo• 4 years ago

When coding JS + SQL, nothing beats WebStorm’s DB plug-in with SQL auto-completion, validation, etc.

I really wish the VS Code SQL/Postgres plugins would get there, but it’s a lot of work so I get that it probably will never happen unless Microsoft puts in the effort.

slumber86• 4 years ago

Super sad, atom's column editing still rocks. are there alternatives for vsCode?

pjmlp2• 4 years ago

Well, they managed to drive it much longer than I expected after GitHub's acquisition.

sakaroz• 4 years ago

who was using it anyway ?

wly_cdgr4• 4 years ago

Atom has been dead for years, this is just the state funeral.

The situation now is:

* Sublime for the Williamsburg corpo-hipsters

* emacs and vim for the wizards and furries

* VSCode for all the normies who just want to get on with doing their job and don't feel a need to express their identity or politics through choice of editor

* WebStorm for the chads with the monster rigs to run it

ThaDood• 4 years ago

This makes me feel conflicted.

tinco4• 4 years ago

I use VSCode because its Vim plugin is better than that of Sublime. If/when Sublime has caught up, I'd happily go back to it for that sweet performance and uncluttered UI. So am I a normie, a corpo-hipster or a furry wizard?

throwaway413• 4 years ago

Hermione Granger - muggle born with vested corporate interest

alpaca128• 4 years ago

its Vim plugin is better than that of Sublime

I'm pretty sure Sublime has a plugin that uses an actual NeoVim instance to process all inputs with all your configuration. Never tried it, I don't use Sublime. But I can confirm the feature works well in Firefox via FireNvim.

jbiason• 4 years ago

The Vim plugin in VSCode is the thing that drives me out of VSCode, to be honest.

I have to say that I built so much muscle memory in those years that it is kinda hard to realized I'm not using Vim, and there is always something not-quite-like-vim in VSCode-vim that usually gets in my way.

(To be honest, the only editor that I found that is really close to Vim without being a Vim-thing was GNOME Builder.)

fartcannon2• 4 years ago

VSCode is for Xbox gamers.

tristor• 4 years ago

* Textmate & BBEdit for people who were using Macs for development before they took over the tech industry.

oblio3• 4 years ago

All 3 of them?

MikePlacid• 4 years ago

I’ve “just” (as in: a couple of years ago) switched from BBEdit to Atom for my Python development, and now this.

philwelch• 4 years ago

emacs and vim for the wizards and furries

…respectively? TIL I’m a furry.

bitwize5• 4 years ago

Now all you need is a nice comfy pair of programming socks.

skohan7• 4 years ago

So MS owns the default place where code is hosted, and the default tool people use to edit code. Neat.

jamil7• 4 years ago

Cool and normal.

oblio3• 4 years ago

It's kind of bad, but they're probably the least bad behemoth owner.

Apple would try to switch everything towards their walked garden, no questions asked. Google would shut stuff down every two years. Oracle... I'm not even going to bother.

Amazon and Facebook could be interesting. Facebook is a bit shady, see the Oculus Facebook account debacle, but they're decent as stewards of dev tools. Amazon is also quite reliable for dev tools.

Would anyone really big be a better steward? Did I miss someone?

adolfojp• 4 years ago

Well, Microsoft has always been about developers, developers, developers...

burlesona2• 4 years ago

"VSCode for all the normies" ... feels weird. Maybe it's true. But I feel like VSCode rose 1:1 with Typescript, and I kind of resent it because I associate it with script kiddies around me cargo-culting React in places it isn't needed and writing thousands of lines of overcomplicated javascript to "manage state" on pages that don't even need to have any.

It's also noticeably slower than Sublime, which makes switching hard.

But "Williamsburg corpo-hipster" feels off the mark. To me Sublime aligns more around the "JS minimalist" camp, which overlaps a lot with the "bootstrapped and profitable" crowd.

nemothekid• 4 years ago

JS minimalist

I mean, just that phrase sounds very "Williamsburg corpo-hipster" to me. Minimal, artisan javascript.

wly_cdgr4• 4 years ago

I am sorry if I hit a nerve, I was just riffing for kicks based on my own limited experience and the fact that I haven't had any coffee yet

omoikane• 4 years ago

I disagree with these labels, I would say the choice of editor is more religion than politics.

oldgradstudent• 4 years ago

Religion and religious conflict is often an expression of politics.

The conflict between Catholics and protestants in northern Ireland is not actually about subtle differences in religious doctrine.

derefr• 4 years ago

Isn’t Sublime also for people whose haven’t bought a new computer in 10 years and so can’t run VSCode? That’s why I started using it, at least. (Now it’s just inertia.)

luoc• 4 years ago

Only the lack of slurs reminded me I'm not browsing /g/ in the moment

vorpalhex2• 4 years ago

I went back to try Sublime lately and.. it's lost a lot of the minimalism that attracted me to it initially. That was the same reason why I loved Atom during it's golden years before it got too slow.

Right now I am using a very stripped down VSCode, which is.. fine. It works. I don't love it but it gets the job done usually.

Any other good editors on the minimal side? I need a bit more than vim/emacs, but I don't want or care for autocompletion or anything that alters what I have written. I don't need vcs support. I don't need a built in terminal. Just a good, simple and fast code editing experience with modern ergonomics and syntax highlighting that works across every language.

MobiusHorizons• 4 years ago

Have you tried neovim with any of the lsp integrations? I’m not going to pretend it’s trivial to set up, but the result seems very powerful. If you just want to dip your toes without doing that he setup yourself, I believe there are some prepackaged options eg onivim which you can try out.

diarrhea• 4 years ago

Well put. There's just no reason to move off VSCode so far (for Python and friends). In a couple weeks' time, I'll be working with C# in Visual Studio. It has me excited since I've heard many good things about Microsoft developer tooling, of which VS is a huge tool in the box (C# as a language also seems attractive).

hansoolo2• 4 years ago

Can confirm. Also that git integration that everyone talks about in Atom is built right in.

BaseballPhysics4• 4 years ago

VSCode for all the normies who just want to get on with doing their job and don't feel a need to express their identity or politics through choice of editor

Seems like just another kind of identity: The self-titled "normie" who glances over at the "corpo-hipsters" and "wizards and furries" and smugly pats themselves on the back about how they're so much better because, unlike everyone else, they just want to "get on with doing their job"...

bitwize5• 4 years ago

The fact is, I can't do my job very effectively with Visual Studio Code. That's why I throw it down in frustration and storm back to Emacs every time I try it. Emacs has features that allow me to pretend to be an organized, functional person on the job -- notably, Magit, org-mode, and always-on Lisp that helps me automate away the tedious unusual bits of our process. If you were to compel me to use Visual Studio Code, much of my effort which is today productive would be lost as waste heat.

wly_cdgr4• 4 years ago

Heh, yes, def agree, although I think that a person who is genuinely oblivious or indifferent to all this will also prob end up using VSCode just cos it's free and has the highest brand awareness

racl101• 4 years ago

TIL I'm a Williamsburg corpo-hipster.

This entire time I thought I used Sublime because it was a fast enough, full of features, battle tested editor, that also wasn't a bloated IDE nor an exercise in self flagellation (i.e. choosing to use an command line editor with a high learning curve like Vim or Emacs).

femiagbabiaka• 4 years ago

No 4Chan tier comments here please.

reactspa• 4 years ago

Anyone else use Notepad++ ?

Why not?

hansoolo2• 4 years ago

Occasionally

keewee7• 4 years ago

Really begs the question what Visual Studio Code did right and what Atom did wrong.

bogwog4• 4 years ago

I didn’t use Atom much, but I think it’s obvious that the primary reason it died was because Microsoft decided to make their own competing editor, and then bought the parent company of Atom. It wasn’t exactly the most popular editor at the time, but it did still have some users.

Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting development.

Of course, Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways, but I still think it’s interesting to see the similarities to the Adobe situation.

mynameisvlad4• 4 years ago

the primary reason it died was because Microsoft decided to make their own competing editor
Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways

How can Microsoft both give zero shits because it was effectively dead, while also still being the primary reason it died? That seems to be a chicken-egg problem.

akagusu5• 4 years ago

Glad to see that someone remembered FreeHand. It was much better than Ilustrator, this is why Adobe killed it.

avrionov• 4 years ago

The first thing which Visual Studio Code did right was the better performance. The initial reaction to Atom was that it was very promising, but very slow.

The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.

radus• 4 years ago

Third, for me at least: Remote Extensions. That suite of extensions including SSH WSL, and Container support made things I was already doing frictionless.

wiseowise7• 4 years ago

LSP, better performance, better defaults, better plugins ecosystem, better (subjectively) UI.

Santosh832• 4 years ago

MS poured developers at VS Code which resulted in it blowing away Atom pretty soon in terms of performance. Soon devs started migrating to VSC, plugin ecosystem started accreting, and gradually people just forgot about Atom. It is not that Atom did anything horrendously wrong. If the same dev effort had been put into it that VSC got, am pretty sure it could've become almost as good now. Maybe even better in certain respects.

jahewson• 4 years ago

I don’t think that’s true. I used VSCode when it was first released and the team was just a dozen people in Switzerland. The performance was blazing.

jacquesc• 4 years ago

Speed. I used Atom for a couple years, but quickly switched to VSCode once it was viable as it was the first electron editor to actually be "fast enough" for me.

WorldMaker3• 4 years ago

VS Code had a really interesting "head start": the core editor (named Monaco) had been built for very early stages of the Azure Portal and then been adopted into IE 10/11's Developer Tools to replace an aging code viewer/editor. In order to run in Dev Tools it had to run through an extreme gauntlet of some of the web's worst "files": giant one-line minified things, massive multi-megabyte bundles, and so forth. So the Monaco code editor got a huge amount of performance testing and work years before Atom arrived and built Electron.

It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.

hansonw• 4 years ago

(Note: I worked on https://ide.atom.io and Facebook's Nuclide team).

On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:

(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious

(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..

The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.

As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.

dindresto• 4 years ago

Does anyone know the current status of https://zed.dev/, the editor by former Atom devs?

geodel2• 4 years ago

Editors are like browsers, huge amount of upfront work to even get parity with decades old editor and no commercial potential to sell product. Charge a little bit of money and a million of well paid IT workers suddenly become so poor to pay for tools they need for work. They would further spend productive time haranguing maintainers on why editor need to be open source (code word for just free as in beer) or how 60-70 dollars / year is too much for a code editor and so on.

So end result is only editors exist are feature complete long time back/ or maintained by companies who could just give it for free, compensating it with cloud revenues. Besides a couple of paid editors with insignificant market share of course.

aniforprez5• 4 years ago

I wish there was an editor I feel comfortable paying for

Idea stuff is just way too bulky for me. I don't like using any of them, sacrilegious as that may be, and don't feel the need to use them for since I don't use java. Paying for Sublime is just not worth it with its far poorer plugins and API and their release cadence is atrocious. I checked Nova from Panic out and it looks promising but it's VERY far from being a replacement for my current setup

So I see almost no reason to switch from vim and VSCode, both of which are free and have extensive plugin support and are great at what they do. If something comes along that is faster, has good language support and good list of extensions, I would have no trouble paying for it

iamnbutler4• 4 years ago

We just started a private alpha this week! Lots of news and more public facing information coming soon.

sphars• 4 years ago

The founder is in this thread, stating they just started an alpha release: https://news.ycombinator.com/item?id=31669615

mattsouth• 4 years ago

This makes me sad as I very much prefer the atom approach to the git and github panels than the vscode approach. vscode is much faster for typescript development though.

peter_retief• 4 years ago

I actually used atom for a while, it was a bit bulky but not terrible. I had forgot that it was an option.

ericd• 4 years ago

Every now and then I’m reminded of why I decided to stop chasing the shiny new and just go back to emacs.

akagusu5• 4 years ago

Emacs is up and running for the last 40 years and it will be for the next 40.

Definitely is a software you can bet on.

lanstin• 4 years ago

Yeah. Which Linus uses, so probably works well enough for all non UI work whatsoever. Except maybe SQL?

faho• 4 years ago

He doesn't. Linus uses MicroEMACS [0], which is an entirely different editor that uses emacs bindings.

It's not the lisp vm that incidentally happens to edit code that GNU Emacs is.

Or, as he puts it [1]:

I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar.

[0] https://github.com/torvalds/uemacs [1]: https://www.tag1consulting.com/blog/interview-linus-torvalds...

tlhunter• 4 years ago

Even though Atom was much "lighter" than VS Code in terms of UI, VS Code had so much more development resources thrown at it that it was ultimately much speedier than Atom. IIRC, even Brackets was faster.

I see people complaining about the death of Atom, but in the past few years there just hasn't been a use case where Atom was the best choice.

deeptote• 4 years ago

Seriously, who actually uses Atom anymore? Before VSCode was a thing, I used it but then I got into Vim, Neovim, and now VSCode with the Vim plugin.

sheepybloke• 4 years ago

Exactly. I used Atom for a while, but then it started getting so slow. My coworker mentioned I should try VSCode, and it did everything I wanted Atom to do but faster.

nerdponx2• 4 years ago

Atom to me was always "toy version of Sublime Text for web dev hipsters".

a1371• 4 years ago

Good memories with Atom. I had a silly "super mode" extension on it that gave me streaks when typing uninterrupted. It has lots of action graphics and screen shakes, I loved it.

vjandrea• 4 years ago

Just a noob here, but I love the way Atom displays and handles merge conflicts; still my editor of choice when I rebase / merge.

brundolf10• 4 years ago

I held out for a year or so after VSCode was released. It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented (this was before they'd been acquired, I believe)

But once I tried VSCode... man, there was no going back. It was infinitely more performant and cohesive. Atom (with IDE-like features installed) felt so sluggish by comparison. I think the main improvement was how opinionated VSCode and its extension APIs were; Atom extensions could have dependencies on each other. I remember you had to install an extension for generic IDE hover-overs and such, before installing the actual language plugin, and then there were competing standards for which generic hover-over framework each language wanted to use. It didn't just complicate the user-experience, I'm convinced this was the reason the editor would get so slow; the APIs were too low-level and all the plugins were fighting with each other instead of going through standard channels.

But, Atom will always have a special place in my heart. It blazed new trails in editor customizability (even if the degree ended up being its downfall, quite a bit of that legacy can still be found in VSCode). It invented the entire concept of web apps as desktop apps, which despite what some here would tell you, I think is a very good and important thing. And it always had such a fun, community feel to it that's been mostly lost with VSCode.

It was time, but I will miss it. I'll close off with the very cute and fun Atom 1.0 announcement video: https://youtu.be/Y7aEiVwBAdk

SahAssar• 4 years ago

It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented

Wasn't brackets and atom released pretty much at the same time, both built on CEF?

brundolf10• 4 years ago

Interesting! I hadn't heard of brackets before.

moffkalast2• 4 years ago

Atom extensions could have dependencies on each other

This. This always has been and always will be a critical ecosystem mistake.

The principle of one msi/exe installing everything you need on Windows, one click downloading an entire app from a store on Android or iOS is seamless and almost always error free. Or in your example with VSCode having self contained encapsulated plugins that install with one click.

Meanwhile I'm having issues installing things and resolving dependencies with pip in python, apt in linux, npm, etc. basically all the time. It's a shit system that only pretends to be elegant and it's time we fucking admit it to ourselves. Designed by elitist morons for elitist morons and everyone else is paying the price.

brundolf10• 4 years ago

That seems extreme.

Any ecosystem has to strike a balance between which things should be opinionated/officially-sanctioned/standardized, and which things should be left open in "userspace". I think Atom made the wrong choice by outsourcing some very standard features to the community, like hover-overs and underlines. VSCode seems to have hit a sweet-spot, offering standard solutions for common functionality but leaving plenty of doors still open for people to build on.

mook• 4 years ago

It invented the entire concept of web apps as desktop apps

Mozilla actually had that in early 2000 or so; their whole UI (before Firefox existed, even) was a webby. Except it was their own weird sort of webby and not normal HTML, most of the time.

Using normal HTML would be around IE4 with their .hta files, I think. Didn't seem to have too much uptake though.

brundolf10• 4 years ago

Fair! Maybe I should've said "got web apps as desktop apps to finally take off"

nerdponx2• 4 years ago

I held out for a year or so after VSCode was released. It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented (this was before they'd been acquired, I believe)

Depending on what you consider the "category" to be, Sublime Text (2) was well-established for years before Atom came out, with BBEdit and TextMate before it.

Not to mention Kate, Geany, and the various other "lightweight extensible code editors" that have been out there for years and years.

brundolf10• 4 years ago

I meant editors built with web technologies, specifically. Though I've been informed in another thread that there was one called Brackets that I hadn't known about

mr_toad• 4 years ago

this new category of editor that GitHub had invented

There was prior art in the form of Bespin. GitHub’s innovation was electron and turning it into a desktop app. I think it’s amusing that VSCode has recently come full-circle and introduced a browser-based version.

https://en.wikipedia.org/wiki/Mozilla_Skywriter

Narann• 4 years ago

I use Atom for static Markdown blogging only. The reason is I customized Atom for this specific task and nothing more. Atom is mostly an advanced text editor than an IDE. I have Hunspell in both English and french, it detect word similarity and provide auto completion for this, it has some typewriter extension, etc.

I'm reluctant to use VSCode because of M$ pushing for its tooling, but it looks like I will have no choice on the long run.

Is there anyone in the same boat? Which highly configurable text editor can be use for this?

trinsic23• 4 years ago

I'm in the same boat and look for a configurable text editor. I have Sublime, but haven't used it much, until now.

trinsic23• 4 years ago

Man this is sad... As a markdown/HTMl writer, I used Atom every day... It had great extensions. So It looks like Sublime then.. Any other Editors for a non-coder that has good (Community) extension support like Atom besides Sublime?

fartcannon2• 4 years ago

So this would be slightly different than embrace, extend and extinguish (EEE). This is acquire, substitute and then sunset (ASS)

gcau• 4 years ago

I still use Atom purely for its simple easy git UI (while coding in VSCode). VSCodes git UI, and all others I've seen, are a disaster in comparison. I want a simple, easy UI - in atom its exactly that. If I need more I'll just type it in the CLI. I wish there was something else I could use that's like this.

fbcpck• 4 years ago

Interesting to find that I'm not the only person doing this! I also just hop to Atom if I need to do something more involved with git

I typically do this when tidying up / amending >1 commit at a time (anything I can't do easily with git rebase interactive mode), or to resolve merge conflicts.

hbn3• 4 years ago

I've never used a better git UI than the one built into JetBrains' IDEs (though I always switch it from appearing in the sidebar to appearing in a popup window, like how it used to). They could honestly package it as a standalone app and it'd justify its own existence

The merge conflict resolver is so intuitive and easy to use. I have colleagues who come to me for fixing merge conflicts even though I'm pretty mediocre at git in general :p My secret is I do it in IntelliJ

mempko• 4 years ago

And here we are with vim and emacs still being updated and improved. Good job Bram and John.

bellBivDinesh• 4 years ago

Atom was my first go to editor years ago when its git integration felt miles ahead. Then I saw gitglass(?) in VS Code and was moved to switch for shared workspace files at my job. I remember it as lightweight and fun.

jlkuester73• 4 years ago

I have never found a git integration that I liked more or found more simple and intuitive than Atom's. I found that even folks who were new to git would quickly become comfortable with managing git interactions via Atom.

VSCode's "Source Control" on the other hand is a such a big UX dumpster-fire that I cannot bring myself to even try using it any more....

oefrha• 4 years ago

Atom will live on in the form of Electron, one of the highest impact and most controversial technologies of the recent decade.

I still remember the day VSCode was announced, and the binary on macOS (inside ./Contents/MacOS in the app bundle) was literally named Atom.

alchermd• 4 years ago

Atom was my first text editor when I was getting serious into learning software development. Sharing this neat video for those who hasn't seen it yet:

https://www.youtube.com/watch?v=Y7aEiVwBAdk

andrew_• 4 years ago

Nooooooo. I so much prefer Atom over VSCode. I've read the spin, but this smells like Microsoft finally doing what we all predicted - killing off the competing product.

wiseowise7• 4 years ago

killing off the competing product.

There's nothing competing about Atom. Its fate was sealed when VSCode started gaining traction, and that happened before GitHub acquisition.

whiskey142• 4 years ago

Oh this is sad. As a teacher I loved introducing Atom as a first text editor as out of the box it did nothing but look nice. Then I could gradually add plugins everytime a student said something was annoying. Great for teaching principles before tools/shortcuts. Something which I think IDEs do far too often imo.

gtsnexp• 4 years ago

I guess this idea of "Sunsetting" a project highlights one of the main differences between Open source and Free Software. A successful Free Software project rarely gets "Sunset".

likortera3• 4 years ago

Even after they promised they'll keep developing it despite of the acquisition:

https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...

Not surprising. When this stuff happens is always lies because you plan for people to forget about stuff as times goes by, which usually happens.

iterati• 4 years ago

They continued for 4+ years. That's not lying, that's time passing.

likortera3• 4 years ago

What's the amount of time that divides lying from just time passing?

uneekname• 4 years ago

RIP Atom. I wrote a lot of code in Atom back in the day.

kylebarron2• 4 years ago

I personally found Atom + Hydrogen [0] to be the most productive interactive Python environment I've ever used. I really want to see VSCode adopt some way to run a Jupyter kernel for a Python file (with a notebook UI) and have rich results in line with the code (i.e. not a terminal output off to the right side of the screen).

[0] https://github.com/nteract/hydrogen

amanwithnoplan• 4 years ago

VSCode already does that as of some versions ago.

https://code.visualstudio.com/blogs/2021/11/08/custom-notebo...

https://code.visualstudio.com/docs/datascience/jupyter-noteb...

kylebarron2• 4 years ago

oh I had a typo in my original comment. I meant *without* a notebook UI. i.e. I don't want to see a cell UI like a notebook. I want it to be just a normal Python file where the output shows up in line.

oxff• 4 years ago

VSCode ate everyone's lunch. It is SO GOOD

nathansobo22• 4 years ago

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev.

We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting.

Here's a talk I gave last month: https://youtu.be/wXT73bBr83s

aniforprez5• 4 years ago

IMO the killer thing that VSCode has over all the other editors is the wealth of extensions and a certain degree of simplicity. What are your plans for Zed in terms of extensibility and are you aligning more towards making something beefy and full-featured like the IntelliJ offerings or something more "lightweight" like VSCode or Sublime?

quaunaut• 4 years ago

Atom practically invented the kind of extensions that VSCode had, and even several years into VSCode's life Atom far outstripped it in Extensions.

Perf became the biggest problem however, which VSCode took over.

nathansobo22• 4 years ago

We plan to make Zed extensible via WebAssembly, but we're taking a different approach than we did with Atom.

Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions.

Our goal is for Zed to have the lightweight and snappy vibe of Sublime with the power of a more full-featured IDE. These objectives are obviously in tension, but I think we can build something that balances them well. A collaborative IDE that feels fast and powerful.

l33t2328• 4 years ago

The bloat VSCode has over Atom kills it for me.

rjh294• 4 years ago

IMO the killer thing is performance, VSCode starts fast and is smooth to write with. It blew away the older set of Electron-based editors. They work tirelessly on performance every release and it shows imo. Allowing extensions without destroying perf isn't easy either.

bstar772• 4 years ago

NeoVim can compete on this front. See LunarVim for a heavily extended experience.

rattray6• 4 years ago

Interesting. Will you have built-in LSP support for most popular languages then?

brianzelip• 4 years ago

The killer feature for me wrt to Atom -> VSCode was the built in terminal.

rafaelturk• 4 years ago

Amazing! Sounds like a great foundation! Curious about UI execution in Rust

nathansobo22• 4 years ago

We plan to start blogging about this pretty soon.

ilovecaching2• 4 years ago

Please make zed capable of running in a terminal. If I could have a modern editor that can run in the terminal and had a nice GUI, I would definitely pick it up. There's still many instances where I'm working on a remote dev machine, on my iPad, over a serial connection, inside of tmux, where a terminal based text editor is a necessity.

nathansobo22• 4 years ago

We have graphics, but I could see a mode where you `scp` a headless moon lander version of Zed up to a remote server to do remote development. VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.

dymk3• 4 years ago

Does a single text editor exist that supports both a TUI and GUI mode?

420official• 4 years ago

What's the reasoning behind this iteration being closed-source?

nathansobo22• 4 years ago

This time we're on our own in the marketplace with no big revenue-generating company supporting us. We'd like to be as open as humanly possible while being able to build a defensible business around the editor.

geodel2• 4 years ago

Well, unless it is paid, I don't know how would you continue to toil for years making great editor. And unless it is free, gain a good market share to continue to support.

I hope you would have some solution to this conundrum.

nathansobo22• 4 years ago

We plan to monetize collaboration. Zed is a collaborative platform disguised as a world-class code editor.

a4isms2• 4 years ago

Nathan, I remember your passion for this project from its very early days. It has already borne fruit that has grown into a garden in the form of Electron, and I'm excited to see you are reimagining Atom in the form of Zed.

Best wishes for Zed's success!

nathansobo22• 4 years ago

Thanks very much for your kind words and wishes!

BaseballPhysics4• 4 years ago

custom native UI framework

Cool project, but this is clearly a contradiction.

wxWidgets? That offers a native UI. Wherever possible it uses the UI controls from the underlying OS/system to render the interface.

Looking at the project page it describes "a GPU-powered UI framework that met our needs."

That's not a native UI. That's a non-native UI compiled to native code, ala something like Flutter.

nathansobo22• 4 years ago

Sure, cross-platform UI that's on the metal is a more accurate description.

munificent• 4 years ago

"Native UI" can be interpreted to mean "UI written in native (i.e compiled to machine) code" or "UI written using the OS's native widgets". You are presuming that the only correct definition is the latter, but it's pretty clear from context that they mean the former.

nsonha5• 4 years ago

I feel like people are talking about different things when they say "native", to me it's more about being compiled to native binary, or being performant, than "native UI".

I've never been impressed with native UIs in any platform, web or mobile. The only context where I appreciate them is accessibility.

pvg2• 4 years ago

Should development ever wind down, you already have the advantage of being able to announce it as "Zed's dead, baby" instead of clunky corporate euphemisms.

nathansobo22• 4 years ago

Fabulous point. Always good to have solid contingency plans.

nsxwolf• 4 years ago

They should name its engine or one of its components "Chopper".

behnamoh3• 4 years ago

yet another buzzword we hear a lot these days: Zed is “lightning fast”… I hear that a lot about Rust projects, like Kitty or Alacritty

jl6• 4 years ago

In the meantime, zed.dev, baby, zed.dev.

tiffanyh• 4 years ago

Re: Native UI

Is Zed web-based or not? Would it be able to be hosted in the browser like the web-based version of Github Codespace (Visual Studio Code Online)?

nathansobo22• 4 years ago

We plan to compile to WebAssembly that writes pixels to a WebGL canvas.

polutropos• 4 years ago

Any screenshots to share?

nathansobo22• 4 years ago

Here's a demo from a talk a give not too long ago:

https://youtu.be/wXT73bBr83s?list=PL3TSF5whlprXqwYNIM0X8mBzu...

mwcampbell3• 4 years ago

zed sounds like a great project. What are your thoughts on the existing Rust GUI frameworks? Naturally the core editor widget will need to be custom no matter what, but for the rest of the UI, have you considered using one of the Rust GUI frameworks already being developed?

nathansobo22• 4 years ago

When we started on Zed the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point.

gosukiwi2• 4 years ago

Atom was the first editor I wrote plugins to and contributed to core. I prefer it over VSCode, as it does less, and it's easy to customize for web devs. Sad to see it go, but it's for the best :(

gigatexal2• 4 years ago

Add a really good vim mode and I’m there.

nathansobo22• 4 years ago

Earlier this year Keith Simmons, the author of Neovide (https://github.com/neovide/neovide), joined our team. He's been working on Vim bindings and paying a lot of attention to getting it right. As you probably know there's a lot of surface area, so this will take time.

sdfhdhjdw3• 4 years ago

Humble question, I don't mean to sound confrontational, I ask of genuine curiosity: Why not contribute to VS Code instead?

For Julia, Atom+Juno was excellent. It was the first time I could select+run on a proper IDE (I was coming from python+notebook). To me this was revolutionary. Then I discovered VS Code, so Atom+Juno stopped making sense. You seem to be a very competent developer, so why not just contribute to VS Code?

vlunkr3• 4 years ago

Not the person you're responding to, but it sounds like they're going in a different direction with Zed in terms of the tech stack, where VSCode is pretty similar to Atom.

nathansobo22• 4 years ago

Our goal is to build something substantially better than VS Code.

mynegation• 4 years ago

If nothing else, Atom was the birthplace of Electron.js and I know it is controversial, but Electron was a boon for the rapid development of cross-platform desktop applications. VS Code was built - in turn - on Electron.

We need people like nathansobo to try out new ideas and directions. I, personally, am very much looking forward to their WebAssembly-based extension system and Zed being the flagship UI application developed in Rust.

qbasic_forever• 4 years ago

I don't think VS code would ever accept a change to native UI or switch off of electron, so it seems like a nonstarter for someone who wants to experiment with native UI text editors.

VS code is written almost 100% in JS and typescript, it will always be a nodejs app through and through without a complete rewrite. And even if they wanted to rearchitect VS code all of the extension APIs, extensions themselves, etc. would demand the existing nodejs runtime.

So long story short... VS code is a good editor if you want to contribute to a nodejs and web tech based text editor, but not if you want to explore other architectures or ideas.

input_sh• 4 years ago

I just wanted to say I really liked your product and despite multiple attempts to switch to VS Code (in anticipation of this day), I kept returning to Atom. I don't know why, I could never get VS Code to feel right to me, while Atom always felt right despite many of its quirks I've gotten used to over the years.

Looking forward to its spiritual successor!

nathansobo22• 4 years ago

Thanks very much!

Aeolun2• 4 years ago

Hmm, curious how this will compare to Jetbrains’ fleet editor.

Of course, they share the problem that I can’t yet use either :)

nathansobo22• 4 years ago

We're pure Rust and hopefully faster. But yeah, plenty of competition in the space!

jupp0r• 4 years ago

I hope it will be much faster. I try JetBrains IDE every couple of years and the sheer latency and lack of text rendering quality is turning me away every time.

tormeh• 4 years ago

Any chance of collaboration with https://lapce.dev/ ?

woojoo6662• 4 years ago

Wow this does seem to share a lot of features. Rust based, WASI plugins, real time collaboration. And it's open source!

greyhair• 4 years ago

Just make it keyboard centic. I don't want to touch the mouse.

nathansobo22• 4 years ago

Definitely a priority.

PascLeRasc3• 4 years ago

I think Atom was perfect, for what it's worth. I've always found it to be faster than VS Code.

kobalsky• 4 years ago

Cool project.

Since it's not mentioned on the website, what will be your roadmap regarding security?

I feel that all IDEs have security handled as an afterthought, VSCode made some progress but it's far from being there.

I just want to be able to use a code formatting / language extension without having to worry about it subverting my whole computer in a future update.

vscode is halfway there with containerized development, but apparently they didn't intend that to be security measure and they make it clear to only run trusted extensions. I'm guessing there are ways to access host files through the bridge.

It's obvious that we still have to trust extension authors, but an IDE with the correct security sandboxing can limit the blast zone if it gets compromised (leaking a source file vs getting a rootkit installed and ending up releasing compromised updates to production)

hit8run3• 4 years ago

Did that happen to you? Sounds scary…

CJefferson• 4 years ago

What is the accessibility (for example for blind users) of your custom UI framework like?

Communitivity• 4 years ago

Sounds interesting. I've love to take part in the alpha and provide feedback. I've done software engineering professionally for 25 years in Javascript, C++, Rust, Java, Erlang, Elixir, Clojure and Python (mostly Java and C++). I've used Emacs, VS Code, Visual Studio, and other IDEs.

Petersipoi• 4 years ago

https://zed.dev/waitlist

alephnan• 4 years ago

All these new generation text editors are cool and all, but I feel they are mostly rehashing the UI of VSCode. VSCode is fast enough, and the perceived speed of text editors / typing only needs to be so fast.

Looking forward to innovations in UI. Cause otherwise, VIM is comparable if not better in performance than modern text editors.

thewoolleyman• 4 years ago

Best of luck with Zed, Nathan! I've always been impressed with your brilliance, vision, hope, and positivity. Hope we can catch up again soon, until then keep changing the world for the better!

omaranto• 4 years ago

Is it caled Zed because it is inspired by the old Zed text editor? https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801001...

ljm• 4 years ago

How many times do you have to re-invent the text editor?

lytedev• 4 years ago

For the same reason people have and use many different tools in all sorts of professions.

bananamerica• 4 years ago

I love Emacs and use it every day, but not everyone is up to the time commitment of maintaining it.

eikenberry• 4 years ago

When will the source repository going to be made public and what license do you plan to use? For the editor and the UI kit. Looking forward to seeing how that all works.

ravedave5• 4 years ago

Please be aware of the second system effect https://en.wikipedia.org/wiki/Second-system_effect

neoneye2• 4 years ago

Also implementing undo for a big project is tricky. If the user switches to another file, collapses/expands things, runs a plugin, auto-formats some code, and then undoes things.

What will undo be like for a collaborative editor?

jonathankoren• 4 years ago

Is Zed a company? I wish you luck, but I'm pretty skeptical that a whole company can survive on making a text editor, or even editing tools in general. Wouldn't it be safer for user if you open sourced this?

As someone that loved Atom, and have been screwed over by Facebook's Nuclide, and now Github's Atom, I have to think about my options.

(No emacs isn't an option.)

marxplank2• 4 years ago

why isn't emacs an option? It's the longest continuously maintained open source code editor there ever has been and still outperforms electron editors half a century after it first appeared

hannob• 4 years ago

I've spend a few minutes on your page, yet I couldn't answer the following questions:

* Do you already have a working editor I could test or is this merely an announcement?

* Is this an open source project or a proprietary product? Does it cost money? If yes how much?

wodenokoto• 4 years ago

From the webpage, I figure this much:

- It's in closed alpha, so yes they have a product, no they don't have a product.

- It is a closed project. It probably will cost money, it is not decided how much.

folknor• 4 years ago

Interesting! I just wanted to let you know my perspective, which is probably quite unique.

I started using atom pre-1.0, a long, long time ago. I immediately jumped to vscode when I realised it existed.

The reason is a bit weird; it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens c-s-F results in the main window, vscode opens them in the sidebar and doesn't clutter the main view with it.

The reason this is powerful to me is that I code mostly in domain-specific, esoteric, private languages that have no API documentation, no stdlib or docs, and no online resources to learn from. So the only way to learn is by example, or talk to someone who knows. Learning by example is usually much faster than talking.

So what I do is any new project is just a subfolder in a workspace that contains all known code in the language and the way I find out how to do something is c-s-F.

When the results cover the main view, or even parts of it (which is also possible with atom), it's just way too intrusive. The sidebar file list is useless to me at this point - where the result comes from is irrelevant. So why not use that space?

Also of course the fact that vscodes cross-file search was blazingly fast was an upside as well (I believe they used ripgrep for that since the start?)

Another thing I want to mention is (and you highlight the keyword search in that youtube talk around 18:54) the power of the command palette search method that is available in vscode: first-letter-matching. I don't know what the proper name of it is, but essentially "ps" matches "pub struct" for example. Obviously it matches it with a lower score than something that starts with "ps", but it's very powerful for matching in the command palette.

Thanks for listening.

theteapot2• 4 years ago

I code mostly in domain-specific, esoteric, private languages, no stdlib or docs, and no online resources to learn from.

Jesus, who are you?

mmcnl3• 4 years ago

I think this is powerful to everyone. I use that feature too and didn't even realize it was unique to VS Code. VS Code is really good in having a lot of features but not cluttering the main window.

breatheoften• 4 years ago

wow I couldn't disagree more ... the search/replace interface of atom is the thing I missed the most from atom when I migrated to vscode ...

vscode _has_ added an non-sidebar find interface somewhat similar to the atom one -- but its not as good ... for one thing it doesn't support replace (find only)

jzzskijj• 4 years ago

I have to assume no-one in the team saw Pulp Fiction (1994) when you ended up picking up the name "Zed"...?

slightwinder• 4 years ago

Written in Rust, custom native UI framework

Interesting. I think a major reason for VS Code's success is their usage of web-stack, which is stable, powerful and well documented, enabling easy access to higher customizations for anyone. It will be interesting to see how much a custom UI can emulate this without html&css.

lifeplusplus• 4 years ago

i hate vscode is written in electron, i always noticed the latency, it's good enough but it's annoying. atom was same but worse. what I also disliked about atom and sublimetext, is how you needed to install 20 extensions to get basic functionality and they weren't always compatible, with each other. Vscode approach of having most of basic functionality builtin but behind flags which can be disabled meant most people had good setup from the get go. Vscode to me was like jetbrains but faster and lighter. Although in some cases jetbrains was more robust.

If there is vscode that was written natively. I'd be so happy. Even if there is a new branch of vscode that is 6 months behind in features but is built in native it'd be huge for me.

ClawsOnPaws4• 4 years ago

Hey,

Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either.

Blind developers exist. Please don't forget about us. It's one of the few areas where we can actually make a meaningful difference together with our peers on an equal playing field.

serial_dev• 4 years ago

How do other editors/IDEs perform in terms of accessibility? What are your favorites?

polote• 4 years ago

It is normal to advocate for your needs but asking for it to be included from day 1 is weird. The same way you don't start a saas app with localization from day one.

I'm not blind so for sure I won't really care about accessibility but honest question why not use an ide developed for blind people instead of using the same as non blind people?

mongol• 4 years ago

Unrelated question: how does accessibility work on smartphones? Do you use something like a physical keyboard to interact with GUI elements in apps?

dao-• 4 years ago

Especially for a _collaborative_ editor, a11y seems like a must. Everyone can pick their own personal editor, but you don't want to shut out your (potential) peers from (potential) collaboration. Without accessibility, such an editor likely wouldn't stand a chance at Mozilla where I work; I certainly would lobby against it.

scotty79• 4 years ago

Please, please, please, make it infinitely pluggable from the start. That's the strength of Atom and similar editors. That anybody can create a plugin either for something very niche or just connect some huge amazing tooling directly to the editor.

If you can make editor in Rust pluggable or scriptable with JS, Lua, C#, Python and whatever someone knows and is comfortable with you got a winner.

zamalek2• 4 years ago

Just starting our private alpha this week

I'm holding thumbs, I have been massively excited about your elevator pitch since your original announcement. Good luck!

jeppester2• 4 years ago

In VS Code the collaborative editing (live share) seems like a dirty workaround put on top of an architecture not built with multiple users in mind.

I use live share all the time because it's the best thing we have for pair programming, but I often wish for a better solution. We often get disconnected for no reason, editors get out of sync, terminal sharing is near useless.

If you can produce something that doesn't feel like a hack, then I'm all in!

Features I would love to have:

- Terminal sharing should work like tmux with window size "smallest". It's the best solution I've found for having a shared terminal.

- Let us join a collaboration session from the terminal: `zed [URL]`. No annoying website that takes ages to open, or having to open the editor before joining the session.

- Let me start a server on a port and let others join that server. I can forward that port if I need to.

- Let me start a headless server on a shared dev env, and let me and others connect to collaborate

cercatrova• 4 years ago

Have you seen https://tuple.app?

404mm• 4 years ago

Hi, when can we expect to see some first preview?

AtNightWeCode• 4 years ago

"Mission-critical tools should be hyper-responsive." Did not seem to be important with the worlds slowest dev-tool ever, Atom. ;)

"Real-time collaboration produces better software." At design level, ok. Programming is in most cases not a co-op operation. If it is, then you are probably creating solutions while writing code which is the best guarantee for bad solutions.

“Conversations should happen close to code.” Agree to some degree, this is a big flaw with GIT. It is also a flaw with many programming langs and tools. Even if I use collaboration features in VS and VSC many langs are simply not designed for presenting code to people not highly familiar with the specific code base. So, an editor may not solve the problem here.

“Your editor should disappear.” I mainly code in VS and what I can do in VS in 10 mins takes me a couple of hours in VSC. A tool should aim to be the default of a problem. The amount of time I have seen wasted over the years with people trying to master VIM or git from a prompt is just ridiculous.

ghshephard5• 4 years ago

I don't use Visual Studio, so I'm intrigued as to what VS can do in 10 minutes that takes 2+ hours in VSC?

infogulch• 4 years ago

"collaborative" "Rust" "code editor" "CRDTs" is very reminiscent of Xi Editor by @raphlinus which shared all of these traits. Xi was abandoned with the conclusion that CRDTs aren't suitable as a basis for text editing interactions, or at least that implementation wasn't.

Is Zed related to Xi in history or as inspiration? Why are you confident that Zed will be able to overcome the issues that blocked Xi's advancement?

raphlinus• 4 years ago

I've been talking to Nathan and think he has a good handle on the issues. One of the biggest mistakes in xi was an over-reliance on async and a loose coupling between the main logic and the UI surface. Zed isn't making those mistakes. I'm eager to see what the come up with and look forward to friendly competition in the open source Rust UI space when they release their toolkit.

diziet2• 4 years ago

Will it be native Sublime Text fast? Not on electron?

I tried using VScode and Atom. Both were noticeably slow compared to sublime text. I can do silly, bad practice things like open a 50 meg log file in sublime and search for simple regex in the editor. Electron based editors stall and potentially crash.

iamnbutler4• 4 years ago

I may be biased, but at least sublime fast, hopefully much faster! Moving to Zed felt like going from a 30fps to 144fps.

You should be able to open stupidly big files and shouldn't experience much to any lag. Nathan has a demo he likes to give opening one one of those huge json files and searching, using multiple cursors, etc. It is pretty cool to watch.

ghshephard5• 4 years ago

50 Megabytes? That's tiny I would hope in 2022 that any text editor can handle a 50 megabyte file.

I routinely (like every day) open 500 megabyte files in SublimeText, and just checked to make sure that it can handle 1.5 Gigabyte files without much difficulty (it can).

Admittedly - once we get into the 5+ Gigabyte file size, startup times become annoying enough that I usually switch over to vim.

So, thank you for bringing this up as an important requirement for modern text editors - they should be able to open up multi-gigabyte text files without even breathing hard.

beliu• 4 years ago

In case folks are interested, I had a delightful interview about a year back with Max Brunsfeld, one of the original Atom devs who is now working on Zed: https://about.sourcegraph.com/podcast/max-brunsfeld. (YouTube link: https://www.youtube.com/watch?v=0Jf8AqaZ7IU)

Very excited about where this new collaborative editor goes!

LoveMortuus2• 4 years ago

Does 'lightning-fast' mean that the application will be light on the system or does it mean that it's well optimised but still demanding enough that you require a modern computer?

I'm asking because I like to use my laptop Acer Aspire One most because of the size and because it the incredibly good feeling keyboard. BUT the system is 32-bit and running Intel Atom which means that before VSCode moved away from 32-bit I could use it, but it would take some time to open and I wouldn't really call it writing in real time, if you know what I mean~ :D

But I love the keyboard shortcuts and the multiple cursor functionality, which is why I stuck with it for as long as I could!

smcleod• 4 years ago

Great to see you've dropped Electron!

giancarlostoro2• 4 years ago

I'm a huge fan of Text Editors, I've made a few basic ones myself. Thank you for creating Atom! For ages before Atom was a thing I grew fascination with using web servers for front-end UI and thereby using HTML / CSS for a local applications UI, I had seen this in SlickBeard and a few other usenet applications that used a web interface instead of a standard GUI interface to render a UI. I also remember a Google program that did this, though I can't recall the name. It might sound crazy to some to do it this way, but because the web server is localized to your system and your browser is usually responsive once open, every app I used that worked this way was always highly responsive and just worked.

I was dreaming of taking Vibe.d and CodeMirror and making something you could install as a daemon on any machine and code from anywhere. When Atom came out I was obsessed with it for a while, it was a whole other approach from what I was thinking of!

Did you ever do a write up on how you came to the thought of just taking a browser engine and turning it into your own sandbox and what that entailed in the earlier days? That seems like a fun story. Because of Atom we got great innovations that followed, for example Slack, Discord, VS Code, and the list goes on... and on... Heck POSTMAN! Which is probably used or has been used by every developer under the sun.

shuntress• 4 years ago

This actually looks really promising despite fitting snugly into the "Show HN: Hey check out my cool unique new project" mold.

I know it's not the main point of the DevXConf presentation but I really like the look of that multi-buffer feature.

derelicto• 4 years ago

Thank you for everything! Atom paved the way for the next gen of editors. Curious to see what comes out of zed! Live collab seems amazing.

As a wishlist item, can we get a native vim mode with .vim.rc support? :D

ksec• 4 years ago

Mission-critical tools should be hyper-responsive.
When you move the cursor or type a character, you should see pixels on the next refresh of your display—every time. Even sub-perceptual pauses add up over the course of a day to create unnecessary stress.

I remember there were lots of research for this in Next-Generation Atom during the Atom era, before VSCode came along. Having a UI and text responsiveness within 16ms on a 60Hz Monitor is a tall order which I believe even Sublime is incapable of.

Considering 95% if not 99% of developers on HN thinks VSCode is very fast or fast enough, I am not sure this point is worth pursuing. Personally I really want to see it happen. As I hate latency.

still_grokking• 4 years ago

How does it do in comparison to the other upcoming "better VSC"s? Like for example:

https://v2.onivim.io/

https://helix-editor.com/

xwolfi• 4 years ago

You're not going to get it right. At worst you ll make the same mistakes and at best you ll do the opposite mistakes.

No migration, sunsetting, "this is legacy, let s redo it all" will ever fix anything. Fix what doesnt work.

rattray6• 4 years ago

Funny, this doesn't sound like a spiritual successor to Atom at all. What made people excited about Atom (compared to Sublime Text, which people switched from and was ~always faster) was the extensibility.

Sounds like this won't have that. It's only a successor in the sense that it's built by the same people and tackles some of its challenges.

rattray6• 4 years ago

I'm not sure if this feedback is useful, but I have to say that a collaborative text editor doesn't feel like that big of a sell.

Pairing in VS Code over Zoom has gotten a lot better over the last year or two, to the point that I choose it for simplicity over more purpose-specific tools like VS Code Live Share (which is a bit slow/glitchy but fine, and overall "neat") or Tuple (which is great).

Would I pay money for "VSCode, but faster"? Absolutely. I'm waiting multiple seconds for keystrokes to apply sometimes and don't know why. But the extensions are what make it VS Code – if I just wanted "a faster text editor" I'd uninstall all my extensions and just keep using VS Code (it'd blaze), or switch to Sublime.

I'm excited to see more people working in this space, so I certainly wish you luck!

ThinkBeat• 4 years ago

This will be interesting.

For me Sublime seems to hit all the same spots without the web assembly plug in feature.

sgtnoodle• 4 years ago

Good luck! A clean slate code editor with Rust's memory safety guarantees sounds great. Just don't fall for the 2nd system fallacy. Keep things simple and pragmatic.

I tried Atom for a while, but it didn't cope well with other IDEs renaming files before overwriting them. I tried to fix it, but the response I got from the community was rather dismissive. It was quite irritating to present obviously wrong behavior and be told that it was correct.

My attempts to dive into the code myself lead me down a rabbit hole of dependencies of dependencies of dependencies, to the point that I just gave up. I switched to vscode and it has mostly stayed out of my way.

lenkite2• 4 years ago

first class VIM keybindings also please!

niutech4• 4 years ago

Why not collaborate with developers of existing code editors such as Xi Editor (https://xi-editor.io) or Lapce (https://lapce.dev) instead of making yet another one?

As for lightweight alternatives to Atom, there is also Lite-XL (https://lite-xl.com).

PoignardAzur2• 4 years ago

Speaking as someone involved in the Xi community, there's not that much to collaborate with. Work on Xi has completely stopped, and work on the Druid GUI framework is still in early stages.

I think it could be interesting to compare notes re GUI frameworks (especially since the Druid community is about to see some overhauls there) but I don't think it would have saved them that much work if they'd done that from the start.

wvh• 4 years ago

A new approach with native speed and incorporating LSP and easy extensibility at its core instead of bold-on – as in older editors – sounds interesting. LSP and across-file editing doesn't always fit nicely into the old tab-per-file or view-per-file paradigm. Is there going to be an open-source version with free license available for Zed, or will this be a commercially licensed project?

zanethomas• 4 years ago

sad to see it go vscode? i've been trying to avoid it

ilovecaching2• 4 years ago

Embrace. Extend. Extinguish. I won't touch VSCode with a 10 foot pole. Pick an editor that will last 40 years and isn't run by a mega-corporation that wants to eat FOSS so they can get us to buy into their subscription ecosystem.

jlkuester73• 4 years ago

Friendly reminder that https://vscodium.com/ offers Free/Libre open source binaries of VS Code without all the M$ telemetry or integrations with proprietary services.

db39• 4 years ago

I was a big fan of Atom for years. And one thing I wish VS Code could have is the Git UI. It always just clicked better for me.

ramesh31• 4 years ago

Embrace, extend, extinguish. It's in their DNA.

adictator• 4 years ago

Call me old, but I cannot look beyond vi/vim for an editor. A few years ago I had to edit a text file that was 9GB in size. It took a while to open it in vim, but once it was open, it was no different than any 2kb file. No other editor was able to even open the 9GB text file.

swlkr• 4 years ago

I loved and used atom for years, despite the performance.

It was just such a nice editing experience.

Also never got on the vscode train and opted for neovim instead (been using vim and bindings since 2012)

jimnotgym2• 4 years ago

Sounds like a good decision. I used Atom until everyone was talking about VScode... then I hopped over.

I think Electron is an amazing legacy to leave. Like many I would like it to use less resources, but it is still a grest idea.

alaricus• 4 years ago

Microsoft kills another great open source project. This is sad. Don't rely on Microsoft.

franciscop2• 4 years ago

Totally understandable, but the justification in the first paragraph of "Why are we doing this now?" seems a bit self-inflicted:

• Atom has not had significant feature development for the past several years

• (thus) Atom community involvement has declined significantly

• (thus) we’ve decided to sunset Atom

Feels a bit weird in that sequence to blame the community. Just say that YOU have abandoned the project since Microsoft acquired Github and get done with it, no need to sugarcoat it or others in the way.

petre• 4 years ago

This. I might as well try Spacemacs now as Emacs isn't getting 'sunsetted' anytime soon, plus it runs in Lisp. Vim user. It's just that Vim on a GUI doesn't make a lot of sense to me. So I went from Sublime Text to Atom just because Atom was open source. Tried VS Code several times and ditched it, as it was full of MS-isms. It had a bloody Twitter react button in the status bar and telemetry.

jdaxe• 4 years ago

VSCodium exists which is VS Code without the Microsoft "added features" (telemetry etc.) which sounds like more what you want.

jw143• 4 years ago

I checked back regularly for years to look for signs of life in Atom. There weren't any.

Last blog? 2019.

None of the releases did anything interesting. I work in Vue.js and needed that toolchain to work well, it never did with Atom.

So they're blaming the community for something they decided years ago and kept deciding every week when no resources were allocated.

Also, Zed isn't filling the void Atom left. Rust is interesting. Collaborative editing, not so much. Electron's lack of speed doesn't prevent VS code from fading into my workflow and being the most popular editor. I would still like an alternative because I don't think Microsoft should have the whole market.

rattray6• 4 years ago

I would still like an alternative because I don't think Microsoft should have the whole market.

Asking genuinely, why not Sublime Text? (I haven't tried it or Atom in several years, but used both back in the day).

emehex• 4 years ago

This is terrible. While I like VSCode, I exclusively use Atom for programming in Python because of Hydrogen [0], an extension which makes .py scripts feel and behave as though they were Jupyter Notebooks. I hope the nteract/Hydrogen devs are able to save their work and move it over to Zed/VSCode.

[0] https://github.com/nteract/hydrogen

marcodiego• 4 years ago

I had high hopes for atom. At first I thought about it as a FLOSS competitor to sublime. Its slowness (mostly because of electron) was entirely tolerable for me even on 10-year old hardware. I was afraid at how fast VSCode ate it. It is a good thing we have VSCodium.

Animats• 4 years ago

Do not want a "cloud based text editor". Being reliant on an external service is a huge point of failure. It can go down. It can join the huge list of discontinued Google products. It can have security problems. You can be arbitrarily banned by the service operator. Most cloud-based services only live for a few years.

KronisLV• 4 years ago

What was Atom good for, when compared with something like Visual Studio Code?

I recall reading about typing latency and it seemed to come out as one of the slower options: https://pavelfatin.com/typing-with-pleasure/

I guess it would have occupied a similar place as Brackets, another vaguely similar project? https://brackets.io/

Then again, with how popular VSC has become and with how insanely many extensions there are for it, using any other editor feels a bit... counterproductive at times?

Personally, i'm using the following:

  - CLI: nano (vim works too, I just like the simplicity more)
  - Simple text editing: Notepad++ or similar (usually whatever is on the system on *nix)
  - Some scripting, but nothing too serious: Visual Studio Code
  - Development in larger and more complex codebases: JetBrains products (e.g. IntelliJ IDEA, WebStorm and so on)

chad_strategic2• 4 years ago

I will admit that I'm biased, I hate to use Microsoft products. I hate Bill Gates and I hate Microsoft.

I will not be switching to VsCode just on principal. Yes, I'm still using Github, so I guess I'm a walking contradiction.

I also understand the economics of this situation why keep Vscode and atom IDE can't co exist, i'm surprised it took so long.

This is the second software application that Microsoft has ruined, remember the incredibly awesome wunderlist?

PascLeRasc3• 4 years ago

3rd actually, Sunrise was a fantastic calendar app. Microsoft is a blight on the world.

chad_strategic2• 4 years ago

Thanks!

Sometimes it feels like I live all alone with my hate for Microsoft/Gates, but I'm glad I'm not alone.

Matthias247• 4 years ago

Quote:

It’s worth reflecting that Atom has served as the foundation for the Electron framework, which paved the way for the creation of thousands of apps, including Microsoft Visual Studio Code, Slack, and our very own GitHub Desktop.

This is so true! Atom spearheaded a new generation of exciting apps and set them up for success. That is a huge achievement on its own - so thanks Atom team for everything you have done!

productceo• 4 years ago

Wow! End of an era!

albertzeyer• 4 years ago

So I wonder a bit, VSCode has clearly won over Atom.

But technically, as far as I know, they are both pretty similar.

So where is the difference? Are these just small details which VSCode got better? Or are there bigger things?

Or why else did VSCode actually won?

I have used both in the past. VSCode seemed a bit snappier, which is an important aspect for an editor. But I'm not sure if this was really the case actually. Or also, why there would be such a difference. Both used Electron, and I assumed both would use similar techniques for the editor.

aniforprez5• 4 years ago

Performance and extensions being forced to be simpler due to a fast more restrictive API. VSCode was miles ahead in terms of performance and way snappier than Atom was and the extensions on Atom gave frequent troubles cause they had all sorts of weirdness to them

josephcsible• 4 years ago

I hope that a new editor gets first-class Agda support so that Emacs won't be your only choice for it once Atom is gone.

eberkund• 4 years ago

I see a lot of people remarking that VS Code's killer feature is its extension system but I am not sure I fully agree.

Sure VS Code has a lot of extensions, but many of them offer only basic features or are poor quality. The extensions which deliver the most value are actually the ones supported by large corporations (like the Go extension from Google or the Python extension from Microsoft).

If another editor could port these powerful extensions I would care very little about the lack of icon themes and snippet extensions.

stjohnswarts• 4 years ago

I expected this with the Microsoft takeover. Most "extraneous" non-profitable activities and projects will be killed off. Also MS produces VS which is a successor in a sense to Atom.

dokem• 4 years ago

LOL this is why you just use vim/emacs/bash and move on with your life.

stefanos822• 4 years ago

Kraken, the company behind https://cryptowat.ch use the following cross-platform GUI library for Rust https://github.com/iced-rs/iced

rubyist5eva• 4 years ago

Who didn't see this coming after Microsoft bought GitHub?

DarkContinent• 4 years ago

Is Julia's Juno IDE going to be affected by this?

eigenspace• 4 years ago

No, because they already transitioned to VS Code years ago.

sam0x17• 4 years ago

In other news, the Atom One Dark color theme is alive and well in the VS Code marketplace. I've used it for 5 straight years. https://marketplace.visualstudio.com/items?itemName=zhuangto...

robinsonrc• 4 years ago

I hope the main thing you leaned is that people want a text editor to start up in less than a second

spicysugar• 4 years ago

Vscodium + LiteXL[0] replaced Atom + Sublime for me.

[0]https://lite-xl.com/

mohas• 4 years ago

I think the most essential feature that vscode had over atom was good default features, once I see my coworker struggle for an hour to setup a dev env and I decided it is not going to be the tool of my profession

7speter• 4 years ago

I’m old enough to remember when microsoft said that atom developmennt would continue alongside Visual Studio Code after the company bought github…

fungiblecog2• 4 years ago

Another editor bites the dust - another reason to stick with Emacs

fungiblecog2• 4 years ago

If i had a dollar every time a developer said "we're going to get it right this time"...

wellsjohnston• 4 years ago

I tried "hacking" on Atom recently for a side project and found it was full of bugs and not performant at all. Next.

betamaxthetape• 4 years ago

The video produced to introduce Atom 1.0 [1] is my all-time favourite tech announcement video, and I honestly don't see that ever changing.

[1] https://www.youtube.com/watch?v=Y7aEiVwBAdk

eftychis• 4 years ago

Why would I want to learn a new editor, if it is going to be sunset -- there are many great options out there that are unlikely to disappear or be unsupported? Meaning Github's new editor has to offer something unique and great.

hexo• 4 years ago

Glad that sunsetting of emacs is not going to happen any time soon :)

bilekas• 4 years ago

I loved Atom when it fisrt came out, was a little heavy on my machine at the time, but it was worth it. Had much easy plugin system than sublime and editplus that I was using. It was a go to for my windows machines where i didn't want to play with my VIM config etc.

But when VSCode came along it was over for my time with Atom. Wish the best for the new spiritual successor though zed.dev.

meanmrmustard92• 4 years ago

RIP. Hydrogen [https://atom.io/packages/hydrogen] running on Atom is the cleanest multi-lingual data science IDE in existence and has been my go-to for years. Haven't found a drop-in replacement elsewhere [vscode's language support is scattered: native python integration, different for R, Julia etc].

Anyone on HN have recs [besides vim slime or send-to-terminal options in other editors, which work but are clunky] ?

dangjc• 4 years ago

People kept asking me why I was still using Atom, and Hydrogen was it. It doesn't seem like there's an exact equivalent in VSCode. For now, I'm just relying on sending blocks of code to the interactive Python terminal. Or using the Jupyter extension. But the former might not work with other languages and the latter requires .ipynb files which maybe you don't want to check into git.

ihnorton• 4 years ago

I'm just relying on sending blocks of code to the interactive Python terminal. [...] the latter requires .ipynb files which maybe you don't want to check into git.

I use `#%%` code blocks in the interactive window for this purpose: https://code.visualstudio.com/docs/python/jupyter-support-py

This allows a normal editor workflow, interactive execution, and linear history of executed cells. But the code blocks can still be executed top-to-bottom and exported as a clean notebook for sharing purposes.

john-titor• 4 years ago

Can someone explain the hype around VSCode to me? I looked into it about a year ago and was immediately turned-off by the overwhelming amount of features that they throw at you right in the 'beginner's tour'.

What I appreciate about Atom is that it is very simple right out of the box and does not get in your way. You cold always beef it up with packages later, but that progression is much more pleasant to me than the VSCode approach.

The biggest selling point of Atom to me as a Python dev was the Hydrogen package. That tight integration of notebook features within the editor is something I have never seen before and a total game changer. Especially if you are working with data that you might need to visualize a lot. Correct me if I'm wrong, but from what I understand there is no Hydrogen equivalent in VSCode? Sure, there are plug-ins that let you run your code through a jupyter kernel and display the output in a second terminal pane, but that is not the same as the ability to simply highlight a bit of code, run that and have the results displayed immediately on the next line below. Having pyplot figures displayed in such a way is also not possible from what I saw, or did I miss something?

seoaeu• 4 years ago

The killer feature of VS Code for me is that when you open a source file for python, or C++, or whatever it pops up a dialogue: “would you like to install the extension for this file type?”. Click that and you’ve got working IDE features for that language with none of the hassle of tracking down which is the right extension, how do I keep my plugins up to date, which dependencies do I have to install first, etc.

hbn3• 4 years ago

In my experience, it works up to the point where it installs the extensions, and then it does a bunch of processing and still can't figure out how to run the project or what the code means anyway. Plus I now have a slew of new extensions installed, and I'm not sure which are new looking in my list of extensions.

IntelliJ has a pretty damn good track record for me, when I import a project it indexes for a minute or so, then it automatically knows the entrypoint to run the project, and has a fantastic understanding of all my code. Cmd+click any symbol and it can show me definitions, usages, implementations, etc. I can hit shift+F6 to rename a symbol, and it hits every usage perfectly (as opposed to every time I've tried to use VS Code to rename something, and it just causes me more problems than if I were to do it manually). I haven't found any other text editor or IDE that works as seamlessly in this regard, and it's a dealbreaker for my productivity.

samstave• 4 years ago

Nothing make me more happy than programmer nerds bitching on HN

hdivider• 4 years ago

To the founders and contributors of Atom: thank you.

Your work made more impact than you can possibly know. Atom became my absolute #1 editor. For code, and notes of every possible kind. As an entrepreneur, it carried me through so many adventures. The death of a cofounder, great losses and victories, the madness of 2020, a close friend's betrayal, a subsequent rebirth of sorts, and on and on. And always, this trusty piece of software sat there. Ready whenever calamity struck.

Thank you, folks. You created a wondrous piece of art and greatly impacted this entrepreneur's way of thinking and organization. Many have gained as a result.

Will follow Zed closely!

tough• 4 years ago

I subscribed to WL, free me from my laggy VSCode pls

sykp241095• 4 years ago

Atom has been in my choices, but actually, many development metrics of atom/atom is growing down: https://ossinsight.io/analyze/atom/atom

Gentil2• 4 years ago

This article bugs me. I would have liked them to be honest. Just say we prioritized VS Code or that handling two products of the same category is resource hungry and a waste. We all understand. But this article is making it look like it's Atom's fault. They just let it die slowly so people will be pissed but move on. It's a great tactic because "sunsetting" Atom after MS takeover would've pissed the community. This was great for PR for sure.

Atom has not had significant feature development for the past several years, though we’ve conducted maintenance and security updates during this period to ensure we’re being good stewards of the project and product.

Because MS made sure it didn't get any?!

As new cloud-based tools have emerged and evolved over the years,

Big player being VS Code and Codespaces?

Atom community involvement has declined significantly.

Because MS made sure the community was NOT backed with actions?

we are archiving Atom to prioritize technologies that enable the future of software development.

This should be the first sentence. Not last.

OberstKrueger• 4 years ago

Atom might be retiring, but One Dark lives on in every other editor.

jhoelzel• 4 years ago

DANGER: since everybody and their mom seems to be switching to VS-Code, we are going putting MS into a position where it does Microsoft things and that's dangerous.

mytailorisrich• 4 years ago

I've moved to VS Code for good partly because I often need to load big log files and Atom simply couldn't do that....

ionescu77• 4 years ago

Hi, thank you for your contributions to Atom @nathansobo. I really enjoy the git/github integration and the window for staging files and writing the commit message. It is clean and easy to read. I still prefer the Atom clean interface to VSCode/JetBrains PyCharm, mostly due to this git readability.

HouseOfBagels2• 4 years ago

Great, they couldn’t monetize a fucking IDE. I will say without shame, I fucking hate Microsoft.

HouseOfBagels2• 4 years ago

Ban me or whatever but Bill Gates is coming after your sperm, retards.

lozzo• 4 years ago

Just now I was checking the trending repos in github.com (JavaScript/Today) and I got atom on no.5 and more than 50K stars

lionkor• 4 years ago

Projects rewritten from the ground up in $POPULAR_LANGUAGE are notorious for being more bug-free, faster, and more stable than mature, well tested and widely used software written in $OTHER_LANGUAGE (which also already has an entire community and ecosystem).

It's legacy the minute we don't feel like adding any more features to it.

I'm being snarky for the sake of clowning on corporations who do this.

I'm sure the choice of Rust was made on the shoulders of many existing issues in atom. However, it bothers me incredibly when a product advertises itself as being built with a specific language. If that's your main selling point (it's in the headline for zed.dev), maybe you're about to build something utterly irrelevant.

mshenfield• 4 years ago

I used Atom for a long time after it was cool. I just loved the idea of an editor I could extend using the standard web tools and frameworks. Overall love this project, and still am a little miffed that VSCode ate their lunch. Best of luck on everything Nathan and the team do.

theteapot2• 4 years ago

I wonder how much of this is about not wanting to have to deal with and be ultimately responsible for the security implications of a plugin system built on top of npm packages and tooling ... It's a great editor but seriously vulnerable.

Sunsetting Atom

Related Stories