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.

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.

Maybe it's just me but I'd not judge things like that on the first non-public beta.

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.

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.

https://www.videospeedup.com/

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?

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)

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?

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.

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.

Approaches like yours are why people who are differently abled feel left out and like second class citizens a lot of the time.

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. :)

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.

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.

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!

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.

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.

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.

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.

EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist

For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!

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.

LOL, as if Firefox provided a stable API to extensions

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.

If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.

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!

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?

Man that felt a bit like extortion, but I mean well.

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

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.)

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.

fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.

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.

Let me introduce you to Emacs, vim, Sublime, TextMate, ...

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

Sublime has ongoing development on https://www.sublimetext.com/dev and the last major release (4) was just about a year ago.

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.

Everything works just the same, and I don't get the purchase pop-ups.

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.

That's not the point, we were talking about 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

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.

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.

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

Or, you know, you could just click on the File menu and click on Quit.

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-`

and in Vim, there is no such display.

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.

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?

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.

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.

With emacs this is a feature, not a bug ;)

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

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.

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.

I actually use VS Code as well, but more like an IDE with tons of extensions, and Sublime is my 'basic' text editor.

I ended up purchasing the upgrade to Sublime 4, definitely worth the price.

While Vscode is my IDE now, I definitely love the instant-opening of Sublime.

Ironically, it's even launching faster than TextEdit.

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!

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.

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?

Why does this matter? What is the point of saving RAM instead of using it?

Thanks for the tips! I love HN.

P.S. Any other plugins, tips/tricks you recommend for a vim user jumping into NeoVim/LunarVim?

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.

Jesus, who are you?

- 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.

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)

* 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?

- 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.

Bare metal thunder

"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.

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'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.

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.

[0] https://www.construct.net/en/blogs/ashleys-blog-2/simple-sof...

1 - https://nativeshell.dev

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.

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've never been impressed with native UIs in any platform, web or mobile. The only context where I appreciate them is accessibility.

Best wishes for Zed's success!

Not sure if Atom was a fruit that grew into an orchard or a seed that grew into a garden. How about both?

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.

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.

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.

Looking forward to its spiritual successor!

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)

What will undo be like for a collaborative editor?

I hope you would have some solution to this conundrum.

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.

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?

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

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

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.

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!

Very excited about where this new collaborative editor goes!

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.

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

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.

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 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)

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.

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!

https://v2.onivim.io/

https://helix-editor.com/

>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.

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.

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?

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.

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

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.

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

I'd be interested in even lighter than VSCode IDE ;)

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)

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.

[1]: https://github.com/AccessKit/accesskit

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

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

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

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

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)?

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

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?

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.

Eg: Speed? Different UI layout? Fundamentally different design/UX philosophy?

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.

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.

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!

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.

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 :)

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

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.)