Пролог

Сайты появились практически сразу после создания всемирной паутины. С каждым десятилетием браузеры и web-сервера развивались, каждое новое поколение меняло языки программирования и стандарты, с каждым разом индустрия предлагает всё более новый подход к разработке сайтов и web-приложений.

К чему это нас привело? Если вспомнить технологии нулевых, то решения тех времён имели недостатки, но для работы сайтов это был эталон: язык программирования PHP хоть и работал со скриптами небрежно, запуская их и сразу закрывая, на что требуются мощности, однако взамен он предлагал удобный читаемый код сверху-вниз и безопасную систему ошибок, которая прерывала скрипт и писала, в чём проблема. Сервер Apache был медленным из-за архитектуры “один запрос – один поток”, но блестяще решал проблему с конфигурацией сайта в виде единого файла конфигурации “.htaccess”

Но взамен старых технологий пришли современные решения, и посмотрите, вот что это превратилось: реакт убил саму идею веба быть динамическим и внедрил туда компиляцию, вместо единого верстака для инструментов дали npm install, который тянет половину Интернета зависимостей, а Django и прочие вообще превратили веб-разработку в конфигурационный ад.

Да, раньше технологии были не ахти, но по сравнению с современностью это эталон удобства и оптимизации. Вы когда-нибудь видели пустой проект с ts конфигами на 120 Мб? NestJS вам покажет. А пустой проект с 300 Мб от Реакта хотите? Я молчу про то, что после каждого изменения проект собирается минутами.

Мы потеряли файловый роутинг, где предельно ясно, что файл – это скрипт, вместо него мы получаем самописный роутер с запутанными правилами. Мы потеряли читаемость сверху-вниз, прощай PHP, да здравствует try-catch и if-else ад и простыня из import, module со странным синтаксисом. Мы потеряли конфигурацию в одном файле, теперь ты должен договориться с каждым модулем на их языке, чтобы просто запустить сайт.

Теперь мир принадлежит либо ветеранам с phpMyAdmin в руке, либо айтишникам с папкой node_modules в грузовике. Почему никто не предложил альтернативу и не собрал всё лучшее в единый инструмент, спросите вы? Потому что для индустрии это “велосипед” и молодёжь не может копнуть глубже команды require, ведь общество утверждает, что “это слишком сложно, это не будет востребовано, инженерам из корпораций¬ лучше знать”. Таким был и я.

Я познакомился с вебом в 2022-м году, чтобы понять, а как вообще создаются сайты. Я в детстве видел конструкторы наподобие a5.ru, но я не чувствовал себя создателем, ведь я мог только перетаскивать блоки и ещё платил за это. Но меня даже тогда не покидало ощущение, что если есть функциональные сайты и такие конструкторы, значит их кто-то создаёт. Значит, есть та отправная точка, которая называется “с нуля”. И значит такое могу создать я сам. Так, спустя месяцы обучения я познакомился с базой из HTML, CSS, JS и золотой компанией в лице Denwer, PHP, MySQL и phpMyAdmin…

В те времена, пока я собирал информацию по кусочкам из туториалов htmlbook и пытался понять, как оно работает самостоятельно - сверстники ходили на курсы для того, чтобы “войти в IT”. Мог ли я тогда пойти на них “за компанию”? Конечно, ведь там есть “волшебная палочка” в виде установки модулей или готовых компонентов. Но я не пошёл… Но почему?

Что-то внутри меня остановило. Я всё ещё чувствовал, что у меня нет контроля над своим проектом. Когда я попробовал создать пустой проект в Django, меня поразил шок от того, сколько странных файлов он мне накидал в пустую папку. Это был явный сигнал, что даже когда я скачал фреймворк на свой компьютер, все “мои” проекты - НЕ “мои”. И вместе с чувством потери контроля я ощущал и другое. Меня терзал вопрос “почему”. Почему современные решения создают кучу файлов, засоряя чистый проект, когда был эталонный “.htaccess”, хоть и с зубодробительным синтаксисом? Почему для создания пустого проекта или его изменения я жду какой-то “сборки” по несколько минут, когда PHP работал моментально и при редактировании файла всё менялось в реальном времени?

Мне отвечали “раз компании это используют, значит так надо”, и на удивление, я видел в этом ответе смысл. Ведь если за считанные года ВЕСЬ земной шар с инженерами, гениями и новаторами двигался от “удобства” к необъяснимым усложнениям, значит это техническая необходимость и по-другому было никак нельзя. Но что именно мешает сделать удобно? Ведь если подумать логически, раз современная индустрия отняла у нас удобство, то значит, ей есть, что предложить взамен? Может, это окупается бесконечным масштабированием или запредельной производительностью? Чем оправдано убирание удобства и простоты в web-индустрии?

Это и стало моей отправной точкой в расследовании, которая в итоге привела к тому, что я переписал весь стек веб-технологий под себя.

Что это?

Если официально, это вертикально-интегрированный SDK. (далее: движок)

Если простыми словами, то это экосистема, которая содержит в себе весь стек технологий в одном бинарном файле: сервер, фронтенд-движок, бекенд-движок, СУБД (основан на SQLite и поддерживает шифрование на SQLCipher), фильтр трафика (WAF-фаерволл), планировщик задач (нативный аналог cron), менеджер ресурсов, а также ограничитель ресурсов для веб-приложений (аналог pm2, позволяет распределять оперативную память и ядра процессора между веб-приложения). Всё это управляется через терминальную панель управления (дешборд), представляющую из себя TUI (позволяет управлять рантаймом через SSH и терминал).

Если преувеличивать, то это полноценная операционная система для веб-приложений, позволяющая контролировать весь процесс работы на любом уровне технологий. (операционная система в плане архитектуры)

Для чего нужен?

Движок расценивается как исследовательский эксперимент, который отвечает на вопрос “Можно ли сделать по-другому?”, предлагая свою альтернативную ветку развития веб-разработки с упором на удобство, экономию ресурсов и минимальное количество зависимостей.

Предназначен для малых и средних веб-приложений, инди-проектов, стартапов, прототипов и малого/среднего бизнеса. Позволяет быстро и просто развернуть веб-приложение на ограниченном железе.

