Sunsetting Atom
251–260 of 880 posts
Re: Sunsetting Atom
#252I 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…
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 soooo…
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.
Re: Sunsetting Atom
#253We 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
Re: Sunsetting Atom
#254“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.
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.
Re: Sunsetting Atom
#255Re: Sunsetting Atom
#256It'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.
Also all have the same magnitude of latency and lag. At least you know if one of them bugs you, they all will.
Examples for me would be: VSCode and Linear
Re: Sunsetting Atom
#257I 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.
Maybe I’m misremembering but didn’t VSCode begin as a fork/skin of atom?
Re: Sunsetting Atom
#258Earlier quoted context omitted.
I looked into that plugin but we don't run any special daemon/server for editing on our servers (nor do we want to).
Maybe don't edit on a server. Have you heard of git?
Of course I've heard of git and we use it, we just don't use local (on the computer we develop on) dev environments, we have a mix of developer-specific VMs and local physical hardware due to the nature of our business.
Re: Sunsetting Atom
#259Earlier quoted context omitted.
Why not pop out an integrated terminal and execute commands there? It's still within the editor and you could have a shell script that runs to deploy.
It all comes back to that "development cycle" and wanting to make that as short as possible. What you suggest is absolutely fine, it's just my personal preference (and something that I've seen help other devs) to make the "write code"->"see results" as tight as possible. If you add any delays, any potential chance of forgetting a step, etc then it breaks my programming flow which can kill my productivity.
I mean, hell, just set up gulp/grunt/another task runner to watch your files and run scp if you want it continuously running? Why involve your IDE at all at that point?