Waveterm
A new Electron-based terminal app, Waveterm, aims to modernize the command line with VS Code–style editing, rich inline previews, workspaces, and collaborative cloud features. Commenters are split between enthusiasm for improved UX and integrated tooling, and concern over performance, Electron’s latency and resource use, remote agents being auto-installed over SSH, telemetry defaults, and the risks of a VC-backed, EULA-governed tool in such a critical part of the developer workflow. The project is open source and free for local use, with plans to monetize optional cloud and team features, which some see as promising and others as a likely path to “enshittification.”
Technology stack, performance & latency
- Built with Electron / web tech; many see this as a red flag for a core tool like a terminal, citing memory use and sluggishness with large outputs compared to xterm/kitty/iTerm2.
- Others report Electron terminals (including VS Code’s) as “fast enough” in typical use, arguing that only edge cases (huge scrollback, multimedia) expose issues.
- Long subthread debates whether millisecond-level input latency is perceptible; some insist it’s critical for “serious” terminal users, others argue humans don’t notice 1–10ms and that graphics, not Electron per se, dominate overhead.
Features, innovation & UX
- Praised for design effort, workspace concept, rich previews (code, images, markdown, CSV), universal history, resumable sessions, and per-command metadata.
- Integrates a Monaco/VS Code–style editor for “quick edits” instead of vim; some users find that very attractive, others say vim users are already extremely fast.
- Several feel the UI is visually busy and hard to parse (prompt location, shadows, borders); some describe actual app as more overwhelming than screenshots.
- Image preview and some operations reportedly show noticeable latency.
Remote helper (mshell) and SSH model
- When connecting over SSH, the app attempts to auto-install an
mshellclient on the remote host without a clear upfront warning. - This surprises and alarms users who manage many or sensitive servers; they expect explicit prompts and the ability to avoid installing anything remotely.
- Some note similarity to VS Code’s remote model but emphasize they would not use such a tool for ad‑hoc hosts or production fleets.
Business model, VC & telemetry
- Project is open source and free for local use; creator states future revenue will come from optional cloud/team features (sharing, collaboration, sync, AI).
- Telemetry is present and default-on but can be disabled; any “phoning home” from a terminal is a hard no for some, especially in devops/security contexts.
- VC backing raises fears of future “enshittification” (lock‑in, upsells) or collapse if monetization fails; several request clear, legally binding commitments on privacy and long-term openness.
Target audience & scope
- Perceived primary audience: VS Code‑centric developers uncomfortable with classic terminals/vim, not hardcore terminal/tmux users.
- Currently Linux/macOS only; Windows support is planned, likely WSL‑focused.
- One commenter notes that, given its bash‑centric command model, it behaves more like a GUI shell controller than a fully general terminal, and doesn’t work cleanly with other shells (e.g., zsh).