Потому что если при обычном css я хочу сделать, скажем, текстовый блок с рамочкой в разных местах, то достаточно просто присвоить элементу нужный класс. А при использовании подобных библиотек нужно будет вместо класса присваивать объект стилей. И там, где CSS подразумевает банальное использование нескольких классов, теперь придётся мерджить один объект стилей из нескольких. Это мало того, что неудобно для разработчика, так ещё и раздувает результирующие стили, снижая производительность веб приложения.
И если для react-native это приемлемо, потому что это не веб-платформа, то в вебе это всё нужно, как собаке пятая нога.
Современные фронтендеры никогда не пойдут на то, чтобы вот так просто загрузить файл стилей, а в компоненте просто использовать класс, к которому привяжутся стили. Это же придётся признать, что все эти 100500 библиотек стилей просто не нужны и как минимум половину кода проекта можно будет просто удалить за ненадобностью.
Кстати, многие в погоне за сокращением размера файла стилей забывают о таком понятии, как браузерный кэш, поэтому иногда лучше иметь один файл в 100кб, чем десять или даже пять по 10кб.
Выглядит точь в точь, как стили в react-native. И по своему опыту скажу, что это далеко не самое удобное решение, поэтому не вижу ничего хорошего в том, чтобы тянуть это в веб.
А вообще, десятки мегабайт стилей для Фейсбука - это какой-то нонсенс. Вот, что происходит, когда нанимают тысячу разработчиков, чтобы каждый из них покрасил одну из тысячи одинаковых кнопок. Вместо того, чтобы взять несколько толковых людей и построить простую и понятную дизайн-систему.
А я и не говорю, что это сложно решается. Я говорю, что в условном Laravel или Drupal это всё уже решено, но за это приходится платить "подгрузкой 150 классов".
Очень странная затея делать подобные бенчмарки. Само собой, что самописный код всегда будет работать быстрее, потому что в нём ничего нет. Не "ничего лишнего", а именно просто "ничего". Возьмём простой пример, список из 5 статей с заголовком и текстом. Вот напишете вы запрос в базу данных, который это выберет. Ну ок. А теперь представьте себе, что одна из статей неопубликованная и показывать её можно только админу или автору. Есть ли среди ваших шести подгруженных классов тот, который отвечает за сессию и роль пользователя? Далее, что там ещё в тексте можно сделать? XSS-фильтрация? Добавить target=_blank и rel=nofollow к внешним ссылкам. Сделать ресайз картинок в тексте. Всё ещё думаете, что шесть классов достаточно? А давайте добавим в хэдер и футер менюшку, которую можно редактировать из админки!
честные бенчи
Честный бенч будет только тогда, когда сравниваться будет одинаковый функционал. Для этого надо взять внятное ТЗ простейшего сайта, и сделать этот сайт несколько раз с использованием разных технологий, причём так, чтобы во всех случаях внешний вид и функционал был полностью одинаковым. Кроме того, чтобы функционал на 100% соответствовал не только ТЗ, но и всем общепринятым практикам, начиная с защиты от SQL-инъекций, заканчивая всякими SEO-штуками вроде генерации внятных заголовков страниц и метатегов.
Но и этого на самом деле недостаточно. Скорее всего самописное решение по-прежнему будет выигрывать по производительности. Но вот только какой ценой будет даваться внесение изменений и дополнений в самописный функционал? Вряд ли кто-то захочет намертво привязывать себя к одному разработчику ради того, чтобы главная страница отдавалась не за 200мс, а за 100.
Да, но в этой науке очень много вкусовщины. Например, можно написать свой правило eslint для пустой строки между глобальными и локальными импортами и использовать его. Скорее всего, уже кто-то его создал, просто надо установить соответствующий пакет. В разных организациях и в разных проектах могут использоваться разные правила. Но вообще, на мой взгляд, если речь идёт о чистом коде, то использование автоматизированных инструментов проверки качества кода, таких как eslint должно стоять на первом месте.
Обычно того факта, что глобальные в начале, а локальные в конце, достаточно. К слову, создатели eslint-config-airbnb, который я использую в своих проектах, придерживаются такой же точки зрения.
Это надо, чтобы визуально отличать импорт внешних и внутренних зависимостей. Очень помогает при рефакторинге, когда надо перетащить в другую папку компонент, у которого штук 10 импортов, и нужно перебить все относительные пути.
Вообще, в целом визуальная составляющая кода очень важна. Поэтому все линтеры и проверяют всякие пробелы, отступы, двойные/одинарные кавычки и т.д. Когда код следует этим правилам, что глаз очень легко выцепляет всякие ошибки. Если же всё в кучу, то визуальный ритм сбивается и для ревью или отладки приходится внимательно перечитывать каждую строчку кода.
Простота хостинга. Статические сайты намного легче развёртывать на различных хостинг-платформах, так как они не требуют настройки сложной инфраструктуры.
Вот тут вы немного (вернее очень даже много) недоговариваете. Помимо хостинга статического сайта, ещё нужно где-то хранить его данные, иметь эндпоинты для отдачи этих данных сборщику, плюс ещё где-то запускать компиляцию этого всего. То есть получается нужен хостинг для Headless CMS, затем сервер с поддержкой Node.js, затем сервер для отдачи статики. То есть три сервера вместо одного. Понятное дело, что какие-то или даже все эти штуки можно физически разместить на одной машине, но это всё равно уже достаточно сложная инфраструктура получается.
А ведь если приделать фронтенд напрямую к CMS, как было принято раньше, то вместо трёх сервисов останется всего один.
Но самое непонятное для меня вот что: как вообще можно продать клиенту систему, где нужно запускать компиляцию фронтенда, чтобы увидеть изменения, внесённые в контент.
PS: я сам люблю все эти модные реакты и делал несколько очень серьёзных проектов, где использовался next.js для SSR, но не SSG.
Сам сейчас работаю над pet-проектом и через всё это прохожу. Со страхом осуждения борюсь следующим образом: сначала выложил ссылку на приложение в соцсети, где у моих друзей меньше всего активности. В результате установило 5 человек, а их фидбэка хватило на месяц работы над ошибками. Ошибки были в том числе и критические. Второй раз выложил там, где у меня побольше подписчиков, баги после их фидбэка исправил, сейчас работаю над тем, чтобы сделать приложение более интересным. Дальше уже наверное надо будет рекламироваться. Сейчас понимаю, что если бы сразу начал рекламироваться, было бы фиаско из-за ряда нерешённых проблем. Слил бы бюджет впустую, заодно растеряв оптимизм. Самое главное сейчас не застрять на текущем этапе надолго.
С одной стороны получается, что художественные книги в таком виде можно представить более наглядно, чем технические. С другой стороны, когда читаешь художественную книгу, смысл действия не в том, чтобы быть в курсе написанного, а в том, чтобы получить удовольствие от процесса чтения. Вот зато если бы вы придумали это лет на 20 раньше, когда я учился в школе, это бы мне сильно помогло улучшить оценки по литературе! )))
"Глупый юзер" - это вовсе не обязательно глупый человек. Иногда интерфейс нужно упрощать для того, чтобы какой-нибудь профессор истории с тремя высшими образованиями смог себе заказать в интернете складной стульчик для рыбалки.
Что касается в целом тенденции к упрощению интерфейсов, то как правило, никто не делает интерфейсы менее функциональными. Просто убирают возможность сделать одно и то же несколькими способами, то есть уменьшают избыточность.
Увы, это так не работает. Если разработчик не понял задачу, то это не потому что он "забыл её понять", а потому что у него недостаточно опыта или способностей. То же самое касается "заданного набора тестов". Иногда оказывается, что набора никакого нет, но это не значит, что в таком случае можно ничего не делать.
Измеряя продуктивность, нужно сразу уточнять, на каком отрезке жизненного цикла ПО она измеряется. У меня много раз было, что условный джун делает задачу, скажем, за час и закрывает её, как решённую. Потом оказывается, что применённое решение работает хорошо только при определённом стечении обстоятельств, да ещё и имеет кучу побочных эффектов. И тогда эту задачу повторно открывают и отдают мне, а я её делаю, к примеру несколько дней. Вот и получается, что джун сделал задачу в десятки раз быстрее меня, вот только за мной её переделывать не пришлось. Также надо иметь в виду, что возврат задач на доработку (в том числе в виде заново открытых багов, когда задача уже на продакшене) негативно влияет на планирование в целом и на общую продуктивность команды, т.к. всё больше ресурсов уходит на фиксы. Это, кстати, довольно типичная картина, когда маленькая команда берётся за слишком сложный проект, не оценив его сложность. Клиент ведётся на обещанную быстроту реализации, но к назначенному сроку получает лишь очень сырую заготовку, а затем всё тонет в бесконечных исправлениях и доработках, что часто заканчивается судами и даже банкротством одной из сторон.
Хотя конечно, если смотреть в разрезе каких-то средних задач, то обычно я их делаю значительно быстрее уловного джуна. То есть, подход оценки продуктивности по количеству затраченного времени при определённых условиях, безусловно, имеет право на жизнь. В то же время, при других условиях, лучше выбрать того разработчика, который будет делать дольше и дороже, но в итоге сделает хорошо.
Чтобы этого всего не было, нужен нормальный тимлид и нормальный проджект менеджер (скрам-мастер). Кстати, в маленькой команде эти задачи может совмещать и один человек. Собрал, выслушал всех по поводу темы, потом сказал, используем вот эту и всё. То же самое с задачами: чтобы не было такого, что кто-то набрал себе задач, а другим не осталось, нужно брать разработчиков на планирование спринта. Перед назначением задачи уточнять, согласен ли разработчик с эстимэйтом. А те задачи, которые никому не нравятся, распределять в приказном порядке.
И это очень сильное заблуждение, что выбор инструмента как-то влияет на продуктивность команды. Для разработчиков важно, чтобы было видно свои задачи, был виден канбан и бэклог, были комментарии, и было удобно фиксировать затраченное время. Но всё перечисленное есть практически в любой системе управления проектами
На моей первой работе был случай: при подключении принтера комп уходил в синий экран. Забрали в наш кабинет чинить - всё работает. Вернули обратно - та же история. Потом кто-то догадался подключить принтер в другую розетку (речь о питании 220В) и всё заработало. Оказалось, что розетки, куда изначально включали комп и принтер, были запитаны от разных фаз.
Не каждую сложную задачу можно разбить на маленькие. И не каждая большая задача является сложной. А бывает , что очень сложная задача по своей сути очень маленькая, например, есть функционал, который уже работает, но появляется ошибка, которая всё ломает при определенных обстоятельствах. И в итоге можно потратить несколько дней, чтобы исправить одну строчку кода. Если же при возможности декомпозировать задачи по максимуму, то маленькие задачи будут очень зависимы от контекста. В итоге, владея контекстом, проще будет сделать маленькую задачу самому, чем вводить ChatGPT в курс дела. Ну и не забываем о всяких генераторах кода и автодополнении в IDE, которые бесплатны, работают быстрее и надёжнее. Плюс есть документация и исходный код проекта + исходный код используемых пакетов, где можно найти практически все ответы. Я вообще даже поисковиком для решения рабочих задач крайне редко пользуюсь. Обычно последовательность поиска решения такова: подумать самому, если не придумал, тогда поискать нужное по проекту, если там нет, то посмотреть документацию по используемому пакету, если там нет, тогда посмотреть в issues пакета. И вот уже есть и там нет, тогда приходится вбивать нужный вопрос в Google, но это случается 1-2 раза в месяц.
Конечно же, ещё лет 5 назад мне значительно чаще приходилось искать ответы в поисковике и тогда мне бы ChatGPT здорово помог, но сейчас я просто не вижу мест, где он бы смог ускорить мою работу.
Потому что если при обычном css я хочу сделать, скажем, текстовый блок с рамочкой в разных местах, то достаточно просто присвоить элементу нужный класс. А при использовании подобных библиотек нужно будет вместо класса присваивать объект стилей. И там, где CSS подразумевает банальное использование нескольких классов, теперь придётся мерджить один объект стилей из нескольких. Это мало того, что неудобно для разработчика, так ещё и раздувает результирующие стили, снижая производительность веб приложения.
И если для react-native это приемлемо, потому что это не веб-платформа, то в вебе это всё нужно, как собаке пятая нога.
Современные фронтендеры никогда не пойдут на то, чтобы вот так просто загрузить файл стилей, а в компоненте просто использовать класс, к которому привяжутся стили. Это же придётся признать, что все эти 100500 библиотек стилей просто не нужны и как минимум половину кода проекта можно будет просто удалить за ненадобностью.
Кстати, многие в погоне за сокращением размера файла стилей забывают о таком понятии, как браузерный кэш, поэтому иногда лучше иметь один файл в 100кб, чем десять или даже пять по 10кб.
Выглядит точь в точь, как стили в react-native. И по своему опыту скажу, что это далеко не самое удобное решение, поэтому не вижу ничего хорошего в том, чтобы тянуть это в веб.
А вообще, десятки мегабайт стилей для Фейсбука - это какой-то нонсенс. Вот, что происходит, когда нанимают тысячу разработчиков, чтобы каждый из них покрасил одну из тысячи одинаковых кнопок. Вместо того, чтобы взять несколько толковых людей и построить простую и понятную дизайн-систему.
А я и не говорю, что это сложно решается. Я говорю, что в условном Laravel или Drupal это всё уже решено, но за это приходится платить "подгрузкой 150 классов".
PS: хайлоад на пхп вполне возможен и существует
Так я и использую. Это же не я задаюсь вопросом, почему там 150 классов грузится. Я прекрасно понимаю, зачем они туда грузятся
Очень странная затея делать подобные бенчмарки. Само собой, что самописный код всегда будет работать быстрее, потому что в нём ничего нет. Не "ничего лишнего", а именно просто "ничего". Возьмём простой пример, список из 5 статей с заголовком и текстом. Вот напишете вы запрос в базу данных, который это выберет. Ну ок. А теперь представьте себе, что одна из статей неопубликованная и показывать её можно только админу или автору. Есть ли среди ваших шести подгруженных классов тот, который отвечает за сессию и роль пользователя? Далее, что там ещё в тексте можно сделать? XSS-фильтрация? Добавить target=_blank и rel=nofollow к внешним ссылкам. Сделать ресайз картинок в тексте. Всё ещё думаете, что шесть классов достаточно? А давайте добавим в хэдер и футер менюшку, которую можно редактировать из админки!
Честный бенч будет только тогда, когда сравниваться будет одинаковый функционал. Для этого надо взять внятное ТЗ простейшего сайта, и сделать этот сайт несколько раз с использованием разных технологий, причём так, чтобы во всех случаях внешний вид и функционал был полностью одинаковым. Кроме того, чтобы функционал на 100% соответствовал не только ТЗ, но и всем общепринятым практикам, начиная с защиты от SQL-инъекций, заканчивая всякими SEO-штуками вроде генерации внятных заголовков страниц и метатегов.
Но и этого на самом деле недостаточно. Скорее всего самописное решение по-прежнему будет выигрывать по производительности. Но вот только какой ценой будет даваться внесение изменений и дополнений в самописный функционал? Вряд ли кто-то захочет намертво привязывать себя к одному разработчику ради того, чтобы главная страница отдавалась не за 200мс, а за 100.
Да, но в этой науке очень много вкусовщины. Например, можно написать свой правило eslint для пустой строки между глобальными и локальными импортами и использовать его. Скорее всего, уже кто-то его создал, просто надо установить соответствующий пакет. В разных организациях и в разных проектах могут использоваться разные правила. Но вообще, на мой взгляд, если речь идёт о чистом коде, то использование автоматизированных инструментов проверки качества кода, таких как eslint должно стоять на первом месте.
Обычно того факта, что глобальные в начале, а локальные в конце, достаточно. К слову, создатели eslint-config-airbnb, который я использую в своих проектах, придерживаются такой же точки зрения.
Вроде да, но почему-то срабатывает не всегда. Наверное, надо делать через Refactor - Move File, а не просто перетаскивать мышкой по дереву папок.
Раньше использовал пустую строку, сейчас никак не отделяю.
Это надо, чтобы визуально отличать импорт внешних и внутренних зависимостей. Очень помогает при рефакторинге, когда надо перетащить в другую папку компонент, у которого штук 10 импортов, и нужно перебить все относительные пути.
Вообще, в целом визуальная составляющая кода очень важна. Поэтому все линтеры и проверяют всякие пробелы, отступы, двойные/одинарные кавычки и т.д. Когда код следует этим правилам, что глаз очень легко выцепляет всякие ошибки. Если же всё в кучу, то визуальный ритм сбивается и для ревью или отладки приходится внимательно перечитывать каждую строчку кода.
Вот тут вы немного (вернее очень даже много) недоговариваете. Помимо хостинга статического сайта, ещё нужно где-то хранить его данные, иметь эндпоинты для отдачи этих данных сборщику, плюс ещё где-то запускать компиляцию этого всего. То есть получается нужен хостинг для Headless CMS, затем сервер с поддержкой Node.js, затем сервер для отдачи статики. То есть три сервера вместо одного. Понятное дело, что какие-то или даже все эти штуки можно физически разместить на одной машине, но это всё равно уже достаточно сложная инфраструктура получается.
А ведь если приделать фронтенд напрямую к CMS, как было принято раньше, то вместо трёх сервисов останется всего один.
Но самое непонятное для меня вот что: как вообще можно продать клиенту систему, где нужно запускать компиляцию фронтенда, чтобы увидеть изменения, внесённые в контент.
PS: я сам люблю все эти модные реакты и делал несколько очень серьёзных проектов, где использовался next.js для SSR, но не SSG.
Сам сейчас работаю над pet-проектом и через всё это прохожу. Со страхом осуждения борюсь следующим образом: сначала выложил ссылку на приложение в соцсети, где у моих друзей меньше всего активности. В результате установило 5 человек, а их фидбэка хватило на месяц работы над ошибками. Ошибки были в том числе и критические. Второй раз выложил там, где у меня побольше подписчиков, баги после их фидбэка исправил, сейчас работаю над тем, чтобы сделать приложение более интересным. Дальше уже наверное надо будет рекламироваться. Сейчас понимаю, что если бы сразу начал рекламироваться, было бы фиаско из-за ряда нерешённых проблем. Слил бы бюджет впустую, заодно растеряв оптимизм. Самое главное сейчас не застрять на текущем этапе надолго.
С одной стороны получается, что художественные книги в таком виде можно представить более наглядно, чем технические. С другой стороны, когда читаешь художественную книгу, смысл действия не в том, чтобы быть в курсе написанного, а в том, чтобы получить удовольствие от процесса чтения. Вот зато если бы вы придумали это лет на 20 раньше, когда я учился в школе, это бы мне сильно помогло улучшить оценки по литературе! )))
"Глупый юзер" - это вовсе не обязательно глупый человек. Иногда интерфейс нужно упрощать для того, чтобы какой-нибудь профессор истории с тремя высшими образованиями смог себе заказать в интернете складной стульчик для рыбалки.
Что касается в целом тенденции к упрощению интерфейсов, то как правило, никто не делает интерфейсы менее функциональными. Просто убирают возможность сделать одно и то же несколькими способами, то есть уменьшают избыточность.
10 лет занимаюсь веб-разработкой, ни разу не спрашивали алгоритмы на собеседовании.
Увы, это так не работает. Если разработчик не понял задачу, то это не потому что он "забыл её понять", а потому что у него недостаточно опыта или способностей. То же самое касается "заданного набора тестов". Иногда оказывается, что набора никакого нет, но это не значит, что в таком случае можно ничего не делать.
Измеряя продуктивность, нужно сразу уточнять, на каком отрезке жизненного цикла ПО она измеряется. У меня много раз было, что условный джун делает задачу, скажем, за час и закрывает её, как решённую. Потом оказывается, что применённое решение работает хорошо только при определённом стечении обстоятельств, да ещё и имеет кучу побочных эффектов. И тогда эту задачу повторно открывают и отдают мне, а я её делаю, к примеру несколько дней. Вот и получается, что джун сделал задачу в десятки раз быстрее меня, вот только за мной её переделывать не пришлось. Также надо иметь в виду, что возврат задач на доработку (в том числе в виде заново открытых багов, когда задача уже на продакшене) негативно влияет на планирование в целом и на общую продуктивность команды, т.к. всё больше ресурсов уходит на фиксы. Это, кстати, довольно типичная картина, когда маленькая команда берётся за слишком сложный проект, не оценив его сложность. Клиент ведётся на обещанную быстроту реализации, но к назначенному сроку получает лишь очень сырую заготовку, а затем всё тонет в бесконечных исправлениях и доработках, что часто заканчивается судами и даже банкротством одной из сторон.
Хотя конечно, если смотреть в разрезе каких-то средних задач, то обычно я их делаю значительно быстрее уловного джуна. То есть, подход оценки продуктивности по количеству затраченного времени при определённых условиях, безусловно, имеет право на жизнь. В то же время, при других условиях, лучше выбрать того разработчика, который будет делать дольше и дороже, но в итоге сделает хорошо.
Чтобы этого всего не было, нужен нормальный тимлид и нормальный проджект менеджер (скрам-мастер). Кстати, в маленькой команде эти задачи может совмещать и один человек. Собрал, выслушал всех по поводу темы, потом сказал, используем вот эту и всё. То же самое с задачами: чтобы не было такого, что кто-то набрал себе задач, а другим не осталось, нужно брать разработчиков на планирование спринта. Перед назначением задачи уточнять, согласен ли разработчик с эстимэйтом. А те задачи, которые никому не нравятся, распределять в приказном порядке.
И это очень сильное заблуждение, что выбор инструмента как-то влияет на продуктивность команды. Для разработчиков важно, чтобы было видно свои задачи, был виден канбан и бэклог, были комментарии, и было удобно фиксировать затраченное время. Но всё перечисленное есть практически в любой системе управления проектами
На моей первой работе был случай: при подключении принтера комп уходил в синий экран. Забрали в наш кабинет чинить - всё работает. Вернули обратно - та же история. Потом кто-то догадался подключить принтер в другую розетку (речь о питании 220В) и всё заработало. Оказалось, что розетки, куда изначально включали комп и принтер, были запитаны от разных фаз.
Не каждую сложную задачу можно разбить на маленькие. И не каждая большая задача является сложной. А бывает , что очень сложная задача по своей сути очень маленькая, например, есть функционал, который уже работает, но появляется ошибка, которая всё ломает при определенных обстоятельствах. И в итоге можно потратить несколько дней, чтобы исправить одну строчку кода. Если же при возможности декомпозировать задачи по максимуму, то маленькие задачи будут очень зависимы от контекста. В итоге, владея контекстом, проще будет сделать маленькую задачу самому, чем вводить ChatGPT в курс дела. Ну и не забываем о всяких генераторах кода и автодополнении в IDE, которые бесплатны, работают быстрее и надёжнее. Плюс есть документация и исходный код проекта + исходный код используемых пакетов, где можно найти практически все ответы. Я вообще даже поисковиком для решения рабочих задач крайне редко пользуюсь. Обычно последовательность поиска решения такова: подумать самому, если не придумал, тогда поискать нужное по проекту, если там нет, то посмотреть документацию по используемому пакету, если там нет, тогда посмотреть в issues пакета. И вот уже есть и там нет, тогда приходится вбивать нужный вопрос в Google, но это случается 1-2 раза в месяц.
Конечно же, ещё лет 5 назад мне значительно чаще приходилось искать ответы в поисковике и тогда мне бы ChatGPT здорово помог, но сейчас я просто не вижу мест, где он бы смог ускорить мою работу.