Kinda wild to me that people who frequent a website that bills itself as a site for news for "hackers" show such a nil-level of ability to comprehend anything themselves.
This website allows extremely vituperative people to make their points without being banned as long as they follow the rules. My account being the primary example.
That this website is littered with retarded morons that cannot handle the slightest bit of pure direct argumentation is more a function of the times, where heavy-handed moderation fills in for massive gaps in their vacuous perspective, which in any other situation completely undermines one's understanding of the world outside a pseudo-intellectual bubble.
The moderates here do better than any other online, IMO. And I say that knowing the moderators here do not unflag some of my comments because it's ideologically inconvenient to them personally.
At the time you posted this comment, there was no link to the home page for mobile devices. Also, on mobile devices it's a pain to edit the URL in the address bar. You could have gone to the About page, but there's no summary. You'd gather right away that this was about an editor, but you'd have to read quite a bit about history, goals, etc. before you find out what differentiates this editor from any other editor.
- Move your mouse cursor to the "Zed Industries" icon in the upper-left-hand-corner, then click.
- This "hypertext link" will instruct your browser to load the site's root "index.html", sometimes known as a "landing page".
- The "landing page" is a great place to start if you're unfamiliar with a site or product! Here, you'll find the following text prominently displayed:
"Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter. It's also open source."
Some troubleshooting tips while dispensing dickface advice:
There is no such logo.
(If there is for you, good for you. Some information for you, different browsers get fed different content, iyt's a new thing that only started around 1993 so I can see how you weren't aware.)
Actually there is one, 7000 pages down at the bottom, embedded in the footer and not looking at all clickable.
The logo in the top left leads to the startpage, explaining what zed is:
[..]Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter. It's also open source.[..]
Not sure if I should care, but more fast modern editors are good. But if they only just now got linux-support, then I think they will still need much much love to reach a good shape.
The logo in upper-left links to zed.dev, if that's what you mean.
This is not always great for accessibility (they don't have alt=, title=, or aria-*= attributes on the <a> or <img> tags) but seems to be a common pattern.
>Yup, that's a native file dialog, but we don't use GTK in Zed and that clearly is GTK — so, how does that work? You'll find the answer in the companion video in which Mikayla and I dive deeper into this and also touch on the question of whether or not we should use GTK or Qt or something else (spoiler: it's complicated).
Unless I missed it, the video doesn't actually answer the question. They talk 38:50 onwards about how they don't want to pull in GTK / Qt as dependencies, rather they just want to be able to read the toolkits' config and render a mimicking UI themselves. Then they show the editor opening a "native" file dialog, but don't actually say how exactly they did it.
Anyway, I assumed they would use xdg-desktop-portal, and based on searching the repo that does seem to be the case.
Yep! That's how we did it, with the heavy lifting done by the delightfully named "Aperture Science Handheld Portal Device" crate: https://crates.io/crates/ashpd
Yes, xdg-desktop-portal is a standard dbus interface. The interface covers file picker, print, screenshot, screencast, etc. The implementation of the interface (the "backend") is expected to be provided by the desktop environment in some way that makes sense for that DE. So gnome has xdp-gnome, kde has xdp-kde, etc, and there are some like xdp-gtk that are DE-agnostic but toolkit-specific.
Backends can implement a subset of the interfaces, and xdp can be configured to try multiple backends in sequence until it finds one that provides the interface that the application wants. Eg xdp-wlr for wlroots-based Wayland compositors only implements compositor-specific interfaces like screencast, so users would chain it with something like xdp-gtk for other interfaces like file picker.
Native applications usually use their toolkits' API for showing file picker dialogs etc, and xdp's file picker interface is primarily used by flatpak applications since that is a way for sandboxed applications to read/write outside their sandbox. But it's not impossible for native applications to also use it, as zed is doing.
Yeah, there are some caveats to using desktop portals this way, but at least it'll usually give you a native dialog. I do wonder what happens on a machine with no desktop portals, though. I suppose in the future it probably would be feasible to implement a decent file picker directly in GPUI as a fallback, so it's not that big of a deal; I reckon they could make one that's more usable than the GTK one anyways.
If you want a GTK-based IDE experience there's always GNOME Builder. Like other modern GTK apps, it actually works quite well with custom GTK themes which provide a Win9x-like look (see the chicago95 and b00merang projects on github) if you want the better usability and higher information density that this enables.
Partially because Kvark, who has a long history in graphics programming, was enthusiastic about it, and has similar values of simplicity and effectiveness to our own. Mainly because our renderer is simple enough that we would have preferred to use Vulkan APIs directly, rather than going through wgpu. Blade is a thinner abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and it already supports our long term platform goals (Linux, Windows, and the web though via WebGL). So far, it's been running flawlessly, and it's been everything else that's the hard part!
wgpu (and webgpu more generally) is often presented as a very good choice for a cross platform low level graphics api. but it was designed around safety/security constraints to support the web, sometimes at the cost of performance (my understanding)
i heard somewhere this nice example: only big actors like AAA game engines would really benefit from the extra development effort it would take to use an even lower level api like vulkan/dx12 to squeeze the last 10% of performance that wgpu can't get you
so if i understand correctly, zed, just like a AAA game engine, wants to squeeze every last bit of performance from the gpu, and so wgpu is "too high level" for it? and blade is "like wgpu, but no design tradeoffs and lower level" so its a better fit? does that mean someday zed might reach for vulkan directly one day? im assuming dx12 is gonna be used on windows anyway?
Roughly yes, though I'd caveat it with the specific application of the GPU: simple, 2D, UI elements. We've already built an abstraction that allows us to fluently build up a design, and then burn it down into a collection of rectangles, paths, images, and such. We're not dealing with particle effects, lighting, 3D models, or anything else that game engines need to consider. As such, it's a lot lower cost for us to use something like Vulkan or DX12 directly. And, in fact, that was the backup plan if we didn't find something like Blade that we where happy with.
The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.
> The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that.
The page you linked clearly states that wgpu-hal's API is extremely unsafe and skips many checks in order to reduce overhead. So while "secure and sandboxed" explains why wgpu wasn't chosen, it doesn't explain why wgpu-hal wasn't chosen.
> On macOS, for example, Zed makes direct use of Metal. We have our own shaders, our own renderer, and we put a lot of effort into understanding macOS APIs to get to 120FPS.
So they are taking the exact opposite approach of Electron (VS Code).
In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written.
Because Macs are expensive (in absolute terms) Mac users are a self-selected group who are willing to spend money. Linux users have high standards and are not willing to spend money. For a text editor in particular Linux is going to be the toughest market because it's already pretty saturated.
Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.
Well, that is usually refering to some form of "simulated fluid motion", not new characters appearing and disappearing. The only case where that kinda fluid motion would matter is when you have text scrolling by at semi-fast speeds.
I count myself among the people that would consider >60hz necessary.
For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)
I've had the privilege of using a merely 90Hz display and the difference is still incredible. It gives me input feedback much faster so my brain does not have to do as much buffering/prediction, everything feels a lot more direct. One would think a measly 5 milliseconds wouldn't amount to much, but for input feedback it absolutely does.
I do not suffer from nausea or motion sickness of any kind arising from computers or visuals in general, but I can still easily tell the difference between a 60Hz and 90Hz display. A few months ago I had the privilege of checking out the 120Hz displays on the new MacBooks and they're amazing.
I'd still say that draggin a window would count as a "simulated fluid motion". Maybe not something you'd immediatly think of, but its still trying to convey the sense of motion. Just text appearing and dissappearing isn't something I personally could categorize ass the same type of animation.
And I also count myself as someone who considers 120 at least necessary (on the primary monitor)
Fps in itself is not important, but it is a substitute for input latency, and if your keystrokes start lagging it feels sluggish. At least historically electron based editors (like atom) has been feeling significantly more sluggish than sublime text or vim with a decent terminal emulator.
For terminal emulators comparisons at least the metrics used are latency and throughput. Now those plus times to do operations (load file, search & replace, etc) wouldn't surprise me to be the comparison metrics for text editors. FPS though feels weird.
The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient.
I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.
> I assume zed isn’t doing that either as it would be horribly inefficient.
What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, which ran on the laptops of 2009 for the exact same reason: it used the GPU!
Rerendering each frame is wasteful because it keeps hardware from reaching deeper power-saving states. This includes the CPU, GPU and even the display, due to technologies such as FreeSync. On modern hardware, even removing the blinking cursor has been found to save quite a bit of power, by eliminating needless screen redraws.
Zed only rerenders the window each time it changes (and also for about a second since the last interaction for reasons[0]) but every time it rerenders the window it does rerender the entire window and not just the area that changed. That's what I thought GGP was calling horribly inefficient.
Neither Windows Aero nor Zed renders every single frame, 120 times per second. The parent comment is correct is correct that the important thing is to be able to render any given frame in 1/120th of a second, but to leave things alone when nothing is changing.
Zed does do it for about a second following user interaction[0] but I assumed GGP was talking about only redrawing the changed part of the window. Not rendering frames continuously even when nothing is changing at all, which Zed doesn't do (and Windows Aero didn't either, at least to a certain extent).
Yes, it's just rendering into the texture redraws the entire window and you never really need to worry about redrawing only the parts of the screen that changed. But I think GGP was actually talking about redrawing the window every frame even if nothing's changed at all, which is indeed inefficent (though not necessarily "horribly").
GGP is me, and yes that’s what I meant. Under no circumstance would zed actually be drawing 120 frames each second, right? That would be 100x more energy usage than would actually be required, and so I think “horribly” is accurate.
> Under no circumstance would zed actually be drawing 120 frames each second, right?
It does this when scrolling for sure. That's a trivial case where 120 FPS is required on a 120Hz display.
It also does this even when nothing on the screen is changing, but only for about 1 second after the last user input. This is explained in a blog post[0].
Now this does cause more power usage, because when Zed does not do this, the display can actually downclock to save power. But downclocking like that increases latency, which is why they prevent it from happening in the middle of user input (but still allow it to happen betwen each burst of input).
> Honest question. What could you possibly do with a text editor at 120 fps that you can't do at 15 or 30?
More-honest-than-it-should-be answer: sell a product to Apple-ecosystem developers trying desperately to find something to justify the $3k they want to spend on a new MBP.
(Typing this very comment in emacs running out of the Linux VM on a mid-range chromebook attached to a 30 Hz 4k television, btw. Come at me, as it were.)
Oh come on. Fancy wires do nothing. 120Hz makes motion much smoother. It also reduces latency. Those make a big difference in many video games, or even just moving my mouse around and having it not skip two inches at a time.
Your cynicism over 120Hz should match your cynicism over 4k.
That, doesn't make any sense 4k allows monitors to push past 24 inches, though, on a 24 or less 2k is plenty for me, but the generation of 22 inch 1080p monitors was rough on the eyes.
Your mouse cursor aliasing test is sort of the tell here. Normal human beings are very hard put to be able to even detect the difference between a 60 Hz and 120 Hz display, and have to resort, as you do, to trickery and artifacts to measure it. And the use case at hand is text editting!
As far as 4k, not sure I understand? It's not a nonsense retina tablet or whatever, it's a 42" television with 100 DPI pixels I can see with my own eyes (well, when I put my reading glasses on -- presbyopia comes for us all). I bought it because it's cheap and it subtends 60 degrees of pixels small enough to be unresolvable, and sits farther than an arms length from my eyes (presbyopia again).
It's hard to tell the difference with smooth motion.
With rendered frames, the stuttering makes it meaningfully harder to click on fast moving things.
> And the use case at hand is text editting!
People were being dismissive about frame rates in general, so I gave an example that wasn't test editing.
The benefit for text editing is much smaller, but also if you're text editing then you don't need significant amounts of compute power to do text at 120. One big criticism disappears. You need that power for games, which actually benefit.
I've used 4k at 30Hz before, but I switched it to 60Hz with chroma subsampling for faster things.
> As far as 4k, not sure I understand?
They're both good but not necessary, and partly situational. But you're choosing to ignore the benefits of one.
A curmudgeon should dismiss both, and most people should want both.
Not really, 120Hz produces a noticeable improvement over 60Hz, unlike "golden boutique speaker wire", just like 4k produces a noticeable improvement over 1080p.
It's not like everyone is going to be able to tell whether a given display is 60Hz or 120Hz, but all other things being identical, they will probably be able to tell which display is faster after using both.
Higher refresh rates tighten the feedback-response loop, creating a smoother and more direct interface to the computer, which is generally perceived as desirable.
Consider VR, where HMDs often have to refresh at 90Hz or 120Hz in order to reduce motion sickness. This actually isn't that different than operating a computer. The brain tends to quickly get very upset when it can't reconcile your visual field with your felt position in space, but even though most people don't get motion sick from looking at a computer display (some do), the refresh rate certainly affects it feels to use the display.
Cross platform toolkits, more than other software components incur massive tradeoffs. They’ve written one themselves, tailored to their needs and open sourced it along the way. I guess I don’t see the problem here. If one that’s existed for decades fits your needs better then use that.
Wgpu seems very very well loved & supported, is one of the most successful comings together of the graphics world in ages. I'd love to hear some actual critique of it, hear what people think are shortcomings, because it feels to an outsider like this is the fantasy land, that we're living in the better place now. https://github.com/gfx-rs/wgpu
What I find interesting is that kvark, the open source contributor that made Linux port possible was the main developer on wgpu at Mozilla, yet he decided to build an alternative [1] to wgpu that he used for zed. I wonder what's the rational for that.
Dzmitry gave a talk at a rust gamedev meetup on Blade.
This ain't my turf so apologies for inaccuracies here. It appears to be a fairly novel attempt to write a graphics library with a semi conventional looking pipeline, that under the hood ends up eskewing a lot of the Vulkan concepts. Instead of per object contexts, it uses global contexts to do most work. Instead of taking resources and binding them into descriptor sets to use across pipelines (tracking state), Blade kind of recreates resources on the fly, lets them get used, and disposed of them.
Kind of interesting philosophy of a complex binding model in Vulkan/WebGPU vs a more direct diy render model?
Zed tool this work as an outside contribution. Maybe that someone did the work was good enough. I'm not sure what would make Blade a better match or not, vs wgpu-hal.
Someone has to pay for it, time, money, wait for it whatever.
I love working with technical people who ask why and think about more optimal paths.
On the other hand I'll listen to the same folks complain about some random app being stinky (I don't disagree) and wonder "Yeah but you going to pay more for that burrito so that company can hire folks to write it natively on every platform?" No you're not ...
I know our customers at times aren't willing to pay / wait for the optimal path, and their customers aren't, so I get it.
> In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written.
This is certainly one takeaway. On the other hand, this very blog post points out that a community member, Dzmitry Malyshau, did the work to get the program working on the OS he uses. Malyshau does not work for Zed, which is a for-profit company; as far as I can see, he gets nothing out of working on Zed, except that he and other Linux users get to use it. Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other.
"Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other."
... and that even if it means signing away their rights in a CLA to a for profit company. This is on another level than contributing to the Linux kernel that is GPL2 plus practically not relicensable because of the multitude of copyright holders.
> Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other.
That's more an "Open Source" thing rather than Linux specific. A personal case in point was when I got Mellanox adapter support officially added to FreeNAS (now TrueNAS) because that's the adapter brand I had and needed it to work.
Not a super huge effort as the FreeBSD driver worked (so just needed porting), but the integration process and follow up testing/advocacy/etc work wasn't exactly trivial either.
MoltenVK is also a thing. Whatever small translation overhead it incurs is probably not that important for a text editor. And then you get a cross-platform API: not just Linux, but Windows as well. Maybe also other more niche OSes as well.
Molten VK is amazing. When I started working with it, I was expecting a lot of caveats and compromises, but it's shockingly similar to just using Vulkan that you can easily forget that there's a compatibility tool in play.
Probably you can squeeze a bit of optimization out of using Metal directly, but I think it's a more than viable approach to start with Vulkan/MoltenVK as a target, and add a Metal branch to the renderer when capacity allows (although you might never feel the need)
Over the last few years I've had two applications that tended to rot after a week or two running, one is Firefox, which I still use for political reasons, and VS Code, the only Electron thing I've used for more than a few hours. The other being MICROS~1 Teams, which doesn't play nice with my window manager, tries to force me into identifying myself to join some video chat for a bit, and prefers to hang rather than shut down when asked nicely. Instead I join chats without video support.
This is my problem with Electron applications. I'd be fine with them gobbling up a few GB if they were stable.
> In my mind, if you're someone who types in HN comments in a rage because your text editor
WebGPU exists. It works with Metal. Vulkan could have also worked and MoltenVK would have bridged it to Apple. No, this is just like every other project that only works on MacOS: a mentality I really can't comprehend or explain.
From what I understand Zed is a text editor that is built like a game engine, which I understand is why the marketing copy uses the term "multiplayer" rather than "multiuser". I didn't find other mention of its multiplayer capabilities, which is too bad. Has anyone used it for that purpose, I'm curious as to what the experience was like.
Used it the other day with my teammate to pair on some stuff, and it genuinely felt magic. We went from never having used it, to digging through their code together in about a minute, and have used it a few times since. Really nice UX.
it was used back with a popular website which opened a text document and anyone viewing could type, but I can't remember the name. That became a thing in Google Docs, Microsoft Office, Floobits, and lots of self-hosted and cloned sites.
You may be thinking of Hackpad from 2014, which later was bought by Dropbox and morphed into Dropbox Paper. I guess I was thinking that a multiuser IDE is substantially different than a multiuser text editor. I did notice that Zed is by the same team that brought us tree-sitter, which is a wonderful innovation that many text editors are now using to good effect. I was wondering if were powerful enough for one person to be debugging some code in the same session that another person was refactoring.
Earlier than that; I wanted to say EditPad but that's not it. I found it; EtherPad in 2008 is the one I was thinking of, but the history of collaborative editing apparently goes back to Doug Englebart's Mother of All Demos in 1968:
If you care a lot about Linux support, Lapce is a very promising alternative. Much like Zed, it also is written in Rust with native GPU-based rendering and a shared focus on enabling integration with modern IDE technologies such as LSP servers, tree-sitter parsers and DAP for debugging.
If Apple had just adopted the Vulkan standard instead of going off with their own proprietary graphics API this would have been a non-issue. Smacks of Canonical and their repeatedly doing one thing while ignoring the rest of the community standardizing on something else.
Unfortunately, the renderer is only one step in supporting an alternative platform. Even if we could have used Vulkan on every platform, the windowing APIs are completely different and those do most of the things we like our code editors to support, like typing.
"Sorry no" whatever. Khronos was discussing what to do with Mantle as it became Vulkan. Apple was part of those industry players who were invited to the table. Apple left and did their own thing, like Apple does.
These specs don't spring up fully formed. Vulkan was a collaboration long before it was named as such and released; Approaching Zero Driver Overhead/bindless was 100% clear writing on the wall for a while by then. Apple just doesn't collaborate; they demand control. That's why they didn't participate when everyone else was figuring out how to distill out Vulkan from Mantle & other close to the metal patterns that were already about.
Microsoft, Sony and Nintendo also don't really care Vulkan exists.
Besides AMD most likely only offered Mantle, because OpenGL vNext was going to be another Long Peaks failure, had it not been the case.
And for what, Vulkan is already an spaghetti extension mess, with a complexity that feels like build a car out of LEGO Technics pieces, when one wants to drive down to the grocery store.
Serious question: I am looking at the measurements of speed on the landing page between Zed and the other editors, and they don't seem drastic. Do you actually feel the difference when typing?
Compared with VSCode, absolutely. VSCode has a range of responsiveness from "good enough" to "oh right, this is Electron". Zed is both faster and more consistent. Sure, we're talking 10s of milliseconds, but it's surprisingly noticeable. Can't speak for other editors.
I'm becoming a true convert, though I occasionally must drop down to a termianl for advanced vim features. That's high praise coming from me, as I have a high bar for adopting new tools.
Agree with the "hanging" and general responsiveness issues with VS Code, but typing (when VS Code is not taking a nap)? No way. Pure typing is not distinguishable.
No. However, VS Code sometimes freezes shortly. Maybe some GC stuff going on. But when both VS Code and Zed have finished starting (Zed of course faster) and you start typing, you don't feel a difference (unless you're on a very slow computer I guess). At least I don't. Same with Neovim.
I don't get this. There are so many things that Zed does better than VS Code, but typing latency is the least noticeable and interesting.
In all fairness, and I already knew what Zed was, the About page is a long read to find out anything more than that Zed is an editor. (As in, it says right away that they are building an editor, but then there is a long-winded discussion about history, goals, etc.)
> please use the original title, unless it is misleading or linkbait; don't editorialize.
> If the title includes the name of the site, please take it out, because the site name will be displayed after the link.
> Please don't do things to make titles stand out, like using uppercase or exclamation points, or saying how great an article is. It's implicit in submitting something that you think it's important.
I really appreciate how Zed tries to tailor make and ensure their app looks and feels native on Linux.
One thing that scares me with it though is the lock in of the multiplayer features. I can see it forcing me to use it and not my preferred editor, because other people use Zed.
Would love it if we were not only platform independent but also editor independent regardless of social pressure.
I am generally wary of anything that proposes to monetize the process of doing my core work.
I recognize that that attitude makes marketing and selling a product to developers difficult, though. If they changed from a CLA to a DCO I'd feel less uneasy about it, but but is that something their investors and business can permit?
I tried it out briefly, and it seems promising so far! Zed reminds me a lot of Lite [1] and its community successor Lite-XL [2], which are also "built like a videogame" using a custom renderer and ui engine.
A term coined Casey Muratori for this is immediate-mode GUIs or else IMGUI programming[1]. Hence the name for the very popular Dear ImGui project. GPUI used for Zed is mentioned as hybrid immediate and retained mode UI framework[2].
Right now: mixed. We provide both user defined themes and theme overrides that let people color-correct things as they need, we have a strong cultural focus on keyboard accessibility for all UI elements, you can increase or decrease the font size in the editor and the UI, and we have strong support for IME on macOS and will be extending that to Windows and Linux.
However, our accessibility to screen readers is non-existent. I have ambitions to incorporate AccessKit but it's a bit of a project due to the lack of a clear guide on how to implement it. That said, I already made some progress based on the old egui PR and we should have all the pieces we need once I have time to actually do it.
We also lack any way to tab through our UI elements to select each piece in turn. This one I have yet to do any thinking on, particularly as the tab key already does a lot of work in a code editor. I'm sure there's prior art here, I just haven't looked at it yet.
So, piecemeal and insufficient for many cases, usable for some others. I'm very interested in improving this but we still have a lot to do.
Thanks, will keep an eye on the developments there.
A note, the tab key is not all that important. f6 for jumping the different parts of the screen and the arrow keys for neighbouring elements could be a good substitute for most cases. Add a few key bindings and tabless is not an issue any more.
Simply put: historical artifact and we want to own the stack. Zed was first created when these abstractions where a lot younger, and a text editor needs certain features, like IME support, that weren't as common back then. Further, owning the stack we're built on gives us the flexibility to change the framework whenever and however we want, which we value more than the additional work it takes to re-implement things ourselves.
From how they've been talking about Zed (on The Changelog, among other places), I expected to be wowed on my first open of the application, but the experience kind of fell flat for me. I might try it again when they have some better onboarding, though!
168 comments
[ 2.9 ms ] story [ 207 ms ] threadWhen you eliminate all human repercussions for acting like a moron, even if it's as small as feeling bad, one should expect to see more idiocy.
That this website is littered with retarded morons that cannot handle the slightest bit of pure direct argumentation is more a function of the times, where heavy-handed moderation fills in for massive gaps in their vacuous perspective, which in any other situation completely undermines one's understanding of the world outside a pseudo-intellectual bubble.
The moderates here do better than any other online, IMO. And I say that knowing the moderators here do not unflag some of my comments because it's ideologically inconvenient to them personally.
- Move your mouse cursor to the "Zed Industries" icon in the upper-left-hand-corner, then click.
- This "hypertext link" will instruct your browser to load the site's root "index.html", sometimes known as a "landing page".
- The "landing page" is a great place to start if you're unfamiliar with a site or product! Here, you'll find the following text prominently displayed:
"Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter. It's also open source."
Hope this helps!
(If there is for you, good for you. Some information for you, different browsers get fed different content, iyt's a new thing that only started around 1993 so I can see how you weren't aware.)
Actually there is one, 7000 pages down at the bottom, embedded in the footer and not looking at all clickable.
"Hope this helps!"
[..]Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter. It's also open source.[..]
Not sure if I should care, but more fast modern editors are good. But if they only just now got linux-support, then I think they will still need much much love to reach a good shape.
[1]: https://github.com/zed-industries/zed
Seriously, what do people think when designing headers like this? Like wow we should totally link to every other part of our site except the homepage.
Because who would want to go there after they found out about a project through a blog post?
This is not always great for accessibility (they don't have alt=, title=, or aria-*= attributes on the <a> or <img> tags) but seems to be a common pattern.
I would not have found it or even thought to try to click on it except after reading this claim that it's there somewhere.
Unless I missed it, the video doesn't actually answer the question. They talk 38:50 onwards about how they don't want to pull in GTK / Qt as dependencies, rather they just want to be able to read the toolkits' config and render a mimicking UI themselves. Then they show the editor opening a "native" file dialog, but don't actually say how exactly they did it.
Anyway, I assumed they would use xdg-desktop-portal, and based on searching the repo that does seem to be the case.
Backends can implement a subset of the interfaces, and xdp can be configured to try multiple backends in sequence until it finds one that provides the interface that the application wants. Eg xdp-wlr for wlroots-based Wayland compositors only implements compositor-specific interfaces like screencast, so users would chain it with something like xdp-gtk for other interfaces like file picker.
Native applications usually use their toolkits' API for showing file picker dialogs etc, and xdp's file picker interface is primarily used by flatpak applications since that is a way for sandboxed applications to read/write outside their sandbox. But it's not impossible for native applications to also use it, as zed is doing.
https://flatpak.github.io/xdg-desktop-portal/docs/api-refere...
There's a bit of detail here: https://github.com/zed-industries/zed/issues/7015
But I'd be curious to read a longer writeup on the tradeoffs and how they came to their decision.
i heard somewhere this nice example: only big actors like AAA game engines would really benefit from the extra development effort it would take to use an even lower level api like vulkan/dx12 to squeeze the last 10% of performance that wgpu can't get you
so if i understand correctly, zed, just like a AAA game engine, wants to squeeze every last bit of performance from the gpu, and so wgpu is "too high level" for it? and blade is "like wgpu, but no design tradeoffs and lower level" so its a better fit? does that mean someday zed might reach for vulkan directly one day? im assuming dx12 is gonna be used on windows anyway?
i love kvark's work btw, we need more kvarks
The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.
The page you linked clearly states that wgpu-hal's API is extremely unsafe and skips many checks in order to reduce overhead. So while "secure and sandboxed" explains why wgpu wasn't chosen, it doesn't explain why wgpu-hal wasn't chosen.
So they are taking the exact opposite approach of Electron (VS Code).
In my mind, if you're someone who types in HN comments in a rage because your text editor (VS Code) eats up 200+ MB ram, you don't get to cry about Zed not being supported on Linux from day one, because you can't have your cake and eat it too - if you want it on your platform, you gotta wait for the shaders to be written.
However if they did, the games would sell because the mac people wanted games and there were so few available they would buy anything.
problems of a closed ecosystem.
(honest question - I've never looked into it myself)
For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)
I do not suffer from nausea or motion sickness of any kind arising from computers or visuals in general, but I can still easily tell the difference between a 60Hz and 90Hz display. A few months ago I had the privilege of checking out the 120Hz displays on the new MacBooks and they're amazing.
And I also count myself as someone who considers 120 at least necessary (on the primary monitor)
I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.
What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, which ran on the laptops of 2009 for the exact same reason: it used the GPU!
Hadn't heard of that before, but it makes sense now you mention it. :)
[0]: https://zed.dev/blog/120fps
[0]: https://zed.dev/blog/120fps
Oops, thanks for the correction.
> Under no circumstance would zed actually be drawing 120 frames each second, right?
It does this when scrolling for sure. That's a trivial case where 120 FPS is required on a 120Hz display.
It also does this even when nothing on the screen is changing, but only for about 1 second after the last user input. This is explained in a blog post[0].
Now this does cause more power usage, because when Zed does not do this, the display can actually downclock to save power. But downclocking like that increases latency, which is why they prevent it from happening in the middle of user input (but still allow it to happen betwen each burst of input).
[0]: https://zed.dev/blog/120fps
I can't think or type that fast and I can't read scroll back that fast either so I can't wrap my head around needing something like that.
More-honest-than-it-should-be answer: sell a product to Apple-ecosystem developers trying desperately to find something to justify the $3k they want to spend on a new MBP.
(Typing this very comment in emacs running out of the Linux VM on a mid-range chromebook attached to a 30 Hz 4k television, btw. Come at me, as it were.)
I assume they have a reason, I just can't guess whatnot is.
Your cynicism over 120Hz should match your cynicism over 4k.
I'm not saying to be highly cynical, I'm saying to be equally cynical. You can change either side to reach equality.
As far as 4k, not sure I understand? It's not a nonsense retina tablet or whatever, it's a 42" television with 100 DPI pixels I can see with my own eyes (well, when I put my reading glasses on -- presbyopia comes for us all). I bought it because it's cheap and it subtends 60 degrees of pixels small enough to be unresolvable, and sits farther than an arms length from my eyes (presbyopia again).
With rendered frames, the stuttering makes it meaningfully harder to click on fast moving things.
> And the use case at hand is text editting!
People were being dismissive about frame rates in general, so I gave an example that wasn't test editing.
The benefit for text editing is much smaller, but also if you're text editing then you don't need significant amounts of compute power to do text at 120. One big criticism disappears. You need that power for games, which actually benefit.
I've used 4k at 30Hz before, but I switched it to 60Hz with chroma subsampling for faster things.
> As far as 4k, not sure I understand?
They're both good but not necessary, and partly situational. But you're choosing to ignore the benefits of one.
A curmudgeon should dismiss both, and most people should want both.
It's not like everyone is going to be able to tell whether a given display is 60Hz or 120Hz, but all other things being identical, they will probably be able to tell which display is faster after using both.
Higher refresh rates tighten the feedback-response loop, creating a smoother and more direct interface to the computer, which is generally perceived as desirable.
Consider VR, where HMDs often have to refresh at 90Hz or 120Hz in order to reduce motion sickness. This actually isn't that different than operating a computer. The brain tends to quickly get very upset when it can't reconcile your visual field with your felt position in space, but even though most people don't get motion sick from looking at a computer display (some do), the refresh rate certainly affects it feels to use the display.
It also seems like you can configure VSCode to go faster: https://stackoverflow.com/questions/52230196/vs-code-is-visi...
But honestly, 'responsiveness' should come from not blocking the main/UI threads, and rendering in the right order of importance.
[1]: https://github.com/kvark/blade
This ain't my turf so apologies for inaccuracies here. It appears to be a fairly novel attempt to write a graphics library with a semi conventional looking pipeline, that under the hood ends up eskewing a lot of the Vulkan concepts. Instead of per object contexts, it uses global contexts to do most work. Instead of taking resources and binding them into descriptor sets to use across pipelines (tracking state), Blade kind of recreates resources on the fly, lets them get used, and disposed of them.
Kind of interesting philosophy of a complex binding model in Vulkan/WebGPU vs a more direct diy render model?
https://www.youtube.com/live/63dnzjw4azI?si=KzLPm-gBX0gDKq7H...
Zed tool this work as an outside contribution. Maybe that someone did the work was good enough. I'm not sure what would make Blade a better match or not, vs wgpu-hal.
Emacs is looking at you
I love working with technical people who ask why and think about more optimal paths.
On the other hand I'll listen to the same folks complain about some random app being stinky (I don't disagree) and wonder "Yeah but you going to pay more for that burrito so that company can hire folks to write it natively on every platform?" No you're not ...
I know our customers at times aren't willing to pay / wait for the optimal path, and their customers aren't, so I get it.
This is certainly one takeaway. On the other hand, this very blog post points out that a community member, Dzmitry Malyshau, did the work to get the program working on the OS he uses. Malyshau does not work for Zed, which is a for-profit company; as far as I can see, he gets nothing out of working on Zed, except that he and other Linux users get to use it. Perhaps, rather than characterizing Linux users as whiny, we could take away the idea that many Linux users are willing to put in quite a lot of work to make things better for each other.
... and that even if it means signing away their rights in a CLA to a for profit company. This is on another level than contributing to the Linux kernel that is GPL2 plus practically not relicensable because of the multitude of copyright holders.
That's more an "Open Source" thing rather than Linux specific. A personal case in point was when I got Mellanox adapter support officially added to FreeNAS (now TrueNAS) because that's the adapter brand I had and needed it to work.
Not a super huge effort as the FreeBSD driver worked (so just needed porting), but the integration process and follow up testing/advocacy/etc work wasn't exactly trivial either.
Probably you can squeeze a bit of optimization out of using Metal directly, but I think it's a more than viable approach to start with Vulkan/MoltenVK as a target, and add a Metal branch to the renderer when capacity allows (although you might never feel the need)
This is my problem with Electron applications. I'd be fine with them gobbling up a few GB if they were stable.
WebGPU exists. It works with Metal. Vulkan could have also worked and MoltenVK would have bridged it to Apple. No, this is just like every other project that only works on MacOS: a mentality I really can't comprehend or explain.
it was used back with a popular website which opened a text document and anyone viewing could type, but I can't remember the name. That became a thing in Google Docs, Microsoft Office, Floobits, and lots of self-hosted and cloned sites.
https://en.wikipedia.org/wiki/Etherpad
https://en.wikipedia.org/wiki/Collaborative_real-time_editor...
I thought this was some component. Lol, yeah if your IDE doesnt work on Linux, the problem is your IDE, not linux.
I'll just stick to Sublime Text.
Huh. Did you mean to disagree with yourself the very next sentence?
Basically I have no reason to be interested in another Atom clone, and there is no sell in this article that explains why I should care.
You're not the target audience. Move along.
[0] https://zed.dev/download
[1] https://discord.com/channels/869392257814519848/120467985020...
I'm kind of tired of this contention cropping up again and again. Technically true but insufficient & obfuscating more than revealing.
Had Apple adopted Mantle then where would they be now? Apple did what they do, took ownership of their own stack.
These specs don't spring up fully formed. Vulkan was a collaboration long before it was named as such and released; Approaching Zero Driver Overhead/bindless was 100% clear writing on the wall for a while by then. Apple just doesn't collaborate; they demand control. That's why they didn't participate when everyone else was figuring out how to distill out Vulkan from Mantle & other close to the metal patterns that were already about.
Besides AMD most likely only offered Mantle, because OpenGL vNext was going to be another Long Peaks failure, had it not been the case.
And for what, Vulkan is already an spaghetti extension mess, with a complexity that feels like build a car out of LEGO Technics pieces, when one wants to drive down to the grocery store.
I'm becoming a true convert, though I occasionally must drop down to a termianl for advanced vim features. That's high praise coming from me, as I have a high bar for adopting new tools.
I don't get this. There are so many things that Zed does better than VS Code, but typing latency is the least noticeable and interesting.
> please use the original title, unless it is misleading or linkbait; don't editorialize.
> If the title includes the name of the site, please take it out, because the site name will be displayed after the link.
> Please don't do things to make titles stand out, like using uppercase or exclamation points, or saying how great an article is. It's implicit in submitting something that you think it's important.
One thing that scares me with it though is the lock in of the multiplayer features. I can see it forcing me to use it and not my preferred editor, because other people use Zed.
Would love it if we were not only platform independent but also editor independent regardless of social pressure.
I recognize that that attitude makes marketing and selling a product to developers difficult, though. If they changed from a CLA to a DCO I'd feel less uneasy about it, but but is that something their investors and business can permit?
I'd happily pay a fixed one-time fee for them though.
[1] https://github.com/rxi/lite
[2] https://github.com/lite-xl/lite-xl
A term coined Casey Muratori for this is immediate-mode GUIs or else IMGUI programming[1]. Hence the name for the very popular Dear ImGui project. GPUI used for Zed is mentioned as hybrid immediate and retained mode UI framework[2].
[1]: https://caseymuratori.com/blog_0001 (fist post on his blog!) [2]: https://github.com/zed-industries/zed/tree/main/crates/gpui
However, our accessibility to screen readers is non-existent. I have ambitions to incorporate AccessKit but it's a bit of a project due to the lack of a clear guide on how to implement it. That said, I already made some progress based on the old egui PR and we should have all the pieces we need once I have time to actually do it.
We also lack any way to tab through our UI elements to select each piece in turn. This one I have yet to do any thinking on, particularly as the tab key already does a lot of work in a code editor. I'm sure there's prior art here, I just haven't looked at it yet.
So, piecemeal and insufficient for many cases, usable for some others. I'm very interested in improving this but we still have a lot to do.
A note, the tab key is not all that important. f6 for jumping the different parts of the screen and the arrow keys for neighbouring elements could be a good substitute for most cases. Add a few key bindings and tabless is not an issue any more.
I found a few issues, but overall it already works quite well and is very fast. It might even get me to give up on Neovim!