Heynote: a block-based scratchpad for developers who live in a text buffer

The scratchpad problem Heynote targets

Most editors assume you are working on a project. You open a folder, you get a file tree, and the untitled buffer you use for pasting an API response sits in a tab you will eventually lose. Heynote inverts that. The README describes it as "a large persistent text buffer where you can write down anything you like", and the examples it gives are telling: a Slack message you do not want to accidentally send, a JSON response from an API, meeting notes, a daily to-do list. None of those belong in a repository, and all of them benefit from syntax highlighting.

The target reader is someone who already keeps a terminal open and reaches for a text editor to hold transient data. The block model is what separates it from a plain notepad: each block carries its own language, so the JSON block can be formatted while the Markdown block next to it stays prose. The README lists C++, C#, Clojure, CSS, Elixir, Erlang, Dart, Go, Groovy, HTML, Java, JavaScript, JSX, Kotlin, TypeScript, TOML, TSX, JSON, Lezer, Markdown, Mermaid, PHP, Python, Ruby, Rust, Scala, Shell, SQL, Swift, Vue, XML and YAML as supported languages, with auto-detection as a separate feature.

How blocks, buffers and the Electron shell fit together

Heynote is an Electron application, and the repository layout shows the split. There is an electron/ directory for the main process, a src/ directory for the renderer, a webapp/ directory, and shared-utils/ for code the two sides share. The editor itself is CodeMirror, which the README credits alongside Vue, Math.js and Prettier. That credit list explains the feature set: CodeMirror supplies the editing surface and language modes, Vue supplies the interface, Prettier backs the auto-formatting, and Math.js backs the calculator and currency conversion modes.

The unit of structure is the block. Pressing Ctrl/Cmd + Enter creates a new one, and the language attached to a block drives both highlighting and formatting. Buffers are the larger container, and the README lists multiple buffers in tabs plus a sidebar buffer tree. Search works within a single buffer or across several. Inline images are supported, which means the buffer is not strictly plain text.

One design consequence is worth stating plainly: because this is Electron, the app ships a browser engine with it. That is the cost of running the same editor on Mac, Windows and Linux without a separate native build per platform. The package.json confirms the packaging path, with electron-builder.json5 at the repository root and an appId of com.heynote.app.

Installing Heynote and formatting a JSON block

The README points to the website and the release page rather than walking through a download. Releases are tagged on GitHub, and the most recent listed is v2.9.1 from 2026-07-15. The README states the app is available for Mac, Windows and Linux, so the platform-specific install steps live on heynote.com and in the release assets rather than in the repository text.

Building from source is documented. The README says you need Node.js and then gives two commands, run from a checkout of the code:

npm install
npm run dev

The first installs dependencies and triggers a postinstall step that runs patch-package, which the package.json declares. The second starts Vite, which is the development server. The package.json debug block points VITE_DEV_SERVER_URL at http://127.0.0.1:3344/, so that is the address the dev build expects to talk to.

Once the app is open, the first real use is the one the README leads with. Paste a JSON response into the buffer, then create a new block with Ctrl/Cmd + Enter and set its language to JSON. The block gets syntax highlighting, and auto-formatting becomes available for it. Keeping each payload in its own block means a later paste does not disturb the formatting of the one above it.

For testing changes to the app itself, package.json defines the test scripts:

npm run test
npm run test:ui

The README says the first runs the tests and the second opens the Playwright UI. There is also a test:e2e script for the @e2e-tagged tests, and a test:main script that runs vitest, which the README does not mention.

Where Heynote stops being the right tool

The README answers the mobile question directly: "No, at the moment this is out of scope, sorry." If your workflow depends on capturing something on a phone and reading it on a laptop, Heynote is the wrong choice and the maintainer is not pretending otherwise. There is no sync story in the README either; it points to the documentation for where the buffer data is stored, which implies storage is local and that moving between machines is your problem, not the app's.

Collaboration is absent from the feature list. There is no sharing, no comments, no revision history. A scratchpad that holds the Slack message you have not sent is deliberately single-player.

The block model also has a cost. Because language is a property of a block, a long document that switches between prose and code repeatedly becomes a stack of many small blocks rather than one file. For a Markdown document with a dozen code fences, a normal editor with a Markdown mode is less friction. Heynote is optimised for fragments, not for documents.

Finally, the licence deserves attention rather than a shrug. The LICENSE file is present at the repository root, and package.json declares the licence as "Commons Clause MIT". That is a source-available licence with a restriction attached, not the OSI-approved MIT licence, which matters if you intend to redistribute the app or build a product on the code. The repository is not archived, and the last push was on 2026-06-24.

Heynote compared with a plain editor buffer and with a notes app

The nearest alternative is the untitled buffer in the editor you already have. VS Code, Sublime Text and similar tools all give you a scratch file with syntax highlighting, and you already know their key bindings. The difference is persistence and structure. An untitled buffer is tied to an editor window and disappears with it, while Heynote is built around the assumption that the buffer outlives the session. The block model is the second difference: in a general editor, one file has one language, so pasting JSON into a Markdown file gives you highlighting for one of them at best.

The other alternative is a note-taking application in the Notion or Obsidian family. Those are document-oriented: they give you a hierarchy, links between notes, and often sync. Heynote gives you none of that. What it gives instead is an editing surface with multi-cursor editing, Emacs-like or custom key bindings, spellchecking, and a global hotkey to show or hide the app, which is closer to a launcher than to a notebook. The README lists dark and light themes as well.

There is also a webapp/ directory in the repository with webapp:dev and webapp:build scripts in package.json, so a browser build exists in the codebase. The README does not present it as a supported distribution channel, and the documented platforms remain Mac, Windows and Linux.

Maintenance, upgrades and the licence in package.json

The release cadence visible in the repository is steady rather than frantic: v2.9.0 on 2026-05-06, a v2.9.1-beta on 2026-06-21, and v2.9.1 on 2026-07-15. The last push to the default branch was on 2026-06-24. The repository is not archived. Upgrades are handled through the release channel that electron-builder produces; the build config sets generateUpdatesFilesForAllChannels to true, which means update metadata is generated for beta and stable channels alike. If you install a beta, expect to be on a channel that receives its own update files.

The upgrade cost for a user is low because the app is self-contained. The upgrade cost for anyone building from source is higher: the build script runs vue-tsc --noEmit, then a Vite build, then a script that prepares a universal ripgrep binary, then electron-builder. A Node.js version mismatch or a failing patch-package step will stop that chain before packaging begins.

On licensing, the repository root contains a LICENSE file and package.json says "Commons Clause MIT". The Commons Clause adds a restriction on selling the software on top of the MIT terms. This is a factual difference from a permissive licence, and if your plan involves reselling a build or embedding the code in a commercial product, that is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt Heynote if you want one persistent text buffer where each block carries its own language, and you are comfortable installing a desktop build rather than running it in a browser. Do not adopt it if you need a mobile client: the README answers the mobile question with a flat no and calls it out of scope. Before committing, verify three things against the documentation: where the notes library is stored on your platform, which key bindings your muscle memory expects, and whether the Commons Clause MIT licence in package.json is acceptable for how you intend to use the code, since that is a source-available licence and not the same thing as plain MIT.

Frequently asked questions

Official sources

1. heyman/heynote on GitHub
2. Issues
3. Project website
4. README
5. Releases