Запуск идеи стоит 5 млн, и это дорого. Как сэкономить на проекте? Спойлер: откажитесь от React

Серверный рендеринг — маст‑хэв для бизнесов, которые хотят запуститься быстро. Секрет высокой скорости — более простой код и меньшее количество багов.

Вау. А где связь?

Статья о том, как лендинги на реакте - это оверхед и админки для сбора звонков перестали покупать в вашей веб-студии?

В целом, рендеринг на сервере — идеальный вариант для проектов со статичным контентом. Как правило, на подобных сайтах возможности React и Vue не используют на полную мощность. Получается, заказчик переплачивает за CSR там, где можно сэкономить.

1. для статики есть ssg, ssr тут не нужен.

2. Реакт и вью используют не потому, что они "мощщщные", этот аргумент вообще безоснователен в рамках всей статьи в целом.

У нас нет цели взять как можно больше денег — и ради этого посадить дорогостоящих специалистов отрабатывать часы

Верю. У вас есть цель взять как можно больше денег, продав время работы джунов как сеньорское, потом написать статью как вы не смогли в <имя_технологии> и налить водички, корявенько себя порекламив, т.к. пройдя даже по сайту, который вы привели в качестве примера, и без профилирования виден layout shift, и как уже после загрузки страницы даже с кешем к кнопкам применяется css :)

Успехов вам, в любом случае.

React vs Vue vs Angular. Часть 3

Vuex, Redux, мы в каком году вообще?

Микрофронтенды на Module Federation — наш опыт. Часть 2

Можете раскрыть, что подразумеваете под этим?

Синхронная федерация - это когда адрес прописывается в remotes. Динамическая - когда в рантайме дергается get/init вебпака (примерно, как тут)

А что именно содержится в этом JSON?

Переменные окружения, адрес ремоута, filename, exposes, некоторая бизнес-информация

Если там по аналоги с нашим манифестом инфа о shared, то как вы обеспечиваете актуальность версий

Фронтовым монорепозиторием + отдельно в той структуре генерируется информация о шареде - все версии жестко зафиксированы и не имеют права фронты без согласования трогать каким-либо образом бибилиотеки (установка, обновление и т.д.). Ну и жесткие правила гитфлоу. В общем, доверия никакого никому с частичной атоматизацией)
Не смотря на возможность работать в отдельный репах, с module federation я в принципе не сторонник такого подхода + приходилось работать не всегда работать с самыми квалифицированными кадрами, отчего упаковка в монорепу с единым списком библиотек стал единственным подходящим вариантом для работы

Микрофронтенды на Module Federation — наш опыт. Часть 2

Немного не ясен момент - у вас все-таки динамическая федерация или синхронная на промисах?

Идея с плагином для манифестов интересная, но я в своих проектах держал отдельно с каждым фронтом json, который его описывает. В последних итерациях пришли сбору всех и мержингу в одну большую (относительно, для прода минифицируется и чистится от dev переменных) структуру, которая запрашивается шеллом в рантайме + содержит переменные окружения (динамическая федерация).
В крайнем проекте, все это упаковано в nx и генерируется его инструментами

Архитектура front-end приложений — react, react native, angular. Обзор

От архитектуры только слова, зато как папки разложить - миллион скриншотов. Обидно

7 интересных API на JavaScript для создания веб-сайтов, о которых вы (скорее всего) не знали

Необходимо учитывать, что некоторые api работают только при наличии https соединения. Clipboard Api так точно это требует

Планировщик задач: не замораживаем вкладку при открытии страницы

Гидратация - инициализация скриптов на клиенте, потому что изначально они выполнились на сервере, а точнее - "довешивание" отсутсвующих событий и т.д.

Перерождение Lerna. Что нового в Lerna 6?

Допустим, мне, как человеку, который выбирает себе систему управления монорепой, не понятен момент смысл лерны, если существует NX, а все изменения из статьи, насколько я понял, крутятся вокруг того, что лерна теперь крутит NX под капотом.

Отсюда вытекает вопрос, а смысл мне использовать лерну? что она дает, что не делает NX?

Паттерны верстки. Как объединить верстальщиков и дизайнеров

что мы получим по факту

по факту мы получаем при правильном системном подходе построения типографики несколько строк css для построения адаптива, который сохраняет принципы поточности, задуманные дизайнером. Например, это хорошо видно тут. Вы получаете не только DX (developer experience) в виде построения адаптива, но и отзывчивый UX к масштабированию.

ведь по сули используем те же px в миксине, а визуально нечего не меняет. можете дать комментарий?

