Всё началось с, казалось бы, простого желания
Мне хотелось написать небольшое приложение. Я работаю fullstack‑разработчиком, поэтому для разработки я решил использовать web‑технологии. Мне хотелось, чтобы я мог написать код один раз, и чтобы он запускался на всех моих устройствах (windows, linux, android).
Самое главное: написать приложение быстро
Мне хотелось использовать готовые инструменты. Я был уверен, что их мне будет достаточно. Посмотрел на существующие решения: electron, neutralinojs, apache cordova, tauri, capacitor, ... Все они мне не нравились по разным причинам. Разберём основные моменты:
Electron — в каждое приложение (даже в мой hello world) запихивает chrome (130mb). Для моего простейшего приложения — это очень плохо. Не умеет упаковываться в мобильное приложение.
Neutralinojs — backend нужно писать на c++, также не умеет в мобилки.
Apache cordova, capacitor — умеют упаковываться только в мобилки. Capacitor умеет упаковываться (с помощью electron) в десктоп, но проблему electron мы обсудили.
Tauri — хороший инструмент. Но он не для меня, не хочу писать на rust. Хочу всё приложение писать на typescript, к которому привык. Порог входа этого инструмента слишком высокий
Wails — тоже хороший, но использует Go.
PWA — хочется именно нативное приложение, которое можно было бы распространять в google play + проблема десктопа остаётся.
В общем, мне не нравилось, что при выборе мне всегда нужно с чем‑то мириться. Я подумал: а что если просто взять системный WebView и Node.js, и склеить их вместе?
Если не нашёл подходящее чужое, то напишу своё?
В какой‑то момент я решился погрузиться в разработку. Спустя вот уже два года (от идеи до работающей реализации), я представляю вам:
Webnative — Build Web, Ship Anywhere (такой слоган придумал)
Фреймворк объединяет лучшие стороны остальных других инструментов:
Не тащит за собой chrome.
Позволяет использовать js/ts и на бэке и на фронте.
Одна кодовая база для всех платформ сразу.
Абстракция апи от реальной реализации на платформах.
Старается изо всех сил дать ощущение «работает как магия» — удобный dx.
Главная цель проекта -
позаботиться о fullstack разработчиках, дать им удобный и простой инструмент для сборки приложений под любые платформы.
На данный момент поддерживаются linux, windows и android. Далее планирую поддерживать и остальные платформы: macos, ios.
Как начать пользоваться:
npm install -g @mindw1n/webnative
webnative init my-app && cd my-app
webnative build linux
Всё! Через 7 секунд у тебя готовый AppImage.
Довольно простой синтаксис: webnative build <platform>. При этом <platform> — это windows, linux, android или all (все по очереди).
Структура проекта тоже очень простая:
my-app/
app/ # любой фреймворк: React, Vue, Svelte, vanilla
app/backend/ # Node.js, точка входа index.ts / index.js
webnative.json # конфиг
Внутри app и backend есть по папке api, чтобы удобно абстрагировать специфичный для платформы код. Также я написал и опубликовал библиотеку webnative‑core, она позволяет необходимые апи для десктопа. Апи для мобильных устройств можно взять у Capacitor, они работают из коробки без проблем.
Как это работает изнутри (только для очень любопытных)
Если тебе интересно только «поставил и работает» — листай до следующего раздела. Здесь для тех, кто хочет понять, что происходит под капотом.
C++ хост‑процесс запускает два дочерних процесса: WebView с твоим фронтендом и Node.js с твоим бэкендом. C++ при запуске nodejs открывает pipe и передаёт fd процессу nodejs. Тот в свою очередь запускает http сервер и отправляет по трубе (pipe) данные:
{ "port": number, "key": string }
Эти данные нужны для того, чтобы фронтенд мог напрямую разговаривать с бекендом по защищённому каналу. Защищён он ключом «key», который сервер генерирует и при запросе проверяет.
Всё максимально кастомизируемо: бекенд пишется разработчиком, фронт тоже. С++ нужен был только чтобы их подружить.
Думаю, остальные детали реализации я опишу уже в документации к проекту.
Бенчмарки
Давайте сравним Webnative и Electron (самый популярный фреймворк для создания приложений на десктоп)
Все замеры — на реальных hello‑world проектах. webnative app с фронтендом и Node.js бэкендом против стандартного electron-builder
Время сборки
webnative build linux — 7.4 сек electron-builder — 19.3 се
Webnative собирается в 2.6 раза быстрее!
Размер дистрибутива
webnative (fullstack AppImage) — 36 МБ webnative (frontend-only AppImage) — 1.1 МБ Electron AppImage — 130 МБ
36 МБ против 130 МБ — потому что мы не тащим Chromium. А если бэкенд не нужен, то 1.1 МБ — это просто нативное окно с WebKit внутри.
Потребление RAM
webnative (+ системный WebKit) — ~300 МБ Electron — ~566 МБ
Важная оговорка: WebKit в случае webnative — системный, он уже есть на машине. webnative его не устанавливает и не дублирует. Electron же тащит свой Chromium в каждое приложение отдельно.
Заключение
Если у Вас остались вопросы или вы хотите присоединиться к проекту, то вот ссылка на github проекта: https://github.com/kl1ro/webnative.git
Также прикрепляю пример использования: https://www.youtube.com/watch?v=BdnwlwOvEts
Спасибо, что дочитали это до конца! Рад, что вам была интересна моя работа!
Комментарии (19)
MountainGoat
10.06.2026 17:46На Tauri можно писать на одном только TypeScript.
zartdinov
10.06.2026 17:46Это если backend совсем не нужен и не нужны взаимодействия с самой системой.
Но в таком случае проще даже тулзы юзать, которые оборачивают в Tauri.
Типа таких https://github.com/tw93/PakeMountainGoat
10.06.2026 17:46В Tauri можно из TS работать с файлами, сокетами, БД, а на мобилках с NFC и биометрией, и ещё там всякого.
mindw1n Автор
10.06.2026 17:46Доброй ночи, MountainGoat!
Хочу коротко прокомментировать ваши слова: да, технически можно. Но как только приходится выйти за рамки предустановленных API — нужен Rust. Вся бэкенд-логика, нестандартные системные вызовы, плагины — это Rust. В webnative бэкенд — это просто Node.js, вся npm экосистема доступна без ограничений.
Спасибо за ваше внимание к моему проекту!
xormark
10.06.2026 17:46не пишите ерунды, разберитесь сначала в вопросе.
Если приложение работает с
работает с файлами
сетью
UI
BD
окнами
уведомлениями
то можно почти 100% кода писать на TypeScript.
и даже если нужен winapi, есть способы интеграции node-процесса и делать import ffi from 'ffi-napi'
что является конечно же бредом, зачем тянуть ноду, когда можно просто в расте команды написать и дергать их из js
MiracleUsr
10.06.2026 17:46C++ хост‑процесс запускает два дочерних процесса: WebView с твоим фронтендом и Node.js с твоим бэкендом.
Nodejs таскаете с собой в дистрибутиве, или пользователю надо его обязательно в систему устанавливать нужной версии как зависимость?
Как оно работает с типичными андроидовскими особенностями - например, можно ли создать background/foregorund-сервис, подписываться на системные события, и т.д.?
Ну и на iOS оно не взлетит - Apple не пускает в AppStore ничего с JIT -компиляцией, а у вас там нода с V8.
mindw1n Автор
10.06.2026 17:46Доброй ночи, MiracleUsr!
В процессе дизайна этой системы я потратил кучу времени на то, чтобы придумать как это всё правильно упаковать. В проекте я ставлю приоритетом удобство пользователя. Занимаемое на диске пространство - это один из самых важных параметров!
Однако в первых версиях webnative (в тех, которые сейчас есть в открытом доступе) я сфокусировался на self-contained приложениях. В будущем я планирую добавить windows (setup) и linux (flatpak) дистрибьюцию. Эти версии: v4 и v5 соответственно, я постараюсь опубликовать в открытый доступ в ближайшее время. Они позволят грузить зависимости динамически. При этом nodejs как зависимость будет устанавливаться автоматически (при разрешении пользователя) глобально, что позволит многим приложениям использовать один и тот же бекенд.
Отвечу на вопрос про особенности мобильных платформ. Плагины Capacitor позволяют получить доступ к нативным api устройства. Их можно использовать вместе с webnative без ограничений.
Спасибо за ваше внимание к моему проекту!
xormark
10.06.2026 17:46Tauri — хороший инструмент. Но он не для меня, не хочу писать на rust. Хочу всё приложение писать на typescript, к которому привык. Порог входа этого инструмента слишком высокий
риально? а почему на ts тогда не писать, а растом только запускать webview?
а bun зачем существует? c электроном сравнивать это конечно мощно, го сравнение с tauri и bun
mindw1n Автор
10.06.2026 17:46Доброй ночи, xormark!
Electron взят для наглядности — это самый известный инструмент в нише. Tauri и webnative решают схожие задачи по-разному, каждый со своими компромиссами.
Спасибо за интерес к моей работе!
xormark
10.06.2026 17:46если честно выглядит так, будто он взят потому что он самый тяжелый и тормознутый инструмент в нише
acusric
10.06.2026 17:46Системный WebView будет сильно зависеть от оси (Linux WebKitGTK и Windows WebView2 — для коммерческих и моб. app не очень). Да и размерчик.. это из-за nodejs.
cmyser
10.06.2026 17:46Тоже хотел написать что в таури можно и чисто TS использовать и что апи у веба очень большой, но об этом и так много сказано
А у вас вот бэкенда это взаимодействие с нативной платформой получается ? А то непонятно зачем писать бэк рядом с фронтом если бэк всё равно хостить на сервере
И если да, то хотелось бы примеров в статье с работой системного при из TS, но тут получается что они на фронте нужны, а если они на бэке только как передать взаимодействия ?
MiracleUsr
10.06.2026 17:46А у вас вот бэкенда это взаимодействие с нативной платформой получается ? А то непонятно зачем писать бэк рядом с фронтом если бэк всё равно хостить на сервере
Судя по всему да. И тут дальше зависит от того, насколько грамотно продумана архитектура самого конкретного приложения, использующего этот рантайм.
Если разработчик запилит свое приложение так, что вся логика приложения все-таки живет в браузерной части, а на бэкенд оно лазиет от случая к случаю, только когда нужно как-то взаимодействовать с системой - это в целом ок. Хотя в этом случае довольно жирно тащить для такого целую огромную ноду (это и дополнительная зависимость, и потребление памяти), тут больше напрашивается какой-нибудь легковесный враппер системных API (файлы, сокеты, и т.д.) в REST API (или JSON-RPC через какие-нибудь вебсокеты), и можно обойтись без ноды. Подобный подход уже реализован в Tauri.
А если писать как обычно пишут под веб - на фронтенде только представление, а логика вся на бэке - то для десктопа/мобилок получается ещё более неэффективно, мало того что нужно тащить ноду на клиентскую машину и ее процесс висит в памяти, так например куча структур дублируется и в процессе браузера, и в процессе ноды, и данные гоняются туда-сюда на каждый чих.
cmyser
10.06.2026 17:46да
вот ялавка например как то так делала мост https://t.me/yandex4frontend/469
и я тоже считаю что это лучший вариант
веб уже сейчас почти всё позволяет, по сути новый уровень абстракции, при этом крайне безопасный ( слить данные зачастую можно только самому )
и крайне четкий и строгий по правилам
RigelGL
10.06.2026 17:46Попробуйте Flutter, тоже норм стандарт, развитая экосистема, собирается под веб, винду, линукс, андроид, ios, маки. По скорости +- также как и js на v8, если не быстрее. Памяти потребляет в разы меньше чем электрон.
Не знаю как вы собирали бандл электрона, но у меня на выходило около 80-85мб. После установки, конечно, было больше 200-300 мб.
lonberg
10.06.2026 17:46Задавался тем же вопросом(Chromium-200MB), … по началу. Остановился на связке python+webview. Позже спустился на землю: Ну что такое сегодня для типичного компа 200MB? Кто это вообще считает?
savostin
Чем Bun не устроил?
https://bun.com/docs/bundler/executables#full-stack-executables
Мобилки? Интересно как вы Node на iOS запускать собираетесь…
zartdinov
Есть Electrobun, но без мобилок, для десктопа удобно
mindw1n Автор
Доброй ночи, savostin! Отвечу коротко на ваши вопросы.
В проекте я использовал nodejs как стандарт индустрии, поддержку bun можно добавить в будущем.
Мобильные устройства - это отдельный мир. Я задавался вашим вопросом. Честный ответ - на мобильных устройствах нельзя запустить nodejs. Но что можно сделать - это добавить ts обёртку для java вызовов (если мы говорим про андроид). И ребята из команды capacitor с этим успешно справляются: https://capacitorjs.com/docs/plugins. Webnative спокойно поддерживает плагины capacitor, я проверял.
Спасибо за ваш интерес к проекту!