Мне в 23 году дерматолог поставил диагноз заболевания кожи
На прошлой неделе второй дерматолог подтвердил диагноз, не смотря на то, что лечение приносило кратковременные результаты
Загрузил фотографии поражённых мест в чат гпт. За 5-10 минут в чате он предположил другой диагноз (верный), который подтвердился третьим дерматологом и анализами
Конечно, есть вопросики к первым двум дерматологам, т.к. они из одной и той же сети клиник (в МСК) и почему я лечил 2 года не ту болезнь, но учитывая мою ситуацию я склонен верить нейронке немного, а хотя намного больше
По поводу учителей тейк не понятен, нейронка на 100% справится с ролью учителя, но тут важно понимать, что какие-то скользкие исторические вопросы все же она раскрывать не будет (привет яндекс гпт, дипсику и т.д.). Учителей и преподавателей по точным наукам я уверен что способна полностью заменить, по некоторым гуманитарным наукам вопрос
Кто такие современные бэкендеры? Те кто берут монгу + nest и потом диву даются, что продукт не выдерживает 10к rps и 5к одновременных пользаков?
А дизайн и ux? Это наверное про Яндекс.Плюс, в котором надо быть гением, чтобы отключить подписку и когда найти, то три раза нажать отключить? Или про интерфейс, в котором модальные окна на каждый чих и пук и серые буквы на сером фоне? Про доступность я вообще молчу, нам же на фон надо паралакс навесить и чтобы контент со всех возможных сторон вылетал и всплывал на скроле.
Это статья набор стереотипов 5-10 летней давности, которая претендует на что? Что надо брать htmx и serverless для фронта и все будет хорошо? Что вместо бека можно в txt сохранять? Или что вместо ui kit можно использовать нативные браузерные стили?
И очень интересно посмотреть сколько мвп выжили и сколько потом по итогу не переписали с нуля и по итогу не превратились то самое зло оверхедное.
1) Звук от фильма к фильму скачет, подтверждаю. Сам думаю докупать саундбар
2) иногда сама переключает приложения или задаёт вопрос.
3) почти всегда отказывается запускать приложения по номеру, только если это не hdmi разъём
4) с последними обновлениями раздражающе подсовывает в начало списка иви и вк видео, ещё и увеличивает в размере. У меня и так вк видео установлен, но пользуюсь редко. Но вот такие рекламные ходы уменьшают и без того низкое желание использовать
5) если не перезагружать, то начинает очень тупить. Не помогает даже убийство приложений.
6) Нет эквалайзера (или не нашел)
На самом деле, у меня впервые больше претензий к устройству, я не советую к покупке, если только не по скидке
Серверный рендеринг — маст‑хэв для бизнесов, которые хотят запуститься быстро. Секрет высокой скорости — более простой код и меньшее количество багов.
Вау. А где связь?
Статья о том, как лендинги на реакте - это оверхед и админки для сбора звонков перестали покупать в вашей веб-студии?
В целом, рендеринг на сервере — идеальный вариант для проектов со статичным контентом. Как правило, на подобных сайтах возможности React и Vue не используют на полную мощность. Получается, заказчик переплачивает за CSR там, где можно сэкономить.
для статики есть ssg, ssr тут не нужен.
Реакт и вью используют не потому, что они "мощщщные", этот аргумент вообще безоснователен в рамках всей статьи в целом.
У нас нет цели взять как можно больше денег — и ради этого посадить дорогостоящих специалистов отрабатывать часы
Верю. У вас есть цель взять как можно больше денег, продав время работы джунов как сеньорское, потом написать статью как вы не смогли в <имя_технологии> и налить водички, корявенько себя порекламив, т.к. пройдя даже по сайту, который вы привели в качестве примера, и без профилирования виден layout shift, и как уже после загрузки страницы даже с кешем к кнопкам применяется css :)
Синхронная федерация - это когда адрес прописывается в remotes. Динамическая - когда в рантайме дергается get/init вебпака (примерно, кактут)
А что именно содержится в этом JSON?
Переменные окружения, адрес ремоута, filename, exposes, некоторая бизнес-информация
Если там по аналоги с нашим манифестом инфа о shared, то как вы обеспечиваете актуальность версий
Фронтовым монорепозиторием + отдельно в той структуре генерируется информация о шареде - все версии жестко зафиксированы и не имеют права фронты без согласования трогать каким-либо образом бибилиотеки (установка, обновление и т.д.). Ну и жесткие правила гитфлоу. В общем, доверия никакого никому с частичной атоматизацией) Не смотря на возможность работать в отдельный репах, с module federation я в принципе не сторонник такого подхода + приходилось работать не всегда работать с самыми квалифицированными кадрами, отчего упаковка в монорепу с единым списком библиотек стал единственным подходящим вариантом для работы
Немного не ясен момент - у вас все-таки динамическая федерация или синхронная на промисах?
Идея с плагином для манифестов интересная, но я в своих проектах держал отдельно с каждым фронтом json, который его описывает. В последних итерациях пришли сбору всех и мержингу в одну большую (относительно, для прода минифицируется и чистится от dev переменных) структуру, которая запрашивается шеллом в рантайме + содержит переменные окружения (динамическая федерация). В крайнем проекте, все это упаковано в nx и генерируется его инструментами
Допустим, мне, как человеку, который выбирает себе систему управления монорепой, не понятен момент смысл лерны, если существует 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 (тык, тык) и т.д., и тот же Вадим Макеев что-то про шрифты и относительные единицы говорил. И даже в приведенных ссылках ведутся дебаты по поводу надо или нет, но лично мои реалии таковы, что лучше перестраховаться
в этой кейсе лично я бы оставил только минимальную высоту и в том же rem, т.к. в идеальных условиях будет выглядеть так, как надо, а в иных случаях будут работать связки rem + rfs. Скорее всего у меня в этих случаях не вылезет текст за кнопку и в большинстве нетривиальных кейсов пропорциональность будет более-менее соблюдена
поплывет куда? ваша задача делать интерфейс адаптивным. Он должен быть таким, каким его задумал дизайнер, но при этом быть дружелюбным к другим юзкейсам. Речь не только об отступах, а об и респонсивных шрифтах и тот же бутстрап использует у себя rfs
браузеры весьма неплохо справляются с масштабированием значений в пикселях
браузер не делает ничего, чтобы ваша верстка оставалась такой, какой она есть на увеличенных/уменьшенных масштабах. А некоторые, в т.ч. и я когда-то, принудительно выключали масштабирование, только потом за это и валидатор и LightHouse по рукам бьет
Для всего, что не должно зависеть от размера шрифта, не нужно использовать единицы, которые зависят от размера шрифта.
остается только отступы межды элементами и то, в некоторых юзкейсах, например, том же масштабировании, когда перестраивается интерфейс, отступы в пикселях выглядят отвратительно :)
Не задавать высоту элементам (input button и тд) с помощью padding. Дизайнер задает конкретные параметры элемента в пикселях, поэтому изменение количества строк или внутреннего контента повлияет на исходные размеры. Поэтому height у элементов задаем в пикселях
Дизайнер как раз должен учитывать ситуацию переполнения контента, и не задавать паддинги не вижу смысла по причине ниже
Лучше использовать пиксели в верстке, а не другие единицы измерения. Дизайн изначально создан в пикселях, поэтому не стоит вмешиваться в исходные параметры.
Еще как стоит. В бытность мою работы на фрилансе и галере веб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?
Получается, что: 1) Вместо установки rem на боди и пропорциональному уменьшению/увеличению его на мобилке, я должен буду руками ходить все исправлять? 2) Я не учитываю работу клиентского устройства под разного рода масштабированием
А масштабирование - это элемент доступности, вы предлагаете делать интерфейсы недоступными, просто потому что дизайнер прав? А если он не прав?
Данная статья поможет улучшить взаимодействие между дизайнерами и верстальщиками для минимизации ошибок и повышения продуктивности работы.
Вот если честно, не видно тут никакого взаимодействия между верстальщиком и дизайнером. Согласен только с некоторыми тезисами в начале статьи, категорически не согласен с цитируемыми выше блоками.
используя bootstrap и прочие ui системы, вы скорее всего будете обвязывать их дополнительными обертками и костылями, при этом неся за собой неиспользуемый функционал в виде js и style кода. Поэтому в проектах с индивидуальным визуалом стоит этого избегать и кастомизировать все под свои нужды.
Почему стоит избегать? Опять же, тот же бутстрап позволяет атомарно пересобрать свою сетку просто импортируя к себе нужные scss файлы и дальше вот те примеры по изобретению велосипеда не нужны от слова совсем. Например, откопал такие участки кода в своих проектах +-3 лет давности :
Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку.
а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" . Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?
дык, при потреблении федерализации откуда типы брать?
я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).
Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии
Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей
У каждого выбора есть свои сильные и слабые стороны. В случае моем, все сильные стороны перекрыли слабые. И я в целом остался доволен, а предупредить про неприятные моменты - вот цель статьи, потому что нигде это не освещается практически
Мне в 23 году дерматолог поставил диагноз заболевания кожи
На прошлой неделе второй дерматолог подтвердил диагноз, не смотря на то, что лечение приносило кратковременные результаты
Загрузил фотографии поражённых мест в чат гпт. За 5-10 минут в чате он предположил другой диагноз (верный), который подтвердился третьим дерматологом и анализами
Конечно, есть вопросики к первым двум дерматологам, т.к. они из одной и той же сети клиник (в МСК) и почему я лечил 2 года не ту болезнь, но учитывая мою ситуацию я склонен верить нейронке немного, а хотя намного больше
По поводу учителей тейк не понятен, нейронка на 100% справится с ролью учителя, но тут важно понимать, что какие-то скользкие исторические вопросы все же она раскрывать не будет (привет яндекс гпт, дипсику и т.д.). Учителей и преподавателей по точным наукам я уверен что способна полностью заменить, по некоторым гуманитарным наукам вопрос
А что там по бекенду?
Кто такие современные бэкендеры? Те кто берут монгу + nest и потом диву даются, что продукт не выдерживает 10к rps и 5к одновременных пользаков?
А дизайн и ux? Это наверное про Яндекс.Плюс, в котором надо быть гением, чтобы отключить подписку и когда найти, то три раза нажать отключить? Или про интерфейс, в котором модальные окна на каждый чих и пук и серые буквы на сером фоне? Про доступность я вообще молчу, нам же на фон надо паралакс навесить и чтобы контент со всех возможных сторон вылетал и всплывал на скроле.
Это статья набор стереотипов 5-10 летней давности, которая претендует на что? Что надо брать htmx и serverless для фронта и все будет хорошо? Что вместо бека можно в txt сохранять? Или что вместо ui kit можно использовать нативные браузерные стили?
И очень интересно посмотреть сколько мвп выжили и сколько потом по итогу не переписали с нуля и по итогу не превратились то самое зло оверхедное.
1) Звук от фильма к фильму скачет, подтверждаю. Сам думаю докупать саундбар
2) иногда сама переключает приложения или задаёт вопрос.
3) почти всегда отказывается запускать приложения по номеру, только если это не hdmi разъём
4) с последними обновлениями раздражающе подсовывает в начало списка иви и вк видео, ещё и увеличивает в размере. У меня и так вк видео установлен, но пользуюсь редко. Но вот такие рекламные ходы уменьшают и без того низкое желание использовать
5) если не перезагружать, то начинает очень тупить. Не помогает даже убийство приложений.
6) Нет эквалайзера (или не нашел)
На самом деле, у меня впервые больше претензий к устройству, я не советую к покупке, если только не по скидке
useImperativeHandle и половину извращений можно выбрасывать
Вау. А где связь?
Статья о том, как лендинги на реакте - это оверхед и админки для сбора звонков перестали покупать в вашей веб-студии?
для статики есть ssg, ssr тут не нужен.
Реакт и вью используют не потому, что они "мощщщные", этот аргумент вообще безоснователен в рамках всей статьи в целом.
Верю. У вас есть цель взять как можно больше денег, продав время работы джунов как сеньорское, потом написать статью как вы не смогли в <имя_технологии> и налить водички, корявенько себя порекламив, т.к. пройдя даже по сайту, который вы привели в качестве примера, и без профилирования виден layout shift, и как уже после загрузки страницы даже с кешем к кнопкам применяется css :)
Успехов вам, в любом случае.
Vuex, Redux, мы в каком году вообще?
Синхронная федерация - это когда адрес прописывается в remotes. Динамическая - когда в рантайме дергается get/init вебпака (примерно, как тут)
Переменные окружения, адрес ремоута, filename, exposes, некоторая бизнес-информация
Фронтовым монорепозиторием + отдельно в той структуре генерируется информация о шареде - все версии жестко зафиксированы и не имеют права фронты без согласования трогать каким-либо образом бибилиотеки (установка, обновление и т.д.). Ну и жесткие правила гитфлоу. В общем, доверия никакого никому с частичной атоматизацией)
Не смотря на возможность работать в отдельный репах, с module federation я в принципе не сторонник такого подхода + приходилось работать не всегда работать с самыми квалифицированными кадрами, отчего упаковка в монорепу с единым списком библиотек стал единственным подходящим вариантом для работы
Немного не ясен момент - у вас все-таки динамическая федерация или синхронная на промисах?
Идея с плагином для манифестов интересная, но я в своих проектах держал отдельно с каждым фронтом json, который его описывает. В последних итерациях пришли сбору всех и мержингу в одну большую (относительно, для прода минифицируется и чистится от dev переменных) структуру, которая запрашивается шеллом в рантайме + содержит переменные окружения (динамическая федерация).
В крайнем проекте, все это упаковано в nx и генерируется его инструментами
От архитектуры только слова, зато как папки разложить - миллион скриншотов. Обидно
Необходимо учитывать, что некоторые api работают только при наличии https соединения. Clipboard Api так точно это требует
Гидратация - инициализация скриптов на клиенте, потому что изначально они выполнились на сервере, а точнее - "довешивание" отсутсвующих событий и т.д.
Допустим,мне, как человеку, который выбирает себе систему управления монорепой, не понятен момент смысл лерны, если существует NX, а все изменения из статьи, насколько я понял, крутятся вокруг того, что лерна теперь крутит NX под капотом.Отсюда вытекает вопрос, а смысл мне использовать лерну? что она дает, что не делает NX?
по факту мы получаем при правильном системном подходе построения типографики несколько строк css для построения адаптива, который сохраняет принципы поточности, задуманные дизайнером. Например, это хорошо видно тут. Вы получаете не только DX (developer experience) в виде построения адаптива, но и отзывчивый UX к масштабированию.
Этот миксин всего лишь 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 по рукам бьет
остается только отступы межды элементами и то, в некоторых юзкейсах, например, том же масштабировании, когда перестраивается интерфейс, отступы в пикселях выглядят отвратительно :)
Дизайнер как раз должен учитывать ситуацию переполнения контента, и не задавать паддинги не вижу смысла по причине ниже
Еще как стоит. В бытность мою работы на фрилансе и
галеревеб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?Получается, что:
1) Вместо установки rem на боди и пропорциональному уменьшению/увеличению его на мобилке, я должен буду руками ходить все исправлять?
2) Я не учитываю работу клиентского устройства под разного рода масштабированием
А масштабирование - это элемент доступности, вы предлагаете делать интерфейсы недоступными, просто потому что дизайнер прав? А если он не прав?
Вот если честно, не видно тут никакого взаимодействия между верстальщиком и дизайнером. Согласен только с некоторыми тезисами в начале статьи, категорически не согласен с цитируемыми выше блоками.
Почему стоит избегать? Опять же, тот же бутстрап позволяет атомарно пересобрать свою сетку просто импортируя к себе нужные scss файлы и дальше вот те примеры по изобретению велосипеда не нужны от слова совсем.
Например, откопал такие участки кода в своих проектах +-3 лет давности :
И дальше использовались те же классы или миксины бутстрапа. При этом, 0 js, потому что в моем случае мне только сетка и нужна.
Можно пойти еще дальше и принудительно обновлять ветки, если локальный мастер отстает от ремоута :)
а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" .
Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?
я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).
Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей
У каждого выбора есть свои сильные и слабые стороны. В случае моем, все сильные стороны перекрыли слабые. И я в целом остался доволен, а предупредить про неприятные моменты - вот цель статьи, потому что нигде это не освещается практически
К сожалению, такое случается :)
Когда заказчик узнал, что от MVP ничего не осталось, его удивлению не было предела :)