Зачем фронтенд? (1)
Признаться, я давно потерял мысль, зачем нам фронтенд. Я имею в виду реакты-вуи,
папки node_modules
весом в тонну, тормозной гуй и спиннеры в каждом углу.
В самом деле, какую проблему мы решаем? Неужели так важно писать километры кода на js, чтобы элемент обновился динамически? Почему никто не помнит закон сохранения энергии: если на беке кода стало меньше, его станет больше на фронте? Плюс и минус схлопываются, и в лучшем случае получится то же самое. Но прибавляется энтропия, вызванная фрагментацией технологий и стеков, тулинга, языков.
Есть и другое замечание. Когда-то браузеры были медленными, и рендеринг страницы был узким местом. Даже если разметка приходила быстро, ее было трудно вывести на экран. Сайты верстали таблицами, на которых IE знатно подвисал. Поэтому Ajax казался спасением: выдернем данные в полете, не придется перезагружать страничку.
Сегодня браузеры ушли в космос: это уже почти операционные системы. Видео, дизайн, игры, офисный редактор. Если взять обычный сайт и доработать под стандарты — Etag-и, кэширование, правильная разметка, оптимизация стилей — то он будет работать мгновенно. Страницы будут открываться так быстро, что никакие аяксы не понадобятся.
Вместо того, чтобы ускорить сайт целиком, фронтендеры пишут приложения. Они как Джава — загружаются долго, но, вроде бы как, работают быстро. С оговоркой, потому что новых вкладок порой не избежать, и загружается вторая копия приложения. Со всеми этими спиннерами, загрузками и клиентским рендером.
Казалось бы, хочешь обновить кусок страницы динамически — пришли с сервера кусок разметки и вставь в нужное место. Это самый простой способ, проще невозможно. Но у фронтендера свой путь: он запрашивает данные, складывает во внутреннюю базу, подписывается на обновление базы, по событию ее изменения вызывает другое событие, которое читает базу, рендерит HTML и вставляет в документ.
Этот как налить чай не в кружку, а сначала в тазик, потом в блюдце, потом по трубочке в кувшин, а оттуда в кружку. Что ты хотел этим доказать?
Разработчики разучились мыслить критически. У всех перед глазами шоры: реакт-вуй-протобуф-кубернетис. Никто не думает, как решить задачу просто, дешево и в срок. Всем подавай бест-практис и блидинг-эдж.
Нашли ошибку? Выделите мышкой и нажмите Ctrl/⌘+Enter
Pavel, 15th Aug 2025, link
Когда мне потребовались более-менее сложные интерфейсы, я пошел примерно таким путем, но более логично – просто открыл на клиенте (в браузере) WS-соедниение и стал выполнять всё, что пришло с сервера через eval(). А результаты отсылать обратно. Код пишу на CL, сделал макрос defun-f, который как defun, но функция будет выполнена в браузере. Когда требуется, она компилируется в JS через JSCL и отправляется клиенту. Причем она там и остается, так что повторно код уже пересылать на надо. Никакого HTML, все элементы создаются программно через модификацию DOM.
Все браузерные функции общаются друг с другом внутри браузера, не трогая сервер без необходимости. В результате у меня цельный код на чистом CL, когда я меняю функцию (в REPL или через swank-соединение из редактора) она автоматически обновляется во всех присоединенных браузерах. Библиотека: https://github.com/hemml/OMGlib
В итоге я обнаглел до нужной степени и сделал построение доплеровских томограмм (это для астнономов, астрофизик я) прямо в браузере, тоже на этой технологии: https://tomo-v.inasan.ru/
По моим оценкам этот подход ускоряет разработку и отладку в разы, но может, конечно, это только у меня так :)
Ivan Grishaev, 15th Aug 2025, link
Прикольная штука! И всего лишь 47 звезд. С удовольствием посмотрю, хотя знаю CL посредственно.
Pavel, 15th Aug 2025, link
Я старался делать документацию (см. Readme), но она, скорее всего, плохая. Если будут вопросы – пишите на hemml@me.com, с удовольствием пообщаюсь на эту тему. Дело в том, что я не программист (в смысле, не зарабатываю деньги написанием кода), но, кажется, изобрел нечто, что может быть полезно. Жаль будет, если идея не получит развития.