Этот миксин всего лишь DX. Пиксель это та единица, которая понятна всем. Пиксель статичен. EM/REM уже относительные единицы и ими оперировать сложнее.
Миксин позволяет выставить базовый контекст, которым может отличаться от 16 пикселей и указывая размеры, rem будет обозначен относительно контекста. Если у вас контекст, например, 10 пикселей, а шрфит - 16, то вы получаете 1.6. Поменяв контекст, вы получите 1, при этом менять типографику вам не нужно от слова совсем (на случай важных правок)

ы делаем размеры шрифта зависимыми от размера экрана. что может создать проблемы с восприятием чтения читателем

ваш дизайн обязан строго соответствовать макетам. Для остальных случаев нужен rfs, чтобы не ломать поток. У вас, например, макеты для 320-380, 768, 1360+ пикселей, при этом есть особые виды пользаков и клиентов, которые любят проверять адаптив, изменяя размер окна бразуреа. Я, когда работаю на своем маке самом свежем, часто пользуюсь сплит-скрин режимов до 4х окон и есть сайты, которые уже на полэкрана выглядят просто ужасно, потому что там все прибито гвоздями по пикселям, и расползаются и кнопки, и заголовки, и изображения теряют соотношения сторон, потому что верстальщику/фронтеру было лень добавить немного для того, чтобы во внештатных брейкпоинтах все выглядело более-менее чинно. И меня, будучи верстальщиком, некоторые заказчики этой историей так же выбешивали, и вот до чего я дошел, по сути, и по сей день использую в своих проектах. Если у вас шрифт будет чуть меньше того, что задумал дизайнер на внештатном разрешении - это не страшно, страшно когда он остается такой же и скорее всего он будет ломать поток.

Есть, например, вот такая статья, которая "поясняет за rem/em" и другие стороны доступности и адаптивности, есть куча других докладов на smashing magazine (тык, тык), css tricks (тык, тык) и т.д., и тот же Вадим Макеев что-то про шрифты и относительные единицы говорил. И даже в приведенных ссылках ведутся дебаты по поводу надо или нет, но лично мои реалии таковы, что лучше перестраховаться

Паттерны верстки. Как объединить верстальщиков и дизайнеров

del

Паттерны верстки. Как объединить верстальщиков и дизайнеров

если для вас норм писать такие значения и потом в них не путаться, то ок

для этого есть миксин , если не нужно работать со шрифтом. для шрифтов используется респонсивный размер

обычно это кейс редкий

в этой кейсе лично я бы оставил только минимальную высоту и в том же rem, т.к. в идеальных условиях будет выглядеть так, как надо, а в иных случаях будут работать связки rem + rfs. Скорее всего у меня в этих случаях не вылезет текст за кнопку и в большинстве нетривиальных кейсов пропорциональность будет более-менее соблюдена

Паттерны верстки. Как объединить верстальщиков и дизайнеров

"поплывет" вся верстка

поплывет куда? ваша задача делать интерфейс адаптивным. Он должен быть таким, каким его задумал дизайнер, но при этом быть дружелюбным к другим юзкейсам. Речь не только об отступах, а об и респонсивных шрифтах и тот же бутстрап использует у себя rfs

браузеры весьма неплохо справляются с масштабированием значений в пикселях

браузер не делает ничего, чтобы ваша верстка оставалась такой, какой она есть на увеличенных/уменьшенных масштабах. А некоторые, в т.ч. и я когда-то, принудительно выключали масштабирование, только потом за это и валидатор и LightHouse по рукам бьет

Для всего, что не должно зависеть от размера шрифта, не нужно использовать единицы, которые зависят от размера шрифта.

остается только отступы межды элементами и то, в некоторых юзкейсах, например, том же масштабировании, когда перестраивается интерфейс, отступы в пикселях выглядят отвратительно :)

Паттерны верстки. Как объединить верстальщиков и дизайнеров

Не задавать высоту элементам (input button и тд) с помощью padding. Дизайнер задает конкретные параметры элемента в пикселях, поэтому изменение количества строк или внутреннего контента  повлияет на исходные размеры. Поэтому height у элементов задаем в пикселях

Дизайнер как раз должен учитывать ситуацию переполнения контента, и не задавать паддинги не вижу смысла по причине ниже

Лучше использовать пиксели в верстке, а не другие единицы измерения. Дизайн изначально создан в пикселях, поэтому не стоит вмешиваться в исходные параметры.

Еще как стоит. В бытность мою работы на фрилансе и галере веб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?

Получается, что:
1) Вместо установки rem на боди и пропорциональному уменьшению/увеличению его на мобилке, я должен буду руками ходить все исправлять?
2) Я не учитываю работу клиентского устройства под разного рода масштабированием

А масштабирование - это элемент доступности, вы предлагаете делать интерфейсы недоступными, просто потому что дизайнер прав? А если он не прав?

