Вот только мемоизация любого из компонента убьет все ваше открытие. Кроме того оно не работает вверх по дереву. Используйте контексты или MobX и не страдайте.
Этот сайт выполнен как клиентский рендеринг и напичкан JS буквально в каждом элементе. При этом он отлично себя чувствует на читалке. Секрет в легковесных библиотеках и стейт менеджере.
Кроме того использован эффект одного TCP пакета. В нем расположен лоадер. За счет чего на читалке почти сразу отобразился лоадер и еще секунд 10 шла загрузка.
Потом попытался открыть сайт на SSR, долго отображался белый экран, я уж подумал даже что сайт лежит. Но в итоге тоже отрисовался. Все это время он парсил документ и гидрировал страницу.
Обратите внимание, редактор комментариев это не просто текстовый элемент, а довольно таки сложный редактор со сложным функционалом. Без JS такое работать не будет.
Эта форма отправляет на бекенд не то что вы видите и не html. Эта форма отправляет на бекенд JSON. Это нужно для того чтобы потом можно было отобразить те же комментарии в нативном приложении.
Форма на submit вызовет мерцание страницы с потерей положения скрола + лишним трафиком на повторную загрузку статьи. Форма на JS красиво вставляет комментарий в список комментариев, без каких либо мерцаний и перезагрузок страниц. Если любому человеку предложить два варианта поведения, то он выберет форму без мерцания и потерей скрола.
Ходить по телеграмм каналам и теребить чувства верующих не в моих правилах. Но сами наверное понимаете что рендерить страницу на html и оживлять через jquery в 2023 может только совсем не адекватный человек. Куда проще взять Next.js и написать изоморфное приложение.
Где вы вообще нашли функцию выключения JS в 2023 году? )) Вы недооцениваете хабру. Если посмотреть профайлер инициализации хабры, то у нее скриптов не меньше чем в любом навороченном сайте. Карму вы не поднимете, комментарий не напишите, элементарно три точки под комментом работать не будут, я уж молчу про аналитику и рекламу. Если вам нужен текст без JS вы можете прочитать в другом формате, например RSS. Но нет, вы открыли не RSS, а JS и жалуетесь на то что здесь работает JS. Это был ваш выбор, а не чей то другой. Выбирали бы RSS было бы больше контента на RSS.
Вы почему то думаете 1 сервер обслуживает только 1 клиента. Но это не так. Один сервер обслуживает сотни и тысячи клиентов в секунду. Если взять бюджетный телефон, например Redmi 9 за 9 тысяч и новый Xeon за 200 тысяч, да, Xeon будет в 100 раз быстрее, но обслуживать будет 1000 клиентов. При таком раскладе на одного клиента придётся в 10 раз меньше ресурсов. Уже писал в статье что делал программу на клиентском рендеринге и она занимала всего 10% от 4 ядер, в то время как аналогичная программа с серверным рендерингом занимала 15 навороченных серверов. Которые еще и поддерживать надо. И метрики TBT и TTI у клиентского рендеринга лучше за счет отсутствия двойной работы по серверному и клиентскому рендерингу.
vue, react, angular - да, на помойку. Как минимум надо использовать preact, svelte, solidjs (на худой конец $mol ;) ).
alpine.js - выдает вам шаблон который все равно рендерится на клиентской стороне. Вы не сможете прочитать статьи выведенные в циклы в alpine.js пока их не обработает JS. Это все го лишь другой шаблонизатор. Кроме того по тестам перформанса он в разы медленее не только preact, но и react. Пруф по ссылке.
Да, я когда делаю софт делаю поддержку не всех браузеров, а только тех чья доля составляет более 0,5% на рынке. Понижать эту планку экономически не целесообразно, т.к. такая поддержка не то что никогда не окупится, но и принесет ущерб самым массовым клиентам. Если бы клиенты хотели бы видеть контент без JS они бы выбирали RSS, Markdown и другие статичные форматы. Но именно клиенты выбирают JS.
Ну и php мертв, очень странно легаси считать актуальным стеком.
Имеется ввиду скорость редеринга страницы, а не инициализации. График из чужого теста так же это подтверждает. Оптимизация происходит за счет того что в DOM вставлены только те стили что используются на странице. Например в тайлвинде во всем приложении вы используете стили w-48, w-52, w-56, w-60, w-64, w-72, w-80, w-96. Соответственно все эти стили используются и войду в сборку. Но на странице которую открывает пользователь используется только стиль w-60. В таком случае tailwind все равно загрузит все стили которые есть в сборке, даже если они не используются на странице. Тем самым пользователь проиграет и в трафике и в скорости рендеринга, ведь движку рендеринга надо будет обработать больше CSS правил. SC в таких случаях загружает только один стиль на w-60. Таким образом клиент выиграет на трафике и рендеринге.
Mixins и includes есть, реализуются только не через ключевые слова SASS, а средствами языка typescript. Кроме того у вас вообще есть вся мощь TS и нету ограничений возможностей препроцессора.
Такие вещи как apply, extends, includes работают одинаково в SC и SASS, на выходе в обоих случаях строка которая скармливается браузеру. Только SC это делает покомпонентно, а sass все сразу.
А мне потешно восхваление tailwind при ненависти к bootstrap, хотя по факту это одно и тоже.
Зная внутренности работы библиотеки styled-components вы либо пишите про другую библиотеку, либо в чем то путаетесь. Конкретно в библиотеке styled-components не может такого происходить, там нету такой логики. Так же поиск в гугле не выдал ничего похожего с этой ошибкой.
На клиентах он действительно не нужен, т.к. на клиенте в любом случае придётся рендерить чтобы оживить сайт. И получается что к времени клиентского рендеринга добавляется еще время серверного рендеринга и передачи серверной страницы на клиент. Т.е. клиент от этого только проигрывает как по объему трафика, так и по времени ожидания. Где то в англоязычных интернетах про это даже хорошая статья есть с цифрами и графиками. Да и на моих проектах я не могу получить 500 балов по ligthouse через SSR из-за лишнего трафика и времени, на клиентском рендеринге 500 балов получается элементарно.
Поэтому все фреймворки с SSR работают по следующему принципу. При обращению к первой странице происходит SSR, при последующих страницах работает исключительно клиентский рендеринг. А боты не умеют в переходы, поэтому они запрашивают следующую страницу.
А про трудности слабых устройств вы сильно преувеличили, даже бюджетного 10 летнего телефона хватит что бы без проблем отрендерить сайт на стороне клиента. Главное использовать легковесные библиотеки и фреймворки. Но основная проблема на таких устройствах не скорость рендеринга JS, а скорость обработки CSS. Слабые устройства заставляют тормозить сложные CSS.
Статья про то как роботам увидеть весь контент. Вариант с минимальной частью на сервере ближе к клиентскому рендерингу. Гугл и яндекс научились рендерить такие сайты, но у гугла результат совсем плохой, у яндекса совсем недавно появилось поэтому статистики еще нет. Остальные роботы зависит от поддержки клиентского рендеринга.
Пессимизируют если контент отличается. Например, на сервере вы выдаете контент про здоровое питание, а скриптом подменяете на контент про что-то нелегальное. Когда контент одинаковый то роботы воспринимают его правильно. Кроме того у того же гугла пререндер недавно был рекомендуемым инструментом. И на личной практике он успешно справляется и сайты на пререндере находятся в топе по нужным ключевым словам.
Родной для меня C#, русским владею только с Вордом. Лицензия на который кончилась, и продлить невозможно. Если знаете хороший сервис проверки грамматики посоветуйте пожалуйста. Спасибо за правки, где понял какая ошибка поправил.
Используем самописную сетку на гридах, ничего подобного не наблюдаем. Да и в MUI ничего подобного не встречал, а он на emotion.
Судя по описанной вами проблеме она находиться на уровне реакта, а не SC. Поскольку SC ничего не знает о тех стиля с которыми он работает, в т.ч. о гридах. У вас в каком то месте происходит пересоздание компонента, вероятнее всего из-за динамического контента или некорректно заданного key.
А секрет прост. Движок CSS не бесплатно работает, он тоже имеет свои расходы. Просто об этом никто не пишет на хабре, поэтому вы о стоимости стилей и их рендеринга не задумываетесь. И чем больше в движке стилей, тем медленнее он делает выборки в этих стилях и следовательно рендерится страница. Сложные селекторы тоже убивают скорость движка CSS. SC готовит стили таким образом что во первых готовятся только те стили что реально используются и не тянет в прод мусор, во вторых имеет крайне простые селекторы. За счет чего движку CSS проще работать.
Да, подготавливает строку CSS и передает в движок. Примерно тоже самое что скормить CSS файл. Но SC скармливает не все стили сразу, а порционно, по мере необходимости.
Для того что бы запустить обычный сайт тоже надо скачать js и распарсить его. На самом деле в загрузке огромного файла CSS перед кодом нету никакой необходимости. Вы его все равно не увидите. А если вы будете добавлять CSS вместе с созданием компонента вы ничего не теряете. Даже выигрываете. Например можно использовать этот трюк https://habr.com/ru/post/684836/. Огромный CSS файл вы никак не положите в 14КБ. А в SC его нету. И можно получить лучший FCP в метрике перформанса.
Через атрибут stylе далеко не все можно сделать. Например нельзя отрисовать разный стиль в хроме и сафари.
Так то любую дичь и JS позволят творить ) По вашей логике Веб должен был бы развалиться, но нет. Веб жив. =)
Вот тут мы и выясняли кто тут школота. Любой дед знает что во вьюхе не может быть никакой логики. Поэтому любой дед разделяет компонент на MVC. Поэтому возвращаемся к исходному коменту про разделение. И получается что вы сами себя школотой обозвали ))
А что для движка CSS нативно? Файл CSS? Не угадали. Это всего лишь файл данных, примерно как JSON для V8. Нативно для для движка CSS это массивы объектов в памяти. И тут SC гораздо ближе к нативно чем CSS. А с точки зрения движка между CSS и SC разница лишь в том что первый скармливает сразу все стили, а второй порционно по мере необходимости. Какая проблема с производительностью? 10% на инициализацию? Не смертельно. Зато скорость рендеринга почти в два раза возрастает что напрямую влияет на пользовательский опыт. Какие еще проблемы совместимости? Это js, его полифилить хоть до ie6 можно. Какое еще отсутствие кроссплатформенности? Работает во всех браузерах и операционних системах.
Смешались в кучу люди, кони, и залпы тысячи орудий... (C) Лермонтов
Вот прямо вижу картину, добавляешь в проект SC и у тебя сразу перемешивается все, код, стили, бизнес логика...
У меня вот с точки зрения организации кода все остается неизменным. Компонент разбит на 3 файла: верстка, логика, стили. Только у стилей вместо расширения css используется расширения ts.
А у тебя в проектах логика вынесена за пределы вьюхи или все в куче и в одном файле? )))
Это религия. В религии не нужны аргументы и доказательства, в религии нужна только вера.
Вот только мемоизация любого из компонента убьет все ваше открытие. Кроме того оно не работает вверх по дереву. Используйте контексты или MobX и не страдайте.
Вы так и не поняли. Это не время отрабатывания сервера. Это время отрисовки устройства. Очень медленно парсится страница и рендерится CSS.
Вы как то не так прочитали, вариант с серверным рендерингом грузился дольше чем вариант с клиентским рендерингом и вызвал ощущение зависшего сайта.
Кстати про читалку.
Этот сайт выполнен как клиентский рендеринг и напичкан JS буквально в каждом элементе. При этом он отлично себя чувствует на читалке. Секрет в легковесных библиотеках и стейт менеджере.
Кроме того использован эффект одного TCP пакета. В нем расположен лоадер. За счет чего на читалке почти сразу отобразился лоадер и еще секунд 10 шла загрузка.
Потом попытался открыть сайт на SSR, долго отображался белый экран, я уж подумал даже что сайт лежит. Но в итоге тоже отрисовался. Все это время он парсил документ и гидрировал страницу.
Почему форма именно на JS:
Обратите внимание, редактор комментариев это не просто текстовый элемент, а довольно таки сложный редактор со сложным функционалом. Без JS такое работать не будет.
Эта форма отправляет на бекенд не то что вы видите и не html. Эта форма отправляет на бекенд JSON. Это нужно для того чтобы потом можно было отобразить те же комментарии в нативном приложении.
Форма на submit вызовет мерцание страницы с потерей положения скрола + лишним трафиком на повторную загрузку статьи. Форма на JS красиво вставляет комментарий в список комментариев, без каких либо мерцаний и перезагрузок страниц. Если любому человеку предложить два варианта поведения, то он выберет форму без мерцания и потерей скрола.
Ходить по телеграмм каналам и теребить чувства верующих не в моих правилах. Но сами наверное понимаете что рендерить страницу на html и оживлять через jquery в 2023 может только совсем не адекватный человек. Куда проще взять Next.js и написать изоморфное приложение.
Где вы вообще нашли функцию выключения JS в 2023 году? ))
Вы недооцениваете хабру. Если посмотреть профайлер инициализации хабры, то у нее скриптов не меньше чем в любом навороченном сайте. Карму вы не поднимете, комментарий не напишите, элементарно три точки под комментом работать не будут, я уж молчу про аналитику и рекламу. Если вам нужен текст без JS вы можете прочитать в другом формате, например RSS. Но нет, вы открыли не RSS, а JS и жалуетесь на то что здесь работает JS. Это был ваш выбор, а не чей то другой. Выбирали бы RSS было бы больше контента на RSS.
Вы почему то думаете 1 сервер обслуживает только 1 клиента. Но это не так. Один сервер обслуживает сотни и тысячи клиентов в секунду. Если взять бюджетный телефон, например Redmi 9 за 9 тысяч и новый Xeon за 200 тысяч, да, Xeon будет в 100 раз быстрее, но обслуживать будет 1000 клиентов. При таком раскладе на одного клиента придётся в 10 раз меньше ресурсов. Уже писал в статье что делал программу на клиентском рендеринге и она занимала всего 10% от 4 ядер, в то время как аналогичная программа с серверным рендерингом занимала 15 навороченных серверов. Которые еще и поддерживать надо. И метрики TBT и TTI у клиентского рендеринга лучше за счет отсутствия двойной работы по серверному и клиентскому рендерингу.
vue, react, angular - да, на помойку. Как минимум надо использовать preact, svelte, solidjs (на худой конец $mol ;) ).
alpine.js - выдает вам шаблон который все равно рендерится на клиентской стороне. Вы не сможете прочитать статьи выведенные в циклы в alpine.js пока их не обработает JS. Это все го лишь другой шаблонизатор. Кроме того по тестам перформанса он в разы медленее не только preact, но и react. Пруф по ссылке.
Да, я когда делаю софт делаю поддержку не всех браузеров, а только тех чья доля составляет более 0,5% на рынке. Понижать эту планку экономически не целесообразно, т.к. такая поддержка не то что никогда не окупится, но и принесет ущерб самым массовым клиентам. Если бы клиенты хотели бы видеть контент без JS они бы выбирали RSS, Markdown и другие статичные форматы. Но именно клиенты выбирают JS.
Ну и php мертв, очень странно легаси считать актуальным стеком.
Имеется ввиду скорость редеринга страницы, а не инициализации. График из чужого теста так же это подтверждает. Оптимизация происходит за счет того что в DOM вставлены только те стили что используются на странице. Например в тайлвинде во всем приложении вы используете стили w-48, w-52, w-56, w-60, w-64, w-72, w-80, w-96. Соответственно все эти стили используются и войду в сборку. Но на странице которую открывает пользователь используется только стиль w-60. В таком случае tailwind все равно загрузит все стили которые есть в сборке, даже если они не используются на странице. Тем самым пользователь проиграет и в трафике и в скорости рендеринга, ведь движку рендеринга надо будет обработать больше CSS правил. SC в таких случаях загружает только один стиль на w-60. Таким образом клиент выиграет на трафике и рендеринге.
Mixins и includes есть, реализуются только не через ключевые слова SASS, а средствами языка typescript. Кроме того у вас вообще есть вся мощь TS и нету ограничений возможностей препроцессора.
Такие вещи как apply, extends, includes работают одинаково в SC и SASS, на выходе в обоих случаях строка которая скармливается браузеру. Только SC это делает покомпонентно, а sass все сразу.
А мне потешно восхваление tailwind при ненависти к bootstrap, хотя по факту это одно и тоже.
Зная внутренности работы библиотеки styled-components вы либо пишите про другую библиотеку, либо в чем то путаетесь. Конкретно в библиотеке styled-components не может такого происходить, там нету такой логики. Так же поиск в гугле не выдал ничего похожего с этой ошибкой.
На клиентах он действительно не нужен, т.к. на клиенте в любом случае придётся рендерить чтобы оживить сайт. И получается что к времени клиентского рендеринга добавляется еще время серверного рендеринга и передачи серверной страницы на клиент. Т.е. клиент от этого только проигрывает как по объему трафика, так и по времени ожидания. Где то в англоязычных интернетах про это даже хорошая статья есть с цифрами и графиками. Да и на моих проектах я не могу получить 500 балов по ligthouse через SSR из-за лишнего трафика и времени, на клиентском рендеринге 500 балов получается элементарно.
Поэтому все фреймворки с SSR работают по следующему принципу. При обращению к первой странице происходит SSR, при последующих страницах работает исключительно клиентский рендеринг. А боты не умеют в переходы, поэтому они запрашивают следующую страницу.
А про трудности слабых устройств вы сильно преувеличили, даже бюджетного 10 летнего телефона хватит что бы без проблем отрендерить сайт на стороне клиента. Главное использовать легковесные библиотеки и фреймворки. Но основная проблема на таких устройствах не скорость рендеринга JS, а скорость обработки CSS. Слабые устройства заставляют тормозить сложные CSS.
Статья про то как роботам увидеть весь контент. Вариант с минимальной частью на сервере ближе к клиентскому рендерингу. Гугл и яндекс научились рендерить такие сайты, но у гугла результат совсем плохой, у яндекса совсем недавно появилось поэтому статистики еще нет. Остальные роботы зависит от поддержки клиентского рендеринга.
Пессимизируют если контент отличается. Например, на сервере вы выдаете контент про здоровое питание, а скриптом подменяете на контент про что-то нелегальное. Когда контент одинаковый то роботы воспринимают его правильно. Кроме того у того же гугла пререндер недавно был рекомендуемым инструментом. И на личной практике он успешно справляется и сайты на пререндере находятся в топе по нужным ключевым словам.
Родной для меня C#, русским владею только с Вордом. Лицензия на который кончилась, и продлить невозможно. Если знаете хороший сервис проверки грамматики посоветуйте пожалуйста. Спасибо за правки, где понял какая ошибка поправил.
А я бы послушал про историю с топ менеджером с точки зрения топ менеджера. Что то в этой былине явно приукрашено.
PS: Микросервисы действительно помогают масштабироваться если умеешь делегировать и распределять труд.
Вообще в докере можно обращаться по имени сервиса, оно же будет именем хоста.
Этот конфиг используется для локальной разработки?
Пытался найти эту багу, не нашел.
Используем самописную сетку на гридах, ничего подобного не наблюдаем. Да и в MUI ничего подобного не встречал, а он на emotion.
Судя по описанной вами проблеме она находиться на уровне реакта, а не SC. Поскольку SC ничего не знает о тех стиля с которыми он работает, в т.ч. о гридах. У вас в каком то месте происходит пересоздание компонента, вероятнее всего из-за динамического контента или некорректно заданного key.
А секрет прост. Движок CSS не бесплатно работает, он тоже имеет свои расходы. Просто об этом никто не пишет на хабре, поэтому вы о стоимости стилей и их рендеринга не задумываетесь. И чем больше в движке стилей, тем медленнее он делает выборки в этих стилях и следовательно рендерится страница. Сложные селекторы тоже убивают скорость движка CSS. SC готовит стили таким образом что во первых готовятся только те стили что реально используются и не тянет в прод мусор, во вторых имеет крайне простые селекторы. За счет чего движку CSS проще работать.
Да, подготавливает строку CSS и передает в движок. Примерно тоже самое что скормить CSS файл. Но SC скармливает не все стили сразу, а порционно, по мере необходимости.
Для того что бы запустить обычный сайт тоже надо скачать js и распарсить его. На самом деле в загрузке огромного файла CSS перед кодом нету никакой необходимости. Вы его все равно не увидите. А если вы будете добавлять CSS вместе с созданием компонента вы ничего не теряете. Даже выигрываете. Например можно использовать этот трюк https://habr.com/ru/post/684836/. Огромный CSS файл вы никак не положите в 14КБ. А в SC его нету. И можно получить лучший FCP в метрике перформанса.
Через атрибут stylе далеко не все можно сделать. Например нельзя отрисовать разный стиль в хроме и сафари.
Так то любую дичь и JS позволят творить ) По вашей логике Веб должен был бы развалиться, но нет. Веб жив. =)
Вот тут мы и выясняли кто тут школота. Любой дед знает что во вьюхе не может быть никакой логики. Поэтому любой дед разделяет компонент на MVC. Поэтому возвращаемся к исходному коменту про разделение. И получается что вы сами себя школотой обозвали ))
А что для движка CSS нативно? Файл CSS? Не угадали. Это всего лишь файл данных, примерно как JSON для V8. Нативно для для движка CSS это массивы объектов в памяти. И тут SC гораздо ближе к нативно чем CSS. А с точки зрения движка между CSS и SC разница лишь в том что первый скармливает сразу все стили, а второй порционно по мере необходимости. Какая проблема с производительностью? 10% на инициализацию? Не смертельно. Зато скорость рендеринга почти в два раза возрастает что напрямую влияет на пользовательский опыт. Какие еще проблемы совместимости? Это js, его полифилить хоть до ie6 можно. Какое еще отсутствие кроссплатформенности? Работает во всех браузерах и операционних системах.
Смешались в кучу люди, кони, и залпы тысячи орудий... (C) Лермонтов
Вот прямо вижу картину, добавляешь в проект SC и у тебя сразу перемешивается все, код, стили, бизнес логика...
У меня вот с точки зрения организации кода все остается неизменным. Компонент разбит на 3 файла: верстка, логика, стили. Только у стилей вместо расширения css используется расширения ts.
А у тебя в проектах логика вынесена за пределы вьюхи или все в куче и в одном файле? )))