Представьте себе Denwer или OSPanel, который можно скачать, запустить и он уже будет работать, а также помимо сборки стека технологий имеет свои технологии, которые идеально сочетаются друг с другом и позволяют выжимать из производительности максимум в связи с тесной связью сервера и модулей за счёт специфичной архитектуры.

Выгода для бизнеса

Как было сказано, концепт монолитного приложения для запуска полного стека технологий лучше всего подходит малым/средним проектам и предлагает в качестве преимуществ для компаний следующее:

1. Экономия на серверах – современные инструменты занимают гигабайты постоянной памяти, сотни мегабайт оперативной памяти и тратят вычислительные мощности впустую, в следствии чего на запуск и работу всего инструментария потребуется мощный сервер, за который и платить придётся больше. Cryanide может спокойно работать на самом дешёвом VPS за 250-300 рублей в месяц и чувствовать себя комфортно в ограниченных ресурсах при малой нагрузке. Сервер экономит память, RAM и мощности, что позволяет за те же деньги выдержать более мощную нагрузку за счёт рационального потребления ресурсов. Это не просто “небольшие средства”, а ежемесячная экономия, которая на долгие годы сэкономит гораздо больше средств, чем корпоративные решения.

2. Экономия на рабочих местах – современные инструменты приучили к чрезмерной масштабности и огромному количеству конфигов, что неоправданно расширяет штат и усложняет выпуск продукта. Концепция конфигурации в одном файле и портативности Cryanide позволяет сократить штат DevOps и Backend до нескольких грамотных JS-разработчиков, убирая лишние слои абстракций.

3. Оптимизация найма – даже не имея учебной программы, IT-курсов и туториалов, компаниям будет гораздо проще найти разработчиков под этот инструмент. Всё связано с тем, что движок написан по всем стандартам и правилам базового JavaScript и весь его инструментарий представлен в виде объектов с методами API. Разработчику не потребуется учить диалект наподобие JSX, VueJS или TypeScript, достаточно базовых знаний JS и умения работать с документацией. Это значительно расширяет поиск специалистов, убирая фильтр на узкую специализацию под конкретный фреймворк.

4. Улучшение дисциплины – помимо документации Cryanide предлагает best practices, где показаны лучшие методики написания кода на Cryanide, что позволит сохранить дисциплину и чистоту кода. Также Cryanide имеет отдельную документацию для ИИ-агентов типа “Cursor”, где находится весь материал, который позволит им разрабатывать проекты на данном движке, сохраняя все методики и стиль кода.

Технические характеристики

Движок на данный момент находится в разработке, однако имеет рабочий прототип MVP на NodeJS (признан создателем как “жирный” рантайм, переход на Bun).

Технологический стек:

• рантайм: NodeJS/Bun

• СУБД: SQLite (с нативной системой дампов, поддержка SQLCipher)

• TUI: blessed

• обработка изображений: sharp

• фронтенд: самописная система компонентов (part) с jQuery/React-подобными методами

• бекенд: самописная система запуска скриптов с изолированным контекстом в виде API-объектов (DSL-язык)

• конфигурация: единый файл конфигурации с API-объектами управления

Прототип в спокойном и рабочем состоянии потребляет примерно 30-40Мб оперативной памяти (90Мб при нагрузке). Исходный код движка занимает в сумме 40Кб (с учётом библиотек blessed и sharp +1Мб) + рантайм NodeJS на 80Мб.

Итого: рабочий прототип на NodeJS занимает 30-40 RAM и в бинарном виде весит ~84Мб с учётом всего NodeJS в комплекте.

По прогнозам релизный продукт (написан на Bun) планирует сократить потребление оперативной памяти и сделать одно из самых производительных и быстрых fullstack решений на базе Bun.serve() или uWebSockets, обгоняя транспилируемый NestJS.

На чём написан?

Написан на JavaScript и работает на рантайме Bun. Этот рантайм был выбран, потому что он, в отличие от NodeJS (на нём работает MVP движка), не тащит за собой много зависимостей и отдельных инструментов. Также из-за того, что Bun вместо V8 использует JavaScriptCore в качестве JS-движка, он работает стабильнее и рациональнее управляет оперативной памятью (меньше потребляет).

Также Bun следует той же идеологии, что и Cryanide – всё в одном, что позволяет ему не тащить зависимости, а держать в себе в виде монолита из взаимосвязанных инструментов.

Главными аргументами в выборе Bun являются встроенный компилятор в бинарник, который не требует зависимостей и самый быстрый HTTP-сервер в мире на основе uWebSockets как модуль.

В качестве библиотек использует только blessed для создания TUI и sharp для работы с изображениями на стороне бекенда. Больше ничего, только нативные и самописные модули.

Сильные стороны

Удаление лишнего жира: Современные инструменты используют много библиотек, которые в свою очередь тянут за собой множество зависимостей. Всё это – много места в постоянной и оперативной памяти, а также множество впустую потраченных процессорных тактов на сериализацию данных между модулями. Мой движок написан с нуля на чистом Bun, использует только нативные модули на Zig (C++) и модули без зависимостей в критических случаях.

Решение Event Loop: Поскольку JS однопоточен и сильно завязан на Event Loop, моя архитектура построена на эмиттерах, где ядро для запуска функционала не вызывает функции, блокируя Event Loop, а использует эмиттеры, чтобы модули посылали друг другу сигналы (эмиты) вместо прямого вызова команд. Для многопоточности используется система воркеров, которая запускает обработчики движка как дочерние процессы на каждое ядро процессора, которыми управляет главный процесс.

Распределение статики на RAM: По сравнению с обычным SSD оперативная память работает в тысячи раз быстрее и на I/O операции тратит сущие наносекунды, а также убирает физические накладные расходы передачи данных. Исходный код HTML/CSS/JS занимает сущие килобайты, но на нём работает весь сайт. Поэтому движок позволяет хранить код сайта прямо в оперативной памяти для мгновенной работы сайта, а также даёт полный контроль для определения, какие конкретно файлы и директории хранить в оперативной памяти, а какие нет.

