Когда я говорю об оценке технологии для интерфейсной разработки, мне нравится проводить различие между двумя категориями технологий.
С одной стороны, у вас есть сырые материалы Интернета: HTML, CSS и JavaScript. Это то, с чем в конечном итоге будут взаимодействовать пользователи.
С другой стороны, у вас есть все инструменты и технологии, которые помогут вам создавать HTML, CSS и JavaScript: препроцессоры, постпроцессоры, транспилеры, сборщики пакетов и другие инструменты сборки.
Лично меня материалы гораздо больше интересуют и воодушевляют, чем инструменты. Но я думаю, что это правильно и правильно, что другие разработчики в восторге от этих инструментов. Хороший баланс обоих, вероятно, самый здоровый микс.
Я никогда не знаю, как назвать эти две категории. Возможно, материалы - это «внешние» технологии, потому что с ними будут взаимодействовать пользователи. В то время как все остальные технологии, которые в большинстве своем находятся на компьютере разработчика, являются «внутренними» технологиями.
Еще одна приятная фраза - это то, что я услышал во время выступления Криса на An Event Apart в Сиэтле, когда он процитировал Брэда, который говорил о передней части передней части и задней части передней панели.
Я определенно больше занимаюсь фронтенд-разработкой. У меня есть мнение о качестве материалов, которые предоставляются пользователям; вывод должен быть доступным и работоспособным. Но меня не особо заботят инструменты, из которых изготовлены эти материалы на задней стороне передней части. Используйте то, что работает для вас (или то, что работает для вашей команды).
Как разработчик, ориентированный на пользователя, мой приоритет - делать то, что лучше всего для конечных пользователей. Это не значит, что я не ценю удобство разработчика. Я делаю. Но я ставлю приоритеты на потребности пользователя над потребностями разработчика. И в любом случае эти две потребности большую часть времени даже не входят в противоречие. Как я уже сказал, с точки зрения пользователя не имеет значения, какой текстовый редактор или систему контроля версий вы используете.
Теперь вы можете привести аргумент, что все, что подходит для удобства разработчика, автоматически полезно для взаимодействия с пользователем, потому что более быстрая и эффективная разработка должна приводить к лучшему результату. Хотя теоретически это верно, я настоятельно рекомендую публикацию Алекса Приманка и переключение на опыт разработчиков.
Интересно, когда технология, разработанная для удобства разработчиков, создается из самих материалов, доставляемых пользователям. Например, фреймворк CSS, такой как Bootstrap, сделан из CSS. Это отличается от такого инструмента, как Sass, который выводит CSS. Выбирает ли разработчик использование Sass или нет, не имеет значения для пользователя - в любом случае конечным результатом будет CSS. Но если разработчик решит использовать фреймворк CSS, это решение окажет прямое влияние на взаимодействие с пользователем. Пользователь должен загрузить фреймворк, чтобы разработчик мог воспользоваться преимуществами.
Итак, в то время как Sass находится в задней части интерфейса - где мне все равно, что вы используете, - Bootstrap находится в передней части интерфейса. Я не думаю, что для подобных инструментов достаточно сказать «используйте то, что вам подходит». Это нужно сопоставить с затратами для пользователя.
Исторически сложилась аналогичная история с библиотеками JavaScript. Они написаны на JavaScript, поэтому будут выполняться в браузере. Если разработчик хотел использовать jQuery для облегчения своей жизни, пользователь платил цену, скачивая библиотеку jQuery.
Но я заметил долгожданное изменение в некоторых более крупных фреймворках JavaScript. В то время как первоначальные сообщения о таких фреймворках, как React, рекламировали преимущества управления состоянием и виртуальной DOM, мне кажется, что сейчас это не так распространено. Вы с большей вероятностью услышите - и совершенно справедливо - людей, говорящих о преимуществах модульности и компонентности. Если вы объедините это с появлением Node - а это означает, что JavaScript больше не ограничивается браузером - тогда эти фреймворки могут перемещаться от передней части интерфейса к задней части интерфейса.
Мы, конечно, видели это на Clearleft. Мы работали над несколькими проектами React, но в каждом случае результат рендерился на сервере. Разработчики получают возможность работать с инструментом, который им помогает. Пользователи не платят цену.
Для меня очень важен вопрос о том, будет ли фреймворк использоваться на стороне клиента или на стороне сервера.
Позвольте мне рассказать вам о проекте Clearleft, который запомнился мне. Мы работали с крупным международным клиентом над продуктом, который собирались внедрить для студентов и преподавателей в развивающихся странах. Это было прямо в моем переулке! Мы провели множество исследований состояния сети и типичного использования устройств. Это тогда сообщило жесткий бюджет производительности. Каждое дизайнерское решение - от веб-шрифтов до изображений - основывалось на этом бюджете производительности. Мы создавали бережливую, среднюю разметку, CSS и JavaScript. Но не мы создавали финальный сайт. Этим занималась оффшорная команда программного обеспечения клиента, и они настояли на использовании React. Ничего страшного, - подумал я. React можно использовать на стороне сервера, чтобы мы могли выводить именно то, что нужно, верно? Увы, нет. Эти разработчики сделали все на стороне клиента. Когда был запущен последний сайт, только экран входа в систему требовал мегабайтов JavaScript только для визуализации формы. На мой взгляд, это было совершенно непригодно для использования. Мне все еще больно, когда я думаю об этом.
Это было несколько лет назад. Я думаю, что в наши дни стало намного проще принять решение об использовании фреймворка в задней части интерфейса. Как я уже сказал, это определенно имело место в недавних проектах Clearleft, в которых использовались React или Vue.
Поэтому меня удивляет, когда я вижу, что вопрос о серверном или клиентском рендеринге рассматривается почти как деталь реализации. С точки зрения разработчика, это может быть деталь реализации, но это ключевое решение для пользовательского опыта. Затраты на производительность размещения всего вашего технологического стека в браузере могут быть огромными.
Алекс Сандерс из команды разработчиков The Guardian недавно опубликовал пост под названием Пересмотр уровня рендеринга. В нем он описывает, как они переходят на React. Теперь, если бы это был переход на React с рендерингом клиентом, это сильно повлияло бы на взаимодействие с пользователем. Дело в том, что я не мог сказать из статьи, будет ли React использоваться в браузере или на сервере. В статье говорится о рендеринге - чем занимаются браузеры - и DOM, что существует только в браузерах.
Так я и спросил. Оказывается, этот план во многом связан с генерацией HTML и CSS на сервере перед отправкой в браузер. Отлично!
Получив ответ на этот вопрос, я готов к тому, что они захотят использовать. В этом случае они предпочитают использовать CSS-in-JS (хотя, если говорить педантично, C больше нет, так что технически это SS-in-JS). Пока часть «JS» - это JavaScript на сервере, это не имеет значения для конечного пользователя и, следовательно, не имеет значения для меня. Ни мой цирк, ни мои обезьяны. Для пользователей конечный результат будет одинаковым независимо от того, применяется ли стиль с помощью селектора во внешней таблице стилей или, например, с помощью встроенного объявления стиля (а в некоторых ситуациях решение CSS-in-JS, отображаемое на сервере, может быть лучше по производительности). Итак, как разработчику, ориентированному на пользователя, мне не нужно об этом заботиться.
Кроме…
У меня есть опасения. Но для ясности: эти опасения не имеют ничего отношения к пользователям. Мои опасения полностью связаны с другой группой людей: людьми, которые создают веб-сайты.
Есть эффект второго порядка. Сделав React - или даже JavaScript в целом - требованием для стилизации чего-либо на веб-странице, поднимается барьер для входа.
По крайней мере, я думаю, что барьер для входа повышен. Я полностью признаю, что это субъективное суждение. Фактически, причина, по которой команда может решить сделать JavaScript обязательным для участия, вполне может быть связана с тем, что они считают, что это делает участие людей проще. Позволь мне объяснить…
Не так давно разработчики из области компьютерных наук высмеивали CSS за его простоту, жаловались, что он сломан, и отворачивались от него. К счастью, эта риторика ослабевает. В наши дни они с гораздо большей вероятностью признают, что CSS может быть простым, но непростым. Такие концепции, как каскад и специфичность, по-настоящему ломают голову, и никакие предварительные знания императивных языков программирования не помогут вам в этом декларативном мире - весь ваш с трудом завоеванный опыт и ноу-хау не взаимозаменяемы. Вместо этого кажется, что весь этот каскад и специфичность убивают модульность ваших красиво изолированных компонентов.
Неудивительно, что программисты с таким опытом восприняли бы CSS как ущерб и нашли способы обойти его. Об этом свидетельствует множество разновидностей CSS-in-JS. С точки зрения программиста, это решение упростило задачу. Лучше всего то, что до тех пор, пока это делается на сервере, для конечных пользователей нет никаких штрафов. Но теперь расплата за разнообразие вашей команды. Чтобы принять участие в программе, в настоящее время в значительной степени необходимо иметь навыки программирования в области компьютерных наук. Для кого-то с более декларативным прошлым - с действительно хорошими навыками HTML и CSS - все внезапно кажется излишне сложным. И как заметил Тантек:
Сложность усиливает привилегию.
Результат - своего рода привратник. Я не думаю, что это сделано намеренно. Я не считаю это злом. Это делается из самых лучших побуждений, в погоне за эффективностью и продуктивностью. Но эти решения по кодексу отражаются в практике приема на работу, которая исключает людей с разными, но одинаково ценными навыками и взглядами.
Рэйчел описывает HTML, CSS и исчезающие точки входа в нашу отрасль:
Если мы сделаем так, что вы должны понимать программирование, чтобы даже начать, тогда мы возьмем что-то открытое и поддерживающее и вернем это в руки тех, кто уже имеет привилегии.
Я думаю, здесь есть сравнение с токсичной мужественностью. Ядовитая мужественность, очевидно, ужасна для женщин, но она также ужасна для мужчин, поскольку клеймит любое мужское поведение, не соответствующее его мировоззрению. Точно так же, если единственные люди, которых ваша команда заинтересована в найме, - это традиционные программисты, тогда эти программисты будут возмущаться тем, что они тратят свое время на семантическую разметку, доступность, стили и другие дисциплины, которым они никогда не обучались. Хейдон правильно определяет это как неохотный привратник:
Принимая на себя роль разработчика полного стека (который на практике является компьютерным ученым, который также пишет HTML и CSS), человек берет на себя ответственность за весь код, несмотря на его радикальные различия в синтаксисе и назначении, и становится привратником. по крайней мере некоторые виды кода никто просто не заботится о том, чтобы хорошо его написать.
Это всем больно. Это плохо для твоей команды. Еще хуже для более широкого сообщества разработчиков.
В прошлом году Меня спросили: Есть ли страх или профессиональный вызов, который не дает вам спать по ночам? Я ответил:
Больше всего я боюсь Интернета, потому что он становится достоянием элитного духовенства разработчиков. Я твердо верю, что, как сказал Тим Бернерс-Ли, «это для всех». И я не имею в виду, что это может использовать каждый - я считаю, что это также может сделать каждый. Вот почему меня очень беспокоит все, что поднимает барьер для входа в веб-дизайн и веб-разработку.
Я описал здесь несколько дихотомий:
- Материалы против инструментов,
- Передняя часть переднего конца против задней части переднего конца,
- Пользовательский опыт и опыт разработчика,
- Рендеринг на стороне клиента против рендеринга на стороне сервера,
- Декларативные языки против императивных языков.
Но больше всего беспокоит следующий раскол:
- Люди, которые создают Интернет, против людей, которые исключены из создания Интернета.
Изначально это было размещено на моем собственном сайте.
