Несмотря на провокационный характер текста – смысл в нем есть. Но я бы сказал, что все подобные советы можно в конечном счете свести к трем посылам: верстайте тупо, верстайте логично, и сознательно выбирайте инструменты под задачи. Если код тупой, последовательный, происходящее в нем понятно с одного взгляда при быстром пролистывании, логика использования компонентов продумана изначально, а возможности инструментов аргументированно используются для решения конкретных задач, а не “потому, что можем и вообще все так делают” — вероятность того, что с кодом будет просто работать, сильно возрастает. И что-то мне подсказывает, что эти посылы применимы не только к CSS. Да и не только к коду.
Да, проблема округлений и сглаживаний — это головная боль, причем не только в вопросах бордеров, это вообще много где может проявиться. А вот по поводу «сверх задания» — у нас рано или поздно появится поддержка CSS Painting API во всех браузерах, и можно будет посмотреть на эту задачу с новой стороны. Ну или уже сейчас забить на это API и руками воткнуть канвасы везде. Это не так производительно, но любые кривые, градиенты, да что угодно — в нашем распоряжении. Нарисовать можно все, что угодно, вопрос времени. Для особых извращений можно использовать WebGL контекст и делать разные волны по этим бордерам при наведении, но это уже совсем другая история. А пока вот концепт (не протестированный) крокодильчиков для вдохновения:
Логичнее было бы предположить иной порядок — по третьей в детстве пострадал, поэтому компенсировался во второй, из-за чего развил первую и не хватило ресурса понять четвертую, поэтому последняя интересна.
Схожие мысли когда-то привели меня к разработке «пирамиды адаптации» — модели психики, в которой я как раз связал разные модели поведения человека, их сочетающиеся и исключающие друг друга комбинации, и закономерности перехода от одних к другим. Это все в рамках корреляций и гипотез, пока что никак не подтвержденных, но оставлю здесь ссылочку на книгу в pdf, если вдруг кому-то будет интересно познакомиться.
Если вы думаете, что люди зря написали, например, three.js, то зря так думаете. Зачем изобретать велосипед?!
Three.js — это комбайн, который умеет много всего и даже в сжатом виде в минимальной комплектации представляет из себя пол мегабайта скриптов, которые тормозят загрузку страницы. Для задачи в духе «вывести одну простую модельку и покрутить» или «сделать красивые волны на фотографии» этот инструмент избыточен, хорошо если 5% его функционала используется. Так что если времени и бюджета совсем нет, то да, можно наклепать все из готовых модулей, но вообще идея написать все руками не всегда плохая. Можно получить в результате узкоспециализированное, очень маленькое и шустрое решение. Тем более, что страшно это делать только в первый раз.
Но вот откуда это убеждение о том, что есть некий большой белый слон, вокруг которого все ходят, закрыв глаза, и дергают за разные части тела? Но, помилуйте, какая «более общая дисциплина»?
Может быть я странно выразился. Есть разные взгляды на все эти темы (развитие личности, понимание мышления, формирование мировоззрения, мироощущения, осознание своего положения в мире). И по идее было бы хорошо смотреть все их, стараться увидеть картину с разных сторон, не замыкаясь полностью на каком-то одном подходе. В нашем же случае часто происходит именно это — взяли одного автора, причем обычно даже не все его взгляды на мир, а какие-то отдельно взятые мысли по конкретным вопросам, например по тому, почему он считает те или иные вещи правильными, и топят за этот подход, а потом еще и устраивают гонения на тех, кто зациклился на других взглядах. А вот посмотреть с разных сторон на один и тот же мир, объединить все эти взгляды в одну систему, обычно забывают. А мне кажется, что именно эта часть про «посмотреть с разных сторон и объединить» здесь чуть ли не основная.
Почитал комментарии… Мне кажется, что тут почти все споры происходят на почве того, что разные люди под понятием “философия” понимают разные куски более общей дисциплины. Скорее всего на это влияет система образования, в которой философию преподают в виде наборов каких-то не связанных между собой имен, дат, и высказываний, вырванных из своего времени и контекста. В общем смысле философия – это не только про познание окружающего мира и какие-то там критерии правильности этого познания, и не только про попытки обозначить границы нашего мышления разными хитрыми логическими конструктами. Это еще и про осознание своего места в этом мире, про мораль, про систему ценностей, про самоанализ, про осознание процессов вокруг себя и отношение к разным вещам. На мой взгляд погружение в эти темы, рассмотрение и анализ принципиально разных взглядов на них — это неотъемлемая часть образования личности. Должно быть грустно от того, что люди массово считают слова “философия” и “словоблудие” синонимами.
Получал предложения из серии 30-50 тысяч рублей за статью. Предлагал в ответ, чтобы мне заказывали с комиссией 10% за такие деньги
Сначала такое утверждение задело каким-то пренебрежительным отношением, а потом понял, что просто скорее всего вы и эти авторы находились в разных системах координат. Разные представления о хорошей статье. Наверняка это были люди, которые уже давно говорят, что «хабр не торт» и желают видеть здесь только хардкор для настоящих программистов. Корпорациям же нужны в первую очередь просмотры и рейтинги для рекламы, про полезность мало кто думает — главное публиковаться часто, заголовки погромче и темы похайповее, чтобы завязывались обсуждения в комментах (хотя бывают редкие исключения, этого не отнять). А так то на написание нейтральной и полезной технической статьи уходит куда больше времени, чем кажется, и ее расчетная стоимость действительно может составлять десятки тысяч. И ППА такие статьи не покрывает от слова совсем. Так что ваше стремление не превратить хабр в дзен — хорошее, но думаю оно разобъется о реальность, в которой только бизнес, ничего личного.
Чтобы начать поиск ошибок в клиентском JS-приложении, достаточно запустить его в браузере
Только лучше сначала прогнать исходники через ESLint и SonarJS. Они сразу найдут все синтаксические ошибки и часть логических, и не нужно будет тратить время и нервы на ловлю этих самых ошибок в случайных местах в реальном времени.
Думаю, что здесь нужно сделать дисклеймер: должен быть какой-то баланс, оценка ситуации в целом, а не слепое следование рекомендациям в вакууме. А то найдется кто-нибудь, кто буквально все прочитает. Например:
1. Вставить в страницу critical css может быть не такой уж и плохой идеей.
2. Убирать нужно _бесполезные_ комментарии. Если там описание того, почему применено нестандартное решение (например фиксит редкий баг), то такие комментарии убирать – себе в будущем вредить.
3. Про использование GitHub – согласен, но не вижу проблемы скачать архив и получить то же самое. Особенно если в самом задании не было указано, что можно все выкладывать в открытый доступ и это не обговорили.
4. Импровизация, выход за границы ТЗ – это хорошо, но сильно зависит от процессов в конкретном месте. Не всегда это нужно, и, если это ожидается, то наверное стоит так и сказать в задании.
5. Футер не всегда нужно прибивать. Пример с типографом вроде и так нормально выглядит. Его бы скорее разорвало в визуальном плане, если бы там был прибитый футер.
6. Новые CSS свойства сильно зависят от списка поддерживаемых браузеров. Светлое будущее наступило еще не везде, как это ни странно.
7. Странно, что здесь в целом не сказано про кроссбраузерность. Особенно по части Safari. И Firefox. Там с тем же SVG всякое веселье бывает. И уж навык кроссбраузерной верстки по списку должен подразумеваться на любом уровне компетенций.
8. “Не должно быть названий классов, которые отвечают за стили” — это, наверное, от методологии зависит.
9. Есть достаточно добротных небольших инструментов, которым не нужно обновляться. Они просто, без хайпа, решают конкретную задачу. То, что они не обновляются годами не говорит, что они вдруг перестали ее решать. Мне кажется странным от всех таких инструментов отказываться просто так, не глядя. Нужно смотреть каждый случай отдельно.
По такому же принципу можно не только прямоугольники закрашивать, но и использовать хеш как рандомизатор для более сложных геометрических объектов. Я как-то с мордашками такое сделал на JS, может кому-то будет полезно/интересно.
И переводы! Переводы надо смотреть как они влияют.
В топе по соотношению закладок к просмотрам (читай «полезные статьи, без хайпа и холиваров»), 8 из 10 — это переводы. Оставшиеся 2 — корпоративные посты. Авторов, пишущих от себя, нет, всех смыло.
Надо бы сделать такой же рейтинг, но без ограничений на 10к просмотров и только для независимых авторов :)
На вкус и цвет, конечно, фломастеры разные, но мне кажется, что два присваивания в одной строке, да и еще и со спрятанным условием, усложняют восприятие кода на ровном месте. А это верный путь к глупым багам, которые сложно искать. Старый вариант может быть и больше по объему, но он простой и понятный при беглом чтении.
Автор статьи — Python developer, и, видимо в силу недостатка опыта во фронтенде, он говорит странные вещи местами. Если примеры инструментов выглядят просто как «смотрите, какую прикольную штуку я нашел», то примеры кода новичкам не стоит воспринимать слишком буквально.
1. Первая штука делается короче, на CSS, на :hover. Зачем там скрипты, да еще и изменяющие CSS напрямую — загадка.
2. Префиксы руками ставить не нужно. В 2020 году есть автопрефиксер, который сам расставит, что нужно, и уберет, что не нужно.
3. Изменение размера шрифта — ок, прикольная идея, только нужно сохранять высоту строки и изменять межбуквенные интервалы, а то все будет дергаться, как у автора на сайте.
4. Список «Вот полный список значений, которые может принимать каждое из этих свойств» вообще ни разу не полный.
5. «полезно разделять запятыми значения внутри @keyframes» — ой, вот не надо этого. Читаемость этот подход в конечном счете портит, а пользы никакой.
Мне кажется главная проблема таких “современных” стартовых шаблонов (не вашего, а вообще) – это то, что они в 99% случаев делаются теоретиками, а не практиками. И если брать их как есть, то быстро обнаруживается, что там обычно даже нет стандартного набора подстраховок, снимающих нагрузку на мозг и предотвращающих глупые баги (w3c-валидатор, stylelint, doiuse, eslint, sonarjs). Это те вещи, которые упрощают работу всегда, вне зависимости от пре/пост-процессоров, сборщиков и.т.д., и казалось бы в 2020 году уже должны быть везде, а их нет. Есть какие-то замороченные варианты загрузки ресурсов, примеры редких мета-тегов, что-то еще такое умное и полезное в теории, а банального настроенного процесса сборки и проверки всего – нет. Но при этом если начать доделывать эти шаблоны, то получаются монстры с кучей зависимостей, в которых только ты и разбираешься (раз уж такое дело, то поделюсь одним из своих стартовых шаблонов). Где-то здесь должна быть золотая середина…
Изначально предполагалось, что это будет небольшой цикл лекций именно в виде классических лекций, а практика будет сама по себе. Но думаю вы правы, в таком формате лучше будет какие-то примеры включить в сами статьи, т.к. читать их будут не только те люди, для кого лекции предназначались, и этот практический контекст немного теряется. Запомню этот момент.
Графики сгенерированы самописным скриптом, «сделанным на коленке» и очень страшным. Скорее всего я его потом зарефакторю и выложу на GitHub. Ну и здесь, в конце статьи, добавлю ссылку.
Все верно, но наверное тут стоит добавить, что пожар часто проще предупредить, чем потушить. А в контексте верстки подобные ошибки очень часто (почти всегда) связаны с тем, что или где-то есть невалидный код (который одни браузеры пытаются интерпретировать на свой вкус, а другие пропускают), или были использованы CSS-свойства, которые не везде поддерживаются. И использование полной автоматической валидации всего кода до и после сборки экономит кучу времени при поиске этих ошибок. Мне кажется, что в наше время W3C Validator, Stylelint, doiuse и ESLint с максимально жесткими настройками (а может быть и sonarjs тоже) должны быть в каждом проекте по умолчанию. Это очень непопулярное мнение по всей видимости, но даже упомянутая в статье проблема (дублирование id) была бы найдена не после кучи экспериментов, а сразу, при автоматической проверке страниц после их сборки.
не очень понятно как в реальных примерах в JS привязываться на значение t? (если там всё на setInterval, или requestAnimationFrame оно ведь +- за одинаковые промежутки времени, а в примерах, насколько я понял время не линейно )
Наверное я как-то не очень понятно выразился, когда сказал про изменение скорости в примерах с кривыми Безье, там со временем никакие манипуляции не производятся. То есть грубо говоря каждый вызов функции в setInterval или requestAnimationFrame мы немного его увеличиваем и получаем нужный результат. Графики на картинках строились именно таким образом — каждый кадр время увеличивалось условно на 0.001 и ставилась точка. При этом каждая следующая точка смещается относительно предыдущей не на определенное расстояние, а на какое получится — иногда больше, иногда меньше. Это как бы нежелательный побочный эффект такого подхода к рисованию графиков, но в случае с анимациями он дает субъективное изменение скорости движения, которое часто приходится очень к месту.
Схожие мысли когда-то привели меня к разработке «пирамиды адаптации» — модели психики, в которой я как раз связал разные модели поведения человека, их сочетающиеся и исключающие друг друга комбинации, и закономерности перехода от одних к другим. Это все в рамках корреляций и гипотез, пока что никак не подтвержденных, но оставлю здесь ссылочку на книгу в pdf, если вдруг кому-то будет интересно познакомиться.
Three.js — это комбайн, который умеет много всего и даже в сжатом виде в минимальной комплектации представляет из себя пол мегабайта скриптов, которые тормозят загрузку страницы. Для задачи в духе «вывести одну простую модельку и покрутить» или «сделать красивые волны на фотографии» этот инструмент избыточен, хорошо если 5% его функционала используется. Так что если времени и бюджета совсем нет, то да, можно наклепать все из готовых модулей, но вообще идея написать все руками не всегда плохая. Можно получить в результате узкоспециализированное, очень маленькое и шустрое решение. Тем более, что страшно это делать только в первый раз.
Может быть я странно выразился. Есть разные взгляды на все эти темы (развитие личности, понимание мышления, формирование мировоззрения, мироощущения, осознание своего положения в мире). И по идее было бы хорошо смотреть все их, стараться увидеть картину с разных сторон, не замыкаясь полностью на каком-то одном подходе. В нашем же случае часто происходит именно это — взяли одного автора, причем обычно даже не все его взгляды на мир, а какие-то отдельно взятые мысли по конкретным вопросам, например по тому, почему он считает те или иные вещи правильными, и топят за этот подход, а потом еще и устраивают гонения на тех, кто зациклился на других взглядах. А вот посмотреть с разных сторон на один и тот же мир, объединить все эти взгляды в одну систему, обычно забывают. А мне кажется, что именно эта часть про «посмотреть с разных сторон и объединить» здесь чуть ли не основная.
Сначала такое утверждение задело каким-то пренебрежительным отношением, а потом понял, что просто скорее всего вы и эти авторы находились в разных системах координат. Разные представления о хорошей статье. Наверняка это были люди, которые уже давно говорят, что «хабр не торт» и желают видеть здесь только хардкор для настоящих программистов. Корпорациям же нужны в первую очередь просмотры и рейтинги для рекламы, про полезность мало кто думает — главное публиковаться часто, заголовки погромче и темы похайповее, чтобы завязывались обсуждения в комментах (хотя бывают редкие исключения, этого не отнять). А так то на написание нейтральной и полезной технической статьи уходит куда больше времени, чем кажется, и ее расчетная стоимость действительно может составлять десятки тысяч. И ППА такие статьи не покрывает от слова совсем. Так что ваше стремление не превратить хабр в дзен — хорошее, но думаю оно разобъется о реальность, в которой только бизнес, ничего личного.
Только лучше сначала прогнать исходники через ESLint и SonarJS. Они сразу найдут все синтаксические ошибки и часть логических, и не нужно будет тратить время и нервы на ловлю этих самых ошибок в случайных местах в реальном времени.
1. Вставить в страницу critical css может быть не такой уж и плохой идеей.
2. Убирать нужно _бесполезные_ комментарии. Если там описание того, почему применено нестандартное решение (например фиксит редкий баг), то такие комментарии убирать – себе в будущем вредить.
3. Про использование GitHub – согласен, но не вижу проблемы скачать архив и получить то же самое. Особенно если в самом задании не было указано, что можно все выкладывать в открытый доступ и это не обговорили.
4. Импровизация, выход за границы ТЗ – это хорошо, но сильно зависит от процессов в конкретном месте. Не всегда это нужно, и, если это ожидается, то наверное стоит так и сказать в задании.
5. Футер не всегда нужно прибивать. Пример с типографом вроде и так нормально выглядит. Его бы скорее разорвало в визуальном плане, если бы там был прибитый футер.
6. Новые CSS свойства сильно зависят от списка поддерживаемых браузеров. Светлое будущее наступило еще не везде, как это ни странно.
7. Странно, что здесь в целом не сказано про кроссбраузерность. Особенно по части Safari. И Firefox. Там с тем же SVG всякое веселье бывает. И уж навык кроссбраузерной верстки по списку должен подразумеваться на любом уровне компетенций.
8. “Не должно быть названий классов, которые отвечают за стили” — это, наверное, от методологии зависит.
9. Есть достаточно добротных небольших инструментов, которым не нужно обновляться. Они просто, без хайпа, решают конкретную задачу. То, что они не обновляются годами не говорит, что они вдруг перестали ее решать. Мне кажется странным от всех таких инструментов отказываться просто так, не глядя. Нужно смотреть каждый случай отдельно.
В топе по соотношению закладок к просмотрам (читай «полезные статьи, без хайпа и холиваров»), 8 из 10 — это переводы. Оставшиеся 2 — корпоративные посты. Авторов, пишущих от себя, нет, всех смыло.
Надо бы сделать такой же рейтинг, но без ограничений на 10к просмотров и только для независимых авторов :)
1. Первая штука делается короче, на CSS, на :hover. Зачем там скрипты, да еще и изменяющие CSS напрямую — загадка.
2. Префиксы руками ставить не нужно. В 2020 году есть автопрефиксер, который сам расставит, что нужно, и уберет, что не нужно.
3. Изменение размера шрифта — ок, прикольная идея, только нужно сохранять высоту строки и изменять межбуквенные интервалы, а то все будет дергаться, как у автора на сайте.
4. Список «Вот полный список значений, которые может принимать каждое из этих свойств» вообще ни разу не полный.
5. «полезно разделять запятыми значения внутри @keyframes» — ой, вот не надо этого. Читаемость этот подход в конечном счете портит, а пользы никакой.
Эту идею можно еще сильнее обобщить, заменив ребенка на неодушевленный или даже несуществующий предмет — получится метод утенка.
Наверное я как-то не очень понятно выразился, когда сказал про изменение скорости в примерах с кривыми Безье, там со временем никакие манипуляции не производятся. То есть грубо говоря каждый вызов функции в setInterval или requestAnimationFrame мы немного его увеличиваем и получаем нужный результат. Графики на картинках строились именно таким образом — каждый кадр время увеличивалось условно на 0.001 и ставилась точка. При этом каждая следующая точка смещается относительно предыдущей не на определенное расстояние, а на какое получится — иногда больше, иногда меньше. Это как бы нежелательный побочный эффект такого подхода к рисованию графиков, но в случае с анимациями он дает субъективное изменение скорости движения, которое часто приходится очень к месту.