Единый язык для всего стека: В связи с принципом работы движка, который является ядром запуска JS-скриптов, весь технологический стек управляется JS-скриптами. Следовательно, движок позволяет разрабатывать и настраивать фронтенд, бекенд, девопс, контейнеризацию на одном языке - JavaScript, что является главной визитной карточкой движка. Это значительно снижает порог вхождения, где для разработки веб-приложений достаточно знания базового ООП в JavaScript и документации.

Агрессивная защита: Движок в своём арсенале имеет опциональный модуль агрессивной защиты, который не просто защищает сервер от вредоносных скриптов для поиска узявимостей, но и ломает их. Принцип вредоносных программ состоит на поиске уязвимых URL, позволяющих получить доступ к закрытой информации или выполнению кода (“.htaccess”, “.env”, “/phpmyadmin”, “/wp-admin”). Движок позволяет расставить “капканы” (honeypot) на данные URL и если вредоносный скрипт пытается получить доступ к таким URL, то получает: gzip-бомбу и умирает от OOM-киллера; карусель редиректов (зацикливается); отравление данных (подставляет фейковые данные для злоумышленника, чтобы испортить достоверность его БД); URL-лабиринт (генерирует для скрипта фейковый HTML-контент с несуществующими ссылками и засоряет навигацию скрипта). (юридический момент: может показаться, что данная защита от скриптов незаконна и опасна для легальных индексирующих ботов от условного Google/Yandex, но это можно опровергнуть тремя фактами: это ответ на вредоносный запрос, а значит априори не атака; легальный бот-индексатор никогда не будет лезть в неиндексированные заведомо подозрительные URL, туда пойдёт только злоумышленник с осознанной целью поиска узявимостей; также это опциональный модуль, который необязателен для работы движка, так что его можно и не использовать)

Бекенд-система: Помимо строгой безопасности, где входные данные проходят жесткую валидацию (ключ, тип, минимальная и максимальная длина в одну строку функции) и БД изолирована от SQL-инъекций, была сохранена простота скрипта, как в старые добрые времена PHP, когда скрипт читался сверху-вниз без ада из try/catch и if/else. Система скрипта работает по прерываниям, бекенд-система позволяет с помощью функции setError(code, reason) обрывать скрипт и на автоматизме формировать ответ ошибки с кодом. Валидация и прочие системы работают подобным образом. Это позволяет вообще не использовать if/else и try/catch без боязни нарушения последовательности скрипта.

Поддержка индустриальных стандартов: Движок предоставляет полноценную самодостаточную экосистему с поддержкой модифицкаций, но не запрещает использовать посторонние решения из условного npm, для этого в проектах будет специальная система поддержки npm-пакетов с сохранением портативности.

Создание экосистемы: Само ядро движка имеет самодокументируемый SDK/API для его модификации со стороны пользователей, это позволяет добавлять пользователям любой функционал, которого им не хватает и делает движок открытой платформой с бесконечной расширяемостью.

Отличие от аналогов

Поскольку проект уникален в том, что собирает в себе абсолютно весь стек в единую портативную легковесную систему, и аналогов такого подхода на данный момент не существует, то можно сравнить его с полноценными стеками: LAMP, XAMPP, React + Django + nginx.

Начнём с того, сколько времени уйдёт на установку всех этих технологий, установку зависимостей, настройку конфигов, контейнеризацию. Это гигабайты впустую потраченного места на диске, сотни мегабайт оперативной памяти на всё и потраченные человеко-часы на настройку всего этого, чтобы оно хотя бы запустилось. А перенос с Windows-среды в настоящий сервер на Linux – это примерно столько же боли и потраченного времени.

Чтобы решить эту глобальную проблему настройки и оптимизации, мало написания своего фреймворка или IDE-среды. Именно по этой причине я решился на переписывание всего стека технологий, чтобы оптимизировать не мелкий этап вычислений, а весь цикл и показать, что значит по-настоящему удобно, благодаря чему я смог добиться максимального удобства и портативности.

Почему это не велосипед

Кто-то может сказать, что это “опасно” или “сложно”, ведь это изобретение своего велосипеда. Именно поэтому мы страдаем от раздутого софта и оверинженеринга и мир увидел этот движок сейчас, а не 10 лет назад. Потому что общество привыкло бить инженерам по рукам за слишком смелые решения, отговаривая от “создания своего велосипеда”, но не от безопасности, а от страха. Индустрия останавливает вас изучать матчасть и создавать технологии не потому что “умные люди уже всё придумали”, а потому что вы для них – не новаторы, а конкуренты. Для индустрии вы должны ходить на курсы и использовать готовое, потому что такие потребители выгодны и заменяемы в IT-бизнесе. Они вас оберегают от “велосипедостроения” не потому что ВАШ велосипед будет хуже, а потому что ИХ велосипед будет хуже вашего.

Моя цель здесь не просто показать свой аналог и сказать, что он лучше, а показать, что всё это время можно было сделать “по-другому” и что вы сами можете решать, как вы хотите создавать свои проекты: проходя через девятый круг ада конфигов и засоряя свой компьютер гигабайтами мусора или беря всё самое нужное и держа в изоляции только тогда, когда оно вам нужно.

Мой проект – не конкурент, а манифест в пользу того, что я такой же, как и вы. Если я смог переписать правила этой игры, то и вы можете это сделать. Программирование дало вам возможность оживлять железо не потому что “так популярно и так делают в айти”, а потому что вы МОЖЕТЕ!

Принцип работы

Движок помимо оптимизации также нацелен на максимальную простоту и удобство разработки, тестирования и деплоя. Движок представляет из себя портативный бинарный файл самого движка, папкой “Projects”, где лежат проекты по умолчанию, папкой “Temp”, где лежат временные файлы для оптимизации движка, папкой “Mods”, где лежат пользовательские или официальные модифицкации, и конфигурационный файл “default.conf.js”, который представляет из себя JS-скрипт, выполняющий роль конфигурационного файла для движка.

Под проектом подразумевается папка, где лежит файл “<имя_проекта>.proj.js”, который является JS-скриптом, где прописываются настройки: запуска веб-серверов (на каких портах и какие директории корневые), настройка железа (какой сервер какие ядра процессора использует и сколько может максимум потребить RAM), фильтрации трафика (какие диапазоны IP блокировать или разрешать), настройки оптимизации (настройка кеша, папки “.temp” для временных файлов и тд), бандлеры (какие файлы вшить в URL и какие моды подключить к проекту). Остальное – код сайтов, который пишет разработчик.

