To use a comparison, have you ever picked up your phone to enter an TOTP / one time auth code and then accidentally found yourself texting a friend, or some other non-work activity. It’s particularly easy to get distracted if you have an open notification you didn’t see until you went to use that one time code on your phone.
Having a desktop app for your workspace helps hide Slack and other distracting items while context switching between different productivity apps.
The homepage explicitly calls out that "Cate is not a window manager replacement" yet as far as I can tell pretty much all its features are window management. And the ones that aren't would be better off living in their own dedicated apps anyway (or aren't going to replace people's preferred editors or terminals).
The infinite canvas idea sounds cool, and I'm not aware of a window manager that lets you zoom and pan around a massive "desktop", but it really does sound like the cool bits would be better implemented as an actual window manager. Then we can keep using our favourite IDEs, terminals, editors, etc. etc which is where the actual friction for change sits, and have the cool infinite canvas/docking/arranging stuff on top.
If you want their fancy windowing stuff, I think you also need to use their apps. Terminal, IDE, etc etc. Switching to a different terminal is friction, switching to a different IDE is a really big jump. My bet is most people aren't going to switch to a different IDE just to get different window management behaviours. And if the bundled IDE is brilliant, then you can't use that without this window management coming along for the ride too.
The differentiator for this project is the window management. Don't restrict that to just the re-implemented apps within the walled garden, and then you have the behaviour implemented in the right place.
Cate is an open source desktop workspace built around an infinite canvas. Instead of constantly switching between terminals, editors, browser previews, docs, and AI tools, you arrange everything spatially in one place.
Big improvements since the earlier posts:
docking, tabs, and splits detachable native OS windows git worktree support unified Cmd+K search much smoother rendering/performance on larger canvases AI provider + MCP integration Stack: Electron, React, Monaco, xterm.js/node-pty, Zustand.
Runs on macOS, Windows, and Linux. MIT licensed.
Would love feedback from people with heavy multi-window or terminal-based workflows.
8 days is a while?
I checked because I’ve had a similar idea for several years and wanted to see the earlier discussion on your shared Cate progress.
There’s nothing. You linked it 8 days ago on a brand new account and it died.
It’s definitely not dead though. Quite the opposite: the project is actively growing and improving. The first post didn’t get much traction, but we kept working on it, fixed a lot of rough edges, and v1 is in a much better state now.
I should have phrased that more clearly.
Right now Cate is a local desktop app because we wanted the first version to work closely with local projects, shells, files, node-pty/xterm, browser panels, Monaco, git worktrees, etc.
A self-hosted web version would need a different architecture: a backend that owns the PTY sessions, keeps them alive when the browser disconnects, handles auth/security, and syncs the canvas state to the client. Definitely possible, but a bigger shift than just “put the current app in the browser”.
Long term I think remote/headless workspaces and reconnectable sessions would make a lot of sense.
- I can't scale windows by grabbing the top edges like I can on the bottom/side edges.
- The command palette provides me with a list of open windows but selecting them doesn't do anything.
- A pinch to zoom gesture zooms in and out over unfocused panes but scrolls on focused ones. A keyboard modifier key I can hold that puts me into workspace pan/zoom mode regardless of where my cursor is would be great.
- It seems really erratic as to whether grabbing a pane and dragging will move it, scale it, or do nothing at all.
- The displayed cursor quite frequently has no correlation with what it's going to do.
- The mini map should really allow me to drag around my viewport on it rather than clicking and jumping to a specific place.
I really want to love this, its a great concept for working with complex projects but as I say right now its simply not there. Here's a few bonus things I'd love to see:
- The ability to rename terminal windows. Terminal 1,2,3,N is going to be unusable almost immediately.
- A jump to pane function (probably triggered via the command palette pane list) which allows me to select a specific terminal/editor/region/whatever and be jumped straight to it.
- Please add Kagi as a search engine option.
- As someone else has mentioned the real killer feature here would be the ability to run Cate with a remote backend, either accessed via a web browser or the Electron wrapper. I routinely use both VSCode devcontainers locally and remote machines over SSH and I'd love to be able to have a bunch of open sessions I can just jump back into.
The IDE has been "static" for most of the past ~20 years, with obvious improvements, but they were always incremental. The kind of exploration we see now is a bit more extreme, and I like it. It also seems like a lot of people are looking for alternatives, and I like some ideas. Even the funky ideas (I once saw a post comparing and proposing IDEs to follow RTS games UI) are interesting. Who knows what might stick.
I love looking through awesome-web-desktops. Most aren't infinite canvases but they are canvases, canvases of programs. There's fun stuff. UI paradigms being cooked up. I'll pitch in particular AetherOS, as being a neat web desktop that also is interestingly connected, networked, which is neat. https://github.com/syxanash/awesome-web-desktops https://bsky.app/profile/aetheros.computer
I do think we need to ask a little more "what next?". Taking Niri as a real desktop example, it's just so good, such simple but enjoyable new bones for a doing computing atop. So close to what was but so unique and nice. It intuitively connects me to the many many what ifs all around, makes me feel like there's such imminent possibility.
Especially today, who can make a UI that can be spoken well with, that is conversationally capable: that frontier feels barely explored. 9p is by far far far the most agentic desktop we have ever had, looked at this way. So beyond how it looks and works, how do computing surfaces express themselves?
LLM powered visual diagramming of the code as you work? The ability to edit the diagrams and have tje LLM apply that back to the code? Visualisation of test coverage over the UI you are working on? Allowing you to attach user submitted videos of bugs directly to tests in the code?
I don't know if any of that is a good idea, but I really hope a bunch of people try.
Unlike Cate, the windows of the terminals, editor, browser, etc, each one was handled similarly like Niri tiling scrolling window manager, that way you can use the keyboard to move around, where you can group windows in a column or split them, have different sizes, is not quite where you have a free form, but an horizontal collection of windows that you can scroll.
Is Cate's canvas per git-repo or can I add multiple?
I have a miro board as a notepad, I constantly add new stuff but at the same time its unmanageable.
Another example could be browser tabs, since there's no limit my current window holds approximately 60 open tabs which (which I dont use ofc) - this is the effect of chrome not having a native way to save stuff for later in a semantic way (you cannot search through bookmarks the same way you would search through google).
The success of this project will be defined by how well and easy users are able to retain the context (or content) of their canvas.
Navigation in default Obsidian is one of the weakest points imo
From a quick look, I agree there is overlap around the canvas editor idea. Cate is aiming a bit more at the broader project workspace layer: terminals, browser previews, editors, notes, agents, git/worktrees, docking/tabs/splits, and persistent layouts around a project.
But yes, fair callout. Appreciate the input.
Re-reading my comment made me realize it sounded condescending, where it was actually meant to emphasize that a canvas editor is a great idea! So I am very glad that there is development is this space.
Just felt the need to clarify this...
That's like the Antithesis of what I want to do and why I am on niri...
But to each their own I guess.
I see Cate also uses node-pty. I didn't know what psuedo terminals were before, it's cool stuff
Cate is a bit broader in scope: Electron desktop app, persistent project workspaces, node-pty/xterm terminals, browser panels, Monaco editors, docs, git/worktrees, docked tabs/splits, and now agent panels as well.
PTYs were a fun rabbit hole. The basic idea is simple, but making terminals feel native inside a canvas is where it gets tricky: lifecycle, resize behavior, restoring sessions, shell fallback, scrollback, performance, and not breaking when panels are moved/docked/detached.
Cool to see someone else exploring the terminal + canvas direction too. I’ll take a closer look at your repo.
It's a weird skill but after seeing website, screenshot etc. I need only couple of seconds to make an opinion. I then look into history of project etc., though it rarely contradicts first impression.
I think I do this because I don't trust thus I don't want to use such projects. Not because vibe coded/vibe-code driven projects are inherently bad (they aren't). Because I think low self-investment translates to low ongoing self-interest.
Since all software is buggy to some degree, I'm certain I'll find a dealbreaker that will never be addressed, and risk is rarely worth it.
One of the reasons why I did not go with an HTML based approach is because the XY translation gets really laggy with a couple dozen items.
Is that something you thought about and accounted for?
We chose Electron because the goal for v1 was to make Cate easy to try across macOS, Windows, and Linux without asking people to change their OS setup or use a specific window manager. A native implementation would probably give us more control and better performance in some areas, but it would also make iteration and cross-platform support much harder at this stage.
The HTML/canvas approach definitely has tradeoffs. Large canvases, XY transforms, terminals, browser previews, editors, and agents all in one workspace can get expensive if handled naively. We’ve been working on viewport-based rendering, transform handling, and avoiding unnecessary re-renders, but it is still an ongoing performance challenge.
So yes, we accounted for it, but I would not claim it is “solved”. v1 is much better than the early builds, and we’re continuing to improve it.
I posted it more as a progress/update thread because I was mainly looking for feedback from people with heavy terminal or multi-window workflows, but I agree that the format fits Show HN better.
Cate is not trying to compete with tiling/scolling WMs. Those are better if the main problem is arranging normal OS windows.
The goal here is more project-scoped: one spatial canvas where terminals, browser previews, editors, docs, notes, agents, git/worktrees, and saved layouts live together. More like a persistent workspace for a single project than a global desktop environment.
I'm not sure what problem it actually solves or aims at solving other than being cool?
Visual orientation does matter in UX of the real world, video game worlds and to some degree operating systems, is this the goal?
