Sunsetting Atom
github.blogFounder 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
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.
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.
How do other editors/IDEs perform in terms of accessibility? What are your favorites?
My favorite is VS Code by far. I use it daily. They recently also added a bunch of sound cues to help figure out if code is folded or a line contains an error. It's pretty great. Auto completion reads well, the parameter hints read, even the built-in terminal works. So overall I'm really happy with it.
Microsoft is particularly good with regard to a11y and devtooling
speaking of VSCODE, i wonder if MS acquiring github has anything to do with sunsetting atom.
It probably played a pretty big role. Everything Atom could do, VsCode could do better. At some point it didn't make sense to put man-hours into two different editors with the exact same technology stack.
Not likely, GitHub is a separate business and makes their own decisions.
MS also competes with GitHub also; Azure Repos are a thing, as is Azure DevOps and those are just two examples. MS has plenty of products that compete with each other.
In some spaces this is a good strategy as you will capture more market share with two products than you will with one and you can avoid to an extent monopoly claims.
GitHub Codespaces is what killed Atom and while MS was probably involved in the decision to develop Codespaces, the decision to sunset Atom likely wasn't explicitly made at that time; its simply a side affect as other things have eclipsed Atom.
Microsoft has moved essentially the whole development team for Azure DevOps to GitHub. GitHub is what they consider the future.
Would you mind commenting on XCode? I heard that Apple really cares about accessibility.
I don't have much experience with XCode, however the few things I did do seemed accessible. As accessible as XCode can be - I personally find a lot of the interface a bit confusing. Super long lists, nested options, but I assume those aren't things that are specifically confusing to people using assistive tech and I'm sure I'd be able to find my way around it well if I used it more. Mac seems to be a lot more consistent with their accessibility story than others, and we constantly get new features from them. With the new MacOS for example we got a VoiceOver feature that tells us when we have formatting problems in text, and we can finally get indentation announced (something which we had to do using custom scripting before). Not to mention all the cool things that involve some form of (live) image recognition, like telling us where people are, where doors are, etc etc.
The design of the existing and previous mac mice and the new System Settings app in MacOS Ventura tell a different story.
> the new System Settings app in MacOS Ventura
Maybe it's just me but I'd not judge things like that on the first non-public beta.
I cannot comprehend being blind and developing for my existence. I think I would die, or else become a lecturer .
What an exceptionally unhelpful comment.
It was. I was in a particularly moody state and my filter was gone. It was meant in a way to be sympathetic to the challenges of that situation but is phrased badly. I'd delete it but I can't.
These things happen. Props for acknowledging.
Visual Studio is quite good: https://youtu.be/94swlF55tVc
I've only ever heard good things about Visual Studio in this area, not sure if other IDEs are comparable. I do know Eclipse has a specialized build for this purpose as well. I wonder if XCode is also decent in this regard. I think Notepad++ might be only other one from memory that I know of.
Unrelated question: how does accessibility work on smartphones? Do you use something like a physical keyboard to interact with GUI elements in apps?
I came across this video from 2020 that demonstrates a couple of ways it works on iOS:
https://twitter.com/Kristy_Viers/status/1287189581926981634
You can turn on the various accessibility features and try them yourselves. While I was already aware of the 'voiceover' features, I was blown away by the braille keyboard and how quickly she could type with it.
Blind people use TTS set at ridiculous speeds that make my 1.5x podcast playback seem glacial. Even back in the late 80s I remember a blind classmate who had a portable electronic typewriter thing that read her entries back to her at rapid speed.
I commonly watch dev talks and walkthroughs on youtube at greater than 2x speed because the talkers make an effort to talk slowly for non native English speakers.
Just pop open the console with F12, enter the following and hit enter:
$('video').playbackRate = 2.5
Change `2.5` to whatever number you wish.
Press up in the console to bring back your last command faster with the cursor at the end so you just delete the number, type a new number and hit enter.
Alternatively, <https://addons.mozilla.org/firefox/addon/enhancer-for-youtub...> offers a much more convenient UI for playback speed.
I made a website that uses bookmarklets just for that.
In the context of blind users: I wonder if it's common to have the display turned off, while still receiving touch input, I wonder how much it would improve the battery life.
smartphones come packaged with a screen reader. The screen reader announces what is present on the screen
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?
Please learn more about the needs of blind people before writing something like this.
Adding accessibility for screen readers is much more difficult to add later in the project lifecycle. Thinking about those design considerations early makes a big difference in how accessible it will later. If developers don't think about these things early, most likely the product will never be fully accessible, ever. Blind people have seen this played out before with other software products and know where this path leads.
(I'm not blind but have worked with blind developers. I'm not an expert in accessibility but I know enough to know how important it is to listen to accessibility needs)
This comment is honestly shocking to me. It’s not “weird” for people with different needs to ask to be included in the software we build. Accessibility is a baseline for any product in 2022 and needs to be included from the start otherwise it inevitably won’t work when it’s strapped on later.
I also find it weird. I’m not disabled but I think designing for accessibility is important. It’s hard to tack on later and have it work well
Actually it's pretty good development practice to start an SaaS app with localization from day one. Why wouldn't you? The world doesn't revolve around English speakers (there are more non-English speakers than there are English speakers, at least what their first language is concerned), the same as it doesn't revolve around people with 100% vision.
You start an editor with extensibility from day one, as well as theming from day one, as well as multi-platform from day one, etc.
Why should it be different for Localization or Accessibility?
Please consider that implementing accessibility during the design phase is infinitely easier than post implementation. Additionally, accessibility benefits everyone and we should always be advocating for it regardless.
Imagine if you can code screenless. Headaches in response to light? Not a problem. Avoiding screens at night to wind down for sleep? Solved. Eyesight deteriorating (a totally normal thing that comes with age)? No new tech or ecosystem to need to adapt to, everything is already there.
> The same way you don't start a saas app with localization from day one. Believe it or not, my native language isn't English, so this doesn't make sense to me. > I'm not blind so for sure I won't really care about accessibility You should. You're not blind yet. You're not deaf yet. You don't have motor control problems yet. It does not take much to get there. One small accident and your life is changed forever. It's terrifying. > why not use an ide developed for blind people instead of using the same as non blind people? Because not only do those not exist, but that seems just a bit silly to me. Most operating systems provide pretty good means to make apps accessible. They usually have API's that, if implemented, will make your app work with whatever assistive tech you may use on that platform. Most apps work on Mac, most apps work on Windows. Linux is sadly another story, but even there we can at least edit text. What about tutorials? Courses? If we can't use the same software, should we also not be able to do any of them? Should we be locked out of great innovation because we need special software that nobody wants to update? Or worse, locked to one specific platform?
I believe I've said this before, but as sad as it is, every time I hear "Custom UI" I immediately think "Oh great, this won't work". In fact, I'm much more likely to give something a go if it's developed using web technologies. While not perfect, at least I know that there's a chance that it might work. It shouldn't be like that.
It is not weird at all, and claiming that asking for accessibility to be considered is weird is frankly rude.
Approaches like yours are why people who are differently abled feel left out and like second class citizens a lot of the time.
I have learnt from VERY painful experience that you cannot "bolt on" accessibility later (not without very painful refactoring and massive tech debt). It needs to be a core feature considered in the base design and a task added for every feature added on top.
OK you want motive. If you do accessibility with priority, you will get a whole new set of users who are always overlooked. A less competitive way to get easy money or user base depending on your product's model. ;)
I recently had a scare with my eyes. Freaked me out. I started looking at my developer tools completely differently. You are not out of the woods buddy. Anything can happen tomorrow. :)
People can and do care about accessibility while not being blind. Being considerate should be a characteristic we all have.
Wow… really? Accessibility is not just for blind users.
It’s also for users with poor eyesight, colour blind folks or folks with motor impairment.
It can happen to any of us and then you’d be glad that developers are taking accessibility standards seriously.
Wouldn't you start a car business with seatbelts and airbags from day one?
I would. I'd also refuse selling to blind persons.
I'm guessing that by "included day 1" they meant that if you do it this way it's much easier then having the product designed and then re-engeneering it to support accessibility later.
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?
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.
Ooh, this is interesting. It sounds like you learned a lesson here. Could you say more about what prompted the change? I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. Was it something like that for you as well?
Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
As someone who loved everything about Atom except the sluggishness and bloat, Zed sounds like exactly the thing that I've been wanting.
VSCode/Codium is amazing but it feels the same - sluggish but a feature/extensions-packed behemoth.
I hope Zed is able to establish a nice extension ecosystem as that is priceless!
Thank you!
This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.
Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things.
Everything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system.
This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways.
> it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict.
This is a sign that emacs has too much extensibility (or, to be more accurate: too little isolation). It's been observed before that emacs really is the antithesis of the alleged Unix philosophy of "doing one thing and doing it well". It is an inner platform.
Well, it's a doulbe-edged sword.
Causally linking glaring deficiencies (long lines, concurrency) to overriding virtues (extensibility) is a weak but common snow job aimed at emacs's critics who know nothing of emacs's internals. For this emacs critic who knows quite a bit about emacs's internals, I call you out.
There's only one reason for emacs's many wtf frailties. No one's paying to fix them.
Emacs either doesn't have APIs or everything is an API, depending on how you look at it - since it's source is available at runtime plugins and modules can be first-class citizens performance-wise.
With Vim at least, and I think Emacs as well (although I don't use it), it seems like they have greater focus on providing the embedded scripting language, than deciding what to expose to the user via an API. In Vim's case at least, this seems to have resulted in multiple third party API-like projects (for things like installing plugins, linters, etc). It isn't clear to me the extent to which this is an artifact of the way the editor is structured, or to what extent it is just a result of having had time for these types of third party projects to grow.
There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.
The web stack is abysmally slow, so you have to carefully pick the levels at which you offer extensibility. Emacs doesn’t have to worry about a DOM, CSS, etc. There’s just not that much between between grabbing input events, storing a character in a gap buffer, updating a glyph matrix, and painting the screen. And it’s all heavily optimized to be usable over ancient serial links: https://web.mit.edu/~yandros/doc/craft-text-editing/Chapter-.... So even making each of those steps heavily programmable in Elisp—every key press invokes a Lisp function that can be rebound, or adviced-around, still ends up performing reasonably well on a modern machine.
This "private alpha", any hints on how we might jump aboard!? ;)
EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist
it's less about being exclusive and more about getting feedback on the specific features we are focusing on and building at the moment.
For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!
This is important, think about the whole Web. Too many ways of doing things and too much backwards compatibility needed for tools to develop further.
I always cringed at languages like Perl and also Groovy where the pride of the language designers seemed to be that there are so many ways to do the same thing.
There are so many ways to do the same thing...in any language. That's just reality.
but Perl have backwards compatibility, developers keep perl1 source code can run on current version.
>I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices.
LOL, as if Firefox provided a stable API to extensions
I think that's the inherent catch-22 of having a big API. You end up in a situation where you can't change things for fear of breaking the API, but you end up also not being able to hold the API stable for fear of not being able to change things. So you end up stagnating and breaking things all at the same time.
Do you think there's any good solution to that problem?
I think companies make brand new products whenever that happens. No legacy baggage. If it gets popular enough then the old software gets killed off.
IMO the leap from sublime to vscode was because the extensions made it so welcoming & bultin. I think the next leap from that is by-default sharing of those extensions and config. WASM might be able to do that coupled with security defining execution. We need a trusted mechanism to share what git-hooks promised without thinking about it. Like you said, collaborative.
If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.
VScode offers workspace settings that you can check into git that will get picked up by anyone else using vscode on that repo.
This is great. Syrus here, from Wasmer.
I think WAPM and Wasmer could help a lot on the extensibility using Wasm plugins. I'd love to chat further, please feel free to reach me at syrus[at]wasmer[dot]io!
Hey there. I've been thinking about implementing an editor agnostic WASM based plugin framework and started prototyping with some promising results, although there are also a lot of of WASM related constraints to consider.
I think cross-platform plugins would be hugely beneficial for the whole ecosystem, and also generally for new editors since they can potentially benefit from a larger plugin developer community.
Is that something you can see your team collaborating on?
If you make Python a first class citizen and give it special support, you won't be disappointed.
Man that felt a bit like extortion, but I mean well.
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.
That's not my recollection, at least. I was more of an Atom fan than a Code fan in the middle of the last decade, mostly due to aesthetics, as shallow as that probably sounds -- but it felt like Code surpassed Atom in terms of community activity head-spinningly fast, like in its second year.
I also think the sibling comment is right; TextMate never had the huge collection of plugins later editors did, but you can very much see the seeds of Sublime Text's package system in it, and Sublime is a very obvious influence on Atom/Code. (Although they were smart to have package management fully integrated; Sublime's package management system is a bit clunky by comparison.)
Same, but if you're staring at an editor all day it has to look good. Atom did and still looks way better than VScode. VScode looks like a Microsoft product.
You can also customize Atom easier than VsCode. Why even build on web technologies if you don't let your users change things. For instance you have to have an extension to custom load CSS and it's kind of a hassle. Heck even Sublime has an easier interface to change the text editor in real time. You don't really need to do much as it already looks good though.
Funny how people are so different. I have never once thought that I needed my text editor to look good. Stare at anything long enough and your brain isn't even going to process it anymore!
fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.
While I am a Mac user, I've used Vim a lot, so I don't want to make it sound too much like I demand text editors be visually stunning works of art. :) Code initially looked just kind of clunky and toylike to me, in a way that Atom -- and Mac native editors like TextMate and BBEdit -- didn't. It's a little hard to explain. Code still isn't my favorite editor, but it's probably my favorite cross-platform editor.
For me, it’s the noise and clutter — every time I spin it up, it feels like VS Code is demanding my attention in multiple popups, and there’s a new tab or button I’ve never seen before with some mystical purpose, and the bottom bar is some jarring color that makes me feel like something is broken.
IntelliJ IDEs feel similar — sometimes I’ll open them up and after upgrading several plugins and dismissing a bunch of popups and “what’s new” dialogs, I don’t even remember what I was trying to do in the first place.
A month ago I switched back to Vim, from TextMate, but still on a Mac, and honestly: Vim is kinda pretty. I spend most of my day in fullscreen Vim, and with a good theme, Airline and a pleasing font it’s just as pretty as VSCode if not more.
Maybe I just have horrendous taste, but I just get GitHub Theme Light and am done with it. Do you tend to be nitpicky around aesthetics?
I really don’t think “selecting a color theme” qualifies as being “nitpicky about aesthetics.” But maybe I’m just nitpicky about aesthetics.
> Atom practically invented the kind of extensions that VSCode had
Let me introduce you to Emacs, vim, Sublime, TextMate, ...
> Emacs, vim
Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex.
> Sublime
Sadly, Sublime is sort of dead.
> TextMate
TextMate: Text editor for macOS
> Sadly, Sublime is sort of dead.
Sublime has ongoing development on https://www.sublimetext.com/dev and the last major release (4) was just about a year ago.
I was under the impression that the "forced" upgrade to Sublime 4 caught quite a few out, and may have been a nail in the coffin.
I'm still rocking SLT 3, and it's my go-to for large file handling or just as a simple scratchpad, but development (of SLT) feels like it moves at a snails pace.
I'm in the same boat. I bought ST3 and have avoided going to 4, as now it's just my scratch pad and .txt viewer, not really used for development.
I can live with a 'LICENSE UPGRADE REQUIRED' text in the title bar.
Everything works just the same, and I don't get the purchase pop-ups.
> but development (of SLT) feels like it moves at a snails pace.
This is how it's always been I think; their model.
> This is how it's always been I think; their model.
I don't think ST needs to move fast. It's a good quality editor. It doesn't need a bunch of new features every couple of months. Just getting a major update once a year is fine imo.
Sublime is very much not dead. It's still much faster than vscode or any other heavyweight IDE.
> Unlike VSCode, Emacs and Vim have a learning curve.
That's not the point, we were talking about plugins.
I think that the learning curve might be in reference to installing plugins.
Installing an extension on vim (never done emacs) is something that does not just happen easily. There is no intuitive search for extensions built in, you likely have to install software that manages your plugins.
VSCode on the other hand rarely requires more than a single click through a built in interface.
The plugin ecosystem exists for command line editors, but it definitely has a learning curve
nope, Emacs has an existing package installer and several packages in itself which make package installation easier than even VSCode or Atom
Emacs has a built in package manager as well as several alternative external package managers! Most of the time installing a package is as simple as running "package-install" or having a "use-package" expression somewhere in the init scripts!
I personally do not use any of these package managers and instead use my systems package manager on Gentoo to manage everything. Gentoo has most of the popular projects in the ::gentoo repo under app-emacs, and packaging your own is only a few lines of bash.
While I don't know about the plugin ecosystem of Vim/Emacs, I definitely agree with the learning curve part.
In Emacs/Vim I can't even escape the program if I don't know a keyboard shortcut.
In Vscode even if I forgot Cmd+W/Q I can simply click the close button. Not to mention that all the shortcuts are just globally used shortcuts in all the other software.
While I respect praising by the community of Vim/Emacs, I really don't think it's beginner-friendly.
So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific.
> In Vscode even if I forgot Cmd+W/Q I can simply click the close button
there is a close button in emacs. however unlike vscode, emacs can also run in the terminal
> So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific
can be said about windows too. i started off on windows and jetbrains. today im on minimal linux, stumpwm as window manager, and emacs for everything except browsing. i find it very liberating having cut down my dependencies without having cut down functionality
> In Emacs/Vim I can't even escape the program if I don't know a keyboard shortcut.
Or, you know, you could just click on the File menu and click on Quit.
I was (obviously) referring to terminal.
You've never run them in a terminal?
> You've never run them in a terminal?
When I run Emacs with a blank config, the default display has this:
Get help C-h (Hold down CTRL and press h) Emacs manual C-h r Browse manuals C-h i Emacs tutorial C-h t Undo changes C-x u Buy manuals C-h RET Exit Emacs C-x C-c Activate menubar M-`> Or, you know, you could just click on the File menu and click on Quit.
and in Vim, there is no such display.
You can’t run VSCode or Atom in a terminal, so I don’t think that’s a fair comparison.
???
I'm not making that comparison.
GP's post was in response to the complaint that Emacs/Vim are hard to exit. They said that "Or, you know, you could just click on the File menu and click on Quit."
And I'm just saying you can't do that in the terminal.
Not sure what you're going on about.
Your terminal doesn't have a way to exit it?
Are you suggesting a good way to quit vim/emacs is by exiting the terminal?
I don't know.
The rare time I use vscode instead of neovim I always end up with a lot of random characters into the code and have to close it without saving for fear of having broken something. You call that user friendly?
>>You call that user friendly?
User friendly is what most users find it easy to use.
Your argument is more on the lines that you are a legacy user who does't want to move.
The whole idea of using vim/emacs was when intellisense/autocomplete was in its infancy. And programming general required using typing skills as a autocomplete mechanism. The only real use of all that edit-commands-as-a-mini-language philosophy of vim is to write keyboard macros. Which again was needed because people lacked decent autocomplete features. Besides typing fast itself isn't connected to coding productivity these days.
See my previous comment. LSP/intellisense support is available on vim/neovim and many other editors. It is not like it is an exclusivity to vscode. Also many people actually configure their vscode to use vim-like keyboard bindings because they actually like the separation of the different modes.
Macros, substitutions and search commands are useful for many things and an editor like vim/neovim/emacs is not only used for code.
Nobody ever talked about typing fast.
> In Emacs/Vim I can't even escape the program if I don't know a keyboard shortcut.
With emacs this is a feature, not a bug ;)
At risk of dating myself, I am still rocking with sublime text and vim.
I'm still rocking with just vim.
> Unlike VSCode, Emacs and Vim have a learning curve
have you seen the extent of available emacs packages? maybe it is a learning curve for a person who just learned how to power on a computer but i find emacs soo much more approachable
There is a fundamental difference between the kind of extensions that Atom has and the type Code has. It's something that people often miss when they compare the two.
Atom was made to be infinitely customizable by using web technology. You can dynamically change everything you want with custom HTML, CSS, and JavaScript. Nothing is off limits. Want to shrink the size of the tabs? Just throw in some CSS, everything is changeable.
Code on the other hand runs plug-ins in a separate isolated thread where they are left to communicate with the editor through an extension API. Every customization "hook" that a plugin has access to needs to be explicitly added in that extension API. The things that the devs didn't think (or want) to add are simply impossible. Want to shrink the size of the tabs? Tough luck (except for unsupported hacks).
Code is awesome, but I think Atom should get more credit for what it tried to do. It is arguably the most customizable text editor ever.
Thing is, the vast majority don’t care about infinite tweaking. I’d never want to change the tab size or anything else like that. It should be right to begin with. Also I don’t want to have to deal with extensions breaking every update.
What I, and almost everyone else wants is extensions which provide real utility like language packs, linters, git tools, etc. All of this works well on VS code.
Sublime, TextMate, …
I love Sublime, still my fave
The instant-opening experience is just soo good, and Electron bloat nowhere in sight...
I actually use VS Code as well, but more like an IDE with tons of extensions, and Sublime is my 'basic' text editor.
I tried to use VS Code but just couldn't stand it. I don't want to say it's sluggish but it definitely isn't snappy, not even with a M1 laptop. It's fine, but it isn't good.
I ended up purchasing the upgrade to Sublime 4, definitely worth the price.
Same thoughts.
While Vscode is my IDE now, I definitely love the instant-opening of Sublime.
Ironically, it's even launching faster than TextEdit.
BBEdit.
I love BBEdit, but its package ecosystem isn't well-developed compared to most other editors, and it doesn't have any kind of package manager -- it's more like Vim's native packages, e.g., "download the package and put it in this folder, and check occasionally for upgrades when you remember and re-install when appropriate."
wonder how much coffeecscript played a role in it. I happen to be writting coffescript at the time and noticed how it tended to hide its unnecessary wrapping when you use its syntax sugar. Still kinda wish we have a typed version of it.
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.
I said basically the same in a sibling comment but I can't agree with you. VS Code doesn't start fast enough and it's not smooth to write with. It's not exactly bad but you definitely feel the slight delays and slowness all the time.
I went back to Sublime exactly to get faster startup and smoother writing than what VS Code was offering. So I'm pretty excited to see how Zed turns out!
Sublime test starts faster and smoother than vscode, but it's plugins leave too much to be desired compared to a good vscode setup.
I was a massive sublime text 2 user with a living document I would share on how to set everything up just right, but now I only ever use it to open the odd 100+mb sql dump if I want to search for something and have it be syntax highlighted.
I don't percieve any of that but I also don't care if a game framerate is 30 or 60 or 120, it's probably the same type of brain difference! More choices is always a good thing.
Which editor did you came from to think vscode start fast? msword?
Comparing it to Atom etc. It takes like 3 seconds to load a medium-sized Python project for me. And I was a long time vim user. The speed of vim is not worth the ridiculous gap in features.
Which gap? There are so many plugins. The only use I did of vscode this last year was to use the drawio integration and now I am doing diagram as code when I need to with mermaidjs or python diagrams and no longer uses it.
Even if it took 3 minutes to load it wouldn't matter because I plan to work on the project for days if not hours. OTOH, like you mentioned feature parity just puts VSCode in a different league altogether.
3 minutes(the imagined extreme scenario) pales in comparison the hours of time most people waste in meetings, or sipping coffee, or chatting with colleagues.
Just how much do you plan to achieve in 3 minutes?
You seem to not be aware that intellisense LSP support is available in many other editors than vscode.
This is why I continued to use sublime text all the way up to capitulating to TypeScript. Code was slower because of all the intellisense. I've had Code freeze on me a few times. Something that I don't have happen in Sublime or Vim. If you have a lot of RAM and work on a current mainstream OS it may seem smooth, but it's still using 400mb of RAM. May as well use Eclipse or WebStorm FWIW. That said I'm using VSCode now too, but things can always be better :).
Part of it may be just Windows. I use Windows a lot to move files and folders around and the File Explorer is something I constantly need to wait on to respond. The Windows as GUI is not very responsive in my experience.
> "but it's still using 400mb of RAM"
Why does this matter? What is the point of saving RAM instead of using it?
Because all my ram is already consumed. I have a 16gb MacBook running only a browser, vscode, ms teams, and the docker containers for the app and I have no memory left so I see a spinning ball every time I change windows. Ms teams was the final straw. Slack was about 300mb but teams is now 700mb+
It matters because your program is probably not the only one running.
It’s a small amount and if you’re using it then it should take priority. Modern operating systems with SSDs are very good at managing memory anyway.
Once you exceed it some of the content will go to swap, which is going to slow down the system (and wear an ssd faster). 400MB is not that much though, for me Code usually takes at least 1.5GB RAM.
NeoVim can compete on this front. See LunarVim for a heavily extended experience.
woah, as a long time vim user who's been too lazy to switch, this might push me over the edge.
I pair it up with Alacritty on Mac and Linux for a nice performance boost. It will work in iTerm or one of the default Linux terminals, but much slower.
Nice! I'm on iTerm but may just go whole hog and switch out that too.
Thanks for the tips! I love HN.
P.S. Any other plugins, tips/tricks you recommend for a vim user jumping into NeoVim/LunarVim?
Interesting. Will you have built-in LSP support for most popular languages then?
The killer feature for me wrt to Atom -> VSCode was the built in terminal.
The bloat VSCode has over Atom kills it for me.
Atom was unbelievably slower than VSCode for any comparable set of capabilities. What do you mean bloated?
anyone can say vscode is bloated except atom. I gave it credit for being highly modular though. I remember being to disable the statusbar component (not just the UI) completely.
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.
> I code mostly in domain-specific, esoteric, private languages, no stdlib or docs, and no online resources to learn from.
Jesus, who are you?
There are also a whole bunch of languages for:
- Describing levels in video games, which are primarily data with code mixed in
- Describing transformations of different sorts (e.g. the types of languages used in compilers for specifying a programming language parser, and then optimizations)
- Defining hardware (analogues to Spice, Verilog, and VHDL). Hardware can also include mechanical objects, as well more broadly, wetware (e.g. custom bacteria, a la Ginko Bioworks)
- Run on custom hardware (e.g. SIMD and MIMD platforms, similar to GPGPU)
- Are primarily mathematical (e.g. for describing control systems, neural network architectures, etc.)
... and so on.
Not all of this is a DOD/medical mess. A lot of DSLs are REALLY REALLY FUN.
My guess based in my experience would a MUMPS developer for someone like Epic or Meditech. That code gives me nightmares whenever I see it.
Still can barely believe MUMPS is real tbh, first saw it on TDWTF and I thought it was a joke at first.
Coming from today's world, sure. But in 1966, a language with a built-in database was a godsend and there were no standard language conventions to adopt (C was still several years away and only COBOL and Fortran were in wide use).
What, like $$foo(3,4,@bar,"baz")?
A brainfuck developer?
Writing DSLs is not uncommon among Lisp developers.
im guessing a very loyal employee to an enterprise company outside of tech - probably logistics
Retired? Or in Academia?
DoD?
The name is Den. Snow Den.
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.
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)
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?
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.
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.
Fabulous point. Always good to have solid contingency plans.
In the meantime, zed.dev, baby, zed.dev.
They should name its engine or one of its components "Chopper".
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
kitty is python+c++ fyi! (and as blazing as the other lightning rust software)
"Real real fast"
I like smoke and lightnin'
Bare metal thunder
Lightning fast must be an upgrade from the blazing[ly??] fast days. Tangential, but I've been wondering, what comes after "web scale" on that axis?
That because they're usually comparing it to a Electron app, at this point it's punching down ;)
"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.
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?
One example could be scaffolding out a CRUD app and DB fairly quickly.
Even excluding scaffolding, VS can eliminate a lot of the boilerplate that takes time if you need to type it out yourself.
Not saying you can't setup VSC to do those kinds of things also, but VS is a tools included solution out of the box. (I say this as someone who hasn't touched VS in a few years now, but used it daily for a few years before that, and who generally enjoys using good/fast text editors.)
I would argue that boilerplates should be minimized in the first place. Regardless how fast it is to generate them, reading them over and over again together with the code human write is a huge waste of energy.
I would point out that there are places where having boilerplates is a significant time savings. I'm not disagreeing with you, just pointing out the practical application sometimes outweighs the cons.
So a generator tool is built in instead of installed via a package manager? Doesn’t sound like a big advantage, you still have to know that those tools are there and learn how to use them so you’re only saving the amount of time it takes to run npm i —global yo once. Same thing with snippets and emmet and a myriad of other shortcuts. Having a huge selection to choose from gives the advantage to VSCode in my book.
Just a single advantage, I should allow others that use VS more regularly than I. VS also has all of the same types of things you mention as advantages for VSCode as well.
I'm not advocating for people using it necessarily, just saying it is a really high quality IDE if you need or want to use an IDE.
> 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.
Sure, cross-platform UI that's on the metal is a more accurate description.
Do you have any plans of open-sourcing the UI framework?
We do have plans. Stay tuned!
Also with your custom UI framework, you will need to re-implement a text editor from scratch which is a pretty daunting task by the way [0]. Do you also have plans to open source the text editing / make text editing a part of the framework? Text editing (right there with accessibility) is the core reason why one would not go with a pure immediate mode GUI for any app. I guess you are baking immediate mode with some extras?
[0] https://www.construct.net/en/blogs/ashleys-blog-2/simple-sof...
Rust on Mac with an open source UI - wow! If nothing else, you guys are ambitious as heck. Can't wait to see more. Also, loved the youtube video you linked to earlier in the comments - great to see an actual working demo instead of just an announcement.
That's awesome! How far off in the future is that? Is it more like a 1 year or a few years?
This sounds awesome! I hope you post it here!
Did you consider using Flutter? If yes, what made you choose against it?
It's been a few years since I used Flutter, but doesn't it still require you to use the related language Dart? I liked the idea of it, and I thought the tight integration between Flutter and Dart allowed them to do some cool things. But I wasn't a huge fan of the language itself. And I think it's a lot to ask prospective extension-writers to learn a new language.
If you know Java or JavaScript, Dart is extremely easy to pick up.
Sure, but that doesn't help if your project is in Rust.
Rust actually has a library with very good flutter integration, it does require using dart for the actual flutter part though, but it works well together.
Are you talking about nativeshell[1] or something else? nativeshell looks to be in early stages of development still.
Sure, there's a whole class of languages that are enough like one another that if you know one you have an advantage picking the other one up.
On the other hand, it looks like Rust is only moderately more popular than Dart: https://www.tiobe.com/tiobe-index/
But I can see why they'd steer away from a language controlled by one company, especially one notorious for killing off projects.
We just wanted to be pure Rust and have complete control.
"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.
Yes, you can argue for another plausible interpretation of those two words, but in actual usage "Native UI" has always meant the platform's native UI framework.
A lot of people started to refer to Qt as native around Electron's time. The only place where Qt is native as such in on a KDE Plasma/LxQt desktop.
You're correct, although Qt attempts to do fake native widgets on Win / Mac, and given how relatively lightweight it is compared to Electron, it's understandable how it became a obviously point of contrast with the latter, which doesn't even pretend to be native. Given a choice between the two I will obviously take fake native widgets over nothing.
I, on the other hand, will take whichever widgets have the better accessibility implementation. Currently Electron beats Qt on this.
> but it's pretty clear from context that they mean the former
It absolutely was not clear, which is why I checked the website and then pointed out the lack of clarity.
At first my thought was "Wow, nice, another UI toolkit that uses native widgets, that's good!" But, alas, it was not to be.
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.
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!
Thanks very much for your kind words and wishes!
You are very welcome. Although in my haste I mixed my metaphors up!
Not sure if Atom was a fruit that grew into an orchard or a seed that grew into a garden. How about both?
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.
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.
I hear you, but atom and vscode are noticeably slower at interacting and searching even at those small file sizes. So we're in violent agreement here!
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.
Any chance of collaboration with https://lapce.dev/ ?
Wow this does seem to share a lot of features. Rust based, WASI plugins, real time collaboration. And it's open source!
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!
Thanks very much!
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)
Did that happen to you? Sounds scary…
Please be aware of the second system effect https://en.wikipedia.org/wiki/Second-system_effect
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?
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.
We plan to monetize collaboration. Zed is a collaborative platform disguised as a world-class code editor.
I'm always excited to see new ways to monetize open source. Hope this is another open source success story.
How often do developers want to edit the same file, at the same time, and have those updates occur in real-time?
I see this as a compelling feature for something targeting the use cases of, say Google Docs, where multiple people are contributing to an outline document or a business plan at the same time - but for code, I don't quite see the appeal.
> How often do developers want to edit the same file, at the same time, and have those updates occur in real-time?
That's a very specific example of collaboration. Remote work is exploding. What about, say, integrated, collaborative debugging or code review? Integrations with things like Slack?
I'm sure the folks at Zed know what they're doing, but this is already possible in multiple editors / IDEs. I'm excited to see how Zed innovates in this space.
Examples:
- VSCode Live Share https://code.visualstudio.com/learn/collaboration/live-share
- JetBrains IDEs Code With Me https://www.jetbrains.com/code-with-me
- Standalone https://www.coscreen.co https://duckly.com
There's also SubEthaEdit for macOS: https://subethaedit.net
Another one mentioned elsewhere in the thread: https://lapce.dev
I do this all the time. I use a tool that has 2 modes: turn-based and multicursor, the turn-based mode is signnificantly more annoying. Most of the time you just use it to highlight but it's also good to be able to help the other person with typos and comments, while they are focusing on the logic.
Do you never pair?
I do, and one person has control over the keyboard at a time. Hell on earth is two people making write operations at the same code buffer.
I don’t see why? Doing some refactoring you’ve decided to do and you can both go through the file at the same time refactoring different methods or whatever. What’s the issue?
We do this frequently :) It's awesome to get through tedious tasks twice as fast
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
Have you seen https://tuple.app?
Thank you for the suggestion.
I have tried tuple, but for me it feels like a step back compared to live share. It has poor linux support, and sharing one screen is not as good as connecting to each other's editors. It just feels worse to watch a video feed compared to something that's getting rendered locally.
I do however believe that tuple can work very well if you are in an environment where everyone has mac computers and similar screen setups.
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!
What's the reasoning behind this iteration being closed-source?
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.
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 :(
Is it caled Zed because it is inspired by the old Zed text editor? https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801001...
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!
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.
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).
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.
Add a really good vim mode and I’m there.
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.
Fantastic. Let us pay you so this sticks around.
Amazing to hear this, looking forward to hearing more about the project.
Hoping he also adds animations. Neovide is beautiful.
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.
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.
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.
> VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.
Please check it out — being able to edit / run / debug code on a linux server using a mac desktop over ssh, and having the whole experience be as seamless as edit / run / debug locally, is a huge win — it's pretty much _the_ reason that I’m currently using VSCode 90% of the time despite being a huge JetBrains fan (to the point of paying for their full enterprise pack out of my own pocket)
(JetBrains tools do kind-of support remote file editing, but it’s flaky and slow, and remote run / debug are a nightmare — compare to VSCode, where I sometimes mix up local and remote development because they’re identical except for the hostname in the titlebar when running remotely)
It also works on Windows through ssh (including desktop win10), which makes working with Windows easier on the nerves.
Is what VS Code does different from using an SFTP mount plugin like remote-edit on Atom?
Does a single text editor exist that supports both a TUI and GUI mode?
Textadept has both TUI and GUI, is Free Software, and runs on Linux, macOS, and Windows: https://orbitalquark.github.io/textadept/
The way it works is that its creator made a TUI implementation of the GUI library he used for the graphical version, so you have the same menus etc.
Emacs supports both a TUI and a GUI mode.
Vim/Gvim ?
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!
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.
How does it do in comparison to the other upcoming "better VSC"s? Like for example:
>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.
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.
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!
"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?
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.
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?
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.
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.
> 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.
Hmm, curious how this will compare to Jetbrains’ fleet editor.
Of course, they share the problem that I can’t yet use either :)
We're pure Rust and hopefully faster. But yeah, plenty of competition in the space!
I work on the linux kernel using CLion and the IDE is still fast. I would not be interested in a non-Java IDE for the performance.
Are you using 32-core / 100GB RAM monster machine? I do everything on my rather powerful laptop, but Jetbrains IDEs are just too much. I can't have more than one project open at time, which is limiting. I didn't try CLion, only IntelliJ for Scala and Rider for C#/F#, all on smallish projects and it will still take 3-6GB of memory :|
I'd be interested in even lighter than VSCode IDE ;)
I can easily open 20ish projects, but the experience is often still sort of sluggish.
Like, change a file outside of the editor, open it again, and it’ll sit there stuttering for a bit while it realizes the file is updated and it has to re-index.
It’s not the end of the world, but the experience there could be more fluid. Because you do this often (e.g. every time you switch a git branch)
I often have several simultaneous PyCharm projects open with separate completely introspected and navigable virtualenv's with lots of installed libraries, and also ongoing DataGrip, and at times CLion or IntelliJ sessions ... all the Jetbrains IDEs are performing quite well. At times running Docker as well. 32GB Macbook Pro M1.
Yeah I'm doing the same on an 2021 intel Mac, I love jet brains stuff!
I feel CLion latencies even on a much smaller project. Sublime Text is faster, and I hope Zed is near. I guess people have different sensitivity for this. It’s not about time waste, it’s just affecting the flow.
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.
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.
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?
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.
Fair enough. Hopefully when you're ready to work on accessibility in your UI framework, AccessKit [1] will be ready. I'm hoping to have usable Windows and Mac implementations by the end of this year.
Accessibility is a peeve of mine (for no other reason than sympathy). Thanks for your work on this.
This will be interesting.
For me Sublime seems to hit all the same spots without the web assembly plug in feature.
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.
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
Just make it keyboard centic. I don't want to touch the mouse.
Definitely a priority.
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.
> 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!
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)?
We plan to compile to WebAssembly that writes pixels to a WebGL canvas.
If you will directly write yourself everything to a GL canvas anyway, what do you gain by going through a whole WebGL dependency & context rather than just using a native OpenGL context?
This would only be for the web. Right now we're macOS only and target Metal.
I have to assume no-one in the team saw Pulp Fiction (1994) when you ended up picking up the name "Zed"...?
I think Atom was perfect, for what it's worth. I've always found it to be faster than VS Code.
What is the accessibility (for example for blind users) of your custom UI framework like?
Amazing! Sounds like a great foundation! Curious about UI execution in Rust
We plan to start blogging about this pretty soon.
Hi, when can we expect to see some first preview?
Great to see you've dropped Electron!
Any screenshots to share?
Here's a demo from a talk a give not too long ago:
https://youtu.be/wXT73bBr83s?list=PL3TSF5whlprXqwYNIM0X8mBzu...
first class VIM keybindings also please!
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?
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.
There is also NW.js (f.k.a. Node-Webkit), which was preceding Electron and was also a foundation for a lot of apps: https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companie...
Our goal is to build something substantially better than VS Code.
Can you be more specific about this, and what you're prioritizing?
Eg: Speed? Different UI layout? Fundamentally different design/UX philosophy?
What would you say are planned to be the primary selling points over VSCode?
From the other parts of the thread: Performance, maybe better collaboration?
Being honest, that doesn't sound too enticing.
Despite VSCode being an Electron app, I've never had any performance issues with it - really, it's a great example of how Electron can be done right.
On collaboration, I'm not sure what they might add that isn't already covered by GitHub/GitLab/AzDo etc. Again being honest, "collaboration" sounds like a weak Open Source pitch to VCs. I'd be interested in some details though, incase there is something truly novel here.
I do. I don't have a powerful laptop though. Whenever I open a new project I hear the cpu fan and cpu usage close to 100%, (TypeScript and ESlint are also a bit heavy and switching the app may not help with that). It's totally bearable though and as the years go by it will be less of an issue when everyone has a faster machine though.
The biggest performance improvement would probably be RAM usage. You don't notice laptop specs get more RAM. The usual options are still 8GB or 16GB. Until 32GB / 64GB is the new default, having a non-electron app will always be an improvement.
Personally I don't think it matters that much in the end, whether it is CPU usage or RAM, but if the editor was just as capable but faster, I'd switch. Code will never be rewritten from scratch and it will always be tied to Electron, starting a new text editor built with faster technologies could give a long-term edge the existing competitors would not be able to use.
I think that's a worthy goal. I find it really bad that in this age of super-mega CPUs apps still feel not much faster than say 20 years ago. The reason I think is because like cities apps are built on top of other apps, like VSCode on top of Electron.
Secondly when you re-create from scratch you can keep the best features and drop the ones we've learned are not so useful.
Godspeed!
Let them talk. You will do it no matter if they get it or not.
What is your definition of better?
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.
you don't need node.js/V8 for plugins
there is quickjs and some others, some of them are rust-based and all of them can run in wasm host
EDIT: to be honest, I clearly see where you are going with this and I agree :)
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.
How many times do you have to re-invent the text editor?
For the same reason people have and use many different tools in all sorts of professions.
I love Emacs and use it every day, but not everyone is up to the time commitment of maintaining it.
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.
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.)
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
“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.
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.
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.
The history of Zulip is one of my favorite counter-examples to this trend. They have seen great growth and success since spinning off from Dropbox!
Not really a counterexample as zulip started life *outside* dropbox.
I wouldn't really call Zulip a counter-example. It wasn't aband^H^H^H^H^H released to the community, it was spun off as a separate company. They offer paid products, have employees, an office in San Francisco, etc.
OT, but: ^W deletes a word, so you don't need to spam ^H. (Though it is a dangerous habit when writing in a browser tab.)
There are some things worse than death, like what MySQL experienced: being turned into a zombie designed to eat the brains and infect people who used to use it when it was truly free, all in the name of tricking people into switching to Oracle's expensive SQL server.
What? MySQL continues to work just fine. 8.0 (which was admittedly released two years ago) was the biggest release in ages in terms of new features and removal of things that should have been removed decades ago. Then there's MariaDB, which is named differently purely for copyright reasons and could be considered the 'real' MySQL (since its dev team are Monty and friends). I don't think MySQL came out of Sun's disintegration badly at all.
To be more precise: 8.0 finally has proper utf-8 out of the box, support for complex replication topologies (including multi-master), window functions, CTEs, etc.
MySQL has been and continues to be a major success for Oracle, and in 8.0+ and beyond the feature set, correctness, and performance have improved substantially; MySQL continues to evolve and currently is in a good spot. It is even more attractive in modern times thanks to systems like Vitess, which add major features (online schema change, excellent horizontal scaling) that give alternatives a run for their money. What are you even talking about?
Then explain MariaDB?
https://www2.computerworld.com.au/article/457551/dead_databa...
>Dead database walking: MySQL's creator on why the future belongs to MariaDB
>MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle
>It's fair to say that MySQL creator Michael "Monty" Widenius is not a fan of Oracle. When the company announced in April 2009 that it was purchasing Sun, Widenius saw a bleak future ahead for the (still) wildly popular open source database, which Sun had snapped up in 2008.
>The day the Sun purchase was announced, Widenius responded in the tried and true open source fashion — he forked MySQL, launching MariaDB, and took a swathe of MySQL developers with him.
>"Many of the original MySQL core developers, including me, didn't believe that Oracle would be a good owner of MySQL and we wanted to ensure that the MySQL code base would be free forever," Widenius explains.
>Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB
>Widenius and a number of other MySQL developers started a company, Monty Program Ab "to provide a home both for MariaDB — the new MySQL — and for all MySQL core developers".
>"Monty Program Ab is owned by the employees and uses the 'hacking business model' as a way to drive the company," Widenius says.
>Although MySQL is still widely used — Db-engines.com ranks it as the third most popular RDBMS after Oracle and Microsoft SQL Server, compared to MariaDB coming in at #35 — Widenius still believes the database has a bleak future under Oracle's stewardship.
>Oracle's treatment of MySQL and its community since its purchase of Sun has proved Widenius' original fears correct, the developer says. Not mincing words, Widenius says that Oracle has made it clear "that they have no love for open source, working with the community, or MySQL in general".
>Widenius cites as examples of Oracle's disregard for open source principles the September 2011 announcement of commercial extensions to MySQL, the bugs database not being public any more, and a lack of test cases for new code in MySQL 5.5 and 5.6.
>Widenius is also scathing of the quality of Oracle's MySQL development efforts. "Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB," he says.
>He also says that security issues are not addressed quickly enough.
>"Instead of fixing bugs, Oracle is removing features," Widenius says.
>"The MySQL documentation was never made open source, even [though] it was promised in the MySQL conference in April 2009," he adds.
>"Flagship features promised for MySQL 6.0 have never been released, even if they were fully developed and ready to be released," he says, referring to online backup for all storage engines and foreign keys for all storage engines.
>"Most of the original MySQL developers have left Oracle. Without people that can understand and explain the code it's almost impossible for Oracle to develop MySQL further even if they wanted to."
>As further evidence of disdain for MySQL users, Widenius cites what he describes as "sharp" increases in licence and support fees, a lack of an open roadmap and no way for the community to participate in the database's development.
>"Why is the price for a MySQL OEM license higher than for Oracle Express?" Widenius asks.
[...]
What exactly does these words prove? Monty has been known to shit on Oracle's efforts just because they are from Oracle, regardless of their quality (as do many others, proven by this very discussion). He's the head of a competing fork that they're trying to monetize, I would take his words with a shovel of salt.
The real problems with MySQL are:
- the bugs database is not public (as he's said)
- all development is going behind closed doors; MariaDB is more open to the public
That's it. Quality-wise it's better than MariaDB IMHO. And they pay more attention to low-level stuff that doesn't add too many new features but greatly improves things like reliability (such as rewriting the underlying InnoDB storage format). Although that one did introduce a significant feature (transactional and fully atomic DDL, which MariaDB implemented only partly and recently).
MariaDB has its share of problems. For example, they have exactly the opposite issue of what he's describing: in their first releases they've imported mountains of code from other MySQL forks without much testing (especially from Percona), things like Cassandra and TokuDB that went practically unmaintained for years and are now in the process of being removed. All to toggle as many feature checkboxes as possible ("look at how much shiny new stuff we ship!")
I personally don't use new MariaDB releases until at least their 5th or 6th patchset.
I also don't really understand this question:
> Then explain MariaDB?
Monty didn't want to work under Oracle. He left and started a competitor. What else to explain?
>2013
For a time it did seem MariaDB would replace MySQL. But your link is almost 10 years old and since that time MySQL has seen it’s biggest release (iirc ever) in terms of features and bug fixes. Meanwhile MariaDB and it have diverged and aren’t really 1 to 1 replacements as they were in 2014.
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.
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.
Then why did they say they are sunsetting it!? It's in the freaking article
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.
> 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.
Also, the core editor experience of VS Code, the Monaco editor, predated Atom by several years. It was used from the very early days of the Azure Portal and also in IE's Developer Tools. It didn't become "VS Code" until sometime after Electron stabilized out from under Atom, but parts of it have existed for longer than Atom.
Slack does not aim to build a superset of features of Atom.
IntelliJ idea also includes most or all features Atom does, but that does not validate this statement:
> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase
They both use Electron as their framework, but that's about where the code similarities end.
Electron could probably be described as "a big chunk" of Atom's codebase. The rest of VS Code has a lot of similar functionality to Atom, so calling it "a rewrite" doesn't feel that far off (except insofar as it was redesigned as well, but that's sort of semantics)
> 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.
If I remember correctly, Electron was made for Atom (by GitHub).
Atom Shell, which was renamed to Electron, was made for Atom. Electron is not Atom. They both use javascript, too, but that doesn't mean they share code.
from the article "This is a tough goodbye. 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."
Yes. As the comment you’re replying to said, “Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.” Code is no more a “rewrite of Atom that reuses a big chunk of the original codebase” than Slack is.
“both using Electron" refers to a period of time that occurs after "Atom has served as the foundation for the Electron" and my quote states that Atom -> Electron -> Spark
I'm not an expert on this at all, I'm just quoting, but Spark is being used rhetorically as if it's an outlandish to consider it to be a descendent
> 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.
I’ve never seen anyone actually using atom, so would hardly say it defined anything much less than the whole industry.
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.
> 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.
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).
Back in the day it also had decent PHP support (don't know how true that still is).
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.
It's only a retirement if no releases happen afterward.
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.
If the community actually cares enough, they can fork it and continue on with development.
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.
if you attempt to sell, or commercially utilize the atom name in a fork of the project, i can see why microsoft would stop you.
It's just a name, but they should be able to call themselves a 'fork of Atom'.
I'd expect them to put the project out to Apache pasture (Apasture?).
"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.
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.
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.
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.
Something as complex as a code editor will never be finished. There will always be new languages, new tooling, and better ways to edit.
Most real world problems have almost infinite demand for more and better software. The final text editor will be the one that reads the minds of the users and product manager and writes the code for you.
Sadly this is not the case for Atom. Many packages are just broken, half baked or missing essential features that their vscode counterparts do have.
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".
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.
No, they didn't buy GitHub to shut Atom down. But they did create VSCode to cut off GitHub's growing expansion of their business through Atom. They could have just extended Atom with Azure plugins etc, but instead they essentially forked it and poured tons of resources and hundreds of developers into it. That effort helped suppress the valuation of GitHub, so that they could buy it for cheaper (or at all?).
The revenue generating upsell for VSCode is already here and it IS GitHub Codespaces. They are going to add features you can't live without based off code synthesis (sky's really the limit here) and gate those off saying it can't run locally because it's too resource intensive. They'll charge you (or your company) by the second for all usage.
It would be much harder or impossible for them to do this if Atom and an independent GitHub had been further entrenching in this space for the last decade.
Many of the biggest developer tooling projects big corp are building now existentially threaten smaller developers and apps, by design.
Don't give Microsoft a pass here.
I'd be willing to bet that even if Microsoft did create VSCode for the purposes of cutting Github's expansion, the effect that VSCode had on Github's valuation is extremely overstated here. The total valuation comes from a range of factors, but let's say there are two major ones: number of users and number of paying organizations. The latter is almost completely not dependent on Atom (companies would not use Atom as a deciding factor to use Github) and while some users might use Github because they used Atom first, I don't think that this is large enough that the migration from Atom to VSCode negatively impacted the valuation.
I think a simpler explanation is correct: Microsoft saw that open source developer tools are gaining a lot of popularity and also knew that it could help revitalize/modernize their image, so they authorized the funding for the creation of a (mostly) open source code editor, and it gained popularity because it was good.
> If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure
This. Microsoft share price depends on the size of their recurring revenue from cloud. They can easily write off a few million on VScode for bringing more users to Azure
VS Code "Pro" is very 1998.
My money is on VS Code 365.
It’s already here. They went with the name GitHub Codespaces.
That is a very good analogy. Considering that Office was also an offline product before it became a cloud-subscribed web/desktop hybrid.
VS Code Pro already exists. It's called Visual Studio.
Despite the name, they have basically nothing in common. They don't share a user interface, they don't share plugins, they don't share hotkeys.
One of the main complaints many of the C# developers on my team have when they have to touch languages that aren't well supported by Visual Studio is that they don't know how to work VSCode.
They do share some plugins actually, that is why VS nowadays also gets a node instance running on the background.
And also why C++ workloads depend on .NET being available.
I'm well aware of the differences between the two products, since I use both on a daily basis. My answer was a bit flippant, sure, but they are both IDEs developed by Microsoft and Visual Studio is definitely the "Pro" version of the two.
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?
I’m not sure the term has ever been applied to Microsoft’s own products…
Atom was developed before the acquisition. Which brings us to the second proud tradition of the tech titans, acquiring companies to end the products the acquirer doesn't like.
Well yeah, if you have two very similar products (editors/IDEs based on web technology), one of them much more successful than the other, putting a lot of effort into the less-used product sounds a bit hard to justify...
Does Microsoft not "like" Atom, or has its market share dwindled to the point that it is no longer worth maintaining?
If you look at the contribution activity it dropped off after acquisition of GitHub by Microsoft and it seems that development was redirected to VSCode.
The writing was on the wall for a long while now, and was one of the reasons why the JuliaCommunity stopped advocating Juno/Atom as a platform and instead switched to VSCode
Probably a bit of both if I was to hazard a guess. MS has VS Code, which is definitely the elephant in the room as far as go to IDEs in the environments I’ve been in lately. So right now they’re spending engineering time on both VS Code and Atom, so they may as well focus their resources on the more popular one.
Look at the Atom repo, very few commits in the last year, and it's not like there are loads of open pull requests (serious PRs do get merged), and it's been strongly dropping off for a long time. It's the programming community that abandoned Atom, not Microsoft.
> Which brings us to the second proud tradition of the tech titans, acquiring companies to end the products the acquirer doesn't like.
Atom is inferior in every aspect to Visual Studio Code. Atom was on life support for too long.
it was dead already, or at least, shown inferior to vscode in feature set. If anything you can accuse MS, it's using its market position and the VS brand name to "steal" adoption, but that completed before the aquisition too.
But Atom isn't, is it? It was started prior to Microsoft, to which Microsoft bought Github, and are now "sunsetting". While i don't think Atom was enough competition to actually warrant any real discussion here, the timeline seems quite fitting to EEE no?
They embrace, extend, and extinguish products they don't make money on, so that people are forced to use products that they do make money on.
Microsoft doesn't make money from VS Code. Atom was retired due to a lack of activity with the project. I've never even seen anyone use Atom, since the time it was released 8 years ago.
Hence the parent comment:
> We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
I don't think it would serve their interests, so I'm not worried about it, but who knows? This cynicism is directed towards Microsoft because they've earned it.
Had two coworkers at my last job use it when they needed to edit some of our legacy PHP stuff (we were mostly a .NET shop) but even they switched to VS Code eventually because the writing was on the wall for support.
> Microsoft doesn't make money from VS Code.
They harvest an astonishing amount of data from it.
I'll go Nova before I go VS Code Pro.
"VS Code Pro" came out in 1997
Note that this will lead to unmaintained Electron Apps until at least 2032.
We're basically fucked.
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.
Sounds like premature optimization.
I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly, if and when something like this happens. And I'd say the risk of it happening in the next three to five years is pretty minimal at this point.
> I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly
Once you start making full use of your editor, switching to a new one and reaching the same level of proficiency takes a long time. I can edit code even in notepad, but I can't ever be as fluid in it as my main editor. I've changed my editor multiple times and it's a huge pain every time.
I don't know why Microsoft would do that - VSCode is HUGELY popular and at the forefront of Microsoft "I'm cool now guys!" 'open-source' movement.
> Contingency planning for this could be a small but wise time investment for dependent teams.
I doubt that switching an editor requires a disaster-recovery plan.
Modern tech companies love to look busy and find the most perplexing solutions for the most basic problems.
I guess they have lots of "solutions" to "design and implement".
I am sticking to my Intellij products for this very reason. They work great and the motives of the company are straightforward.
Same, but nvim
While any software can be cancelled, I'd say Atom is being cancelled because of investment in VS Code (both currently owned by MS), I don't see any reason to think it's "inevitable" that VSCode will be cancelled, except in the sense that eventually everyone dies and the earth falls into the sun.
> 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).
the normalization of this behavior within the industry makes using emacs or vim even more satisfying.
it's nice to having an unchanging cement foundation to stand upon once-in-awhile.
Absolutely. Why continuously reinvent the wheel when there are far more interesting problems to work on :)
:)
Why would this happen to VsCode? VSCode is a proprietary form of Atom is not? It’s hugely successful Microsoft would never do such a thing.
Sort of?
They maintain a trademark on the name Visual Studio Code and some other bits. And it is maintained by a Microsoft team.
But the code itself is MIT licensed. You can build it yourself. I have. There are one or two forks of it out there.
The codebases of VS Code and Atom are unrelated to each other.
Indeed. At least I’m not the first person to make this mistake
https://news.ycombinator.com/item?id=9872976
https://thenextweb.com/news/microsofts-cross-platform-visual...
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.
> 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.
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.
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.
All of the id Software code was release to open source essentially sunsett'ed. That was never a problem.
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
just fork it, no one is stopping ;)
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.
It's not an open source project - it never was, it's commercial, corporate project releasing code licensed as Open Source.
"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.
The project is not open source. The code it releases is open source. There's no contradiction - it's perfectly normal for a company to release their code under an open license; Chromium is another example of this. It's technically open, but for almost every practical purpose it could be closed and it would make no difference.
What you're trying to say is "I don't like the way it's run". Okay, fine. That doesn't make it "not open source".
I have projects where I don't accept patches. "It works for me" and I just don't feel like reviewing patches. Is that not "open source" in spite of being MIT licenced?
"I can do with the code what I want" is the entire and only point of Open Source and Free Software, something Stallman and many others have been pretty clear about over the years.
>"I can do with the code what I want" is the entire and only point of Open Source
This is not true at all, as evidenced by http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... You are mistaking Open Source for public domain.
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.
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.
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.
I completely agree, I'd rather have a memory hungry app than no Linux version at all. Slack is an odd one because you can run it in a browser, but things like 1Password are also good examples. I'd rather buy more ram than have companies pretend Linux just doesn't exist at all, at least it gives me options.
This so much. I'm not fan of electron apps, but it's 1000x better to accept the chromium memory usage than a Windows VM memory usage. And I think that sharing the code between web and desktop also gives us very usable web apps (at least in case of Slack).
It's easy to criticize tools that actually exist. Makes you forget about all the tools that haven't made it to your computer.
Are you kidding? It’s a chat client that works in a browser. About as Linux friendly as it gets.
That's just an example. You want some more? https://www.electronjs.org/apps
Not a very good one then, and never heard of any of those. The big ones like Slack do run in a browser because the whole point is to access an online service.
You haven't heard of Discord or Visual Studio Code?
Yes, the point of discord is to access an online service, which can be done... in a browser. Vs code does too, although a little different.
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.
Yeah I think I am in a similar camp. As a person involved in product development, I love the speed at which web technologies allow us to move.
As a computer scientist, I can't help but cringe at the massive amount of collective inefficiency in the current state of computing.
But don't get me wrong, I'd rather have the inefficient thing which creates value than nothing at all.
> 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.
It wasn't FOSS that settled on Electron - it was businesses and corporations.
Decisions were taken with an eye to balance sheets and P&L reports; Electron remains the cheapest option of them all, because the supply of moderately-skilled HTML/JS labor is naturally larger than for any other language - all thanks to choices the Netscape Corporation made in 1995, when they needed interactivity in their product and they needed it quick.
Businesses and corporations are part of FOSS. The majority of FOSS doesn't exist without them.
Yeah but that's not the whole picture - it's not just FOSS choosing Electron so much as platform holders being hostile to cross-platform development.
For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms.
Electron won because all the platform owners basically had to embrace the implementation of web standards on their platforms. So they couldn't prevent those tools from being used to deploy local software as well.
The absence of Vulkan on Apple platforms—something that it’s worth noting was developed after Apple’s Metal equivalent—is in absolutely no way even approaching a barrier to building a “native GUI framework”.
There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
It's just one example of an impediment. If all the major platforms used a consistent standards-based graphics API, you could have one implementation of the drawing layer shared between all platforms.
All these little wedges add up.
Electron piggybacked on the established (and enforced) open standards of the web to make up for a fragmented proprietary mess of software standards.
Indeed.
Imagine a world where everything had to be deployed to the JVM and all progress depended on Sun/Oracle. Or god help us, IE/VBScript.
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.
Yes. But in reality it was more "write once, debug everywhere". It was actually quite a nice concept, but the resulting UIs were inevitably clumsy and had that distinctive (ugly to me) look, no matter what the platform promised. If it doesn't look good out of the box, it won't look good later either.
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.
> there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001
Disagree with this. As a dev you have a huge advantage in that you can bootstrap a Saas or similar business cheaply. With the tooling and services available today you can launch quicker than ever before
If you can get a semblance of product market fit you can generate enough income to live off of. It’s not easy but it’s definitely possible.
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.
Minification helps the parser too, try running VS Code from sources and you’ll notice startup is significantly slower.
huh I would think there is no measurable difference there.
However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that
Without nonlinearities like optimization/type checking/etc, the runtime is basically just the time to loop through the bytes. Make the input a quarter the size and you have a quarter the bytes to loop through. College classes will say “oh it’s all O(N) anyways, no big deal”. Industry on the other hand says “why make tens of millions of people wait 4 seconds for this to start when we could make them wait 1 second just as easily”.
The product’s source maps are publicly available in a way the debugger understands and the original code is freely accessible so there’s no real downside.
My best guess is maybe faster hash-map lookups on variable names?
Minification also does some tree-shaking, which results in unused branches and libraries being pruned ( and therefore not needing to be loaded into memory ) and a smaller source size. Some constants can be inlined, which leads to faster execution times as there is no need to wait for a variable to be bound as its value is just written directly into the source everywhere it appears.
> 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?).
That’s more of a hack than anything actually serious.
Redbean 2.0: "more than a hobby project"
Category error. The creator certainly seems to be committed to putting this hack towards serious use.
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.
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.
I'd describe it, together with Docker, as good solutions for problems we shouldn't have anymore
Replace "good" with "mostly workable" and I'm on board
I was trying to be more agreeable but yeah, "mostly workable" is a better description.
one could imagine many things ...
Electron was originally known as "Atom Shell"!
Ha, that makes sense from a physics perspective as electrons orbit the nucleus.
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.
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.
Is it officially sunsetted? I can still see commits on Github: https://github.com/brackets-cont/brackets
Thank you for developing Brackets! I used it daily as a web dev, it had an awesome live preview feature.
Oh, that's a good point about the sunsetting. In Brackets's case, Adobe left it active in the hands of the community.
Live Preview in particular is one of the areas I had some fun working on. I worked out a way to do diff/patch to make it quickly and incrementally update the browser[1]
[1]: https://github.com/adobe/brackets/wiki/Research%3A-HTML-DOM-...
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.
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.
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.
Did my first ever paid programming work in Brackets, helping some friends build a Wordpress blog. Good times.
I still use TextMate, mainly for the excellent search & replace preview.
I do, it was quite cool! What stuck most with me is the CSS color picker.
I've used TextMate for a long time. It works great.
I was in TextMate all day every day for a long, long time but gradually shifted to Emacs, hilariously, AFTER I quit coding for a living -- because of OrgMode.
That is hilarious!
Right?
I mean, I tried to become an emacs person several times when I was still coding, and it just never took. My last phase of programming work was on OS X, so I had friendlier yet still capable options like TextMate, which made shifting to emacs a pretty hard ask.
Then my job shifted to a point where my preferred method of tracking activites/tasks/notes was just falling apart. I was all-in on the GTD-inspired Omnifocus, but what I really wanted was a system where I could intermingle notes with Todo items, and then ask the system to collate a list of the Todos for me dynamically.
Which, as it turns out, is pretty much a description of how OrgMode works. And, sadly, almost nothing else that I've found, and so I use emacs all the time now.
My emacs expertise, though, is pretty limited to things I need to know to be productive with Org.
Brackets came first.
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...
Also all have the same magnitude of latency and lag. At least you know if one of them bugs you, they all will.
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
I should have put the example I was comparing to: VIM. I like VIM as an editor because it's extremely fast and works well once you adapt to it.
I'm sure VSCode and Linear are fast, nice, and fine. I just hated the lag/latency compared to my terminal text editor.
A few Electron apps are acceptable. But it's still very noticeable how less responsive they are compared to Win32 programs.
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
> 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.
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.
Well perhaps. The main distinction that needs to be made is whether something is supposed to be a library or a final product. It seems to be more and more usual these days to blur the line between the two and it's making life worse for everyone involved. Libraries should not be shipped separately, no exceptions.
Even cases like installing the .NET framework or the JVM or some C++ redistributable are parts of that idea that leaked into the otherwise flat packed environment of Windows for example, and all I've ever seen it is cause issues due to version mismatches or them missing. Just completely self destructive behaviour in order to save a few megabytes... and not even that when in practice you end up with 14 installations of the same thing with different versions for every app ffs.
Android is arguably handling this way better, as such stupidity simply isn't even allowed there (to my knowledge), as are web browsers. Imagine having to install a chrome extension to use a site properly, people would think you're insane!
> 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.
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
> 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.
Fair! Maybe I should've said "got web apps as desktop apps to finally take off"
> 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.
> 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?
Interesting! I hadn't heard of brackets before.
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.
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
> 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.
Though why does it need to be in your editor vs some command line tools or something else?
So you can deploy at a moment's notice. Why run a command instead of hitting a key combo? Or even deploy as soon as tests pass?
Software should allow that. Especially software for writing other software.
Or just run a command with a key combo. Or setup your test script to run a command afterwards. This is what every IDE is doing in the background.
Then we tell the new upcoming developer that the hard part is setting up your tools. How long will this take? He asks. Oh, you answer: This will take decades! It's a wild, every man for himself kind of ride. You build a battle-royal out of abandon-ware plugins that each almost do what you want until your powerlevel finally rises to the point you just delete everything and use the terminal. The terminal is an emulator that mimics a physical device from 1941 you see, as its a physical device, there are no ever-tinkering developers bloating or [indeed] sunsetting your tools. You will finally be left alone, still in the dark but you get a cursor that no one can take away from you.
Sorry, “weird pattern” was a poor choice of words. I just meant that it’s an approach that isn’t common so it’s understandable that VS Code can’t handle it well.
VS Code is best when it’s just an IDE. I even have to drop into the terminal for some Git stuff
Yeah almost an anti pattern.
No almost about it, it's an anti-pattern and I personally would consider it a "worst practice". If you're deploying from an IDE it means you lack visibility, feedback, and automation fundamentals. What I do like is developer ownership and being able to see a change all the way through to production but having a system of record without manual intervention is always preferred.
It's always so interesting to see people who have no concept of your stack/problem-space speak so confidently about what you must be doing wrong.
I don't know if you've just chosen to assume the worst or don't care enough to think about it for more than a second but I've been very clear in all my comments that these are developer-specific machines we are deploying to. It's literally no different from running VMs on your local machine. There is full visibility and feedback, we aren't deploying to Prod or even QA, this is development where each developer has 2 or more boxes owned by them and only them. We also are working with specific custom hardware that our code runs on which is one reason we can't easily do this locally.
To jump in and call that "worst practice" is just lazy and condescending. On top of that, it's completely wrong.
Your aversion to running shell commands is definitely not helping you and what you're describing definitely doesn't need an IDE to be done so it's not shocking that people are questioning how familiar you are with deploying code and/or leveraging shell programs.
I'm tiring of this thread.
I never asked for or requested input on how we deploy code/manage our servers. I was asking questions about an IDE vs vscode and gave 1 example of trying to do the same thing in both of them. Had I known so many people would come out of the woodwork to tell me I'm doing it wrong without any idea of how our stack works I wouldn't have mentioned it.
I have no aversion to running shell commands and you are being disingenuous by saying that. I have a problem with manually doing a step that I can automate. I write and run shell scripts all the time for one-off process but seeing the code I've actively writing in an environment that can run it is not one of those cases. In fact, anyone doing that manually is just being silly or obstinate. If you aren't automating something that you do 100's+ times a day then I question your skills.
We have an entire industry, devops, that opposes this world view. Manual processes, snowflake developer machines, not testing the deploy piece as part of the process, throwing code over the wall for others to validate. I'm not trying to be a jerk, these are just well known and well documented anti-patterns.
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.
I'm cautiously optimistic for https://www.jetbrains.com/fleet/
I just got access to this the other day and I'm excited to try it out!
My initial experience loading a python project was disappointing. I don't know if I didn't configure it right but auto complete and syntax highlighting didn't seem to work properly.
Isn't it just a frontend with the actual language servers and the whole IDE back end running somewhere else? At least that's what I thought it was from their announcement. Sort of like GitHub codespaces
Depending on the language (I've seen it in Rust and Deno), VSCode has inline buttons that appear over individual tests to run them
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"
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.
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.
But aren't you executing a task either way? Either running a script, or executing a command through Ctrl/Cmd+Shift+P, you have to do something to deploy.
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?
Ahh, I see the disconnect.
I set it up to deploy on save of the file or when the editor loses focus (when it auto-saves). So while you are correct I have to do “something” to make it deploy that “something” is either a hot key or me clicking out of my editor into the browser to refresh the page (talking about PHP here, all my frontend Vue work I do locally with a watch script to rebuild on changes).
Fair, that's more or less equivalent to a task runner watching the files. I'd recommend that approach only because it decouples the action from the editor. As long as the file changes, it executes.
I do the same with inotify tools and an alias or makefile. A simple editor like Geany can save on focus change.
I generally make a "run.sh" script or Makefile to build and deploy. Then it's just a few tappity taps in the terminal to run it again. Still not as good as a "play" button, but easier to set up in many cases.
Remote ssh to dev server and develop directly there using vscode man.
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.
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?
I wrote Java for multiple years in vim with no extensions installed.
I don’t think that is smart
I was more productive than I suspect someone with just an IDE would have been, considering the volume of complex non-coding issues I needed to learn about and solve.
How does spending your time learning about things an IDE would have avoided make you "more productive"? That's a pretty clear cut argument that you were less productive as you were doing things manually a tool would have automated. Thereby spending time being unproductive.
Because an IDE doesn't always (or even usually) avoid those things, and I don't consider learning time to be unproductive if it means in the future I'm more productive.
It's a pretty clear cut argument that using an IDE as a crutch will inevitably bite you in the ass, and if you want the best possible understanding of the language you're using and all of its related tools you ought not use an IDE as it obfuscates those very things you're trying to learn about.
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.
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
VS Code and Vim have intelligent autocomplete for C#, although Vim requires significantly more configuration to get it working.
.NET Core and beyond yes. For older .NET you really need classic VS or you will probably have a bad time.
> 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.
> 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.
> 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.
VSCode has been working just fine for me for the last 5 years. Not sure what you mean by "keeping it working." I program in C/C++, Rust, Python, Go, TypeScript, JavaScript, and Java. Never had a problem that made me bang my head against the desk.
> 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.
An editor will generally not stop working like a car without oil. But, IDEs may stop working due to more complex configurations and disparate use cases.
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.
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.
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.
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.
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.
Ah, a fellow full-time vim user. There are dozens of us!
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.
Oh, I do the same. Coding in vim and debugging in vscode. The GUI and mouse support is a better experience.
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.
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)
https://code.visualstudio.com/docs/remote/remote-overview
far better and faster than sftp
I looked into that plugin but we don't run any special daemon/server for editing on our servers (nor do we want to).
It's utterly life-changing instead of editing locally and using scp/sftp/unison to sync to the server. The "special daemon" is entirely transparent, the only requirement is ssh.
We're also talking about a dev box here, are we not?
Maybe don't edit on a server. Have you heard of git?
There is no need to act like this.
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.
I’d write the SFTP stuff as a script and invoke it as needed via a VS Code task.
I have a few workflow-type things like this that I normally do via the CLI, but now I’ve added them as tasks to VS Code for convenience. I can also create the task at the project level and check in the JSON config so that teammates can use those same tasks.
+1 for remote ssh. If you can SFTP to the box you can use this feature.
The only possible wrinkle is the developer box needs the build toolchain. If you're writing python, your remote box obviously already has it to run your app. But if you're writing Rust or golang, it's very possible the remote machine doesn't have the compilers.
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).
FYI you can drag anything from the sidebar to the bottom pane. It's not much, but can help with the overloaded sidebar.
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...
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.
Depends on the language LSP. From my experience, it works VERY well for JS, reasonably well for Go and not that well for python. Python allows you to refactor variables if it knows the scope of it but won't work if you use star imports and moving files doesn't work at all
It all depends on the language plugin. rust-analyzer can do a lot of this stuff, I haven't seen much of it for TypeScript (though you tend not to need it as much in more flexible languages), not sure about other languages
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.
> 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.
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.
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.
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.
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...
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.
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.
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.
> setup deploys to a dev server from vscode
What does this mean? Setting it up so you can deploy through GUI?
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).
It sounds like your development flow is a bit unusual nowadays, which could explain why no one bothers to maintain such vscode plugin.
I have to agree. I'd rather open the terminal and do a git push or otherwise run a command rather than having every save get deployed.
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.
You're a brave man for asking this question!
> 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.
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.
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.
> 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).
I'm probably going to give Sublime another try.
For one, I'm finicky about colors and VS code makes it easy to tweak one or two colors of a theme without getting involved in forking and creating a whole new theme. I may just do it, though.
Also, I recall having some issues getting linting to work and the editor highlighting lint errors in not-very-visible ways (like the first character of the line had a red underline).
Again, it's been a while and these could be issues I had with ST3 and/or I missed the way to fix it.
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.
VSCodium exists which is VS Code without the Microsoft "added features" (telemetry etc.) which sounds like more what you want.
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.
If level of customizability is your main metric:
Emacs can go from this: https://emacshints.files.wordpress.com/2013/09/spash1.png
+1 for nano-emacs
VSCode killed Atom long before GitHub acquisition.
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.
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.
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.
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
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...
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.
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.
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.
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
Watching your "Hide all the crap" gif made me realize you could do this:
> View: Toggle Activity Bar Visibility
Much nicer, thank you!
I'm not the author of that webpage or e-book, but the e-book has a looooot of other good information like that.
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
Same here. I've tried VSCode multiple times but still switched back to atom. Just FEELS RIGHT.
Yeah, have the same relationship, wish a UX expert could explain why my psychology is different with Atom vs VSCode
So this would be slightly different than embrace, extend and extinguish (EEE). This is acquire, substitute and then sunset (ASS)
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!
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.
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?
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.
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.
And then you spend an hour figuring out how to configure the extension, and it's still clunky.
I like VS Code just fine as a text editor, but as an IDE Visual Studio is so much better, even for CMake projects.
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.
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.
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.
Atom to me was always "toy version of Sublime Text for web dev hipsters".
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.
Eh VSCode killer atom long ago.
What other editors are better and could be recommended? I guess I'm replacing Atom today
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.
Vim, emacs, sublime, vscode, notepad++ there are lots.
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)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.
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.
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
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.
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.
Every now and then I’m reminded of why I decided to stop chasing the shiny new and just go back to emacs.
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.
Yeah. Which Linus uses, so probably works well enough for all non UI work whatsoever. Except maybe SQL?
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...
Atom was great, but I'll admit that I'd forgotten about it entirely.
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?
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.
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.
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.
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....
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] ?
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.
> 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.
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?
I'm in the same boat and look for a configurable text editor. I have Sublime, but haven't used it much, until now.
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.
They continued for 4+ years. That's not lying, that's time passing.
What's the amount of time that divides lying from just time passing?
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.
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.
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
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.
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.
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!).
impotence means powerlessness or inability; the state of lacking potency. It's usually used to refer politely to erectile dysfunction.
Perhaps you meant impetus?
Lmao, you're right indeed. My mistake!
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.
Maybe I’m misremembering but didn’t VSCode begin as a fork/skin of atom?
Atom created Electron, VS Code is built on Electron
No? It did use Electron though (Atom Shell).
Yup. My mistake https://thenextweb.com/news/microsofts-cross-platform-visual...
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.
Yeah, overall UX of VSC bothers me next to Atom and I can't explain why
Really begs the question what Visual Studio Code did right and what Atom did wrong.
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.
Third, for me at least: Remote Extensions. That suite of extensions including SSH WSL, and Container support made things I was already doing frictionless.
Integrated terminal from the get go, built in git interface, and the latest live share.
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.
(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.
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.
> 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.
I mean that Microsoft's acquisition of Github had nothing to do with Atom whatsoever (I assume), but the acquisition was the final nail in the coffin for it.
Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.
Chronology. VSCode ate Atom's lunch before MS purchased GH.
Glad to see that someone remembered FreeHand. It was much better than Ilustrator, this is why Adobe killed it.
I don't know what's worse, that Adobe would do something so shamelessly anti-consumer and anti-competitive, or that the FTC did nothing to stop such an obviously bad acquisition.
Today we can clearly see that as anti-competitive and anti-consumer acquisition, but at time, I guarantee you the FTC saw the agreement as business as usual, since it does not know how to regulate tech companies even today.
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.
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.
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.
LSP, better performance, better defaults, better plugins ecosystem, better (subjectively) UI.
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".
What recommendations do you all have for alternatives?
~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.
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).
Sublime Text
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.
vim -> Sublime -> Emacs -> VSCode -> Emacs ^^^^^ I am here.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.
I've tried, but it's still a little immature for me. Definitely an interesting idea worth exploring more.
And the reason I went back to Emacs is because of elisp and M-x. Those are the true killer features of that editor, still unrivaled.
Yep. I am waiting for its plugin support to come out to start really using it but I have it installed and I use it from time to time. It is pretty nice!
vim -> Sublime -> vim -> Emacs -> vim -> VSCode -> vim ^^^ I am here.My path:
Sublime -> Atom -> Vim -> Emacs -> Emacs -> Emacs -> Emacs
and then vim again. It will come full circle :)
vim bindings in Emacs. :-)
I end up with vim bindings in VSCode at the present. It doesn't do everything but it does most things I want. There is neovim integration, but last time I tried it there were a bunch of glitchy things that didn't work right (I remember selection being buggy but I can't remember the specifics). Maybe I'll have to give it another whirl.
I went for evil-mode for a while, then I decided to just go full Emacs. I still use vim sometimes, but I've come to enjoy the Emacs bindings.
Now I just need to install keymapper and convert all my M-w and C-y inputs to Ctrl-C and Ctrl-V.
vim bindings in Emacs are so great that when something isn't implemented properly (eg. editing macros, global marks) it hurts so much more.
Why use and editor when you can use an operating system? Really love all the editing options. It's a good time to be a developer.
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.
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.
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.
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/
I bought and really wanted to love Nova, but I just didn't. It's so clunky compared to ST.
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.
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…
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
I like brackets but always ends up in VSCode due to extensions.
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.
My even dumber reason 5 years go was sublime's extension system at the time didn't allow styling of the file explorer, so git status wasn't available.
The entire editor being easily tweakble is the killer feature of web-tech based editors.
Sublime may have opened up more customizability since then...
It's amazing how much a minor annoyance can drive someone to a completely different solution.
A minor annoyance that happens often is actually a huge problem. I think we as engineers understate how important these little, often UX related issues really are because we understate how important UX is overall.
Ctl-Shift-P is used in VSCode as well as Sublime. And then, "Install Package"
Or through the Gui - "Preferences --> Package Control"
Sure, I find that every time I google for how to do it :-)
In VSCode, I can browse info about packages without having to remember a thing aside from "one of the six big icons on the left is 'Extensions'". One mouse click, start typing, click anything that looks like it might be good, get a ton of info and an "install" button. There are filters! So I can simply sort by "most popular" if I want, or by name, or a bunch of other things, all without having to remember anything for this somewhat-infrequent operation, because it's in the GUI.
It's mainly the integrated package exploration that's missing. And the auto-suggestion for plugins—in fact, I rarely have to do any of the above, and just click "OK" to whatever VSCode suggests, and everything's fine.
Sublime has (I just checked) a "package discovery" command, which... opens a web browser, to the exact same page you'd have ended on if you'd started by just googling it (which is what I do). So you have to find what you want on there, then go back to Sublime and find it again.
The result is that in the best case it takes me 1% as long to install what I need on VSCode (just click OK), and worst case it takes me perhaps 50% as long, compared with Sublime. I'm also way less likely to go poke around and see if there's anything that might be useful, in Sublime.
[EDIT] "Why aren't you way more familiar with the command palette?" ephemeral shells as anything more than dead-simple launchers make me really uncomfortable. I hate using them. Apple spotlight? I use it extensively—only for launching programs, period, nothing else. I'd much rather have a persistent shell environment I could attach from any terminal and leave open.
That's super fair. I'll admit I'm entirely in the same boat - if nothing happens on a new tool when I type Ctrl-Shift-P, I usually just shrug and go back to using all the other tools I have that do that.
I do love the fact that, with Sublime, that 75%+ of the time when I want to do something, say, pretty-print a JSON text document, it's just:
Ctl-Shift-P, "json" (Don't see anything obvious) [hit backspace to clear json] "Install Package", "json" See the "Pretty Print" option, install it in 2 seconds, and on my way.
Brackets in nearing end of life or is already at that point. Adobe announced it a while ago.
https://news.ycombinator.com/item?id=26341931
Just found this. It’s a shame. I donno why but I just liked brackets interface.
In this case a community of devs seem to have picked up the code base, forked it, and is actively developing. So its not exactly dead.
Oh that’s cool. Maybe that will happen with atom too.
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.
I think the reason it's unused these days is because it's largely been replaced by vscode
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.
https://github.com/lapce/lapce is slowly becoming my favourite editor specially for writing Rust.
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.
VSCode seems to be the go-to for most.
I don't know why anyone would ever move away from Sublime Text in the first place.
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.
Sublime Text has never came close to dying.
It was only adderal driven developer crowd making mountain out of a mole because they felt uneasy their frigging text editor hadn't been updated every other week.
Ha. Fair point!
Proprietary? Lack of quality plugins?
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.
WebStorm and the rest of the IntelliJ suite
BBEdit.
VSCodium
Sad day! But VSCode ate it up. Whatever one might say this had a huge hand in making Electron mainstream.
Atom did much more than help make Electron mainstream. Electron was actually born out of it: https://www.electronjs.org/blog/electron/
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.
> 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.
Microsoft kills another great open source project. This is sad. Don't rely on Microsoft.
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.
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?
3rd actually, Sunrise was a fantastic calendar app. Microsoft is a blight on the world.
Thanks!
Sometimes it feels like I live all alone with my hate for Microsoft/Gates, but I'm glad I'm not alone.
Really?
It's hard to find anyone who'd say they overall like Microsoft as a company. VS Code is one of the very few things Microsoft has made that people actually like.
I recall reading a comment here recently that they've actually create an entirely new generation of children who hate them by recent changes to Minecraft. Supposedly they forced everyone to migrate their accounts to Microsoft accounts, and in the process wiped a bunch of save files.
Microsoft happens to every generation at some point!
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...
Atom might be retiring, but One Dark lives on in every other editor.
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:
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.
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.
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.
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.
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.
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
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).
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...
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.
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.
Does anyone know the current status of https://zed.dev/, the editor by former Atom devs?
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.
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
The founder is in this thread, stating they just started an alpha release: https://news.ycombinator.com/item?id=31669615
We just started a private alpha this week! Lots of news and more public facing information coming soon.
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!
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.
Just a noob here, but I love the way Atom displays and handles merge conflicts; still my editor of choice when I rebase / merge.
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
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.
I really liked Atom for non-code editing as it is usually much faster than VS Code, so this is quite unfortunate news
If you are working in markdown, there are a good bundle of other options too.
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.
Kraken, the company behind https://cryptowat.ch use the following cross-platform GUI library for Rust https://github.com/iced-rs/iced
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.
If i had a dollar every time a developer said "we're going to get it right this time"...
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.
Atom has been in my choices, but actually, many development metrics of atom/atom is growing down: https://ossinsight.io/analyze/atom/atom
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.
And here we are with vim and emacs still being updated and improved. Good job Bram and John.
Well, they managed to drive it much longer than I expected after GitHub's acquisition.
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?
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.
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
Another editor bites the dust - another reason to stick with Emacs
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)
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.
I’m old enough to remember when microsoft said that atom developmennt would continue alongside Visual Studio Code after the company bought github…
Vscodium + LiteXL[0] replaced Atom + Sublime for me.
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....
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.
I tried "hacking" on Atom recently for a side project and found it was full of bugs and not performant at all. Next.
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.
I actually used atom for a while, it was a bit bulky but not terrible. I had forgot that it was an option.
I hope the main thing you leaned is that people want a text editor to start up in less than a second
Great, they couldn’t monetize a fucking IDE. I will say without shame, I fucking hate Microsoft.
Super sad, atom's column editing still rocks. are there alternatives for vsCode?
LOL this is why you just use vim/emacs/bash and move on with your life.
Ban me or whatever but Bill Gates is coming after your sperm, retards.
Glad that sunsetting of emacs is not going to happen any time soon :)
Nothing make me more happy than programmer nerds bitching on HN
Who didn't see this coming after Microsoft bought GitHub?
RIP Atom. I wrote a lot of code in Atom back in the day.
I subscribed to WL, free me from my laggy VSCode pls
VSCode ate everyone's lunch. It is SO GOOD
sad to see it go vscode? i've been trying to avoid it
Translation: 'Extinguishing Atom Text Editor'.
Really expected and unsurprising.
It took longer than I expected.
Wow! End of an era!
Is Julia's Juno IDE going to be affected by this?
No, because they already transitioned to VS Code years ago.
Embrace, extend, extinguish. It's in their DNA.
who was using it anyway ?
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
"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.
>JS minimalist
I mean, just that phrase sounds very "Williamsburg corpo-hipster" to me. Minimal, artisan javascript.
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
So MS owns the default place where code is hosted, and the default tool people use to edit code. Neat.
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?
I guess I would vastly prefer an organization which is not one of the tech giants.
Facebook/meta seems horrifying. Some of their tools are indeed great, but I can just imagine having to use a facebook login to push code to GitHub or to download VSCode plugins.
Amazon is problematic for similar reasons as MS: since they are one of the biggest application hosts out there, bad incentives exist in terms of potentially allowing biases in their tooling to preference their own platform.
Well, Microsoft has always been about developers, developers, developers...
Cool and normal.
* Textmate & BBEdit for people who were using Macs for development before they took over the tech industry.
I’ve “just” (as in: a couple of years ago) switched from BBEdit to Atom for my Python development, and now this.
All 3 of them?
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.
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.
> 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"...
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.
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
This makes me feel conflicted.
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.)
Only the lack of slurs reminded me I'm not browsing /g/ in the moment
VSCode is for Xbox gamers.
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).
Can confirm. Also that git integration that everyone talks about in Atom is built right in.
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).
I disagree with these labels, I would say the choice of editor is more religion than politics.
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.
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?
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.)
> 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.
I think this is what vscode does as well. The magic is in how it cooperates with the GUI. All jumps and movements work, as well as search/replace and the hilighting and selections are even the native vscode hilights and selections so it's fluid going from mouse to vim and back. Last time I used Sublime (4+ years ago) there were a bunch of vim commands that didn't work.
Hermione Granger - muggle born with vested corporate interest
> emacs and vim for the wizards and furries
…respectively? TIL I’m a furry.
Now all you need is a nice comfy pair of programming socks.
And sandals to match :-D
Anyone else use Notepad++ ?
Why not?
Occasionally
No 4Chan tier comments here please.
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.