Поскольку у движка весь стек технологий управляется JS, то вся его работа состоит в том, что он является JS-ядром, который запускает разные JS-скрипты в режиме REPL с изоляцией. Работает по принципу двойных расширений, где файл имеет название “<название>.<вид_скрипта>.js”. Движок при запуске скрипта изолирует весь контент, предоставляя ему голый JS, определяет вид скрипта и исходя от него, добавляет в изолированный контекст те объекты, которые нужны скрипту для работы и дают возможность работать с движком через строго прописанный в этих объектах функционал (функции, методы, эмиттеры).

Главная фишка двойных расширений даёт возможность редакторам кода и IDE определять скрипты как JS-файлы и корректно подсвечивать синтаксис, при этом давая движку информацию о виде скрипта. Это позволяет использовать JS как синтаксическое ядро для создания своих расширений, где каждый тип скрипта определяет, какие объекты даст ему движок для использования. Это главная фишка в безопасности и простоте использования.

Это делает из движка миниатюрную операционную систему, где JS выполняет роль железа или ассемблера, который через Bun имеет доступ к низкоуровневым функциям и даёт приложениям строго определённый API для работы.

Подробные виды JS-скриптов:

- *.conf.js – конфигурационный файл для настройки движка, можно загружать по умолчанию при запуске, а можно загружать при работе через интерфейс, меняя настройки движка в реальном времени.

- *.proj.js – конфигурационный файл для настройки проекта, позволяет движку инициализировать папку, в которой он находится, как корневую папку проекта. При загрузке получает доступ к следующим объектам: Arch (позволяет запускать папки в проекте как отдельные файловые роуты на отдельных портах и доменах), Kernel (позволяет распределять нагрузку процессора, диска и RAM на разные роуты, где на каждый роут можно настроить, какие ядра процессора использовать, какой максимум RAM и пространства диска используется), Firewall (фильтрация трафика, какие диапазоны IP блокировать или разрешать), Config (даёт более детальные настройки проекта), Include (даёт возможность привязать к роуту определённый CSS/JS файл, который будет вшиваться во все html-файлы роута на уровне сервера, что уберёт нагрузку по количеству запросов и вычислениям на уровне клиента), Module (позволяет подключать кастомные модули или показывать список доступных модулей), Schedule (позволяет запускать бекенд-скрипты по расписанию, самописный планировщик задач).

Пример кода *.proj.js:

Route.scan(3000, "/", "/static/"); // (порт, URL, директория, от которой грузятся файлы)
Route.scan(3001, "/api", "/api/");
Route.to("/pages/app.html", "/app");

Firewall.deny("1.18.32.0", "1.118.35.255"); // блокирует диапазон адресов Нидерландов (potential VPN/DDoS);
Kernel.setCores([0, 1]); // запускает на двух ядрах
Kernel.setRamMax("mb", 4096); // макс 4 гб оперативки

- *.part.js – фронтенд-компонент, используется строго во фронтенде (если включён модуль на компоненты), позволяет настроить весь функционал компонента и встраивается в html-файл как JS-объект со всеми встроенными оптимизациями на стороне сервера. Загружается с помощью Include.

-  *.css.js – классовый компонент, можно загрузить как CSS-файл, который генерируется сервером на лету, имеет настройки и удобства для создания более сложных классов с преимуществом JavaScript.

- *.mod.js – компонент модификации, который использует API ядра движка для расширения его функционала. Позволяет писать парсеры, обработчики и свои альтернативные решения.

- (другие типы появятся при необходимости в процессе разработки)

Главная фишка движка и его проектов в полной портативности. Движок не требует установки каких-либо модулей, зависимостей или программ, он способен работать из флешки при запуске бинарника. Проект также портативен, не требует настройки самого движка, позволяет перекидывать саму папку проекта на другое устройство и запускать его через движок без каких-либо изменений.

План развития (Roadmap)

На данный момент движок находится на стадии MVP и переписывается на Bun с абсолютно новой архитектурой, которая в перспективе обещает отличную расширяемость, модульность и производительность. В релизной версии на Bun ожидается следующее:

• (релиз) полноценный инструмент для создания собственных модификаций движка (моды), в перспективе убивает претензии про Bus Factor и Vendor Lock-in

• (релиз) фронтенд-система компонентов (будут использовать React/jQuery стили кода), а также центр загрузки готовых компонентов для быстрой и удобной сборки интерфейса, в перспективе убивает претензии про скорость разработки и аналоги с готовыми компонентами.

• (релиз) документация с описанием принципа работы движка, описанием его объектов и методов, раздела best practices с лучшими примерами кода (как писать грамотно) и генератора промпта для ИИ-агентов типа Cursor, чтобы дать возможность ИИ писать код на данном движке со всеми best practices и рекомендациями чистого кода, поддерживая дисциплину и гигиену кода, а также для индивидуального обучения через ИИ. В перспективе убивает претензии про Vendor Lock-in и Not Invented Here.

• (в следующих обновлениях) типы роута Arch.cdn(port, address) и Arch.clone(port, address), позволяющий одной строкой прокидывать прокси к другому серверу на Cryanide и клонировать статику на другой сервер, тем самым дав возможность развернуть свой собственный CDN-кластер, в перспективе убивая претензии про расширяемость и Google Scale.

• (в далёком будущем) написание своего собственного JS-рантайма на QuickJS (весит 250Кб, потребляет 3Мб оперативной памяти) как абсолютного совершенства оптимизации. Будет разрабатываться после релиза и обновлений движка как хобби. Для MVP будет использоваться Python (в качестве Proof-of-concept), для релизного проекта будет использоваться C/C++/Zig. В перспективе убивает претензии про оптимизацию.

Панель управления (TUI)

Панель управления работает на blessed и представляет из себя окно, верхнюю панель со вкладками: “Консоль”, “Ресурсы“, “Проекты” (другие вкладки появятся при необходимости в процессе разработки) и нижнюю панель с командной строкой. При выборе определённой вкладки окно отображает необходимую информацию вкладки.

Движок содержит в себе систему командной строки, которая позволяет создавать свои команды и использовать модули движка безопасно и декларативно.

