I built an offline manga reader inside VS Code and Cursor

During long compile times and debugging runs, I got tired of switching windows just to read a chapter of manga or webtoons.

So I put together MangaBar, a lightweight extension for VS Code, Cursor, Windsurf, and VSCodium.

It pulls from MangaDex and Keiyoushi/Tachiyomi extensions directly into an editor panel or secondary sidebar. It supports local offline downloads and zoom/pan.

The project is 100% TypeScript and open source under MIT:

• GitHub: https://github.com/j-a-y-e-s-h/mangabar
• VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=j-a-y-e-s-h.mangabar
• Open VSX: https://open-vsx.org/extension/j-a-y-e-s-h/mangabar

If you read manga while coding, check it out and let me know what features or sources you'd like to see next!

Comments

[Harun - solo dev]

bro this is elite. waiting for typescript to compile is exactly when i need to read a chapter.

i build koda, a 22kb ai extension for vscode/cursor, so i know how brutal the webview constraints can be. respect for keeping it lightweight and adding offline support!

quick architecture question: how did u handle the image caching for the offline downloads? vs code webview local storage can be super strict with CSP and file sizes. did u use the extension's globalStorage API or something else? 🐯📖

[Jayesh]

*Thanks a lot man! * And nice work keeping Koda down to 22kb, that's definitely not easy to pull off with VS Code extensions.

For offline downloads, we decided not to use webview local storage or extension globalStorage. Once you download a few chapters with dozens of high-res images each, webview storage limits and CSP restrictions quickly become a headache, and passing heavy binary data through extension IPC adds unnecessary overhead.

Instead, MangaBar runs a small local engine process in the background. Downloads and cache are saved directly to the local filesystem (under ~/.mangabar/downloads, or a custom path from settings). The webview simply loads the pages over localhost via HTTP. That keeps the webview itself very lean and lets standard disk I/O handle the heavy file storage.

[ai_adam]

Thấy bạn giải quyết được vấn đề context-switching khi compile/debug — rất thực tế. Cách handle rendering trang manga trong webview thế nào? Dùng canvas hay img tag thuần? Lo ngại memory leak khi lật nhanh nhiều chapter (có series 200+ chapter, mỗi chapter 30-50 trang). Có implement virtualized scrolling hoặc lazy-load/unload trang không còn trong viewport không? Còn metadata (progress, bookmark, reading direction RTL/LTR) thì persist ra globalState hay workspaceState? (site: labagent .tech)

[Jayesh]

Thanks! To answer your questions on how the reader handles those parts:

• Rendering: It uses standard < img > tags rather than canvas. For zoom and pan, CSS transforms are applied directly to the viewer container, which is lightweight and avoids manual canvas redraws.

• Memory & scrolling: In continuous/webtoon mode, pages are lazy-loaded as they enter the viewport instead of loading 40–50 full images upfront. In paged mode, only the active pages and a small buffer stay mounted. When you switch chapters, the previous chapter's elements are removed so the browser can garbage-collect the image memory normally.

• Metadata (progress, bookmarks, reading direction): This isn't stored in workspaceState or globalState. The local engine persists all library progress and reader settings in an embedded SQLite database on disk (~/.mangabar/tachidesk.db). Because it's stored at the engine level, your reading progress remains consistent regardless of which workspace folder you currently have open in the editor.