Как Саймон Уиллисон перенёс LiteParse в браузер за 59 минут — перевод
59 минут с Claude Code — и опенсорсный PDF-парсер LlamaIndex заработал в браузере. Саймон Уиллисон перенёс LiteParse из Node.js CLI в чистый JS: PDF.js и Tesseract.js парсят локально, файл никуда не уходит.
59 минут с Claude Code и Opus 4.7 — и опенсорсный PDF-парсер LlamaIndex заработал прямо в браузере. Саймон Уиллисон перенёс LiteParse из Node.js CLI в чистый браузерный JS: PDF.js и Tesseract.js делают весь парсинг локально, файл никуда не уходит.
Ниже — перевод статьи Уиллисона: что такое LiteParse, почему его удалось перенести в браузер и как выглядит вайб-кодинг, когда автор не читает ни строчки из получившегося HTML и TypeScript.
Ключевые выводы
Что из этой статьи Уиллисона стоит унести с собой
Пример полезного вайб-кодинга и набор техник, которые можно повторить
LiteParse от LlamaIndex — классический PDF-парсинг без ИИ. Эвристики spatial text parsing вычисляют порядок чтения (колонки, подписи, сноски), а Tesseract OCR добирает сканы.
Браузерная версия собрана из тех же PDF.js и Tesseract.js — никакого сервера, данные остаются на устройстве.
Процесс: план в plan.md, команда «build it», очередь follow-up-промтов, Playwright + red/green TDD, деплой на GitHub Pages через Actions.
Время в Claude Code на фазу сборки — 59 минут. Уиллисон не прочитал ни одной строки получившегося кода.
Уиллисон готов привязать к проекту репутацию — редкий случай для его вайб-проектов. Статический сайт и полная приватность делают blast radius почти нулевым.
Что такое LiteParse и зачем он нужен
LlamaIndex выложили опенсорс-инструмент LiteParse — Node.js CLI для извлечения текста из PDF. Что приятно: LiteParse не использует ИИ-модели. Это старый добрый PDF-парсинг с фолбеком на Tesseract OCR (или другой подключаемый OCR-движок) для файлов, где «текст» представлен картинками страниц, а не самим текстом.
Сложная задача, которую решает LiteParse, — выдать текст в нормальном порядке, несмотря на причудливые макеты PDF. Авторы называют это «spatial text parsing», пространственным парсингом: хитрые эвристики распознают многоколоночную вёрстку и группируют блоки так, чтобы текст читался линейно.
В документации LiteParse описан паттерн Visual Citations with Bounding Boxes — «визуальные цитаты с ограничивающими рамками». Уиллисону идея нравится: отвечать на вопросы по PDF и прикладывать к ответу обрезанный и подсвеченный фрагмент исходника — хороший способ поднять доверие к ответам RAG-системы (retrieval-augmented generation — когда LLM отвечает, подтягивая нужные куски из базы документов).
LiteParse задуман как CLI для агентов. Запускается вот так:
Уиллисон попробовал инструмент с Claude и быстро понял: оставаться CLI-приложением LiteParse вовсе не обязан. Он построен на PDF.js и Tesseract.js — двух библиотеках, с которыми автор уже делал похожие штуки в браузере. Единственная причина, почему у LiteParse до сих пор не было чистой браузерной версии, — её просто никто не сделал.
Знакомство: LiteParse в браузере
Зайдите на simonw.github.io/liteparse/ и попробуйте инструмент на любом PDF — всё работает прямо в вашем браузере. Интерфейс минимальный: перетаскиваете файл, выбираете режим (с OCR или без), на выходе получаете распознанный текст и pretty-printed JSON, оба с кнопкой Copy. Опционально можно вывести превью всех страниц PDF.
Как это собрали с Claude Code и Opus 4.7
Всё началось в обычном приложении Claude на iPhone. Уиллисон хотел пощупать LiteParse и загрузил с телефона случайный PDF с таким промтом:
Clone https://github.com/run-llama/liteparse and try it against this file
Обычный Claude теперь умеет клонировать репозитории прямо с GitHub и ставить пакеты из PyPI и npm — даже без доступа к остальному интернету из контейнера. Уиллисон часто так пробует новый опенсорс с телефона, не доставая ноутбук. После нескольких уточняющих вопросов (весь диалог можно открыть в расшаренном транскрипте) он спросил главное:
Does this library run in a browser? Could it?
Ответ был достаточно убедительным, чтобы попробовать всерьёз. Уиллисон открыл ноутбук, переключился на Claude Code. Форкнул оригинальный репозиторий на GitHub, склонировал локальную копию, создал новую ветку web и скопировал последний ответ Claude в файл notes.md. А потом сказал Claude Code:
Get this working as a web app. index.html, when loaded, should render an app that lets users open a PDF in their browser and select OCR or non-OCR mode and have this run. Read notes.md for initial research on this problem, then write out plan.md with your detailed implementation plan
Подобные проекты Уиллисон всегда начинает с плана. Иногда он включает у Claude «режим планирования», но здесь ему нужен был план как артефакт в репозитории — поэтому сразу plan.md. Это позволяет итеративно править сам план. Заметив, что Claude решил отложить «canvas-encode swap» (замену способа, которым PDF.js сохраняет страницы картинкой — без неё не работает превью страниц в браузерной версии) на v2, Уиллисон дописал:
Update the plan to say we WILL do the canvas-encode swap so the screenshots thing works
Через несколько коротких правок получился plan.md, который автор счёл достаточно хорошим для реализации. И сказал:
build it.
И дальше Уиллисон по большей части оставил Claude Code работать самому: возился с другими проектами, периодически заглядывал проверить прогресс. Параллельно подбрасывал подсказки в очередь. Queued-prompts не попадают в стандартный экспорт транскрипта Claude Code, но их можно вытащить из папки ~/.claude/projects/ командой rg queue-operation --no-filename | grep enqueue | jq -r '.content'. Ниже — выдержка из этих follow-up-промтов с авторскими комментариями:
- «Реализуй через Playwright и red/green TDD, спланируй это тоже» — подробнее про red/green TDD Уиллисон писал отдельно
- «Давай использовать собственный рендерер PDF.js» — Claude начал экспериментировать с pdfium
- «Финальный UI должен показывать и текст, и pretty-printed JSON — оба в textarea с кнопками копирования. И должен быть mobile-friendly» — новая идея, как UI должен выглядеть
- «Делай маленькие коммиты по ходу дела» — см. ниже
- «В
index.htmlвверху страницы добавь ссылку на github.com/run-llama/liteparse» — важно кредитить зависимости - «
View on GitHub →— плохая формулировка: это репозиторий не браузерной обёртки, а базовой библиотеки LiteParse» - «Чекбокс
Run OCRдолжен быть снят по умолчанию» - «Когда пытаюсь распарсить PDF в браузере — вижу
Parse failed: undefined is not a function» — Claude тестировал в Playwright под Chrome, а оказалось, что это баг Safari - «Когда нажимают
Copy, пусть текст на 1,5 секунды меняется наCopied!» - «Оформи поле выбора файла так, чтобы длинные имена не ломали вёрстку в Firefox. И добавь drag-and-drop-зону, которая ещё и кликабельна» — скриншоты мелких UI-глитчей Claude воспринимает на удивление хорошо
- «Текст в drop-зоне сейчас чуть ближе к верху — поцентруй по вертикали» — точечная правка поверх предыдущей
- «В Safari на macOS всё ещё падает с
readableStream» — Claude починил, как только ему подсказали запустить Playwright в этом браузере; следующим промтом Уиллисон подтвердил: «works in safari now»
«Делай маленькие коммиты» Уиллисон теперь просит по привычке: это упрощает последующее чтение и ревью кода, а ещё, по его непроверенной гипотезе, помогает агенту работать эффективнее — дополнительный стимул планировать и брать задачи по одной.
Пока агент работал, Уиллисон решил, что было бы неплохо уже повзаимодействовать с ещё не завершённой версией. Он открыл отдельную сессию Claude Code в той же папке и спросил, как запустить сборку. Ответ — npx vite: команда поднимает dev-сервер с live-reload, так что каждая правка на диске сразу видна в браузере, и можно тут же просить «подкрути вот это».
Ближе к концу Уиллисон решил, что проект достаточно хорош для публикации. Новая сессия Claude Code, промт:
Look at the web/ folder - set up GitHub actions for this repo such that any push runs the tests, and if the tests pass it then does a GitHub Pages deploy of the built vite app such that the web/index.html page is the index.html page for the thing that is deployed and it works on GitHub Pages
После нескольких итераций получился рабочий GitHub Actions workflow, который собирает приложение через Vite и деплоит результат на simonw.github.io/liteparse/. GitHub Pages Уиллисон любит именно за такие кейсы: любой репозиторий бесплатно превращается в задеплоенное веб-приложение с произвольным build-шагом — и всё это настраивает Claude.
В проектах такого типа всегда есть риск, что модель «сжульничает»: пометит ключевые фичи как TODO и сделает их заглушками или срежет углы в требованиях. Ответственный способ это поймать — прочитать весь код. Но здесь это не планировалось, поэтому Уиллисон запустил OpenAI Codex с GPT-5.5 (у автора был ранний доступ к модели) и попросил:
Describe the difference between how the node.js CLI tool runs and how the web/ version runs
Ответ был достаточно подробным, чтобы убедиться: Claude не срезал углы в чём-то критичном. Суммарное время в Claude Code на фазу «build it» — 59 минут. Полный транскрипт сессии Уиллисон потом экспортировал своим же инструментом claude-code-transcripts — правда, без очереди follow-up-промтов, их экспорт пока не подхватывает.
Это ещё вайб-кодинг или уже нет?
Уиллисон педантичен в определении vibe coding: это не любое использование ИИ для написания кода. Вайб-кодинг — это когда вы используете ИИ и при этом вообще не просматриваете получившийся код и не думаете о нём. По собственному определению автора, LiteParse for the web — пожалуй, максимально чистый вайб-кодинг: ни одной строки HTML и TypeScript Уиллисон не прочитал (и, пока писал это предложение, даже полез проверять, JS там или TS).
И всё же этот проект не ощущается как другие его вайб-проекты:
- Это статическое браузерное приложение на GitHub Pages. Blast radius (радиус поражения от бага) почти нулевой: для конкретного PDF оно или работает, или нет.
- Приватные данные никуда не уходят — вся обработка в браузере, поэтому аудит безопасности не нужен. Уиллисон специально заглянул в network-панель и убедился: при парсинге PDF дополнительных запросов нет.
- Инженерный опыт всё равно потребовался — чтобы сообразить, что перенос LiteParse в браузер вообще возможен. Без этого никакой агент не справился бы.
Главное — Уиллисон готов привязать к этому проекту свою репутацию и рекомендовать его другим. В отличие от большинства его вайб-проектов, он не уверен, что дополнительные инженерные часы заметно улучшили бы первый релиз. «Оно работает как есть, и это нормально».
PR в апстрим Уиллисон не открывал — не обсуждал это с командой LiteParse. Но завёл issue: если команде будет интересно взять вайб-код как отправную точку для чего-то более официального — пусть забирают.
Частые вопросы
Что такое LiteParse?
Опенсорс-инструмент от LlamaIndex для извлечения текста из PDF. Не использует ИИ — это классический парсинг с эвристиками spatial text parsing плюс фолбек на Tesseract OCR, если PDF содержит изображения текста.
Чем браузерная версия отличается от CLI?
По сути ничем — под капотом те же PDF.js и Tesseract.js, которые CLI использовал в Node.js. Отличие — в том, где выполняется код: всё работает локально в браузере, PDF не уходит на сервер. По той же причине её удобно давать пользователям без необходимости поднимать бэкенд.
Что такое Visual Citations with Bounding Boxes?
Паттерн из документации LiteParse: когда RAG-система отвечает на вопрос по PDF, к ответу прикладывается обрезанный и подсвеченный фрагмент исходной страницы. Это повышает доверие — видно, откуда взят ответ.
Нужен ли OCR для обычных PDF?
Нет. Если в PDF — живой текст, он извлекается напрямую без OCR. OCR нужен только для сканов и изображений-текста. В браузерной версии чекбокс Run OCR по умолчанию снят.
Можно ли пользоваться из России?
Демо лежит на GitHub Pages (simonw.github.io) — в РФ открывается. Трафик на парсинге никуда не уходит: после загрузки страницы PDF обрабатывается локально, а сетевая панель показывает, что новых запросов нет. Сам исходник лежит в публичном GitHub-репозитории — при желании форкайте и хостите у себя.
Выводы
LiteParse for the web — не прорыв, а аккуратная обёртка поверх PDF.js и Tesseract.js. Но с конкретной пользой: приватный парсинг PDF без облака, который можно забрать и поставить у себя.
Главное в кейсе — не сама браузерная обёртка, а рабочий паттерн: план-артефакт в репозитории, запуск через «build it», очередь follow-up-подсказок поверх работающего агента и финальная проверка результата другой моделью. Такой процесс повторяется на любом проекте сопоставимой сложности.
Оригинал: Extract PDF text in your browser with LiteParse for the web Simon Willison, 23 апреля 2026 года. Апстрим-репозиторий LiteParse — github.com/run-llama/liteparse, демо браузерной версии — simonw.github.io/liteparse/.