Вкладка “Консоль” показывает в окне список логов, куда пишется весь текст движка, модулей и трафика проектов (каждую часть логов можно отключить и включить обратно), а также введённые пользователем команды.

Вкладка “Ресурсы” показывает (предположительно через модуль Kernel, общающийся по FFI) ифнормацию о железе: ядра и нагруженности процессора, потребление и объём оперативной памяти, загруженность и объём постоянной памяти (дисков).

Вкладка “Проекты” содержит список проектов (не запущенных, а прописанных в списке файлов “*.proj.js” или папок в папке “Projects”), их состояния (“РАБОТАЕТ”, “ОШИБКА”, “ВЫКЛЮЧЕН”, “НЕ НАЙДЕН” и тд.), их потребление памяти и мощностей при работе, активность в виде сетевого трафик, списка включённых модификаций и кол-ва запросов.

Примеры DX (удобство)

Графический интерфейс Cryanide MVP:

Бекенд-скрипт “/users/login.js”:

// 1. Валидация входных данных
Api.validateInput("login", "string", 3, 20);
Api.validateInput("password", "string", 6, 100);

let login = Api.getInput("login");
let password = Api.getInput("password");

// 2. Логика и работа с БД
// Ищем пользователя по логину
let user = Database.get(global.db, "SELECT id, login, password_hash FROM users WHERE login = :login", { login: login });
if (!user) {
    Api.setError(401, "invalid-credentials"); // 401 Unauthorized
}

// Проверяем пароль
if (!Safe.hashVerify(password, user.password_hash)) {
    Api.setError(401, "invalid-credentials");
}

// Создаем JWT токен
// !!! Важно: в реальном приложении нужно использовать более сложный ключ и время жизни токена
let token = Safe.jwtCreate({ userId: user.id, login: user.login }, "super-secret-key");

// 3. Ответ
Api.setOutput(null, {
  success: true,
  token: token,
  userId: user.id,
  login: user.login
});

Пример скрипта конфигурации проекта “testApp.proj.js”:

// Структура файла: <проект>.proj.js (КОНЦЕПТ ДЛЯ ДВИЖКА)
// Чтобы появились объекты Arch, Include, нужно назвать как *.proj.js

// Структура команд архитектора
Arch.static(route, port, dir, indexPage = ["index.html"]); // Папка сайта
Arch.api(route, port, dir); // Папка API
Arch.cache(dir); // Папка сохранения кэша
Arch.error(port, code = null, url); // Страница ошибки (null -> все коды ошибок)

Include.css(staticApp, path); // Внедрение CSS-файла в каждую страницу (кроме ошибки)
Include.js(staticApp, path); // Внедрение JS-файла в каждую страницу (кроме ошибки)
Include.prop(staticApp, path); // Внедрение компонента prop -> файл *.prop.js (для внедрения всего можно указать папку)

Bundle.css(“/css/main”, [ // Склейка и минимизация CSS/JS на сервере
    “/styles/main.css”, // Перечисление стилей
    “/styles/ui.css”, // . . .
    “/styles/themes” // Можно также склеивать папки
]);

// Примеры использования этих команд
let mainApp = Arch.static("/", 3000, "/static", ["app.html", "app.htm"]); // 127.0.0.1:3000 -> site.ru/index.html
let filesApp = Arch.static ("/", 3001, "/uploads"); // 127.0.0.1:3001 -> files.site.ru
let apiApp = Arch.api ("/api", 3000, "/api"); // 127.0.0.1:3000 -> site.ru/api/script.js
let cache = Arch.cache ("./.cache");

Include.css(mainApp, "/styles/main.css");
Include.css(mainApp, "/styles/samples.css");
Include.css(mainApp, "/styles/ui.css");
Include.js(mainApp, "/scripts/main.js");
Include.prop(mainApp, "/components");
Include.prop(mainApp, "/static/menu.prop.js");

Arch.error(3000, 404, "/errors/404.html");
Arch.error(3000, 500, "/errors/500.html");

Примеры кода, показывающие эталон опыта разработки, сохраняя классику PHP-кодинга и файлового роутинга.

Практическое применение

Даже с учётом того, что проект находится в статуте MVP, он уже работает на некоторых проектах и на реальном бизнесе:

ALEKSEEV BOT – Telegram MiniApp для планировки фитнес-тренировок. Содержит в себе графики и анализ тренировок. Можно настраивать вес и процентаж жира, следить за своим прогрессом.

MinaOS – экспериментальная операционная система на JS, созданная ИИ для проверки документации дввижка на ИИ-агенте Cursor.

Ответы на вопросы

Здесь находятся ответы на часто задаваемые вопросы, основанные на практическом опыте и собранные из различных дискуссий.

(Not Invented Here синдром) – Вот вы рассказываете, что написали весь стек технологий с нуля на JS. Вы же понимаете, что JS сам по себе медленный и базовые утилиты на компилируемых языках будут работать гораздо быстрее. Получается, вы противоречите самому себе?

Как было указано в тексте, я чётко обозначил границу, что нативные модули на C++/Zig и библиотеки, сконцентрированные на вычисления – это база, а библиотеки с зависимостями на 20Мб, которые можно заменить одной регуляркой (json-strip-comments) – это излишнее усложнение и лишний код.

Что насчёт модулей криптографии, СУБД и других – когда я говорю, что переписал весь стек с нуля, я не имел в виду самописные модули. Как было указано в тексте, движок содержит в себе лучшие технологии и нативные модули (Bun.serve() на базе uwebsockets, bcrypt, SQLite), но с самописной обёрткой на JS, которая специально создана быть совместимой друг с другом. JavaScript используется как клей для лучших технологий в одном месте.

Также рантайм JS позволяет спокойно использовать dll-файлы и C++ код через модули, что делает JS лишь языком абстракций без вреда производительности.

(Bus Factor) – Вот вы говорите про то, что разрабатываете движок один. Им никто не будет пользоваться потому, что разработчик один, и если с вами что-то будет, его некому будет обновлять и исправлять критические уязвимости.

