The blade graphics library is a mess and causes several issues for both Zed users as well as other 3rd party apps using GPUI. This PR removes blade and implements the linux platform using wgpu whic...
Read the original article
Comments
By the__alchemist 2026-02-1316:185 reply I am confused by this without context. I have not heard of blade, but am aware that Zed built its own GUI library called GPUI. Having used Zed, this is a vote of confidence: The crate ecosystem is historically filled with libaries which try to be The future of X in rust but are disconnected from practical applications. GPUI by nature is not that; it's a UI lib built to a practical and non-trivial purpose. It sounds like Blade is a cross-API graphics engine, by one of the original gfx-HAL (former QGPU name) creators?
I have not used GPUI beyond a simple test case, but had (prior to this news?) considered it for future projects. I am proficient with, and love EGUI and WGPU. (The latter for 3D). I have written a library (`graphics` crate) which integrates the two, and I use for my own scientific applications which have both 2D and 3D applications. Overall, I'm confused by this, as I was looking forward to using GPUI in future applications and comparing it to EGUI. I have asked online in several places for someone to compare who's used both, but I believe this to be a small pool.
I was not sure of the integration between GPUI and WGPU, which can confirm EGUI and WGPU have great integration. But I only care about this because I do 3D stuff; if I were not, I would be using eframe instead of WGPU as the backend.
Unrelated, off-topic, but I'm also not sure where to ask this: Am I missing something about Zed? I have tried and failed to get into it. I really want to like it because it's so fast [responsive], but it seems to lack basic IDE functionality in Python and Rust, like moving structs/functions, catching errors dynamically, introspection and refactoring in general etc. I thought I might be missing some config, but now lean that it's more of a project-oriented text editor than true IDE in the fashion of JetBrains. But I have been unable to get a confirmation, and people discuss it as if it's an IDE or JB alternative.
Zed competes mostly against Visual Studio Code. Not against Jetbrains.
I do love jetbrains for its nice-to-have features (eg highlight a few lines in the middle of a spaghetti function -> right click -> extract to new function) and was paying for it out of my own pocket for several years; but had to switch to vscode for a couple of required features that jetbrains was missing (remote dev over ssh, and devcontainers); and now switched to zed for being "like vscode but faster"
By qznc 2026-02-1413:10 Zed can "extract function" for Rust code. I guess, it depends on the language server you use? Since vscode and zed use the same there is not distinction between them.
By outcoldman 2026-02-1411:22 Maybe, but I switched from IntelliJ to Zed. And eventually stopped paying for Jetbrains products.
I am one plugin away from moving to it directly instead of vscode. I really like it. It’s fast. It gets updates seemingly daily. I’ve never had it crash. It integrates LLMs well. It’s everything I wish vscode was if it were native.
Lucky you. It still crashes quite often for me and it drives me nuts that my Claude code history is lost every time…
But love the project and been using it for almost 2 years now though
By dev_l1x_be 2026-02-1317:092 reply Debug log says what about the crash?
By trcf23 2026-02-1323:53 Never thought to check the debug log.
I would say mostly with the agent panel going into panic in longer conversation or not able to proceed for some reason.
Claude code in terminal also has issues rendering. Never have that with vscode or iterm so I guess it’s zed related.
And sometime for eslint it won’t check ts errors then start adding false errors everywhere and become unusable if I don’t start over.
By gigatexal 2026-02-1317:10 This too I’m curious about. If its memory related I have 36 of it on the work laptop if that helps
I used to feel this way, then a week or two ago, after an automatic update, it started hanging. All. The. Time for me. Launching the app now frequently takes 30 seconds before it shows me the “load a git repo” screen.
Speed was its main advantage, before. It has become nearly unusable.
The price of extraordinarily rapid iteration, I suppose.
By grub5000 2026-02-1516:43 FWIW I think I was experiencing the same hangs as you, and they seem to have resolved on their own now. Worth checking again just in case
By the__alchemist 2026-02-1316:303 reply I appreciate the info! Are you able to talk me through how to move a struct[class]?
By kylecazar 2026-02-1317:02 I installed Zed a few days ago and have been trying to get acquainted myself.
It has far less built-in features for refactoring than other editors you might be coming from. It's handled at the LSP level, get the LSP for your language and hit cmd+ to see what it can do. I'm not working in Python or Rust at the moment (Elixir), but I'm sure they have some good extensions.
I don't get the question. albeit in vim I use just the navigation things and selectors and s/../.. to replace stuff I am probably using something like 1% of it's power.
By the__alchemist 2026-02-1316:483 reply I'm asking how to move a function, or class to a different module (including its methods, imports throughout the project etc), as an example of IDE-101 stuff I can't figure out how to do in Zed, and makes me think Zed might [i]not[/i] be a replacement.
By skydhash 2026-02-1317:11 That’s a code intellisense feature set, not part of the core set of an editor. Especially when you have dynamic module loading. An IDE only focus on a few languages and it makes sense for them to have that capability.
By scuff3d 2026-02-1323:24 With the kind of editor Zed is, just like VSCode and Sublime, it's not goong to provide that function natively. The mechanics of moving functions between class/modules/packages/whatever are too different language to language. So you'll need to rely on LSP plugins for the different languages.
Or you could always use an actual IDE, but those are usually more language specific.
Ahh got it. Yeah im not sure but maybe there’s a discord or irc for folks to help with that who use zed. Even Reddit maybe?
By the__alchemist 2026-02-1317:23 Good calls! I haven't fully wrung this out, and want to like Zed, especially on my tablet. (Not too fast, and uses battery)
By actualwill 2026-02-146:201 reply Not OP but I can’t leave jet brains until a double shift search everywhere is implemented.
By madokaaoyi 2026-02-1517:561 reply i dont use jetbrains products but you can map the command palette or the file search to double shift and have it function the same way. zed supports key chords for bindings perfectly well. just do "shift shift" and it should work
By atraac 2026-02-178:45 Default double shift in zed goes to Execute a command window, sadly it doesn't support file searching within the same window and that's what I suppose he meant. I know cause I'm an avid JetBrains fanboy too and I can't use any other IDE because of that and few other features. Also, they're working on Search Anywhere Jet-Brains style feature right now if you believe Github Issues.
> It sounds like Blade is a cross-API graphics engine, by one of the original gfx-HAL (former QGPU name) creators?
My understanding is that wgpu has a lot of constraints and complexity imposed on it by all the backends it has to support (especially WebGPU) and that Blade is meant to be a much simpler closer-to-metal api for people who want more control (and know how to not shoot themselves in the foot)
> I would be using eframe instead of WGPU as the backend.
Do you mean using egui-wgpu directly rather than through eframe? The default backend of eframe is wgpu (it used to be glow/opengl), and you can still use callbacks to directly render whatever you want with wgpu in an eframe app
> EGUI and WGPU have great integration
Can confirm, it was stupid simple to integrate egui into my wgpu gamedev project
> Am I missing something about Zed? I have tried and failed to get into it.
I also tried Zed after getting annoyed at Helix a few times, and thought "oh cool, this is like vscode but fast and even has a helix mode!" but then didn't find any killer features worth abandoning the synergies of having an all-in-terminal-workflow over
By the__alchemist 2026-02-1415:23 I appreciate the details!
> Do you mean using egui-wgpu directly rather than through eframe? The default backend of eframe is wgpu (it used to be glow/opengl), and you can still use callbacks to directly render whatever you want with wgpu in an eframe app
I apparently don't know how eframe works... had no idea it used a GPU at all or WGPU under the hood... I assumed it was just the default you use if making a 2d-only program.
Re zed... I think I am too addicted to IDE functionality to be comfortable without. I had assumed Zed could do it, but have now concluded it can't. And/or I can't figure out how to use the LSP features reffed here, or they are well-hidden.
By stefanka 2026-02-1317:10 Cool, I haven't seen `graphics` before when I was looking for a simple UI/3D visualization option after rend3 has been abandoded. Have been considering bevy/egui too but seems more effort to learn
> as I was looking forward to using GPUI in future applications and comparing it to EGUI. I have asked online in several places for someone to compare who's used both, but I believe this to be a small pool.
I have yet to learn GPUI, but I have used Egui and really like it. I was turned off of GPUI from being forced to have to install Xcode to use it on macOS, which is a major bummer, in my opinion.
Iced.rs is also neat[0].
By bmitc 2026-02-1416:47 Iced indeed seems very neat. Egui is developed by a single person and so is Iced. The difference is that Egui has been quite stable whereas Iced has gone through several rewrites, as far as I can tell. It's why I didn't dive into it more, even though I like how Iced looks and focuses on the Elm model.
The Iced developer is quote open regarding his goals, which is appreciated. So while it's a nice library, it's a hard one to adopt.
Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop
Interesting read, however as someone from the same age group as Casey Muratori, this does not make much sense.
> The "immediate mode" GUI was conceived by Casey Muratori in a talk over 20 years ago.
Maybe he might have made it known to people not old enough to have lived through the old days, however this is how we used to program GUIs in 8 and 16 bit home computers, and has always been a thing in game consoles.
I think this is the source of the confusion:
> To describe it, I coined the term “Single-path Immediate Mode Graphical User Interface,” borrowing the “immediate mode” term from graphics programming to illustrate the difference in API design from traditional GUI toolkits.
— https://caseymuratori.com/blog_0001
Obviously it’s ludicrous to attribute “immediate mode” to him. As you say, it’s literally decades older than that. But it seems like he used immediate mode to build a GUI library and now everybody seems to think he invented immediate mode?
Is Win16 / Win32 GDI which goes back to 1985 an immediate mode GUI?
Win32 GUI common controls are a pretty thin layer over GDI and you can always take over WM_PAINT and do whatever you like.
If you make your own control you musts handle WM_PAINT which seems pretty immediate to me.
https://learn.microsoft.com/en-us/windows/win32/learnwin32/y...
Difference between game engine and say GDI is just the window buffer invalidation, WM_PAINT is not called for every frame, only when windows thinks the windows rectangle has changed and needs to be redrawn independently of screen refresh rate.
I guess I think of retained vs immediate in the graphic library / driver because that allows for the GPU to take over more and store the objects in VRAM and redraw them. At the GUI level thats just user space abstractions over the rendering engine, but the line is blurry.
No, that is event based programming, and also the basis of retained rendering, because you already have the controls that you compose, or subclass.
Handling WM_PAINT is no different from something like OnPaint() on a base class.
This was actually one of mindset shifts when moving from MS-DOS into Windows graphics programming.
Event based or loop based is separate from retained or immediate.
The canvas api in the browser is immediate mode driven by events such as requestAnimationFrame
If you do not draw in WM_PAINT it will not redraw any state on its own within your control.
GDI is most certainly an immediate mode API and if you have been around long enough for DOS you would remember how to use WM_PAINT to write a game loop renderer before Direct2D in windows. Remember BitBlt for off screen rendering with GDI in WM_PAINT?
https://learn.microsoft.com/en-us/windows/win32/direct2d/com...
I even remember WinG, Win32s and co.
You are forgeting most folks did not use bare bones C with WM_PAINT and nothing else.
Most sane devs were quick to adopt C++, even Petzold books moved into C++ still during Windows 3.1 days, although the code samples stayed pretty much the C subset common to both languages, see the preface on his book.
As such many games had their own retained frameworks built on top of Win32 controls, wrapped into C++ classes, or if they were casual games, they would build upon OWL, VCL (Borland TP, C++, Delphi), MFC (VC++), VB.
The kind of games where you would get a bootload of shovelware CDs when buying a Media PC with MS-DOS/Windows 3.1.
By SigmundA 2026-02-1413:59 I wasn't talking about MFC or VB or any higher level abstraction, I specifically was talking about the base Win16/32 GDI gui system that windows started with.
You can take an immediate mode api and abstract it with a retained mode api. My question was is Win32 / GDI immediate.
There was plenty of pure C windows programs and C++ ones that just used Win32.
ImgGui actually uses a retained mode graphics interface so it only sends changes to the GPU while making it look "immediate" thing is its creating internal state and tracking it so its not smash and replace at the driver level.
Win32 / GDI is mostly smash and replace in WM_PAINT, common controls library will abstract it, but looks a lot like ImgGui in that is uses window handles as ID's for internal state while ImgGui has its ID stack which is just a primitive object state system.
The more I look at ImgGui the less immediate it seems, its just a function based api to a retained mode graphic system that tries to hide the state tracking from you by not always exposing the object handle, mostly.
It's like the common claim that data-oriented programming came out of game development. It's ahistorical, but a common belief. People can't see past their heroes (Casey Muratori, Jonathon Blow) or the past decade or two of work.
I partly agree, but I think you're overcorrecting. Game developers didn't invent data-oriented design or performance-first thinking. But there's a reason the loudest voices advocating for them in the 2020s come from games: we work in one of the few domains where you literally cannot ship if you ignore cache lines and data layout. Our users notice a 5ms frame hitch- While web developers can add another React wrapper and still ship.
Computing left game development behind. Whilst the rest of the industry built shared abstractions, we worked in isolation with closed tooling. We stayed close to the metal because there was nothing else.
When Casey and Jon advocate for these principles, they're reintroducing ideas the broader industry genuinely forgot, because for two decades those ideas weren't economically necessary elsewhere. We didn't preserve sacred knowledge. We just never had the luxury of forgetting performance mattered, whilst the rest of computing spent 20 years learning it didn't.
> I think you're overcorrecting.
I don't understand this part of your comment, it seems like you're replying to some other comment or something not in my comment. How am I overcorrecting? A statement of fact, that game developers didn't invent these things even though that's a common belief, is not an overcorrection. It's just a correction.
By dijit 2026-02-1317:02 Ah, I read your comment as "game devs get too much credit for this stuff and people are glorifying Casey and Jon" and ran with that, but you were just correcting the historical record.
My bad. I think we're aligned on the history; I was making a point about why they're prominent advocates today (and why people are attributing invention to them) even though they didn't invent the concepts.
I don't really like this line of discourse because few domains are as ignorant of computing advances as game development. Which makes sense, they have real deadlines and different goals. But I often roll my eyes at some of the conference talks and twitter flame wars that come from game devs, because the rest of computing has more money resting on performance than most game companies will ever make in sales. Not to mention, we have to design things that don't crash.
It seems like much of the shade is tossed at web front end like it's the only other domain of computing besides game end.
I mean... fair point? I'm not claiming games are uniquely performance-critical.
You're right that HFT, large-scale backend, and real-time systems care deeply about performance, often with far more money at stake.
But those domains are rare. The vast majority of software development today can genuinely throw hardware or money at problems (even HFT and large backend systems). Backends are usually designed to scale horizontally, data science rents bigger GPUs, embedded gets more powerful SoCs every year. Most developers never have to think about cache lines because their users have fast machines and tolerant expectations.
Games are one of the few consumer-facing domains that can't do this. We can't mandate hardware (and attempts at doing so cost sales and attract community disgust), we can't hide latency behind async, and our users immediately notice a 5ms hitch. That creates different pressures- we're optimising for the worst case on hardware we don't control whilst most of the industry optimises for the common case on hardware they choose.
You're absolutely right that we're often ignorant of advances elsewhere. But the economic constraint is real, and it's increasingly unusual.
By torginus 2026-02-1320:00 I think we as software developers are resting on the shoulders of giants. It's amazing how fast and economical stuff like redis, nginx, memcached, and other 'old ' software are written decades ago, mostly in C, by people who really understood what made them run fast (in a slightly different way to games, less about caches and data, and more about how the OS handles low level primitives).
A browser like Chrome also rests on a rendering engine like Skia, that has been optimized to the gills, so at least performance can be theoretically fast.
Then one tries to host static files on a express webserver, and is suprised to find that a powerful computer can only serve files at 40MB/s with the CPU at 100%.
I would like to think that a 'Faustian deal' in terms of performance exists - you give up 10,50,90% of your performance in exchange for convenience.
But unfortunately experience shows there's no such thing, arbitrarily powerful hardware can be arbitrarily slow.
And as you contrast gamedev to other domains who get to hide latency, I don't think its ok that a simple 3 column gallery page takes more than 1 second to load, people merely tolerate this not enjoy it.
And ironically I find that a lot of folks end up optimizing their React layouts way more than what it'd have cost to render naively with a more efficient toolkit.
I am also not sure what advances game dev is missing out on, I guess devs are somewhat more reluctant to write awful code in the name of performance nowadays, but I'd love to hear what advances gamedev could learn from the broader software world.
The TLDR version of what I wanted to say, is I wish there was a linear performance-convenience scale, where we could pick a certain point and use techniques conforming to that, and trade two thirds of the max speed for dev experience, knowing our performance targets allow for that.
But unfortunately that's not how it works, if you choose convenience over performance, your code is going to be slow enough that users will complain, no matter what hardware you have.
By moregrist 2026-02-1316:51 It clearly didn’t come out of game dev. Many people doing high performance work on either embedded or “big silicon” (amd64) in that era were fully aware of the importance of locality, branch prediction, etc
But game dev, in particular Mike Acton, did an amazing job of making it more broadly known. His CppCon talk from 2014 [0] is IMO one of the most digestible ways to start thinking about performance in high throughput systems.
In terms of heroes, I’d place Mike Acton, Fabian Giesen [1], and Bruce Dawson [2] at the top of the list. All solid performance-oriented people who’ve taken real time to explain how they think and how you can think that way as well.
I miss being able to listen in on gamedev Twitter circa 2013 before all hell broke loose.
[0] https://youtu.be/rX0ItVEVjHc?si=v8QJfAl9dPjeL6BI
There's also good reasons that immediate mode GUIs are largely only ever used by games, they are absolutely terrible for regular UI needs. Since Rust gaming is still largely non-existent, it's hardly surprising that things like 'egui' are similarly struggling. That doesn't (or shouldn't) be any reflection on whether or not Rust GUIs as a whole are struggling.
Unless the Rust ecosystem made the easily predicted terrible choice of rallying behind immediate mode GUIs for generic UIs...
>Unless the Rust ecosystem made the easily predicted terrible choice of rallying behind immediate mode GUIs for generic UIs...
That's exactly what they did :D
I mean, fair enough, but [at least] wikipedia agrees with that take.
> Graphical user interfaces traditionally use retained mode-style API design,[2][5] but immediate mode GUIs instead use an immediate mode-style API design, in which user code directly specifies the GUI elements to draw in the user input loop. For example, rather than having a CreateButton() function that a user would call once to instantiate a button, an immediate-mode GUI API may have a DoButton() function which should be called whenever the button should be on screen.[6][5] The technique was developed by Casey Muratori in 2002.[6][5] Prominent implementations include Omar Cornut's Dear ImGui[7] in C++, Nic Barker's Clay[8][9] in C and Micha Mettke's Nuklear[10] in C.
https://en.wikipedia.org/wiki/Immediate_mode_(computer_graph...
[Edit: I'll add an update to the post to note that Casey Muratori simply “coined the term” but that it predates his video.]
Dig out any source code for Atari, Spectrum or Commodore 64 games, written in Assembly, or early PC games, for example.
And you will see which information is more accurate.
By piker 2026-02-1315:05 Yeah no doubt you're correct. I wasn't disagreeing - just establishing the reasonableness of my original statement. I must have read it in the Dear ImGui docs somewhere.
By vodou 2026-02-1315:32 I am pretty sure there are people here qualified enough to edit that Wikipedia page in a proper way.
By arandomhuman 2026-02-1314:541 reply Wikipedia clearly has never been shown to have faults regarding accuracy.
By tux3 2026-02-1315:12 {{cn}}
By Matl 2026-02-1411:15 It makes perfect sense if you consider his ego.
> Maybe he might have made it known to people
Yes, he coined the term rather than invent the technique
He definitely did not name it. IRIS GL was termed “immediate mode” back in the 80’s.
He coined the term in the context of UI, by borrowing the existing term that was already used in graphics. Drawing that parallel was the point.
By adastra22 2026-02-1317:15 It might be more accurate to say that he repopularized the term among a new generation of developers. Immediate vs Retained mode UI was just as much a thing in early GUIs.
It was a swinging pendulum. At first everything was immediate mode because video RAM was very scarce. Initially there was only enough VRAM for the frame buffer, and hardly any system RAM to spare. But once both categories of RAM started growing, there was a movement to switch to retained mode UI frameworks. It wasn’t until the early 00’s that GPUs and SIMD extensions tipped the scales in the other direction - it was faster to just re-render as needed rather than track all these cached UI buffers, and allowed for dynamic UI motifs “for free.”
My graying beard is showing though, as I did some gave dev in the late 90’s on 3Dfx hardware, and learned UI programming on Win95 and System 7.6. Get off my lawn.
By pjmlp 2026-02-1315:52 I won't be bothered to go hunting for digital copies of 1980's game development books, but I have my doubts on that.
Open source GUI development is perpetually cursed by underestimating the difficulty of the problem.
A mature high-quality GUI with support for all the features of a modern desktop UI, accessibility, support for all the display variations you encounter in the wild, high quality rendering, high performance, low overhead, etc. is a development task on par with creating a mature game engine like Unity.
Nearly all open source GUI projects get 80% of the way there and stall, not realizing that they are only 20% of the way there.
By kbelder 2026-02-1317:19 You're right, and I think that's because the core functionality of a UI lib is not too difficult. I've tinkered in that space myself, and it's a fun side project.
Then you start to think about full unicode support, right-to-left rendering, and so on. Then you start to think about properly implementing accessibility features. The necessary work increases by a magnitude. And it's not fun work. So you stall out with a bare-bones implementation.
In my experience immediate mode guis almost always ignore internationalization and accessibility.
The thing you get by using an OS widget and putting a string in it is that the OS can interact with the string. It can read it out load, translate it, fill it in with a password, look it up in a dictionary, edit it right to left, handle input method editors whose hot keys are in conflict with app doing its own editing, etc…
There’s a reason why the most popular ImGUIs are targeted at game dev tools and in game dev uis and not end user uis
You could potentially make an Immediate mode gui that wrapped a retained gui. arguably that is what react is. From the programmers pov it’s supposed to look like imgui code all the way down. It runs into the issues of having to keep to two representations in sync. The ui represented by react and the actual widgets (html or native) and that’s where all its complications come from
Yes, one argument that I didn't make in the post but that does favor immediate mode is that you can somewhat straightforwardly convert from an immediate mode GUI to retained mode by just introducing your own abstractions. In some sense this makes you more disciplined about the FPS which could be a net win over all.
[Note that Tritium at least is translated into a number of a different languages. That part isn't that hard.]
hard is this: https://faultlore.com/blah/text-hates-you/
and this: https://lord.io/text-editing-hates-you-too/
those are both things most ImGUIs ignore. And, even if you pick some library that somehow handles the first you're left with all of the issue mentioned above.
To be clear, if I was writing a devtool (and I am actually) i'd reach for an ImGUI (and I did). But I'd be unlikely to use one for user facing tool.
By jason_oster 2026-02-146:17 Those are also things that most retained mode GUIs ignore, unless they are "platform native". Only a small number of GUI implementations get these things right because they are hard. There are many, many GUI implementations, and most of them are pretty rough, to put it mildly.
It has nothing to do with how the state is managed. (This is the only distinction between immediate and retained modes.)
By piker 2026-02-1410:48 Tritium is a rich text editor. I'm familiar with the issues outlined in those posts.
To be fair with a lot of the GUI frameworks in various ecosystems ... they try to solve different pieces of them.
By lazypenguin 2026-02-1316:571 reply Your recent post resonated with me deeply, as someone heavily invested in the Rust GUI I've fallen into this same conundrum. I think ultimately the Rust GUI ecosystem is still not mature and as a consequence we have to make big concessions when picking a framework.
I also came to a similar endpoint when building out a fairy large GUI application using egui. While egui solves the "draw widgets" part of building out the application, inevitably I had to restructure my app entirely with a new architecture to make it maintainable. In many places the "immediate" nature of the GUI mutable editing the state was no longer an advantage. Not to mention that UI code I wrote 6 months ago became difficult to read, especially if there was advanced layout happening.
Ultimately I've boiled my choices down to:
- egui for practicality but you pay the price in architecture + styling
- iced for a nice architecture but you have to roll all your own widgets
- slint maybe one day once they make text rendering a higher priority but even then the architecture side is not solved for you either
- tauri/dioxus/electron if you're not a purist like me
- Rewind 20 years and use Qt/WPF/etc.
By sorenjan 2026-02-1317:41 If your main gripe about the Rust GUI ecosystem is that it's not mature then rewinding 20 years and using Qt/WPF/etc sounds like an excellent alternative. Old and mature versus modern and immature.
> Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented.
Down the stack, low-level 3D acceleration is in a rough spot too unfortunately. The canonical Rust Vulkan wrapper (Ash) hasn't cut a release for nearly two years, and even git main is far behind the latest spec updates.
By the__alchemist 2026-02-1316:382 reply I am not convinced a thin FFI wrapper needs frequent updates, pending updates to the underlying API. What updates do you think it should have?
The underlying Vulkan API is updated constantly, the last spec update was about two weeks ago. Even if we only count the infrequent major milestone versions, Ash is still stuck at Vulkan 1.3, when Vulkan 1.4 launched in December of 2024.
By hickelpickle 2026-02-1316:561 reply Damn, I just dove back into a vulkan project I was grinding through to learn graphics programing, life and not having the time to chase graphic programming bugs led me to put it aside for a year and a half and these new models were able to help me squash my bug and grok things fully to dive back in, but I never even consider that the rust vulkan ecosystem was worse off. it was already an insane experience getting imgui, winit and ash to play nice together, after bouncing back and forth between WGPU, I assume vulkan via ash was the safer bet.
IIRC there is another raw vulkan library that just generated bindings as well and stayed up to date but that comes with its own issues.
By the__alchemist 2026-02-1316:573 reply Vulkano? I remember that! Looks like it was updated last week, but I don't know if it's current with the Vulkan API, nor how it generally compares to Ash.
WGPU + Winit + EGUI + EGUI component libs is its own joy of compatibility, but anecdotally they have been updating in reasonable sync. things can get out of hand if you wait too long between updates though!
By jsheard 2026-02-1317:12 Vulkano is a somewhat higher level library which aims to be safe and idiomatic. It looks like it generates its own Vulkan bindings directly from the vk.xml definitions, but it also depends on Ash, and this comment suggests that both generators need to be kept in sync so they're effectively beholden to Ash's release cadence anyway.
https://github.com/vulkano-rs/vulkano/blob/master/Cargo.toml...
Maybe that's so they can interop with other crates which use Ash's types?
By JBits 2026-02-1323:38 What would be the best way to use Vulkan 1.4 in Rust today? Using the C headers with bindgen or writing my own vk.xml generator?
By the__alchemist 2026-02-1316:46 Ah... that does make sense.
By delta_p_delta_x 2026-02-1317:27 vk.xml[1] is the canonical Vulkan specification; this is updated essentially weekly.
The C++ equivalent, Vulkan-Hpp[2], follows extremely closely behind. Plus, ash isn't just an FFI wrapper; it does quite a bit of RAII-esque state and function pointer management that is generally required for Vulkan.
[1]: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/xml/vk...
WGPU is a much higher level abstraction layer which itself depends on Ash for Vulkan FFI.
By adastra22 2026-02-1316:06 Thank you I didn’t know that. I assume it is well maintained then? Are there outstanding issues?
By queuebert 2026-02-1315:09 This is why I'm using LLMs to help me hand code the GUI for my Rust app in SDL2. I'm hoping that minimizing the low-level, drawing-specific code and maximizing the abstractions in Rust will allow me to easily switch to a better GUI library if one arises. Meanwhile, SDL is not half bad.
Honestly I think all native GUI is in a tough spot right now. The desktop market has matured so there aren't any large companies willing to put a ton of money into new fully featured GUI libraries. What corporate investment we do see into new technologies (Electron, SwiftUI, React Native) is mainly to allow developers to reuse work from other platforms like web and mobile in order to cut costs on desktop development. Without that corporate investment I don't think we'll ever see any new native GUI libraries become as fully featured as Win32 or Qt Widgets.
By DarkUranium 2026-02-1321:061 reply I 100% agree on pretty much everything. The "webapp masquerading as a native app" is a huge problem, and IMO, at least partially because of a failure of native-language tooling (everything from UI frameworks to build tools --- as the latter greatly affect ease of use of libraries, which, in turn, affects popularity with new developers).
To be honest, I've been (slowly) working towards my own native GUI library, in C. It's a big undertaking, but one saving grace is that --- at least on my part --- I don't need the full featureset of Qt or similar.
My plan for the portability issue is to flip the script --- make it a native library that can compile to the web (using actual DOM/HTML elements there, not canvas/WebGL/WGPU). And on Android/iOS/etc, I can already do native anyway.
Though I should add that a native look is not a goal in my case (quite a few libraries already go for that, go use those! --- and some, like Windows, don't really have a native look), which also means that I don't have to use native widgets on e.g. Android. The main reason for using DOM on the web is to be able to provide for a more "web-like" experience, to get e.g. text selection working properly, as well as IME, easier debuggability, and accessibility (an explicit goal, though not a short-term one --- in part due to a lack of testers). Though it wouldn't be too much of a stretch to allow either canvas or DOM on the web at that point --- by treating the web the same as a native platform in terms of displaying the widgets.
It's more about native performance, low memory use, and easy integration without a scripting engine inbetween --- with a decent API.
I am a bit on the fence between an immediate-mode vs retained-mode API. I'll probably do a semi-hybrid, where it's immediate-y but with a way to explicitly provide "keys" (kind of like Flutter, I think?).
By lioeters 2026-02-154:42 > make it a native library that can compile to the web (using actual DOM/HTML elements there, not canvas/WebGL/WGPU)
How interesting to hear. I've been exploring a way to write cross-platform GUI apps in C, using the Sokol library and possibly DearImgui. It's very convenient how it can build to WebAssembly and run the same way as the native app. But for larger canvas sizes it does eat more processing power, more than a typical website, and I was considering using DOM elements instead of canvas.
Good point about better accessibility too, and leveraging the feature set of modern web browsers.
A cross-platform GUI library that works with native and the web, so that the same application can be built for these targets with minimal changes. With the maturity and adoption of Wasm, I expect we'll see growing development in this direction. And some people have cautioned that treating the web as a blob of canvas and compile target to deploy opaque binaries is a step back from the potential of the web, like seeing the source (or source map at least), consistent handling of text, scrolling, accessibility features.
So I like your idea to "flip the script", I think in my own way I'm finding a similar approach.
By Vanuan 2026-02-144:00 I believe it's never been a better time for cross-platform desktop GUI. Vulkan API works on Windows, Android, Linux. Even web has Vulkan support. The only outlier is Apple.
On Linux, Wayland provides better drawing surface and input API.
The only missing piece is a high-level GUI and Vulkan/Metal compatibility layer. Along with ancient issue of packaging of course.
> We ignore for these purposes Zed's GPUI which the Zed team has transparently, and understandably abandoned as an open source endeavour
Do you have a source for this?
By osener 2026-02-1321:49 Ok so it is not going closed source, they are just going to extend it as they need to drive Zed features. Totally understandable for an in-house UI framework, this is why you’d build one yourself anyway. I can imagine maintaining backwards compatibility, doing releases, writing documentation and growing a community around it is a considerable distraction from their product work.
By piker 2026-02-1318:10 The Zed team said it themselves. There is a direct quote in the parent thread.
I'd love to read a writeup of the state of Rust GUI and the ecosystem if you could point me at one.
https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
I started writing a program that needed to have a table with 1 million rows. This means it needs to be virtualised. Pretty common in GUI libraries. The only Rust GUI library I found that could do this easily was gpui-component (https://github.com/longbridge/gpui-component). It also renders text crisply (rules out egui), looks nice with the default style (rules out GTK, FLTK, etc.), isn't web-based (rules out Dioxus), was pretty easy to use and the developers were very responsive.
Definitely the best option today (I would say it's probably the first option that I haven't hated in some way). The only other reasonable choices I would say are:
* egui - doesn't render very nicely and some of the APIs are amateurish, but it's quick and it works. Good option for simple tools.
* Iced - looks nice and seemed to work fairly well. No virtualised lists though.
* Slint (though in some ways it is weird and it requires quite a lot of boilerplate setup).
All the others will cause you pain in some way. I think the "ones to watch" are:
* Makepad - from the demos I've seen this looks really cool, especially for arty GUI projects like synthesizers and car UIs. However it has basically no documentation so don't bother yet.
* Xilem - this is an attempt to make an 100% perfect Rust GUI library, which is cool and all but I imagine it also will never be finished.
By nicoburns 2026-02-1315:57 I wouldn't bother watching Makepad. They're in the process of rewriting the entire thing with AI and (it seems to me) destroying any value they has accumulated. And I also suspect Xilem will never be finished.
Beyond egui/Iced/Slint, I'd say the "ones to watch" are:
* Freya
* Floem
* Vizia
I think all three of those offer virtualized lists.
Dioxus Native, the non-webview version of Dioxus is also nearing readiness.
By yencabulator 2026-02-2420:45 It seems GPUI is no longer viable as a general UI library: https://news.ycombinator.com/item?id=47003569
By eviks 2026-02-1917:34 > * Makepad - from the demos I've seen this looks really cool, especially for arty GUI projects like synthesizers and car UIs. However it has basically no documentation so don't bother yet.
Have you seen their intro that also has an image viewer building tutorial?
https://publish.obsidian.md/makepad-docs/Makepad+Introductio...
By bmitc 2026-02-1417:04 What's wrong with egui's virtual lists? It has support for them. https://docs.rs/egui/0.25.0/egui/containers/scroll_area/stru...
Unfortunately, it seems GPUI is no longer in development.
Iced looks great, but the developer is very open about it being a personal project (https://book.iced.rs/philosophy.html). That is appreciated, but for companies or even individuals wanting to adopt it, it's a big hurdle to get across.
I’m currently writing an application that uses virtual lists in GTK: GtkListView, GtkGridView, there may be others. You ruled out GTK because of its looks I guess, I’m targeting Linux so the looks are perfect.
Not just because of its looks to be fair. Not being native Rust is a pain, and GTK only really works nicely on Linux. At least without a ton of effort to fix everything (I think some apps like maybe Mypaint have done that, but I don't want to).
By WD-42 2026-02-1417:47 Def agree. It feels unnatural to be using gobject in Rust. Refcell everywhere. But the end result (at least on Linux) is fast, well integrated and looks nice.
By nu11ptr 2026-02-1315:37 Yeah, I need cross platform, and GTK looks quite foreign on Windows/macOS IMO. I toyed with custom themes, but couldn't find any I liked for a cross platform look (wanted something closer to Fluent UI).
By cess11 2026-02-1315:45 I've been somewhat involved in a project using Iced this week, seems pretty reasonable. Not sure how tricky it would be to e.g. invent custom widgets though.
I believe latest Iced versions do have a `Lazy` widget wrapper, but I believe that effectively means you need to make your own virtual list on top of it
By tribaal 2026-02-1317:18 Custom widgets aren’t particularly hard to do in iced, but I wish some of those common cases would be committed back / made available.
Except the above virtualised lists, another case I hit was layered images (sprites for example). Not very hard to write my own, sure, but it’d be nice to have that out of the box as in eg. egui
By Vanuan 2026-02-143:47
By kelvinjps10 2026-02-1315:34 I don't feel like having one main library for creating windows it's bad, I feel like that way the work gets shared and more collaboration happens
By piker 2026-02-1315:10 They're just straining already-strained resources on the "contributions" side and pushing interest in other directions (e.g. Electron).
By tonyedgecombe 2026-02-1315:27 What’s the point of writing open source if it’s just going to be vacuumed up by the AI companies and regurgitated for $20 a month.
Really? It seems better than ever to me now that we have gpui-component. That seems to finally open doors to have fully native guis that are polished enough for even commercial release. I haven't seen anything else that I would put in that category, but one choice is a start.
The problem is that Zed has understandably and transparently abandoned supporting GPUI as an open source endeavour except to the extent contributions align with its business mission.
I remember when that came out, but I'm not sure I understand the concern. They use GPUI, so therefore they MUST keep it working and supportable, even if updating it isn't their current priority. Or are you saying they have a closed source fork now?
Actually, this story is literally them changing their renderer on linux, so they are maintaining it.
> except to the extent contributions align with its business mission
Isn't that every single open source project that is tied to a commercial entity?
I don't know what the message means exactly, but I can't plan to build on GPUI with it out there, especially when crates that don't carry that caveat are suffering from being under-resourced.
By nu11ptr 2026-02-1315:23 IMO, as long as Zed uses it, we are safe. If it doesn't, we aren't. I'm keeping it that simple.
By iamnbutler 2026-02-141:22 They haven't. They are just heads down on other work. It wouldn't make sense for them to abandon it - they have no alternative. What that message was about was supporting _community_ prs and development of gpui.
Focus ebbs and flows at Zed, they'll be back on it before long.
By atombender 2026-02-1315:062 reply I tried gpui recently and I found it to be very, very immature. Turns out even things like input components aren't in gpui, so if you want to display a dialog box with some text fields, you have to write it from scratch, including cursor, selection, clipboard etc. — Zed has all of that, but it's in their own internal crates.
Do you know how well gpui-component supports typical use cases like that? Edit boxes, buttons, scroll views, tables, checkbox/radio buttons, context menus, consistent native selection and clipboard support, etc. are table stakes for desktop apps.
Yeah, running just gpui is kinda like writing a react app without a component library. It is going to be on you to implement all your components.
All of those are handled. Run the "story" app. It is very impressive IMO.
Components list: https://longbridge.github.io/gpui-component/docs/components/
By the__alchemist 2026-02-1316:44 I'm not sure about that analogy: HTML provides the basic components atombender laments are missing from GPUI.
By atombender 2026-02-1315:50 Thank you, that looks very promising indeed.
By iamnbutler 2026-02-141:44 I do think gpui needs a native input element (enough that I wrote one (https://github.com/zed-industries/zed/pull/43576) just before they stopped reviewing gpui prs) but outside of that I think it is pretty ok and cool that gpui just exports the tools to make whatever components you need.
I could see more components being shipped first party if the community took over gpui, or for some crazy reason a team was funded to develop gpui full time, but developing baseline components is an immense amount of work, both to create an maintain.
Buttons (any div can be a button), clipboard, scroll views (div, list, uniform_list) should all already be in gpui.
By airstrike 2026-02-1315:27 iced is doing great
By satvikpendem 2026-02-1315:087 reply Zed also stopped GPUI (their GPU accelerated Rust UI framework) development for now, sadly.
> Hey y'all, GPUI develoment is getting some major brakes put on it. We gotta focus on some business relevant work in 2026, and so I'm going to be pushing off anything that isn't directly related to Zed's use case from now on. However, Nate, former employee #1 at Zed, has started a little side repo that people can keep iterating on if they're interested: https://github.com/gpui-ce/gpui-ce. I'm also a maintainer on that one, and would like to try to help maintain it off of work hours. But I'm not sure how much I'll be able to commit to this
https://discord.com/channels/869392257814519848/144044062864...
By laweijfmvo 2026-02-1316:357 reply > We gotta focus on some business relevant work in 2026
Remember that post announcing the millions of VC capital they raised? This is the result
Using mainstream libraries instead of reinventing the wheel would have been a good decision with or without VC money.
I like Zed but it's still my secondary editor because it's missing usability features that I value in other editors. I think we all benefit if they focus their attention on the parts of Zed that differentiate it rather than writing new frameworks and libraries.
By pastel8739 2026-02-1318:563 reply Isn’t the thing that differentiates zed actually largely its performance? Using electron or GTK or whatever would not differentiate it in this way.
By dualogy 2026-02-1322:24 > Using electron or GTK or whatever
You say that like they're in the same category, but one is an embedded Chromium and the other a native windowing toolkit.
By satvikpendem 2026-02-1322:03 Yes, so I'm glad Zed at least did spend the time to reinvent the wheel, because it benefits everyone to focus on performance, not to mention we have a high quality piece of OSS at the end of it, as even if it's paused development for now, it can still be forked or otherwise iterated upon.
By julianbraha 2026-02-1320:011 reply They're switching to wgpu (another performant Rust library), not GTK or electron
By RussianCow 2026-02-1320:05 I think the parent meant that Zed could not have used an established UI library like GTK or Electron since performance was such a big focus of the editor.
By staticassertion 2026-02-1318:081 reply You vastly overestimate the amount of pressure a board can place on an early stage startup. The far more likely scenario to me (someone who raised VC money) is that the CEO likely looked at their run rate and decided to prioritize things more aggressively. This is hardly surprising and it has nothing to do with VCs.
Doesn't it have something to do with VCs? Does the company behind Zed actually make any money on their own?
By staticassertion 2026-02-1413:271 reply I mean, in the sense that they are VC funded and so I guess you can tie anything back to VCs? You could just as easily say it has something to do with the founders mother, who gave birth to them.
No, I don't think you could easily say that. You can't say it literally has nothing to do with VCs when VCs are the only reason they're able to keep operating financially.
By staticassertion 2026-02-1418:401 reply The founder's mother is the only reason they're able to operate at all.
If you want to talk about the VC I think you'll need to get more specific.
By staticassertion 2026-02-1423:32 I really couldn't have been clearer. The implication was that Zed made a decision because of pressure from a VC. I said that they were vastly overestimating the pressure a VC can exert on an early stage company.
You've then pointed out that the company is directly tied to the VC, which is true but just as relevant as saying that the company is tied to the founder's parents. You've failed to explain what different there is between the VC and a parent other than that there's a causal link in the existence of the company.
So I suggested that you substantiate that difference if you want to make a point about the VC.
I don't know what is confusing about this.
What's that, doing actual work rather than labor-of-love open source stuff? Seems reasonable.
Did you not raise a bunch of money from Sequoia? Sounds like you're in a perfect place to quit your job and hack on GPUI for us.
>What's that, doing actual work rather than labor-of-love open source stuff?
except the 'labor-of-love' stuff is what set the editor apart and why real users were choosing it and the 'actual business work' the moneymen are eager about is exactly what's in every other editor and what nobody asked for
By satvikpendem 2026-02-1322:051 reply They wrote GPUI as a business decision, to focus on performance, because they knew that that would be a core differentiator to all the other IDEs out there that use Electron for example. That they also liked writing it (as a "labor of love") is incidental.
Didn't they also invent Electron for their Atom editor when working at GitHub? Which then was hijacked by Microsoft and VS Code. Was Electron (Atom Shell) a core differentiator of Atom? Absolutely. Was it a business decision? No, it was a dream to use javascript/html/css to build a desktop editor. I think, similarly, Zed was an experiment to build a modern desktop app without any C++ legacy or OS API wrappers.
By satvikpendem 2026-02-144:18 Those creators own their company in the case of Zed, so it is a business decision. Otherwise they could've just gone with Electron again. The business decision is that they wanted to be different in the market, the speed of vim with the IDE capability of VSCode.
By satvikpendem 2026-02-1316:482 reply Without such venture capital, I doubt GPUI, at least to the level of complexity it has today rather than being a toy project, would have even existed. It costs money to develop open source sustainably.
By satvikpendem 2026-02-1316:59 Companies start with founders funding themselves through savings and friends and family rounds before institutional investors are usually even interested. But make no mistake, they start it as a commercial venture, otherwise they wouldn't have taken VC in the first place, nevermind that VCs wouldn't have funded it if not for their pitch on how it could become a billion dollar company.
And since Sequoia? It is primarily the Zed team working full time on it, which costs money.
IMGUI and other GPU accelerated toolkits exist and have been created without billons of VC revenue.
In fact the entire Qt group is just work 650m EUR
By satvikpendem 2026-02-1319:16 Who said anything about billions? I just said that it costs money to pay people to work on OSS, which is accurate as ImGui is sponsored by companies and Qt is a commercial entity with infamous licensing. VC doesn't necessarily mean billions in funding.
By dkersten 2026-02-1320:31 They really should focus on fixing bugs and improving basic functionality.
Eg if you edit or create a file outside of Zed, there’s a good chance it won’t show up in the file browser.
Also… multi window doesn’t exist so the multi monitor story is trash.
By ellieh 2026-02-1322:23 gpui existing in the first place is a result of them raising VC
By kitsune1 2026-02-1316:58 [dead]
While unfortunate, to me this just says any user requested features aren't going to get merged anytime soon. As is, it already runs on windows/linux/mac, and will need to do so maturely for Zed to function. Therefore, to me, this isn't that big of a deal, and when they need things like web support (on their roadmap), they will then add that.
I'm curious... does anyone have any PRs or features that they feel need merging in order to use GPUI in their own projects? (other than web support)
By satvikpendem 2026-02-1316:471 reply I recently saw a PR where the author implemented shaders but it was closed by the maintainers as the feature wasn't needed by Zed the editor.
Thanks. I probably could have answered my own question had I simply looked here:
https://github.com/gpui-ce/gpui-ce/pulls
and here:
https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Ao...
By satvikpendem 2026-02-1317:521 reply Sadly it doesn't actually look like gpui-ce has any activity, the maintainer merged one pull request (literally, #1) and then stopped. They should've just added more community maintainers to the GPUI repo directly rather than having a fork.
Yeah, why fork and create confusion if you don't plan to do anything with it?
By satvikpendem 2026-02-1322:05 The creator replied: https://news.ycombinator.com/item?id=47005761
By iamnbutler 2026-02-1318:122 reply I started the gpui-ce fork but I'm becoming somewhat more interested in a fresh framework that is more aligned with the rust ecosystem in general - using crates like glam/glamour, parley, palette, etc
Lots of gpui was built with build Zed/a text editor in mind directly, and as folks have mentioned here, it is hard for Zed Industries to justify work on gpui that is purely for the community. Nathan is usually pretty pragmatic around not optimizing early, and gpui is generally serving Zed's needs at the moment (from what I know, I haven't worked on Zed since July)
I do think ZI would generally benefit if gpui did get pulled out of Zed if there was a community that was passionate about taking it over... but that is time and effort in itself.
By satvikpendem 2026-02-1322:081 reply You might also want to look into Dioxus Native as it's doing a lot of what you're interested in too, with taffy and vello for example. The gaps I see in the Rust UI ecosystem as you asked are that I want a true cross platform solution for mobile, web, and desktop while most focus only on desktop, as I use Flutter currently for this purpose but need to pull in Rust crates through an FFI layer like flutter_rust_bridge, as well as a backend server in Rust and having to share types with the frontend through some agnostic format like GraphQL, so it'd be nice to have everything in one language. Dioxus Native does in fact bill itself as "Flutter but in Rust" which I'm looking forward to a lot.
How was it like working at Zed? Any reason for leaving?
By iamnbutler 2026-02-141:37 Cool, I'll take a look.
gpui will support web eventually - we always planned it, and i've tinkered with some folks on the team on it a bit. The problem is the crate needs to split into core/web/native (and maybe mobile?) as web needs a new executor and native has a number of deps that won't play nice with wasm...
someone did get a very claude-driven demo of gpui on the web up (you can find it in the discord somewhere.)
I would love that too though, a true cross platform solution.
> How was it like working at Zed? Any reason for leaving?
Working at Zed was great. I was employee #4 (#1 after the founders) - it was fun, often hard - Nathan & co helped me learn Rust and I fell in love with it.
I wanted to do something pretty specific (tl;dr, basically skunkworks type work) which was the reason I left.
There are always pros and cons to every role, but I appreciate that Zed is building from the ground up. DeltaDB will be very exciting - we were sitting on our hands waiting for it for a lot of the really exciting things we wanted to do with Zed.
Having to take on investors is never awesome - but as much as I don't like it, I do doubt Zed would never have existed without them.
But yeah, getting paid to design and write rust UI every day was a blast.
By iamnbutler 2026-02-1318:151 reply I would be curious to hear about where folks are finding gaps in the rust ui ecosystem though...
I've written quite a lot of rust UI code for Zed over the past few years so I'm mostly familiar with the pros and cons of gpui, but I haven't spent much time with Iced, Dioxus, Xilem, etc.
By EnergyAmy 2026-02-1318:32 Iced is promising, using it for a small side project. Fairly straightforward and easy to use, but lacking basic things from more mature libraries (unsurprisingly, since it's still early). If you want something like a QTreeView for example, you're on your own. It's cool that it supports WASM, though I'd call it alpha support for now.
Does this mean they’re struggling financially?
Yet more disruption caused by coding agents, I’m sure. We saw it quite visibly with Tailwind, now I can see if code editors are maybe struggling too, especially something like Zed which was probably still used mostly by early adopter type People, who have early adopted TUI coding agents instead.
I only use cursor and zed to browse code now.
By stonogo 2026-02-1317:09 I don't think it means they're struggling financially. I think it means they're not steering the ship alone any more, and are responsible to others. That's how accepting investment money generally works.
By throwaway613746 2026-02-1316:431 reply Ironic, because AI Agent integration is their business model.
By satvikpendem 2026-02-1322:09 Now it is, after their pivot from remote pair programming via collaborative text editing, not originally.
By norman784 2026-02-1317:53 The thing with GPUI is that the library itself is very low level and their scope is limited (by design I suppose), the ui with components is a separate crate with GPL license, while GPUI license is Apache.
As far GPUI has a great foundation, the community can built the components themselves.
Iced.rs is probably the better UI library anyways in the long run as it’s backed by a major hardware vendor.
By satvikpendem 2026-02-1316:441 reply I'm partial to Dioxus with their native renderer coming up, it should work cross-platform on mobile, web, desktop like Flutter (except web is actually HTML and CSS, not canvas) rather than only desktop which is what most Rust GUI frameworks are targeting.
By vatsachak 2026-02-1318:27 Dioxus is the real deal. It makes it super easy to create web-apps
I went from knowing nothing about web stuff to building this tool https://chakravarthysoftware.com/work_distributor in a week
Iced seems really promising, however, it's a passion project by a single developer. They very clearly stated that their goal is to follow their passions and desires first, everyone else second, and that it will always be a single person project. Their readme even discourages contributions.
Companies using it in production are often forking it as a result, and trying to keep their fork in sync. Ultimately, if the community wants iced to become a major and stable framework, it will have to be forked and a community development model built around it.
And I'm not saying this to disparage the author in any way, their readme even seems to suggest that that's exactly what they'd prefer.
By righthand 2026-02-1614:33 This is silly. Definitely use Iced.rs, no one cares about it’s early pre-1.0 state. It has good fundamentals and is easy to use. 99% of people on here aren’t building anything more than a vanity project anyways.
Not contesting your claim, but would you mind sharing what major hardware vendor you mean?
I love iced and wrote a decent amount of code using it, but in my mind the biggest sponsor is system76 - and as awesome as they are they aren’t a major vendor yet :)
By okanat 2026-02-1317:23 Has System76 started designing, or more correctly outsourcing more expensive custom motherboard designs, like Lenovo and Dell or are they still selling slightly customized white-label laptops?
By nu11ptr 2026-02-1317:41 Not sure how the UI engine itself compares, but to me it is all about the available components (as a total non-designer, although AI helps with that now). The only choice I have at the moment that would meet my needs is gpui, as gpui-component now exists.
There is also Slint : https://slint.dev They are also backed by a company, and have kept a stable 1.x release for some time.
By yencabulator 2026-02-1519:32 Slint is essentially proprietary-only. Licensing a library as GPLv3 severely limits where it can or should be used.
what is the business case for a text editor in a code writing agent world?
maybe they could pivot into the luxury boutique hand-crafted artisanal code market
By dxdm 2026-02-1318:25 Text editors are for cleaning up after the agents, of course. And for crafting beautiful metaprompt files to be used by the agentic prompt-crafter intelligences that mind the grunt agents. And also for coding.
