[alokedesai]

Disclaimer: I work at Warp (warp.dev) and wrote the initial How Warp Works blog post (https://www.warp.dev/blog/how-warp-works) that discusses why we chose to write our own UI framework.

This is a great article! Writing a custom UI framework to render on the GPU is a big cost--but it has been worth it for us. It has let us build a UI-heavy terminal while continuing to match the performance of some of the fastest terminals on the market (such as Alacritty). There is certainly an initial velocity hit for new engineers as they have to learn the semantics of our framework, but overall I wouldn't say it has a big detriment on our velocity as a consumer of the framework.

The callout to a11y is a good one--we have basic a11y support but it is by no means robust. There are additional downsides to building your own GPU-rendered UI framework other than a11y that I want to call out: you have to build most of the interactions with the platform yourself instead of getting it for free when rendering using system APIs.

One example of this is properly supporting i18n. A robust framework should support RTL text, positioning IME / the emoji picker, so forth. While implementing these yourself is doable (we have decent support for IME at Warp, for example) it requires an engineer or two to spend a few weeks to implement.

Text rendering is also a beast, see https://www.warp.dev/blog/adventures-text-rendering-kerning-....

For Warp, this has definitely been worth it, but it hints that the community needs better cross-platform GPU-rendered UI frameworks so people don't need to consistently build them themselves.

[buserror]

I don't want to brag, but I wrote GLterm (for OSX) in 2002 or so, first ever terminal emulator using OpenGL... It was a shareware tho (it was all the rage back then)...

In fact I probably reported and had ATI and nVidia fix bugs that even made it possible to have pixel aligned textures, partial refreshes of GL surfaces etc. It was all basic stuff, but it was always overlooked because "gaming"...

I find it hilarious that the GL UIs are all trendy now, I've done many of them professionally for the last 20+ years. One of first one was Sibelius v2, a desktop software for writing (engraving) musical scores, I converted the windows GD code to a GL backend all the way back then, rendering in textures etc etc.

[capableweb]

Interesting terminal, sadly not yet available for other platforms than Mac.

I went to your GitHub (https://github.com/warpdotdev/Warp) in order to see if I couldn't figure out how to build it for Linux, but seems that's like a "issues" repository and I cannot find the source code anywhere, nor is it linked on the main website (https://warp.dev).

I'm guessing at this point that it's on purpose? The source won't be available and it's only a closed source product?

[smoldesu]

They've talked about it being on the roadmap for a while, but I'm not aware of any recent advancement in getting it to work cross-platform (much less publishing the source).

Indeed, "at this point" they've demonstrated that cross-platform development is a low priority for them. Even if they do ship a Linux client, I feel like it will be a hard-sell when there are so many other terminals treating Linux like a first-class target.

[californical]

First off: thanks for sharing! Warp is building some real innovation in a Terminal, and it’s been a blast to follow the project.

It’s interesting that you mention this now - I’ve been a Warp user for a few months but just yesterday started seeking out another option because the UI has been feeling sluggish in Warp.

I installed alacritty and kitty, and they both feel insanely fast, comparatively. iTerm is approximately the same as Warp.

I think the difference is significantly smaller than most people would intentionally target with UI paints. But when I press enter, it feels like warp just has a minuscule delay, where kitty has instantaneous printed the results within the same frame that my finger hit enter.

Do you know if there’s a specific # of ms that Warp is targeting for a UI response from user input? I’m not at all an expert in this domain, but am curious if it’s “all in my head”, or if there really is a difference here. Do you have similar stats for other terminals?

Edit:

Only asking because I know it’s hard to get the right balance between extra feature & speed. The autocomplete & syntax highlighting are really awesome features that I love about Warp, and those likely take many more CPU cycles. Warp is far more powerful than kitty in that way. But how many ms does it cost to have those features?

I know the answer isn’t the same for everyone about what the right trade-offs are between features and speed, and I haven’t made up my mind yet which is more important for me, to be honest. Warp is crazy impressive and has been a step up in functionality. Again, really love the work you’re doing!

[efficax]

Would be great for the rust community and also for warp's rep among developers if y'all opensourced the UI framework. The rust ecosystem just doesn't have a good answer when it comes to choosing a UI lib yet.

[aconbere]

I was shocked to find that there wasn’t a fully fleshed out text rendering engine for WebGL.

On the one hand I think you could argue that if you have a lot of text maybe html would suit your needs better. On the other hand a lot of UIs just need some text and it’s so east for it to look like junk.

[flohofwoe]

There's an entire layer of mid-level web APIs missing to better connect WebGL and WebGPU to all the other browser systems (like text and DOM rendering).

Ideally canvas with WebGL and WebGPU would sit at the bottom of the browser API layer cake, the DOM at the top and squeezed inbetween public APIs for text, shape, CSS+HTML rendering. But instead we got this weird canvas thing dangling off as another high-level DOM element.

[aconbere]

Totally. It would be /amazing/ if I could leverage the browser's existing (and largely excellent) document and text layout engine from /within/ WebGL. Let me build up my UI as I want, and inject a DOM into that.