Тут стоит разграничивать разработку проекта и его поддержку, это разные вещи. Начнём с того, что мой проект – это не “очередной фреймворк”, а кардинально новый взгляд на всю веб-разработку, который предлагает совсем иной подход к созданию веб-приложений. Это полноценная платформа, которая позволяет себя улучшать, дав доступ к API через систему модификаций.

Очевидно, что проект недоделан, и все аспекты архитектуры и концепта неизвестны никому, кроме самого автора. Поэтому доделывание или дописывание движка ДО разработки - это то же самое, что дописывание второго тома Гоголя: извращение авторского видения и додумывание оригинальной идеи.

Я не против модифицикаций и открытости исходного кода, но это стоит делать, когда движок и его ядро полностью готовы. Поэтому когда движок выйдет в релиз, и его исходный код будет доступен на гитхабе, тогда любой сможет его спокойно форкать, писать на него моды и парсеры, ведь это уже будет законченное произведение с понятным окончательным замыслом автора, которое дружелюбно к фан-сервису.

Да и в целом ставить крест на пет-проекте лишь за то, что разработчик один, что присуще всем пет-проектам, неверно, особенно когда продукт ещё не вышел.

(Google scale) – Это здорово, что вы решили сделать такой проект для разворачивания веб-приложений. Но вы же понимаете, что ваш проект слишком мелкий и многие решения популярны именно по той причине, что индустрия их пробовала десятки лет? Что будет с вашим движком, когда у них будет слишком большой трафик?

Начнём с размера: слишком большой трафик – это понятие растяжимое. Если подразумевается трафик уровня мелкого/среднего стартапа, то мой движок для них и создан, и он покажет производительность лучше, чем аналоги, потому что он экономит ресурсы и бережно к ним относится, он на такие проекты и нацелен. Про удобство разработки и развертки вообще молчу.

Если подразумевается трафик уровня гугла, то: во-первых, для решения проблем гугла у нас есть инструменты гугла, а во-вторых у них для такого трафика есть целые кластера мощнейших серверов, им не жалко потратить пару сотен мегабайт оперативы на запуск докера, потому что это капля в море и докер как раз и создавали для решения глобальных проблем.

Мой движок нацелен строго на мелкие/средние проекты, который прост, удобен, лёгок и будет комфортно себя чувствовать даже на дешевом VPS за 100 рублей. А до масштабирования под трафик бизнесу нужно ещё дожить, так что можете не переживать, мой движок удовлетворит ваши потребности сполна.

Притом изучив вопрос CDN-инфраструктуры и масштабируемости до полноценных серверных кластеров, у движка будет решение в виде создания самодельной CDN-системы и клонирующего статику прокси. Всё это будет управляться в одну строку конфигурации и позволит соединять сервера как кластеры с CDN.

(Авторитет) – То есть вы считаете, что вы – студент-самоучка, сделали то, что не могут сделать лучшие инженеры за десятилетия? Не кажется ли вам ваша уверенность самообманом?

Нет, не кажется. Прогресс зачастую всегда держался на том, что из всего земного шара кто-то один мог придумать и создать то, чего не могли сделать всем миром. Индустрия знает много таких примеров: Джон Кармак, Линус Торвальдс, Стив Возняк, Тим Бёрнерс-Ли… Все эти люди создали революцию, будучи такими же самоучками, потому что горели этим. Моя цель - сохранить этот огонь в глазах людей и показать, что даже в мире техногигантов всегда есть, что придумать, главное к этому стремиться.

Если вы являетесь таковым, то мой SDK и документация в открытом доступе и вы сможете создать моды и добавить поддержку индустриальных стандартов, это поможет развить индустрию инди и стартап проектов. Либо же написать свой инструмент гораздо удобнее и лучше, я буду этому только рад, ведь именно честная конкуренция позволяет совершенствовать технологии. Это будет гораздо полезнее для людей, нежели попытка задушить перспективный проект.

Тем более, я уважаю компетентность условных инженеров Google, что они могут сделать лучше меня. Но вот ХОТЯТ ли они, сидя в золотой клетке под назаванием “Googleplex” – это уже другой вопрос.

(Новаторство) – Почему вы так уверены в том, что до вас такого решения не существовало? Очевидно, что если подобный подход не используют, то, наверное, он хуже классического стандарта.

Это одна из главных проблем не только индустрии, но и общества: подражание социуму и авторитетам. Многие считают, что “если так в обществе принято, значит никак иначе”, но никто не вдумывается в то, а почему так принято, кто это внушил и какие были альтернативы.

Меня не устраивало решение индустрии, меня мучали все эти проблемы. Я поддался большинству? Нет, я разбирался, спорил со многими программистами, шёл до конца, когда все называли мои попытки “велосипедом”. И только после трёх лет труда я это сам создал и лично убедился в том, что я был прав, и делать по-другому не просто была возможность, а так даже лучше. Я на своём движке уже как год делаю сайты для фриланс-заказов, решив все проблемы в разработке и сэкономив кучу нервов. Вдумайтесь, уже целый год настоящий бизнес работает полностью на моих самописных технологиях!

Так и получается, что у меня на руках исходный код, тесты, примеры и практика, это и отличает меня от большинства стартапов.

(Патент-приманка) – Вы молодцы, что сделали такой движок, но вы же понимаете, что если разработка хорошая, то её могут украсть? Пока что вы просто теоретики, так что для признания вам стоит запатентовать свою технологию у нас, чтобы иметь вес, и чтобы её никто не украл.

Благодарю за такую заботу ко мне и моему проекту, но я предпочитаю использовать стратегию Prior Art вместо патентной системы, так как история меня научила тому, как это работает. Я не хочу становиться новой Xerox PARC, у которого Apple выкупит патент на компьютерную мышь и графический интерфейс за копейки, после чего подаст как свою инновацию, потому что на неё была “бумажка”.

История показала, что патентная система даёт права на проект не создателю, а юридической системе. У людей много рычагов давления, так что у компаний с целым отделом юристов нет никаких проблем выдавить из тебя патент. Именно поэтому проект должен попасть в руки общества, а не частного лица, ведь только так его невозможно будет забрать.

Именно поэтому мой проект имеет DOI-код, который индексируется всеми патентными системами и анти-плагиатами. Все статьи про движок выпущены на публичных площадках и имеют слепок на Wayback Machine. И именно поэтому открытый исходный код движка лежит на гитхабе под лицензией aGPLv3.

