Для этого случая в ваших рекомендация по @font-face следовало бы сначала прописывать local() и только потом всякие там woff2/woff и т.п. Потому что сейчас ваша рекомендация будет игнорировать локально установленный шрифт и заставит браузер его скачивать.
redux — это Сизиф, упорно толкающий в гору огромный ком фекалий. Можно, конечно, какие-то абстракции и тулкиты использовать, но ком фекалий не прекратит быть комом фекалий. Эффектор, конечно, сильно лучше. Но зачем эти полумеры? mobx просто на голову лучше.
Может быть, конечно, и ложное срабатывание у play protect. Но я человек простой: если мне телефон пишет, что картографическое приложение барагозит, то я его снесу нафиг, благо альтернатив достаточно и, если приспичит, всегда можно открыть 2гис в браузере.
Реальный ад в веб.разработке был лет 15 назад, когда нужно было под разные браузеры разную верстку и код делать. И не было нормальных (да почти никаких) средств отладки.
А сейчас есть выбор. Никто не заставляет использовать фреймворки и JS. Делай статику и радуйся жизни.
Никаких других "разрядностей" нет. Был баг в браузерной реализации, который исправлен. По оригинальной ссылке можно самостоятельно проверить https://codepen.io/chriscoyier/pen/DKKmWE
Конкуренция — это хорошо, и если rollup (который умеет нормально разбивать на чанки) смогут в несколько раз ускорить, то это можно будет тащить в продакшн, а не ждать несколько лет (я про неработающее разбиение на чанки в esbuild).
>Все 3 фреймворка для этой задачи используют решения, которые базируются на архитектуре Flux.
Или фраза коряво составлена, или это заблуждение. Никто не заставляет вас использовать в flux (redux) при работе с реактом, это исключительно выбор разработчика.
Опять же, никто не заставляет тащить ngrx в angular — это тоже выбор разработчиков (с редаксом головного мозга).
Когда вы строите предположения о том, что из-за бОльшего количества CSS пользователь потеряет в производительности — это только ваши фантазии, потому что styled-components добавляет рантайм оверхед (он в рантайме вставляет новые теги style в DOM). Можно себе представить ситуацию, когда на странице одна какая-то простая кнопка и 2MB CSS — в этом случае, действительно, styled-components будут выигрывать, но не потому что технология такая хорошая, а потому что кому-то лень было разобраться с лишними 2MB CSS. Да, парсер CSS жрёт ресурсы, но не надо забывать о том, что в классическом подходе, парсер сожрёт ресурсы 1 раз, когда стили загрузились, а для SC парсер будет запускаться каждый раз, когда создаётся новый компонент и JS сгенерит для него стили. На счёт проигрыша в траффике — тоже вопрос открытый, потому что те, кто не следит за размером CSS, обычно не следят и за размерами JS бандлов, поэтому там будут десятки мегабайт всякого не используемого на странице кода.
Когда вы говорите, что в SC есть mixins и includes, то немного лукавите, потому что styled-components старается изолировать каждый компонент от других, а в настоящих mixins/includes из SASS вся фишка именно в том, что они делают работу с каскадностью чуть удобнее. И, при грамотном написании, CSS кода будет всегда меньше, чем сгенерит styled-components, именно по той причине, что последний пытается делать вид, будто каскадности не существует (да, там тоже можно генерировать глобальные стили, но выглядит это, как костыль).
Когда вы уверяете других, что на выходе у SC и SASS получается строка, которая скармливается браузеру, то так ли это? SC требует для работы JS и не использует каскадность, поэтому ну никак не получатся одно и то же.
P.S. я не пытаюсь накидывать говно на вентилятор. Уже почти три года использую SC с реактом в нескольких проектах. Свою UI либу написали на SC. И в 90% случаев всё хорошо работает и удобно. Но оставшиеся 10% случаев вынудили ряд компонентов переписать c SC на linaria.
P.P.S. У меня параллельно есть ещё один очень большой проект на ангуляре. И как-то ни разу не поймал себя на мысли, что не хватает styled компонент. У ангуляра изоляция стилей работает из коробки, но её можно легко отключить там, где это требуется.
Есть кейсы, где styled-components просто убивает производительность. У нас есть довольно большое приложение, где всё-всё-всё на styled components свёрстано. И мы отгребли проблем с производительностью, когда styled компоненты рендерятся в ячейках гридов (пробовал grid из ant, aggrid и самописный) — происходит очень много созданий и удалений компонентов при скроле, и styled постоянно вставляет и удаляет в DOM дерево CSS стили. И это очень медленно. Баг на эту тему уже много лет существует у них в трекере, но сделать ничего не могут.
подробные бенчмарки есть для большинства сколь-нибудь известных js фреймворков https://krausest.github.io/js-framework-benchmark/2024/table_chrome_123.0.6312.59.html
"Но вот в чем дело: если вы сможете преодолеть первоначальный барьер, использовать React будет сплошное удовольствие."
ээээ, нет. Разве что человек любит боль
Для этого случая в ваших рекомендация по @font-face следовало бы сначала прописывать local() и только потом всякие там woff2/woff и т.п. Потому что сейчас ваша рекомендация будет игнорировать локально установленный шрифт и заставит браузер его скачивать.
Так там же во введении написано: "Мыши плакали, кололись, но продолжали жрать кактус".
redux — это Сизиф, упорно толкающий в гору огромный ком фекалий. Можно, конечно, какие-то абстракции и тулкиты использовать, но ком фекалий не прекратит быть комом фекалий. Эффектор, конечно, сильно лучше. Но зачем эти полумеры? mobx просто на голову лучше.
Может быть, конечно, и ложное срабатывание у play protect. Но я человек простой: если мне телефон пишет, что картографическое приложение барагозит, то я его снесу нафиг, благо альтернатив достаточно и, если приспичит, всегда можно открыть 2гис в браузере.
Если в форме меньше сотни полей ввода, то не всё ли равно, какая из библиотек валидации быстрее? Милисекундой больше, милисекундой меньше.
Бредятина какая-то.
Реальный ад в веб.разработке был лет 15 назад, когда нужно было под разные браузеры разную верстку и код делать. И не было нормальных (да почти никаких) средств отладки.
А сейчас есть выбор. Никто не заставляет использовать фреймворки и JS. Делай статику и радуйся жизни.
Никаких других "разрядностей" нет. Был баг в браузерной реализации, который исправлен. По оригинальной ссылке можно самостоятельно проверить https://codepen.io/chriscoyier/pen/DKKmWE
Количество скачиваний — это аргумент из серии "миллионы мух не могут ошибаться".
Конкуренция — это хорошо, и если rollup (который умеет нормально разбивать на чанки) смогут в несколько раз ускорить, то это можно будет тащить в продакшн, а не ждать несколько лет (я про неработающее разбиение на чанки в esbuild).
Просто перестаньте страдать и использовать редакс.
Не половина. Все
>Все 3 фреймворка для этой задачи используют решения, которые базируются на архитектуре Flux.
Или фраза коряво составлена, или это заблуждение. Никто не заставляет вас использовать в flux (redux) при работе с реактом, это исключительно выбор разработчика.
Опять же, никто не заставляет тащить ngrx в angular — это тоже выбор разработчиков (с редаксом головного мозга).
Как вы предлагаете по истории коммитов wetbkit определить, что и когда попадёт в релиз?
Сафари - дерьмо, которое постоянно что-нибудь новое ломает.
у меня кровь из глаз пошла, когда увидел App.tsx. Дальше смотреть не смог
Круто! На самом деле круто.
(вот уж не думал, что напишу такое под статьёй Карловского)
Какой-то борщ с котлетами у вас выходит.
Когда вы строите предположения о том, что из-за бОльшего количества CSS пользователь потеряет в производительности — это только ваши фантазии, потому что styled-components добавляет рантайм оверхед (он в рантайме вставляет новые теги style в DOM). Можно себе представить ситуацию, когда на странице одна какая-то простая кнопка и 2MB CSS — в этом случае, действительно, styled-components будут выигрывать, но не потому что технология такая хорошая, а потому что кому-то лень было разобраться с лишними 2MB CSS. Да, парсер CSS жрёт ресурсы, но не надо забывать о том, что в классическом подходе, парсер сожрёт ресурсы 1 раз, когда стили загрузились, а для SC парсер будет запускаться каждый раз, когда создаётся новый компонент и JS сгенерит для него стили. На счёт проигрыша в траффике — тоже вопрос открытый, потому что те, кто не следит за размером CSS, обычно не следят и за размерами JS бандлов, поэтому там будут десятки мегабайт всякого не используемого на странице кода.
Когда вы говорите, что в SC есть mixins и includes, то немного лукавите, потому что styled-components старается изолировать каждый компонент от других, а в настоящих mixins/includes из SASS вся фишка именно в том, что они делают работу с каскадностью чуть удобнее. И, при грамотном написании, CSS кода будет всегда меньше, чем сгенерит styled-components, именно по той причине, что последний пытается делать вид, будто каскадности не существует (да, там тоже можно генерировать глобальные стили, но выглядит это, как костыль).
Когда вы уверяете других, что на выходе у SC и SASS получается строка, которая скармливается браузеру, то так ли это? SC требует для работы JS и не использует каскадность, поэтому ну никак не получатся одно и то же.
P.S. я не пытаюсь накидывать говно на вентилятор. Уже почти три года использую SC с реактом в нескольких проектах. Свою UI либу написали на SC. И в 90% случаев всё хорошо работает и удобно. Но оставшиеся 10% случаев вынудили ряд компонентов переписать c SC на linaria.
P.P.S. У меня параллельно есть ещё один очень большой проект на ангуляре. И как-то ни разу не поймал себя на мысли, что не хватает styled компонент. У ангуляра изоляция стилей работает из коробки, но её можно легко отключить там, где это требуется.
Есть кейсы, где styled-components просто убивает производительность. У нас есть довольно большое приложение, где всё-всё-всё на styled components свёрстано.
И мы отгребли проблем с производительностью, когда styled компоненты рендерятся в ячейках гридов (пробовал grid из ant, aggrid и самописный) — происходит очень много созданий и удалений компонентов при скроле, и styled постоянно вставляет и удаляет в DOM дерево CSS стили. И это очень медленно. Баг на эту тему уже много лет существует у них в трекере, но сделать ничего не могут.
А зачем было переводить новость о выходе фрейморка по прошествии почти двух лет?