Я не самый талантливый кодер в мире. Правда. Так что я стараюсь писать как можно меньше кода. Чем меньше кода я пишу, тем меньше кода может ломаться, поддерживаться и требовать пояснений.
А еще я ленивый — мед, да еще и ложкой (я решил использовать в статье аналогии с едой).
Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода. Минифицировать? Окей. Сжимать? Ну, да. Кэшировать? Звучит неплохо. Вообще отказываться кодить или использовать чужой код изначально? А вот теперь — в яблочко! Что есть на входе — должно выйти на выходе в той или иной форме, независимо от того, смог ли ваш сборщик растворить и переварить это своими желудочными соками (я, пожалуй, откажусь от пищевых аналогий).
И это не все. Кроме видимых улучшений производительности, где вам требуется то же количество кода, но его сначала нужно разжевать (не смог удержаться), вы также можете сэкономить. Моему провайдеру без разницы, посылаю ли я кучу маленьких писем или одно большое: все складывается.
В стремлении к уменьшению мне больше всего нравится вот что: в конце остается только то, что реально нужно, только то, что по-настоящему требуется пользователю. Огромная фотка какого-то чувака, пьющего латте? Выкинуть. Кнопки социальных сетей, которые подсасывают кучу левого кода и ломают дизайн страницы? Пинок под зад им. Эта хреновина на JavaScript, которая перехватывает правый клик и показывает кастомное модальное окно? Выставить на мороз!
Речь идет не только про подключение штук, которые ломают интерфейс. То, как вы пишете свой собственный код, тоже играет большую роль в стремлении к уменьшению кода. Вот несколько советов и идей. Я писал о них ранее, но в контексте удобства и отзывчивого дизайна. Просто так получается, что гибкий, удобный веб требует меньше контроля с нашей стороны и его сложнее сломать.
WAI-ARIA
Во-первых, WAI-ARIA != web accessibility. Это просто инструмент для улучшения совместимости с некоторыми вспомогательными технологиями вроде экранного диктора. Поэтому первое правило ARIA — это не использовать его, если не требуется.
LOL, нет:
<div role="heading" aria-level="2">Subheading</div>Да:
<h2>Subheading</h2>Преимущество использования нативных элементов в том, что зачастую не нужно будет кодировать собственное поведение. Следующая реализация чекбокса не только слишком многословная, но также зависит от JavaScript, который контролирует изменение состояния и переопределяет стандарт работы с атрибутами и методом GET. Кода больше, и он менее надежный. Красота!
<div role="checkbox" aria-checked="false" tabindex="0" id="checkbox1" aria-labelledby="label-for-checkbox1"></div>
<div class="label" id="label-for-checkbox1">My checkbox label</div>Стили? Не волнуйтесь, все под контролем. Если вообще нужны кастомные стили, конечно.
<input type="checkbox" id="checkbox1" name="checkbox1">
<label for="checkbox1">My checkbox label</label>Сетка
Вы когда-нибудь получали удовольствие от использования или чтения веб-сайта с более чем двумя колонками? Слишком много информации, которая требует внимания. «Интересно, какая из этих штук, похожих на навигацию, на самом деле является нужной мне навигацией?». Это риторический вопрос: я не знаю, что делать дальше и покидаю сайт.
Конечно, иногда хочется поставить какую-нибудь штуку рядом с другой штукой. Например, поисковую выдачу или еще что-то. Но зачем тянуть сюда тонну библиотек для сеток? Флексбокс умеет это буквально с двумя блоками определений.
.grid {
display: flex;
flex-flow: row wrap;
}
.grid > * {
flex-basis: 10em;
flex-grow: 1;
}Теперь все будет растягиваться до примерно 10em в ширину. Количество колонок зависит от того, сколько ячеек размером примерно 10em поместится в viewport. Готово. Идем дальше. А, кстати, давайте еще обсудим такую штуку:
width: 57.98363527356473782736464546373337373737%;Знаете ли вы, что это число основано на мистической пропорции? Пропорции, которая должна вызывать чувство спокойствия и благоговения? Нет, я не знал об этом и мне пофиг. Просто сделайте кнопку "Порно" достаточно большой, чтоб было видно.
Отступы
Мы знаем, как это делается. Задавайте отступ для всех элементов, используя универсальные селекторы. И переопределяйте когда нужно. Много не потребуется.
body * + * {
margin-top: 1.5rem;
}Нет, универсальный селектор не ухудшит производительность. Это ересь.
Вид
Не нужен целый Angular или Meteor чтобы поделить простую страницу на "views". Views это просто куски страницы, которые видны в те моменты, когда не видны другие. Это можно сделать с CSS:
.view {
display: none;
}
.view:target {
display: block;
}«Но одностраничные приложения запускают код при загрузке view!», — скажете вы. Я понимаю. Для этого существует событие onhashchange. Не нужно библиотек, и ваши ссылки будут нормальными, стандартными, их можно добавлять в закладки. Это клево. Об этом можно почитать больше, если интересно.
Размер шрифта
Тонкая настройка размера шрифта может сильно раздуть ваши блоки media. Поэтому нужно отдать это в руки CSS. Одна строчка кода.
font-size: calc(1em + 1vw);Э-э-э… вот и все. Есть даже минимальный размер, так что не будет нечитаемых крохотных букв на мобильных устройствах.
10k Apart
Как я сказал, я не лучший в мире кодер. Я просто знаю несколько трюков. Но с небольшим количеством знаний можно сделать очень многое. В этом суть соревнования «10k Apart» — выяснить, чего можно добиться с 10kb или меньше. Есть большие призы. Я как судья не могу дождаться, когда возьмусь за изучение всех крутых заявок, идей и реализаций, которые мне хотелось бы придумать самому. А что придумаете вы?
Комментарии (45)
dcc0
23.08.2016 12:31+7Поддержу.
Одна задача, одна программа, одна строчка, как легкий взмах кисти китайского поэта-каллиграфа = ).
Вообще некоторые пользователеи Linux и приверженцы «открытого источника» считают, что порождение новых инструментов в современном программировани — это что-то вроде дурной бесконечности, некоторые полагают, что множество программ генерируют от нежеления учиться, так как большая часть инструментов уже существует (в том же Linux).
AlexanderG
23.08.2016 13:40+29Одна задача, одна программа, одна строчка
… один фюрер :)
il--ya
23.08.2016 12:57+3GorgeousGorge
21.12.2016 13:34У меня появилось как раз такое желание, даже придумал один вариант реализации. Не для массового производства, а этакий дизайн-макет для себя, поиграть с друзьями.
outdead
23.08.2016 13:10+2Очевидные вещи, которые действительно повышают производительность как кода так и разработчика. Почему-то сразу же вспомнился первый пункт этой публикации
Спасибо, что еще раз напомнили об этом.
forcewake
23.08.2016 15:10+3Выскажу мнение непопулярное, но тоже имеющее право на жизнь.
WAI-ARIA очень нужна. Мы живем в 2016 году и люди, у которых не все так хорошо со зрением, тоже хотят использовать интернет на полную катушку, как мне кажется.
Chesheer
23.08.2016 15:21К сожалению многие моменты, касающиеся юзабилити для людей c отклонениями в здоровье (ну, не поворачивается у меня язык, назвать их инвалидами) в 99+% оказываются за бортом разработки.
arandomic
23.08.2016 16:58Нужна не столько ARIA, сколько адекватное тестирование на Accessibility.(Хотя бы автоматизированное тестирование на соответствие WCAG) Большинство современного специализированного ПО неплохо справляются с HTML разметкой и без ARIA, если в разметке нет особых извращений.
sumanai
23.08.2016 19:21+3Скорее речь о том, что при использовании стандартных элементов их описание через Aria не требуется, так как это излишне.
Вон, ниже выложил код кнопки из яндекс-почты, вот его фрагмент:
<button aria-disabled="false" role="button"
Здесь role=«button» абсолютно лишний, эта роль и так назначается всем элементам button.
На счёт aria-disabled=«false» не уверен, но что-то мне подсказывает, что оно тоже тут не нужно.Fayon
24.08.2016 13:06«Здесь role=«button» абсолютно лишний»
Неправильный ответ. Ибо если button находится в форме, он автоматически срабатывает как submit
SelenIT3
23.08.2016 19:33+1Автор не против WAI-ARIA как таковой. Он против популярной (увы) манеры делать интерфейсы на голых div-ах и span-ах, а потом лихорадочно пытаться «вдохнуть в них жизнь» скриптами, той же арией и прочей магией, вместо того, чтобы изначально использовать специально обученные HTML-элементы, у которых — сюрприз — атрибуты доступности вшиты «из коробки» на уровне браузеров.
TrogWarZ
23.08.2016 19:34+1Мне всегда казалось, что элементы HTML из стандарта уже «из коробки» умеют достаточно для людей с ограниченными возможностями, а реализация лежит на плечах разработчиков бразуеров/ридеров. А всякие ARIA следует использовать только когда используется либо «хитрая» логика на странице, которую не может осилить большинство реализаций, либо не семантическая вёрстка.
Как в CSS, где есть стандартные стили в бразуерах/ОС и свои собственные стили для изменения стандартного поведения.
Так ли это? Вопрос скорее к компетентным людям в данной области.
sbnur
23.08.2016 15:56+1Вообще-то краткость кода означает использование инструментов, встроенных в некий язык или некие библиотеки некого языка, что представляет собой неконтролируемую часть кода.
Поэтому утверждение о производительности спорно, если не сказать большего.
Это один аспект желания писать кратко.
Другой аспект — что значит писать кратко при наличии залания на разработку — это аналогично не доложить цемента в раствор.
Что написано, то и должно быть реализовано.
Поэтому писать кратко скорее всего означает предварительно семь раз подумать, чем один раз написать.
А часто думать лень по принципу — что тут думать, писать надо
А писать код надо по принципц — quantum satis
sumanai
23.08.2016 19:17+1Преимущество использования нативных элементов в том, что зачастую не нужно будет кодировать собственное поведение.
Эти бы слова, да Mail.ru в уши. Код кнопки «Отмена» из почты
<div class="b-toolbar__item"><div data-title="Отмена" data-bem="b-toolbar__btn" data-name="cancel" class="b-toolbar__btn"><span class="b-toolbar__btn__text">Отмена</span></div></div>
Впрочем, Яндекс, использующий для этих целей нативный button, смотрится даже хуже:
<button aria-disabled="false" role="button" id="nb-35" class="nb-button _nb-normal-button _init daria-action ui-button ui-widget ui-state-default ui-corner-all ui-button-text-only" data-nb="button" hidefocus="true" data-action="compose.close" data-params="" tabindex="10" type="button"><span class="ui-button-text"><span class="_nb-button-content">Отменить</span></span></button>enniel
24.08.2016 19:51Вы случайно примеры не перепутали? Что bem код делает в mail.ru
sumanai
24.08.2016 22:01Вы случайно примеры не перепутали?
Нет конечно же. В обоих местах используется БЭМ в том или ином виде.
Что bem код делает в mail.ru
Наверное работает. А почему бы в mail.ru не использовать БЭМ?
Можете сами убедится, это не сложно.
stardust_kid
23.08.2016 19:57+2Но, оказывается, что единственный гарантированный способ повысить производительность в вебе — это писать меньше кода.
Странная гипотеза вообще-то. Понятно, что производительность пустой программы стремится к бесконечности, но ее польза стремится к нулю.
Трюки в статье крутые описаны, но это сферические трюки в вакууме. Когда вам в реальном проекте понадобится передавать параметр в url, то магический селектор target не поможет. Потом у вас периодически будут перекашиваться div'ы и прочие элементы — спасибо волшебному селектору *. Если вы попытаетесь адаптировать формулу шрифта под свои нужды, не все любят конские размеры шрифты, то сломаете себе мозг.
В целом довольно глупая статья, где автор пытается играть на эмоциях.sumanai
23.08.2016 19:59+2Понятно, что производительность пустой программы стремится к бесконечности, но её польза стремится к нулю.
Не всегда ))
potan
24.08.2016 03:02На ELM программы получаются удивительно компактными. Но успеху это как-то мало помогает.
Fayon
24.08.2016 13:26Сразу видно адепта методологии ХХивП. Главное написать, а как это будет поддерживаться — пофигу.
junkerSchmidt
27.08.2016 20:36С кэшированием не совсем точно вышло. Как раз без него проще — сделал себе какой-нибудь RPC запрос, и все дела. А тут еще и кэш прикручивать…
Itachi261092
30.08.2016 11:26В целом со многим согласен. к чёрту фреймворки и скрипты, когда можно обойтись без них. Но вот с тем, что нужно как можно больше заниматься копипастом — согласиться не могу. без сомнения, когда ты не знаешь реализацию той или иной фичи — можно поискать и вставить чужое. но такой подход всегда хуже, если ты вставил чужое и не знаешь построчно что делает этот код. такое потом приводит к непредвиденным проблемам, и долгим дебагам.
comerc
А ещё Clojure кардинально сокращает код.
Где-то вычитал (не помню), что одна из главных задач инженера — абстрагировать уровни сложности, постепенно поднимаясь всё выше и выше.
igrishaev
Нет, Кложа по плотности примерно как Питон или Руби. А вот абстракции в ней сильнее, да.
comerc
Конкретный пример. Николай Рыжиков рассказывал, как переписал огромного размера проект с Ruby на Clojure, при этом сократив код на 2/3.
ozkriff
Количество кода почти всегда сокращается при любом переписывании проекта, даже без смены языка.