Тиму Бернерсу Ли не понадобился патент, чтобы быть создателем Интернета. Наоборот, он отдал его обществу. Он хотел, чтобы Интернет был открыт и свободен для каждого? Так почему Cryanide не должен быть открыт и свободен для каждого?

(Реклама) – Я посмотрел вашу презентацию и заметил, что вы как будто хотите продать ваш проект. Это научная конференция, и вы не похожи на человека, который хочет просто рассказать о своём проекте.

Если учитывать, что научная конференция – это одна большая рекламная площадка для студенческих проектов спонсорам IT-компаний, то да, это реклама. Такая, как и требует этого формат.

(Паранойя) – Меня больше смущает ваша боязнь того, что ваш проект украдут. У вас сомнения на всё, словно у вас паранойя.

Вы можете меня назвать параноиком, но это скорее компетенция. Моя паранойя – не просто боязнь всего и теории заговора, а базовая компьютерная грамотность, нацеленная не потерять свой проект. Наша история знает множество примеров кражи интеллектуальной собственности и компаний, которые продали свои изобретения за бесценок и остались без всего. И я не хочу продолжать эту историю.

Как я люблю говорить: “Каждый инфобезник – параноик, но не каждый параноик - инфобезник”. Если мне страшно потерять мою технологию, значит для меня это не просто “поделка” для жюри, как бы вам это не казалось.

(Монолит) – Как я понял, у вас движок представляет из себя монолит? Вы же понимаете, что для веба стоит применять микросервисную архитектуру?

Вы путаете “модульность” и “распределенность”. Распределенность делит проект на разные части, чтобы условная команда на 100 разработчиков не мешала друг другу мерджами и коммитами в общий код, это больше инструмент для менеджмента и дисциплины. А модульность – про разделение жизненноважного кода в программе (то есть ядра) и дополнительного функционала, без которого программа может спокойно выполнять свои функции.

Сейчас микросервисы представляют из себя панацею, которая не защищает сайт от падения, а лишь имитирует его работоспособность. Какая разница, упал ли только бекенд или весь сайт, если вывод один: сервис не работает и выдаёт ошибку 500?

Организм тоже вполне себе микросервисный, но если у человека схватит сердце или откажет мозг - он умрёт. И организму уже будет не важно, все ли зубы целы и все ли пальцы на ноге, подобно красивой ошибке 500 на фронтенде. Да, труп выглядит более презентабельно, но если жизненноважный орган перестал работать, то организм жить без него не сможет – это смерть.

В этом и суть, почему микросервисная панацея – это миф. При падении части системы сайт, конечно, сможет показать ошибку 500 более красиво, но только смысл?

(Пиар) – Я признаю, что ваш проект в целом способен конкурировать с другими популярными решениями. Но вы же понимаете, что вашим движком никто не будет пользоваться, потому что на него нет курсов, компании ваш движок не используют и в целом на него нет так много документации и информации в Интернете?

Отвечу вопросом на вопрос: в чём виноват движок?

Моя цель для инвесторов – показать инструмент, который может выполнять коммерческие задачи с меньшим потреблением ресурсов и с более удобными условиями работы для разработчика, а также дать подробную документацию, которая проинструктирует: как его правильно использовать и развивать. Цель движка – стабильно работать. А то, есть ли у этого инструмента курсы, вакансии и туториалы в ютубе – это уже ответственность инвесторов и спонсоров, так как это уже зависит от денег, я не прав?

Разработчик не виноват в том, что у него нет миллиардных вложений на продвижение своего инструмента, его цель – разработка. А теорема про то, что “если продукт хороший, то им будут пользоваться” – это один из самых старых мифов про так называемый “рыночек”.

Возьмём React, который принёс в мир динамического веба “компиляцию”, убив саму идею “динамического” веба. Казалось бы, плохое для индустрии решение, которое запустило идею компилировать интерпретируемый код, но оно популярно. Причина популярности – его создала Meta, разработчик Facebook и WhatsApp, у них было безграничное количество денег на продвижение своего инструмента, чтобы получить дешевую рабочую силу.

Теперь возьмём хорошие популярные примеры: язык программирования Rust, у которого есть благая идея дать низкоуровневое программирование с безопасным контролем памяти. У него есть своя аудитория, но серьёзные корпорации его не используют, потому что есть C/C++.

Однако, вдруг с 2025 года дистрибьюторы Debian и Ubuntu решили без причины переписать абсолютно все утилиты на Rust, а Microsoft пообещала к 2030 коду переписать весь Windows вместе с ядром и использовать для этого ИИ, достигнув “удаления каждой строчки кода на C”. Компании “Arch Linux Package Management” агентство Sovereign Tech Agency выделило 500 тысяч долларов, чтобы они переписали пакетный менеджер pacman на Rust-аналог.

Почему корпорации спонтанно решили переписать всё на Rust? Потому что его заставило использовать государство США в лице Белого дома с помощью ONCD-рекомендации февраля 2024 года переписывать программы из C и C++ на Rust для продвижения, вдобавок объявив язык “C++” как “угрозу нацбезопасности”. На бумаге это всего лишь рекомендация и ничего не запрещает, но на деле она ставит ультиматум на госзаказы, которые бизнес терять очень не хочет, так как они гораздо прибыльнее.

Это не говорит о том, что Rust ужасен или что он продвинулся лишь за счёт лоббирования. Это напоминание, что корпорации используют только выгодные технологии.

А теперь к хорошим технологиям, которые так и не сыскали популярности: есть рантаймы JavaScript, самый популярный из них NodeJS, все знают только его. Но помимо него есть также Deno от создателя NodeJS, который был создан решить ошибки прошлого проекта и Bun, который также пытается собрать в себе весь инструментарий. Эти рантаймы объективно лучше NodeJS по удобству и оптимизации, но что используют на курсах по JavaScript’у? Думаю, ответ вы и так знаете.

Это означает, что неважно, хороший продукт или плохой – решает маркетинг и лоббирование. Это факт того, что корпорации выбирают не те технологии, которые им будут полезны, а те, которые им будут выгодны. Хочешь дешёвую рабочую силу для дизайна – бери React. Хочешь получать огромные деньги с госзаказов – переписывай всё на Rust. Никаких теорий заговора – простая экономика.

