Comments 78
Я так и не понял, в итоге Symbiote.js умеет в SSR или нет?
Да.
Вопрос от нефронтендера и не совсем по теме статьи:
При прочих равных, на какой из существующих сейчас технологий фронтенда легче всего сделать наиболее производительный SSR ?
Отрендерить на бэкенде и отдать html, который подхватится js’ом в браузере.
Если из js фреймворков смотреть, то svelte умеет компилировать компоненты под ssr - там вместо работы с dom(а на сервере это будет какая-нибудь его эмуляция), будет работа со строками, что довольно шустро.
Симбиот это гораздо лучше и проще делает.
Я понимаю, что детали важны, но если говорить упрощенно:
Вот нужно, чтобы фронт выдерживал 400..500rps, при среднем размере страницы 800кб...1100кб, без какого-либо существенного кеширования. Будем считать, что бэк тратит не больше чем 50..100мс на генерацию данных. Текущее значение вложенности нод в хтмл наверное нет смысла сейчас озвучивать как я понимаю.
Это какое железо навскидку потребуется под решение ssr на svelte js ?
400 rps это не так много, ssr умеет в кеш. В принципе, если это не самый-самый дешевый сервер, то этому требованию удовлетворит любой фреймворк.
500rps
Я своих тестов не делал, но везде где видел, SSR самого React, будучи самым тормозным, показывал результат максимум раза в два медленнее, чем хороший серверный шаблонизатор.
Например
https://blog.platformatic.dev/ssr-performance-showdown
https://malloc.fi/performance-cost-of-server-side-rendered-react-node-js (старая статья)
Скорее всего вы упрётесь в производительность в другом месте.
Бери Nuxt.js, не пожалеешь.
Очень спорно.
Аргументы? В чем спорность?
В моей статье есть аргументы, просто подставьте Vue и Nuxt в нужные места: очередной черный ящик, очередные абстракции поверх ненужных абстракций. В браузере вы видите нечто очень далекое от исходников, что затрудняет дебаг. Я хочу сам контролировать то, как и что у меня собирается и подключается к странице. Честно говоря, очень достали все эти случаи, когда то стили подгружаются в неправильном порядке, то скрипты, то в дев-режиме все работает а в проде - сломано.
При этом вы утверждение "не пожалеешь" делаете без аргументов.
Смешные аргументы в вашей статье) Если руки растут откуда надо, то все решаемо и более того не исключено что проблемы которые вы описываете дело ваших же рук. Аргументы ЗА nuxt.js - это куча проектов в продакшне, известные платформы которые используют именно эту технологию и тем самым инвестирует в ее развитие, что то я не припомню ничего что было бы реализовано на симбиот.
кажется, вы слишком придираетесь к молодой библиотеке. Да, у проверенных технологий за плечами много реализованных проектов, но это не значит, что нужно зацикливаться только на них. Автор предлагает новый подход, который может реально оптимизировать работу и снизить затраты на разработку. К тому же, если посмотреть на статистику, эта библиотека показывает хороший рост в использовании. Понятно, что всё новое часто встречает сопротивление от тех, кто привык к старому и не хочет вникать в новое. Но это же не повод предвзято относиться к свежим идеям, особенно не углубляясь в суть проблемы. Хороший разработчик решит задачу на любой технологии, но именно то, как он это делает, отражает его инженерный склад ума.
Ну во - первых а с чего вы взяли что я против нового? Я вообще никого не трогал) Проходя мимо просто ответил человеку на вопрос, что для задач с ssr я рекомендую nuxt, можно посмотреть выше.
Во - вторых на счет сопротивления и не желания вникать в новое) Если вникать во все новое что появляется каждый день у тебя жизни не хватит что бы во всем разбраться, тут ключевое слово РАЗОБРАТЬСЯ. Тут хорошо бы еще понять в чем вы лично хорошо разбираетесь Mr_FatCat? Причислили себя к тем кто идет в ногу со временем, а того кто решил немного поспорить с тем кто как раз таки пытался сказать что существующий инструмент плох - вы отвели к категории людей которые не хотят ни в чем разбираться?)
В-третьих - на счет хорошего разработчика - я как раз об этом и говорил, что хороший программист возьмет интсрумент и решит задачу. Понятно что задачу можно решить разными способами и с помощью разных инструментов. Но как показывает опыт, разработчик который в своей работе постоянно меняют тех стэк - не являются хорошим специалистом ни в одном из выбранных им инструментов. Собственно поэтому на рынке больше ценятся специалисты узкой направленности.
Аргументы ЗА nuxt.js - это куча проектов в продакшне, известные платформы которые используют именно эту технологию и тем самым инвестирует в ее развитие
Такие аргументы можно применить к любой популярной библиотеке, поэтому они не несут особой силы. Ссылаться на популярность — это не технический довод. Я не увидел от вас конкретных аргументов в пользу Nuxt.js, кроме его распространённости. Просто говорить "используйте это, потому что это популярно" — недостаточно убедительно.
Причислили себя к тем кто идет в ногу со временем, а того кто решил немного поспорить с тем кто как раз таки пытался сказать что существующий инструмент плох - вы отвели к категории людей которые не хотят ни в чем разбираться?)
Повторюсь... Я не увидел от вас аргументов в поддержку ваших советов. Было бы интересно услышать конкретные причины, почему именно Nuxt.js лучше подходит в обсуждаемом контексте.
что то я не припомню ничего что было бы реализовано на симбиот
Я и писал, что вы не разобрались перед таким выводом. Если обратить внимание на рейтинг open-wc.org, можно увидеть, что Symbiote.js сейчас на седьмом месте среди гигантов. Возможно, стоит ознакомиться с ним более подробно перед тем, как делать такие заявления.
Но как показывает опыт, разработчик который в своей работе постоянно меняют тех стэк - не являются хорошим специалистом ни в одном из выбранных им инструментов. Собственно поэтому на рынке больше ценятся специалисты узкой направленности.
Можно не менять стэк в рамках одного проекта, но учесть текущие недостатки и улучшить подход в следующем. К тому же, востребованы не только узкоспециализированные спецы, но и люди, которые могут в R&D, а для этого нужно иметь представление о широком спектре технологий. Тем более в эпоху резкого развития ИИ.
Если делать выводы по вашим словам, то люди, которые разрабатывали тот же Nuxt.js, тоже не являются хорошими специалистами, потому что они тоже когда-то свернули с протоптанной тропинки.
Ссылаться на популярность — это не технический довод.
Вы хоть сами понимаете что пишите?) По вашему что nuxtjs - это сериал какой - то и что он популярен среди домохозяек и простых обывателей?) Он популярен в среде разработчиков и свою популярность он заслужил не статейками "а ля крутое решение" , а получил заслуженное признание в среде специалистов, которые годами тестили на деле этот инструмент, я извиняюсь за выражение, и в хвост и в гриву. И я более чем уверен что разработкой nuxtjs заняты далеко не глупые люди которые не меньше вашего заботятся об оптимизации и производительности данного инструмента. Говорю это со всей ответственностью, так как не мало времени провел изучая исходники на гитхаб. Я уже молчу про комьюнити которое достаточно активно и реагирует на все входящие замечания.
Я не увидел от вас аргументов в поддержку ваших советов. Было бы интересно услышать конкретные причины, почему именно Nuxt.js лучше подходит в обсуждаемом контексте
Вы предлагаете мне за вас сделать вашу работу?) Нет уж, это вам наверное следует подкрепить ваши статьи конкретными бенчмарками, тестами, сравнениями в профилировании, можно даже наверное для убедительности пару ссылок на репы хотя бы средних по масштабу проектов, которые будут являться хоть каким - то подтверждением того, что с интсрументом можно работать на +- больших проектах и не наткнуться на грабли которые заблочат его дальнейшее развитие.
Если делать выводы по вашим словам, то люди, которые разрабатывали тот же Nuxt.js, тоже не являются хорошими специалистами, потому что они тоже когда-то свернули с протоптанной тропинки.
Ну просто выводы надо делать правильные) Я не говорил что создавать что - то новое это плохо, наоборот - это хорошо. Но создавать что - то новое, полезное и лучшее, можно только после того, когда вы досканально изучили какой - то инструмент, провели с ним скажем так не мало времени, и знаете все его слабые и сильные стороны.
Если обратить внимание на рейтинг open-wc.org, можно увидеть, что Symbiote.js сейчас на седьмом месте среди гигантов
)) Кол - во скачиваний - это не то же самое что кол-во серьезных проектов в проде.
От себя добавлю что не имею ничего против симбиота, только посоветую не вести столь агрессивную агитацию в комментариях не подкрепляя ее ничем. Это точно даст обратный эффект ожидаемому. Плюс порекомендовал бы точно существенно переработать сайт с документацией. Успехов.
Вы хоть сами понимаете что пишите?) По вашему что nuxtjs - это сериал какой - то
Стоп, я вообще не писал своё мнение про Nuxt.js и их команду. Только про ваши аргументы. Имея в виду, что новую и старую библиотеку сравнивать по популярности бессмысленно.
)) Кол - во скачиваний - это не то же самое что кол-во серьезных проектов в проде.
Количество скачиваний показывает, что ей вообще достаточно много пользуются, и это свидетельствует хотя бы о востребованности. Более важным показателем здесь является рост, по которому видно, что интерес к библиотеке увеличивается.
И попытка узнать сильные стороны Nuxt.js, ваше мнение как опытного опытного пользователя — это не агрессия )))
Вопрос аналогичный тому, что выше - насколько хорошо nuxt.js впишется в те условия?
Я для своей работы сделал на Kotlin очень клёвый DSL движок для старого доброго серверного рендеринга. Никаких свистелок, всё на Котлин, всё строго типизированное, включая параметры форм и ссылок. Переиспользование компонентов, нативный рефакторинг, компилируемый код – то что нужно для очень больших бэк-офисов, когда программистов мало, задач много, выделенного тестировщика порой нет. Выделил это всё в open source. Давно хотел написать пост на Хабре, может кому будет интересно и полезно (поскольку сам не нарадуюсь от того как это удобно)
А зачем, собственно, React на сервере?
Я не настоящий фронтерндер, но понимаю так: один и тот же код выполняется и на клиенте и на сервере.
Например, есть страница каталога. Её можно открыть сразу со всем содержимым, а можно по навигации перейти на неё и получить данные запросом к апи. А код хождения в апи один и тот же.
А код хождения в апи один и тот же.
Но React то здесь причем? Код хождения в API и рисование UI - это же вещи ортогональные. Вам никто не мешает использовать общий код и без React.
И средства отрисовки одни и те же, и стейт перетекает бесшовное. Т.е. ещё и шаблоны одинаковые.
Да, шаблоны одинаковые. Почти. Но если вы хотите использовать HTML а не JSX, то не одинаковые. Я пишу о том, что JSX - это сущность, которую можно сократить без особого ущерба для дела. Но React-разработчикам, конечно, удобнее когда вокруг один сплошной React. С этим я не спорю.
Только всё это очень сильно бьёт по производительности. По сути дела, когда в нексте появился SSG, это надо было понимать так: "ребята, мы сделали тормознутого монстра и никак не можем его ускорить, поэтому держите статику".
Нужно сравнение от @nin-jin
О, да. Этот сравнит.
Особенно учитывая, что он топит за свой собственный вырвиглазный синтаксис разметки, когда тут прямо противоположная концепция :)
Не очень понял, где вы у нас нашли "разметку", которой у нас никогда не было. Но у меня к вам более интересный вопрос: как в этом распрекрасном синтаксисе понять, почему биндинги не работают?
И почему в эквивалентном коде на вырвиглазном синтаксисе всё работает, а даже если где-то и ошибиться - будет ошибка компиляции?
будет ошибка компиляции
ну за биндинги на строковые значения уже ниже справедливо автору претензию высказали. Хотя наличие compile time проверок и не делает второй скрин сколько либо читаемым.
Что кстати относится и к первому скрину. <${Card.is} ${{ - 7 спец символов + 7 значащих символов (причём .is судя по всему - бойлерплейт) - соотношение такое себе. Ничем не лучше мешанины $ / <= \ ? <=> @ из tree.
Думаю, стоит найти спеца с уровнем повыше, для адекватного сравненя...
Не очень понял что с чем предлагается сравнивать. Тем более, что я слишком тупой, чтобы понять, зачем тут компутед вычисляется дважды на каждый чих.
В моей новой библиотеке аналогичный компонент можно описать таким образом:
const CountingButton = ({ count = 0 }) => (
<button click_e_update={() => (count += 1)}>
Clicked {() => count} times
</button>
);
Туториал тут: https://habr.com/ru/articles/837938/
Рутинг получается надо делать вызывая AppRouter.applyRoute() при клике?
Открыл, увидел
<button ${{onclick: 'increment'}}>Click me!</button>закрыл. Функция по имени - детский сад какой-то.
Я очень рад, что вы так быстро во всем разобрались. Однако, приведенный вами пример - это то, как работает функция-хелпер (ее использование не обязательно), которая преобразует объектную нотацию в следующий вид:
<button bind="onclick: increment">Click me!</button>А это уже - просто HTML-строка, которая использует значения HTML-атрибутов для описания биндингов. Чем эта строка интересна? А тем, что она парсится нативным браузерным парсером и преобразуется в DOM без использования каких-либо дополнительных обработок. А также, может быть полностью независима от контекстов экземпляров компонентов. Может формироваться любым способом, хоть на сервере, хоть на клиенте. Ну, то есть, это бесплатный SSR, если вы понимаете о чем я говорю.
Да, в Symbiote.js биндинги задаются по строковым ключам, это решает массу проблем. Не вижу в этом никакого детского сада.
Это создает одну большую проблему при разработке - очень легко ошибиться в имени. И никто не поможет найти эту ошибку.
Очень часто слышу этот аргумент. Интересно ваше мнение. А разве ошибки не выявляются тестами? И почему, например, во избежание ошибки не завести в коде отдельную строковую переменную, которая будет хранить значение идентификатора?
Хранить имена всех функций в константах? Отличное решение.
Отличное, при боязни ошибиться в имени. Вот ошибка в идентификаторе как раз самая простая, потому что тесты рухнут, если к ненайденному элементу будет обращение.
А при переименовании функции в 10 местах, тесты придётся запустить всего 9 раз.
Проблемы со строковыми константами возникают не при написании своего кода, а при рефакторинге чужого.
Хотя если компонент небольшой, то это не будет проблемой, конечно.
тесты выявляют ошибки времени выполнения, это неплохо, но хуже чем выявление ошибок выявляемых во время компиляции, и ещё хуже ошибок выявляемых во время написания кода. С последним очень помогают анализаторы кода. Я не js разработчик, и не знаю можно ли писать анализаторы кода для js, но выглядит так, что анализатор, который следит за тем, что указанная строка это именно название метода с правильной сигнатурой, на этапе написания кода, было бы крутым решением данной проблемы
И никто не поможет найти эту ошибку.
А с чего вы это взяли? В чем проблема, на уровне дизайна либы, выводить ворниниги или даже выбрасывать исключения в таком случае? В Симбиоте, в частности, реализована мягкая схема с ворнингами, все необходимое вы увидите в консоли.
В нашей практике, для комфортной работы оказалось вполне достаточно спеллчекера в IDE (в принципе очень помогает с опечатками) и вывода предупреждений. Планируем еще запились статический анализатор в будущем (с ИИ), но серьезно, даже без него все нормально работает и никаких проблем не вызывает в сложных приложениях.
А можно ли на уровне шаблона сделать вызов с аргументами? Типа `bind="onclick: (e) => changeRoute('foo')"`.
Вообще, автор, спасибо тебе. Вполне годная библиотека. Попробую в каком-нибудь мелком проекте.
а ведь можно и
<button onclick="increment()">Click me!</button>так тоже было можно ;)
Возможно вам понравится как аналогичный компонент можно описать в моей новой библиотеке:
const CountingButton = ({ count = 0 }) => (
<button click_e_update={() => (count += 1)}>
Clicked {() => count} times
</button>
);
Туториал тут: https://habr.com/ru/articles/837938/
Ни в коем случае не обесцениваю ваш труд. Может быть в конкурсе написания компонент коротким стилем jsx выиграет, однако налицо смешивание вьюхи, логики, модели. Многих это устраивает (вопросов нет), но я из тех, кто считает, что пусть будет немного больше символов, но будет читаемо. Принял принцип разделения все этого на части.
Абсолютно с вами согласен.
Там где это нужно, код следует разбивать на MVC части.
Также специально для тех кто не любит JSX (включая меня), сделал альтернативный способ описания компонентов который не требует транспиляции:
import {button} from '@fusorjs/dom/html';
const CountingButton = (count = 0) => button(
{click_e_update: () => (count += 1)},
'Clicked ', () => count, ' times.',
);
Чем больше я читаю про "продвинутый" фронтенд, тем больше это похоже на JSDD - job safety-driven development https://habr.com/ru/articles/169017/
Раскройте мысль, интересно же.
Так и есть. Но тут еще один момент есть, который относится к веб-разработке в целом: проблемы, чаще всего, решаются не на том уровне абстракции, где они имеют наиболее эффективное решение, а на том, где это решение требует наименьший уровень компетенций. Из-за этого плодятся всякие монструозные мета-платформы, типа экосистемы React.
Чем больше я читаю про "продвинутый" фронтенд, тем больше это похоже на JSDD
и из статьи по ссылке
Фреймворконенавистничество — не стоит использовать популярные фреймворки и библиотеки, гораздо лучше написать свое решение под конкретные задачи. Ведь потом надо поддерживать продукт и возможно на эту роль понадобятся новые более дешевые разработчики. Куда проще найти на рынке разработчика со знанием популярных фреймворков, чем способных разобраться с самописными. А это значит, что вы надолго обеспечены работой.
Статья по ссылке интересная, в целом, но в ней есть и много очень спорных пунктов. Этот - спорный. В общем случае, мысль правильная, но если ее возвести в абсолют - то в мире должен существовать только один фреймворк - самый первый (а не самый лучший). Возведение каких-то вещей в абсолют - грех гораздо более страшный для разработчика, чем любое фреймворкотворчество и велосипедостроение. Все популярные либы и фреймворки когда-то были самописными велосипедами.
И мне нравится как многие, при обсуждении этого вопроса, исключают из контекста такие вещи как производительность, размер, количество зависимостей и так далее. Популярная либа может весьма сильно проседать по этим параметрам, а вашей целью может быть напротив - максимальная эффективность и технические требования, а не то, насколько ваше решение соответствует мнению большинства. И цифры - могут быть серьезным аргументом в пользу условного велосипеда.
Ну и обеспечивать себя (и других) работой - далеко не самая плохая идея.
Всё так, но тут есть проблема, что если вы используете, что-то нестандартное, то оно должно быть либо популярным, либо очень тонким. Вы lit частично в этом обвиняете, кстати.
С другой стороны, я не считаю API Custom ELements заменовй Vue / React / Svelte. Скорее как общий знаменатель библиотеки компонент.
Я и призываю к использованию стандартного: стандартного HTML, стандартного JavaScript, стандартного DOM API, стандартных importmaps, стандартных Custom Elements, стандартного template literal, стандартного патерна Pub/Sub и так далее.
Вот это то, что мне не нравится во многих фреймворках. Код нужно писать в специально придуманном файле. Для подсветки синтаксиса нужен специальный плагин с Language Server и IDE, которая поддерживает плагин. Разметку нужно писать на специальном диалекте при наличии HTML. Для стилей нужны какие-то пакеты, иначе нельзя писать CSS. Вместо JavaScript нужно писать на каком-то мета-языке. Для перехода между страницами нужен ещё один пакет, потому что нельзя использовать a[href]. И чтоб всё это заработало, ещё нужен сборщик, десять плагинов для него, пять конфигов, npm и node нужных версий и 5 минут билда. Утрирую, но суть примерно такая.
стандартного патерна Pub/Sub
А это какого, если не секрет?
стандартного HTML
А у стандартного HTML есть шаблонизатор?
Забавно, но в мире C# примерно так и есть. Но там ситуация такая, что периодически выскакивают интересные библиотеки, но если в них есть какие-то прорывные идеи, довольно быстро эти идеи перекачёвывают в мейнстимные библиотеки. В итоге набность в использовании "чего-то кроме" отпадывает
Не соглашусь. Я не фронтэндер и давно за развитием js не слежу, так что могу и ошибаться, но здесь действительно сделана попытка развить прорывную идею компонентов для web, приблизив их реализацию к стандартным средствам. Реакт на момент появления был отличным вариантом. До него все компонентные фреймворки хромали на одну или обе ноги, т к компонент в них мог жить только в очень приспособленном для него окружении. (Вспомните первые фреймворки для spa типа underscore, там вообще деления на компоненты по факту отсутствовало. Помню ещё очень тяжеловесный ember.js и не менее тяжёлые платные варианты, если не путаю, Ext.js. Медленные, сложные, неудобные...) И тут выходит реакт... Начисто сметая ангулар от гугла первой версии, по всем показателям. (Что и показало время) На тот момент много из того, что автор использует в своём фреймворке в стандартах не было. Поэтому реакт был более чем совершенен. Сейчас возможно настало время пересмотреть концепцию в сторону большей стандартизации. Понятно, что одному человеку вряд ли удастся конкурировать с корпорациями, но это не повод ничего не делать. Ведь и реакт создали не с чистого листа. Это продукт эволюции идеи компонентов в web.
Небольшой совет: укажите прямо, четко и ясно, прямо сразу же и в лоб, в двух-трех емких предложениях что это такое и зачем оно мне нужно как разрабу. На сайте я вижу лишь, что вышла новая версия Симбиота и много разделов. Ни один из них не называется или что-то в этом духе. Окей, жму докс. Там сразу как установить и прочий онбординг. А если я просто хочу узнать что это такое? К сожалению, маркетинг проектов от нас, программистов, зачастую страдает или его вообще нет, так как прежде чем "войти во вкус" и сказать на сколько вы крутые 70% людей бросит это даже не начав из-за таких вот мелочей.
Я тоже разрабатываю супер легкий/нативный способ создания веб приложений https://habr.com/ru/articles/837938/
Извиняюсь конечно, но опять скажу - использовать CustomElements как единственную основу для декомпозиции - это приблизительно как использовать js без модулей и closures
Совершенно не понимаю зачем вы ходите по моим публикациям и повторяете одно и то-же. Может, на этот раз, будут какие-то вменяемые аргументы, кроме проблемы общего скоупа, которая, как вам уже многократно говорили, совсем не проблема? Причем тут модули и замыкания? Общая область имен, в случае с CustomElements, точно такая-же, как и для всех остальных стандартных HTML-тегов. Сама открытая архитектура веба и слабосвязанная архитектура, как концепт, подразумевают наличие таких моментов бай дизайн, и это никогда не было какой-то непреодолимой проблемой. Как, например, значения атрибута id в HTML элементах, в которых тоже могут быть коллизии. И ничего, мир не рухнул и мы как-то живем дальше.
Вы поймите, веб начинается ни с JS, а с HTML. CustomElements - это органичная часть ЛЮБОЙ разметки, будь то статика, сгенерированная ЛЮБЫМ серверным движком или шаблонизатором, или полностью динамическое приложение, которое внедряет зависимости "на лету". А вот ваша кастомная декомпозиция будет работать ТОЛЬКО в рамках вашего кастомного рантайма.
И, таким образом, на другой чаше весов у нас, всегда некая сущность, которую вам необходимо добавить в систему, чтобы реализовать свой механизм декомпозиции. И вот это уже реально темная зона где рождаются монстры.
А что, так можно было?