Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Какой прекрасный велосипед.
Мне нравится.
Удачи с проектом.
А теперь к хорошим технологиям, которые так и не сыскали популярности: есть рантаймы JavaScript, самый популярный из них NodeJS, все знают только его. Но помимо него есть также Deno от создателя NodeJS, который был создан решить ошибки прошлого проекта и Bun, который также пытается собрать в себе весь инструментарий. Эти рантаймы объективно лучше NodeJS по удобству и оптимизации, но что используют на курсах по JavaScript’у? Думаю, ответ вы и так знаете.
Поверь, друг, всё гораздо прозаичнее, bun просто на сегодня не является 100% заменой nodejs https://bun.com/docs/runtime/nodejs-compat
Слова ничего не стоят, покажи мне код
Вы не до конца поняли, что такое микросервисы и зачем их придумали. Тут дело не в красивой ошибке 500, а в том, что при фиксе этой ошибки не придется пересобирать весь монолит (что долго и больно), можно собрать отдельно место фикса ошибки (микросервис) и быстро его выкатить.
И сколько собирается ваш монолит?
Я не использую монолитную архитектуру в проектах с недавнего времени, но обычно сборка большого монолита была от 5 минут. Тут конечно же не только в скорости сборки дело, а и в других факторах, например как @GBR-613написал ниже)
В этом и суть моего движка, что его не надо собирать. Он делает то, что забросили с десяток лет назад - берёт концепцию динамического веба, где ты буквально редачишь файл и он изменяется в реальном времени.
Я понял Вас и ничего против не имею, но лично мое ИМХО - это просто шаг назад, то же самое, что вместо мессенджеров использовать почту) Писать фронт (а тем более бэк) на чистом JS в 2026 такое себе. Чисто мое мнение)
А я предлагаю писать фронт на чистом JS?) У движка есть система компонентов, которая работает на чистом JS, вдохновленная подходом jQuery, в будущем планируется добавить и реактивный подход.
Благодаря тому, что компоненты можно компоновать на сервере через файлы *.comp.js, можно сделать набор UI-элементов на все случаи жизни. Впрочем, я не против заняться написанием и компонентов для своего движка.
И чистый JS никто не отбирает, и компоненты есть :)
Не совсем понял Ваш тейк, мы же не о готовых компонентах говорим а об языке программирования для разработки этих компонентов.
Тогда это меняет дело. Если тема заходит о языках, то чистый JS в моём движке используется по четырём причинам:
1) браузер понимает на фронте именно нативный чистый JS, все остальные диалекты типо JSX или того, что у Svelte (если Вы имеете в виду их) потом переводятся всё равно в чистый JS через чёрный ящик транспилятора, это посредники. А так есть прямое общение с браузером.
2) Ради большинства диалектов приходится пересобирать проект, потому что, как я сказал выше, это всё равно пережёвывается в нативный JS. Удобно ли писать фронт? Наверное. Удобно ли ждать сборку после каждого изменения? Вряд ли.
3) Каждый фреймворк предлагает отдельный язык для фронта и каждый из них учить. Это в целом странно и если лезть глубже, то это убивает айти рыночек, это делает из программистов одноразовых джунов, которые живут до тех пор, пока живёт фреймворк. Когда фреймворк предлагает свой диалект, человек его учит, тратит месяцы, работает на нём и всё хорошо. Но как только фреймворк устаревает, человек уже не нужен с этими знаниями, почему?.. он учил диалект, а не сам язык, его знания ограничены диалектом, и это не его вина. Поэтому я пишу на чистом JS, так как это будет полезно для тех, кто его освоит. Они будут знать не что-то выдуманное, а сам JS и ООП. Это база.
4) Это самый отличный вариант для контроля и стабильности. Что значит создавать диалект или свой язык? Это: писать транспилятор, писать плагины для известных редакторов кода, писать документацию не к объектам, а к самому языку, это продавать курсы. Для гаражной инженерии с бюджетом в два дошика это на грани возможного. А JS стирает эту грань и позволяет создавать что-угодно из объектов и его методов. В этом прелесть.
Да я то не против, но Вы должны понимать, что TypeScript придумали не просто так, и 90% фронтендеров не просто так его используют) Вот когда браузеры получат нативную поддержку TS (а я не уверен, что это произойдет когда-нибудь), тогда и посмотрим. Можно писать на чистом JS, конечно, но если мы с Вами умеем и без проблем пишем, то это не значит что все остальные также будут хорошо писать на нем, т.к. язык с дин. типизацией - что такое себе. И тут дело не в том, что Microsoft захотела отличиться, а в банальной удобности и уменьшении кол-ва багов из-за кривой (имхо) типизации.
Конечно, TypeScript придумали не просто так, ведь нужно поддерживать единую структуру кода среди разработчиков. В конце концов, Microsoft, как и любая компания, работающая на выгоду, делает подобные вещи не ради всеобщего блага, просто это также инструмент менеджемента, который позволяет использовать статическую типизацию в JS.
Я ничего не имею против TypeScript и тех, кто его использует, просто я считаю динамическую типизацию и его особенности в JS наоборот фичей. Кому-то она мешает, а мне помогает.
инструмент менеджемента, который позволяет использовать статическую типизацию в JS
не совсем понял о чем Вы
нужно поддерживать единую структуру кода среди разработчиков
не в этом дело, еще раз: TS придумали как раз чтобы решить проблему плохой типизации JS
Я не знаю, знаете ли Вы что-то кроме JS, но попробуйте освоить что-то со строгой типизацией и Вы удивитесь, насколько станет легче)
Насчёт тейка про менеджемент. Технически это инструмент, строгая типизацая в JS. На языке менеджемента это конституция чистого кода, которая обязывает её следовать. Это не плохо и не хорошо, просто это мотив, зачем такие инструменты создаются.
Опять же, почему правила JavaScript это "проблема плохой типизации"? Типизация JS имеет особенности, которые прописаны в самом движке, это преобразование типов, которое имеет свою логику.
Насчёт Вашей колкой "просьбы" освоить языки со сторогой типизацией, я пробовал, но не втянуло, JS нравится больше. В ответ на Вашу пассивную агрессию предлагаю "попробовать освоить сам JS и Вы удивитесь, как станет лучше, когда вы знаете основы языка")
В любом случае, я заметил, что диалог уходит в вечный спор про holy war типизаций, который не приведёт к значимому результату. Так что предлагаю либо наблюдать за развитием проекта и тем, как используется JS в рамках моего проекта, либо продолжать длинную ветвь комментариев, что я бы счёл неуважением к моим зрителям, которым всё это читать :)
К тому же, для того, что Вы описали есть HMR)
Для того, что я описал, есть практически всё в Интернете - фишка в подходе, всё переписано под единый организм. Можно взять разные детали разных фирм, которые вроде как совместимы, и собрать велосипед. А можно штамповать детали вручную, которые будут идеально подогнаны друг к другу и дадут поставить на свой велосипед реактивный двигатель или пулемёт.
Зачем? Я сделал свой верстак для своих задач, который решает все мои проблемы, и предлагаю чертежи верстака для людей :)
Я же говорю: я не против и никаких претензий) Наоборот похвально, что свое что-то делаете, и Вы получили критику не в свой адрес ни в коем случае, а в адрес вашего продукта, который выглядит как возвращение в прошлое (чем по сути и является). Использовать его или нет - дело каждого, вот и всего)
Благодарю, тоже никаких претензий, просто отвечаю на вопросы насчёт моего проекта :) (не люблю слово "продукт", убивает душу, словно это товар)
Да, это возвращение в прошлое, но на современных реалиях. Не вижу ничего зазорного в том, чтобы брать лучшее из разных временных эпох, в конце концов это не просто "раньше было лучше", а конкретный собирательный образ из того, что было хорошо, а что можно улучшить)
Конечно это не просто "раньше было лучше", потому что раньше не было лучше) Все технологии, что сейчас есть основаны на прошлых технологиях, и так или иначе они приходят им на замену как раз решая их проблемы и делая технологию лучше. Тут все просто: если технология реально стоящая, она найдет свое применение, если нет, то сорри) Остается лишь наблюдать, кто знает, к чему ваш проект приведет :)
Насколько я понимаю, смысл микросервисов в том, что их можно масштабировать независимо друг от друга. Всё остальное не важно. Человеческий организм - типичный монолит: Вы не можете временно добавить к нему ещё одну руку или голову. А вот фирма - это микросервисы. Если нужно - Вы можете временно нанять пару программистов, если нужно - дополнительного бухгалтера. А потом уволить.
По сути да, так и есть, плюс многие приводят как преимущество то, что можно использовать разные стеки технологий, но такое на самом деле, только если реально много команд и компания большая.
Именно так. Для менеджемента и для организации разных отделов команд микросервисы - идеальное решение таких задач. Но в плане работоспособности есть жинзненноважный код и сколько его ни дели, при ошибке базовые функции станут недоступны.
Странно что файлы js, хотя bun с ts работает. Текста много, а смысла null. Репы нет, это mvp, а не продукт Стива Джобса, с фига мы должны заходить в телегу и вожделять восход солнца
Спасибо за ответ!
Потому что я пишу на классическом JS, я считаю, что чистый код можно писать где угодно. Что насчёт того, что кроме mvp нет репозитория, потому что проект на стадии разработки.
Суть: показать концепт, закрепить, что вот придумал такую вещь, собрал рабочий прототип и дальше дело за разработкой.
Зачем заходить в телегу? Застать всё это с самого начала. Моя цель не "продать", а "показать", я за аудит. И может, именно вы заметите в ядре уязвимость, которую удастся устранить
Автор так долго ругался на конфигурационный ад, а потом пол статьи написал о том как настраивается другой более лучший продукт ))))
Ну в целом сильно играет компетентность, продукты сложны не сами по себе, такими они становятся по мере роста внутри комьюнити.
От самоуверенности повеяло Карловским)
Ну честно говоря сложно назвать это движком, скорее фреймворк.
Отчасти вы правы на счёт того, что современный мир диктует ставить оверхед ради небольшого проекта. И то, что всё это потребляет не мало ресурсов - сейчас стало нормой. Но справедливости ради, многие готовые решения включают в себя очень много архитектурных решений, которые из коробки пытаются решить многие головные боли или даже проблемы с безопасностью.
Бизнес обычно требует проверенную практику и проблема в том, что к тяжёлым фреймворкам и либам уже привыкли. Сейчас телефоны имеют в базе 8 ГБ оперативки и 256 Гб постоянной, что говорить тогда о сервере, который должен приносить доход?
Ваш подход мне нравится, я сам стараюсь использовать самые производительные решения, чем ненужный мне оверхед. Например взял Elysia и мне нужна база данных, можно взять драйвер-зависимость, а можно взять Prisma. В моем случае Prisma оверхед, при чем потребляющий не мало памяти.
Всё сейчас усложняется, когда полноценный продукт можно собрать с минимальным набором зависимостей и гораздо лучшим опытом. Я сам вот хотел написать замену реакту, где мы могли бы писать человеческий код, который не будет компилироваться в огромный бандл и иметь те же плюшки, но потом вспоминаю, что врят ли кому-то это будет нужно, то забрасываю эту идею))
Благодарю за ответ. Это очень искренне
Я очень рад, что в коммьюнити есть люди, которые пытаются решать проблемы самостоятельно, это радует.
Не стоит забрасывать, фронтенд-библиотека без лишних компиляций очень нужна. Особенно когда можно совместить jQuery и React стили. Я надеюсь, проект получится отличный :)
Кажется, что мы в тупике, потому что даже если я сделаю хороший продукт, он все равно будет никому не нужен :)
Сражение креветки против гигантского краба
Это и необходимо предотвратить. Мы живём в мире, где мало сделать хорошо, нужно ещё "показать". Но это и не повод останавливаться.
Многие технологии создаются одиночками, кто-то получает известность, кто-то нет, а кто-то продал своё авторство корпорациям.
Для начала стоит поразмышлять о своём проекте и спросить самого себя "Чем проект лучше аналогов и есть ли у него аналоги? Какие проблемы решает? Что может предложить?". Если на эти вопросы удалось найти ответ, значит всё хорошо, это та самая этикетка продукта, которая привлекает покупателей на полке.
Если же ответа нет, то его надо придумать. Инновации и уникальность - это то, что нельзя купить или получить по щелчку пальца, как вдохновение или идея. Невозможно победить корпоратов на их поле, где у них безграничные деньги и юристы.
Если же это буквально "продукт", то тогда нужно выбрать те параметры, которые ты сможешь улучшить или уже улучшил по сравнению с аналогами и указывать именно на эти преимущества.
Главное не бросайте дело :)
>PHP это правильно, ссылка вела на файл
Да нет конечно, апач всегда в приличных сайтах конфигурили внутри кучей реворациов, это разговор о каком то идеалистическом представлении о РАННЕМ ВЕБЕ.
>Конфиги большие
Компайлер все равно стрипит все что надо, нет машины достаточной для сборки Реакта - берете Svelte
Спасибо за ответ. Отличная фраза: "идеалистическое представление о раннем вебе", это станет отличным лозунгом моего проекта. Как я ниже описал, ранний веб был очень удобен, хоть и "имел недостатки", то есть я их не отрицаю. Но такие вещи, как файловый роутинг мне нравились, где я видел эндпоинты API без открытия кода наглядно и без вставок функций. К этому и стремимся - чтобы идеалистическое представление стало реальностью.
Насчёт конфигов, я против больших конфигов не потому что их компилятор пережуёт, а потом что их почему-то пережёвывает человек. Очевидно, многие части можно сократить или автоматизировать, поменяв структуру или связав это с сервером.
Что насчёт компилятора, я могу сказать только одно: если вместо отказа от компилятора в динамичном (!) вебе он защищается тейком "компилятор умный, сам вырежет всё, что не надо и оставит что надо", то компилятор уже Вас победил, и я предлагаю решение этого в данной статье.
В отличии от компиляторов, которые пишут про "tree-shaking", а что от чего зависит - это чёрный ящик, мой инструмент даёт Вам контроль над тем, что сервер пережёвывает. И это не потому что я так заявил, а потому что инструмент изначально создан без нужды компилировать. Вся минификация и оптимизация происходит внутри движка и держится под капотом.
Так что если Вам может стать интересен такой опыт, то по ссылкам ниже буду параллельно вести дневники разработки. С учётом того, что я сейчас начинаю ремейк на Bun, вы сможете предложить свои идеи для улучшения инструмента. :)
> компилятор уже Вас победил
Он победил давным давно, еще в 80-х там где первые оптимизирующие С компайлеры выкинули гору ручной работы, перестраивая код в AST вместо негодного человечка. если вы думаете, что написав условный for в машкоде будет тоже-самое, то вы глубоко заблужаетесь. В чем проблема такого же подхода к JS ?
>где я видел эндпоинты API без открытия кода наглядно и без вставок функций
Это сильно экономило время всяким сканерам уязвимостей, не без этого. Поэтому в приличных местах это все закрывали наглухо через фильтры и редиректы. максимум в интрасеть что-то могло торчать.
Я и не говорю ничего против компиляторов в компилируемых языках, но речь про JavaScript. То, что вы называете "компиляцией" в JS (возможно, можете подробнее указать) - это называется транспиляция (или же минификация), это просто сжатие кода. Если вы имеете в виду JIT, то он по умолчанию есть в рантайме.
Главная проблема подхода компиляторов (транспиляторов) в JS в том, что это не компилируемый язык, а интерпретируемый. Он не создан для компиляции, можно потратить время на сборку, но это его не ускорит, потому что JS интерпретируемый.
Что насчёт сканеров уязвимостей.. А смысл от того, файловый это роутинг или прописанный через фильтры, если факт один - открыто N-ое кол-во URL, при том, что они заранее неизвестны? Если сканер уязвимостей умудрился прочитать содержание директорий, то это означает, что сервер дырявый, у которого не прописали одну строчку в конфиге - запретить просмотр директорий. Это проблема не подхода, а некомпетентности, когда сисдамин не додумался до "Options -Indexes".
>что вы называете "компиляцией" в JS - это называется транспиляция (или же минификация)
Нет, конечно. Там вполне массово инструкции переставляют в JS с предсказанием результатов и потом рендером из AST обратно в код.
The modern option (false by default in Svelte 5) makes the parser return a modern AST instead of the legacy AST. modern will become true by default in Svelte 6, and the option will be removed in Svelte 7.
>Он не создан для компиляции, можно потратить время на сборку, но это его не ускорит
Именно поэтому в Lighthouse вставлено Parse and compile cost, ага. Гугол сам не знает, что JS это только интерпертируемый язык.
>Если сканер уязвимостей умудрился прочитать содержание директорий, то это означает, что сервер дырявый, у которого не прописали одну строчку в конфиге - запретить просмотр директорий. Это проблема не подхода, а некомпетентности, когда сисдамин не додумался до "Options -Indexes".
Я и говорю - не видели вы этого раннего веба. Когда все сконфигурили, а тебе всеравно через хитровыстеганный URL тот самый .htaccess прочли. Ну потому что парсит так Апач ссылки и просто файло читает, а еще может быть и переписан через URL. Пока не выкинули идею файловых ссылок - так все и страдали по кругу, бесконечно чиня уязвимости апача, конфигов и прилаг
Я сейчас просмотрел технологии, которые вы приводите в пример. Это здорово, что в Svelte рендерят из AST и обратно, но причём тут сам JS? Это же фактически его диалект и надстройка. Это не компилятор самого JS, а транспилятор - перевод из диалекта в классический. Это не делает его компилируемым.
Что насчёт Вашего аргумента про гугол и Lighthouse.. То есть вы по сути подтвердили мои слова, что вы имели в виду JIT-компиляцию?Ведь благодаря ей JS и можно использовать как интерпретируемый язык. В рантайме Bun, который я использую, JIT есть, так что с оптимизацией проблем не будет.
Всё, что не лезет в сам рантайм JS или его движок работы, а делает что-то поверх - это надстройка и синтаксический сахар.
Насчёт Apache, опять говорю, я не идеализирую, я четко в тексте написал "Да, раньше технологии были не ахти, но по сравнению с современностью это эталон удобства и оптимизации". Я и так знаю, что раньше было очень много уязвимостей, даже у того же самого PHP их очень много, что активно используется в CTF. Это и есть цель моего проекта - исправить эти ошибки. Не стоит предъявлять за то, что я не говорил. :)
Также я заметил, что суть диалога ушла в другую сторону, которая не приводит ни к чему, кроме соревнований в знаниях. Так что давайте определимся. Если ваша цель - развести демагогию за терминологию, является ли JS компилируемым или интерпретируемым языком - тема интересная, почему бы и нет, узнаю новое. Если ваша цель связана с обсуждением непосредственно движка, то милости прошу следить за разработкой, ваш опыт будет очень ценным для нового инструмента.
Благодарю за понимание :)
Будущее - за безбраузерным интернетом. Мы на пороге величайшей зачистки от визуального мусора».
Нас ждет короткий переходный период, когда headless-браузеры на серверах Perplexity и Gemini будут «по старинке» парсить сайты, выуживая суть под наши промты. Но это лишь мост. Конечная точка - смерть UX/UI дизайна, SEO и баннерного ада. Кому нужны форма и цвет кнопок, если контент потребляет глаз нейросети?
Весь веб схлопнется до чистого обмена JSON/XML данными. Переход будет безболезненным: Telegram уже приучил нас к единому интерфейсу для всего. Эпоха свистелок и перделок официально уходит в небытие.
Спасибо за ответ, интересный взгляд на будущее.
Этап момента, когда вместо дизайна нам подают выжиику, звучит интересно, однако пока нейросети глючат, до этого этапа далековато.
А также не забываем, что маркетологам и рекламщикам тоже нужно поработать, так что даже на этапе выжимки какая-нибудь реклама да будет внедряться. Уже были проекты, которые буквально вмонитровали в фильмы рекламную интеграцию, как будто она так снята и была, и скорее всего, такое будущее будет ближе, так как оно выгоднее для индустрии.
Но в целом концепт интересный. В нём есть отличный потенциал, но его убъют рекламщики, а базовые пользователи захотят цветастых картинок.
Так что я думаю, этот концепт будет отличной идеей для определённой области, где из поиска информации можно выжать максимум
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cryanide как альтернативная ветвь развития web-технологий