Эта история, как и многие другие, полны экономической жестокости и корпоративного цинизма, что я постоянно изучаю и собираю в единую картину мира. Если вы хотите узнать полную историю того, как экономика постепенно превращала Интернет в дойную корову, то я готовлю материалы для своей книги под рабочим названием “Как техногиганты убивают инженерию”, где про всё это можно почитать и узнать.

Так что у спонсоров и инвесторов есть хороший выбор: потреблять привычные решения и переплачивать деньги за дорогие сервера из-за оверинжиниринга; либо популяризировать новый инструмент, решающий проблемы большей части веб-индустрии и экономящий им деньги на серверах и “мёртвых душах”, вышедших с айти-курсов.

(Производительность) Вы всю презентацию говорите, что ваш движок позволяет “выжимать максимум из производительности”, но при этом где бенчмарки?

Как я уже говорил, на данный момент готова только MVP версия, которая должна доказывать своим существованием, что мой движок - работает и его концепт позволяет выполнять задачи веб-индустрии. Он и не обязан “рвать” всех в производительности, потому что это MVP, хоть и даже в таком состоянии показывает неплохие результаты, особенно в потреблении оперативной памяти. Очевидно, что релизная версия движка на Bun будет более конкурентноспособной, но она в разработке. Цель презентации – показать концепт, как можно делать и что он работает.

(Аналоги) Вы показываете новый подход к веб-разработке, но в чём конкретно ваша новизна? Вы же просто взяли готовые технологии и объединили их в бинарник.

Сначала остановимся на двух цитатах: Во-первых, новое – это хорошо забытое старое. Во-вторых, прогресс в целом состоит в том, что новые технологии держатся на прошлых технологиях. Вы не сможете открыть новый закон физики, не зная других законов. Как и Интернет не обязан был переизобретать сетевой стек, чтобы быть революционным.

Я человек, который вырос на Denwer’e, PHP и htmlbook. Я ценю старую веб-разработку за её простоту и лаконичность: файловый роутинг; сервера всё-в-одном как OSPanel; скрипты, которые можно спокойно читать сверху вниз. Люди тогда не лезли из кожи вон, чтобы придумать новое ради нового, они просто делали хорошо. Я хочу вернуть простоту старой разработки и пересадить её на новые технологии. Не только потому, что так удобнее мне, но и чтобы показать молодому поколению, как раньше делали сайты и что раньше действительно было лучше, как минимум в плане удобства и простоты.

Также я, как человек, который пришёл на веб-разработку из геймдева, всегда интересовался концепцией игровых движков, где весь инструментарий был под рукой в одной программе. Меня интересовало, что будет, если сделать такой “игровой движок”, но для веба. И результат вы видите на своём экране.

(Недооценка) То есть получается, вы взяли рантайм JavaScript, нативные инструменты и использовали по назначению, собрав в один проект? А в чём тут инновация?

В идее, концепте и реализации. Этот аргумент имел бы смысл, если бы не было упущено два шага: додуматься и реализовать. Нет ничего сложного в том, чтобы повторить то, что уже придумано и сделано.

Если смотреть на технологии с такой призмой, то iPhone - это просто BlackBerry, но с сенсорной клавиатурой, а нейросети - это просто копипаст учебников биологии и физики.

Знаете фразу: "Всё гениальное просто"? В этом и суть прогресса, что задумка несложная, но она приходит только определённым людям в определённое время, и только с определённой мотивацей такие идеи воплощаются в жизнь.

(Юридическая этика) В вашем движке используется агрессивная защита через gzip-бомбы. Вы же в курсе, что это серая зона и в некоторых странах это незаконно?

Агрессивная защита показана здесь чтобы показать теоретическую возможность движка и не заставляет её использовать в своём проекте. Следовательно, пока вы не используете этот модуль, вам ничего не грозит.

(Регалии) Это здорово, что вы делаете такие вещи, но вы действительно думаете, что вы умнее инженеров с высоким стажем?

Это отличный философский вопрос, потому что он задевает непогрешимое: законы физики. Попытка меряться авторитетом и регалиями в технической среде склонна к поражению. Почему? Потому что мир компьютерных сетей – это чистейшая анархия, которая слушается только чистые законы физики в обёртке модели OSI. Она работает точно так же, как электричество: ему всё равно, кого убить током – гендиректора или серийного убийцу, оно просто бьёт по законам физики. Точно так же и с пакетом, он просто доставляет нули и единицы, а сервер это обрабатывает: неважно что и неважно кому.

Хакеры, инфобезники и кибер-группировки не нарушают эти законы физики, их нарушить физически невозможно. Они просто знают их лучше, чем остальные люди, ведь вся цифровая деятельность – это сплошное манипулирование пакетами, живущих по этим законам.

В этом и главное различие между юристами и техниками. Одни законами физики управляют, другие закидывают его бумагой. Не спорю, что юридическая сила велика в реальном мире, но в мире протоколов ни одна бумажка не защитит сервер от взлома, а код – защитит. Этим я и отличаюсь - я знаю эту разницу.

Последнее слово

После подробного описания и ответов на вопросы, я считаю, что самое время перед уходом сказать своё последнее слово: QuickJS

Если фреймворки и npm install – это прошлое, мой Cryanide – настоящее, то вот это… Это будущее…

Это рантайм JavaScript, бинарник которого весит 250 Килобайт. Потребляет 3 Мегабайта оперативной памяти. Одна фотография в интернете весит и то больше.

Это рантайм, в котором кроме самого языка, нет ни-че-го. Абсолютная цифровая пустошь. То есть для движка нужно сделать свой сервер, свой файловый модуль, базу данных… “Безумие” - скажете вы? “Абсолютное” -скажу я! Но я готов.

Когда я релизну свой Cryanide и пойму, что движок самовоспроизводится за счёт коммьюнити, я буду стремиться к этому идеалу. Мне всегда будет чем заняться.

В мире есть пословица “Ничто не идеально”.
Пора доказать, что это не так!

Ресурсы:

Больше про мнение насчёт индустрии (основа): *тык*

Информация о движке и его разработке (лайв): *тык*