Вы придумали заново Backend Driven Ui, но слишком наивный. В этом нет ничего плохого, но это надо «докручивать» и странно, что вы сразу заразили (если я правильно понял) а не прогнали на тестовом стенде хотя-бы. Вот скорее всего проблема не в мышлении, а в том что это не проверено. Особенно на специально утрированных кейсах, которых у вас не будет, но вдруг…
О чем можно говорить если мы учимся в вузе по УЖЕ устаревшим программам? Система образования не успевает в принципе за реальностью, так что то, о чем речь - не проблема. Как всегда учишь базу, а потом "забываешь все, чему тебя учили" и изучаешь на практике
Мне в 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. Скорее всего у меня в этих случаях не вылезет текст за кнопку и в большинстве нетривиальных кейсов пропорциональность будет более-менее соблюдена
Дальше можно не читать, этот брейн еще и статью эту написал, хотя по стилю это chat gpt
Суть статьи - используя зарубежный VPS , используйте днс с того VPS, а не из РФ. Проблема решена
Не надо ни quic, ни IPv6 - все остальное тыкается в вашем софте-транспорте
P.S. все кроме antigravity использую на своем старом аккаунте с регионом РФ
Вы придумали заново Backend Driven Ui, но слишком наивный. В этом нет ничего плохого, но это надо «докручивать» и странно, что вы сразу заразили (если я правильно понял) а не прогнали на тестовом стенде хотя-бы. Вот скорее всего проблема не в мышлении, а в том что это не проверено. Особенно на специально утрированных кейсах, которых у вас не будет, но вдруг…
В Думе о нем прекрасно знают. Например, как только вы попадаете в околосиловой проект, в котором нужен UI , в списке разрешенных технологий только vue
О чем можно говорить если мы учимся в вузе по УЖЕ устаревшим программам? Система образования не успевает в принципе за реальностью, так что то, о чем речь - не проблема. Как всегда учишь базу, а потом "забываешь все, чему тебя учили" и изучаешь на практике
Мне в 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. Скорее всего у меня в этих случаях не вылезет текст за кнопку и в большинстве нетривиальных кейсов пропорциональность будет более-менее соблюдена