Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Fresh – A new terminal editor built in Rust

sinelaw.github.io

Post reply on HN
Print view View original

1–10 of 158 posts

Show HN: Fresh – A new terminal editor built in Rust

#1

Post by _sinelaw_ »

I built Fresh to challenge the status quo that terminal editing must require a steep learning curve or endless configuration. My goal was to create a fast, resource-efficient TUI editor with the usability and features of a modern GUI editor (like a command palette, mouse support, and LSP integration).

Core Philosophy:

- Ease-of-Use: Fundamentally non-modal. Prioritizes standard keybindings and a minimal learning curve.

- Efficiency: Uses a lazy-loading piece tree to avoid loading huge files into RAM - reads only what's needed for user interactions. Coded in Rust.

- Extensibility: Uses TypeScript (via Deno) for plugins, making it accessible to a large developer base.

The Performance Challenge:

I focused on resource consumption and speed with large file support as a core feature. I did a quick benchmark loading a 2GB log file with ANSI color codes. Here is the comparison against other popular editors:

  - Fresh:   Load Time: *~600ms*     | Memory: *~36 MB*
  - Neovim:  Load Time: ~6.5 seconds | Memory: ~2 GB
  - Emacs:   Load Time: ~10 seconds  | Memory: ~2 GB
  - VS Code: Load Time: ~20 seconds  | Memory: OOM Killed (~4.3 GB available)
(Only Fresh rendered the ansi colors.)

Development process:

I embraced Claude Code and made an effort to get good mileage out of it. I gave it strong specific directions, especially in architecture / code structure / UX-sensitive areas. It required constant supervision and re-alignment, especially in the performance critical areas. Added very extensive tests (compared to my normal standards) to keep it aligned as the code grows. Especially, focused on end-to-end testing where I could easily enforce a specific behavior or user flow.

Fresh is an open-source project (GPL-2) seeking early adopters. You're welcome to send feedback, feature requests, and bug reports.

Website: https://sinelaw.github.io/fresh/

GitHub Repository: https://github.com/sinelaw/fresh

Show HN: Fresh – A new terminal editor built in Rust
sinelaw.github.io

Re: Show HN: Fresh – A new terminal editor built in Rust

#5

Post by _sinelaw_ »

giancarlostoro wrote: post #3

I'm a little annoyed that for a Rust based tool the recommended installation command is to use npm. Why? Is Cargo not good enough? Cargo seems exceptionally well to me.

I did it because not everybody has cargo installed. I'm using cargo-dist to create this npm package.

Re: Show HN: Fresh – A new terminal editor built in Rust

#7

Post by simlevesque »

I hate to be that guy, but did you know about Fresh, Deno's official frontend framework ? [1] If your app wasn't using Deno for extensibility it wouldn't be such a problem but since it is, I think it's gonna make searching for both harder.

[1] https://fresh.deno.dev/

Re: Show HN: Fresh – A new terminal editor built in Rust

#9

Post by Findecanor »

> Efficiency: Uses a lazy-loading piece tree to avoid loading huge files into RAM

I once started writing a text editor on Linux, and first went down a similar route: a piece table over a mmap()'d file. But I abandoned using mmap, because Linux file systems typically don't have mandatory locking enabled, so you can't be sure that the file data won't be modified by another program.

(Then I got bogged down in Unicode handling... so 95% of the code became just about that, and I tired of it)

Re: Show HN: Fresh – A new terminal editor built in Rust

#10

Post by Barathkanna »

giancarlostoro wrote: post #3

I'm a little annoyed that for a Rust based tool the recommended installation command is to use npm. Why? Is Cargo not good enough? Cargo seems exceptionally well to me.

I get the frustration, but I think the npm option actually makes sense here. A lot of users who’d benefit from a fast Rust tool aren’t Rust developers and won’t have Cargo installed. Shipping it through npm lowers the barrier while still giving everyone the performance benefits. It’s not a knock on Cargo, just a way to make the tool more accessible.
Post reply on HN