Данная статья поможет улучшить взаимодействие между дизайнерами и верстальщиками для минимизации ошибок и повышения продуктивности работы.

Вот если честно, не видно тут никакого взаимодействия между верстальщиком и дизайнером. Согласен только с некоторыми тезисами в начале статьи, категорически не согласен с цитируемыми выше блоками.

используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом стоит этого избегать и кастомизировать все под свои нужды.

Почему стоит избегать? Опять же, тот же бутстрап позволяет атомарно пересобрать свою сетку просто импортируя к себе нужные scss файлы и дальше вот те примеры по изобретению велосипеда не нужны от слова совсем.
Например, откопал такие участки кода в своих проектах +-3 лет давности :

@import 'node_modules/bootstrap/scss/bootstrap-reboot.scss';
@import 'node_modules/bootstrap/scss/bootstrap-grid.scss';
@import 'node_modules/bootstrap/scss/utilities/_sizing';

/* Vars:
   ========================================================================== */

// Font
$mainFont: 'HelveticaNeue', 'Helvetica', 'Arial', sans-serif;
$mainFontColor: #101010;

//desktops
$large_desktop: 1440px;
$small_desktop: 1200px;
//tablets
$large_tablet: 992px;
$small_tablet: 768px;
//phones
$large_mobile: 576px;
$small_mobile: 460px;
//core font
$mainFontSize: 16px; //16px
$mainFontWeight: 400;
$mainLineHeight: 150%; //24x or 1.25rem
$boxHeight: $mainLineHeight;

//bootstrap sizing
$grid-gutter-width: 40px;
$grid-columns: 10;

$grid-breakpoints: (
  xs: 0,
  sm: $large_mobile,
  md: $small_tablet,
  lg: $large_tablet,
  xl: $small_desktop,
  xxl: $large_desktop,
);

$container-max-widths: (
  sm: 540px + $grid-gutter-width,
  md: 720px + $grid-gutter-width,
  lg: 960px + $grid-gutter-width,
  xl: 1170px + $grid-gutter-width,
  xxl: 1320px + $grid-gutter-width,
);

$gutter: $grid-gutter-width / 2;

И дальше использовались те же классы или миксины бутстрапа. При этом, 0 js, потому что в моем случае мне только сетка и нужна.

Как подружить Git с приложением на Webpack+React

Можно пойти еще дальше и принудительно обновлять ветки, если локальный мастер отстает от ремоута :)

Мой опыт с Webpack 5 Module Federation

Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку.

а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" .
Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?

дык, при потреблении федерализации откуда типы брать?

я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).

Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии

Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей

У каждого выбора есть свои сильные и слабые стороны. В случае моем, все сильные стороны перекрыли слабые. И я в целом остался доволен, а предупредить про неприятные моменты - вот цель статьи, потому что нигде это не освещается практически

Мой опыт с Webpack 5 Module Federation

К сожалению, такое случается :)

Когда заказчик узнал, что от MVP ничего не осталось, его удивлению не было предела :)

Мой опыт с Webpack 5 Module Federation

Нет, просто в хост приложении загружается uikit и шарится в микрофронт. Сответственно, инжектятся стили с хешами версии ядра.
В микрофронте приложении uikit потребляется из хоста, но если версия будет, например, младше хоста и меняли, допустим, инпут или таблицу - стили отлетали, т.к. в дочернем приложении ожидаются другие хеши для css классов (использовались scss modules). Это как раз случай, когда, вероятно, использовать singleton для библиотеки не лучшее решение, но у нас uikit непонятным образом весит больше 2мб (точнее понятным - некоторую графику загнали в base64 в css и еще куча других проблем) и это мрак полный. Пришлось смириться и быть внимательным, чтобы обновлять единомоментно

Проблема тут еще в том, что uikit нам поставляли со стороны и информациооная поддержка была не лучшего качества - очень долго выбивали ченджлоги, в итоге пришли к тому, переодически высалаются PDF (!!!!) с описанием изменений, про сторибук молчу, больше выглядел как лишняя примочка не понятно для кого

Мой опыт с Webpack 5 Module Federation

Тут ничего сказать не могу, но по отзывам куча issue на гитхабе открытых, которые никак не решаются, так что я лично не хочу с лерной связываться

Мой опыт с Webpack 5 Module Federation

А с чем конкретно возникла сложность в типизации? У нас были проблемы в типизации бутстрапа (устали костылить и влепили мужицкий ts-ignore) и точку входа в дочь, если меняется стор ядра (приходится генерировать .d.ts и перекладывать руками в common), а так в остальном проблем не было

Мой опыт с Webpack 5 Module Federation

@movlпромахнулся веткой, извините