Smashing Podcast Episode 21 с Крисом Фердинанди: вредны ли современные передовые методы для Интернета?

Сегодня мы задаемся вопросом, вредны ли современные лучшие практики для Интернета? Современные фреймворки ведут нас по ложному пути? Я поговорил с экспертом по Lean Web Крисом Фердинанди, чтобы выяснить это.

Показать примечания

• Страница Криса со ссылками и заметками для подкаста
• книга «Бережливый веб»
• Крис Фердинанди в сети
• Крис в Твиттере
• Ванильный подкаст JavaScript

Еженедельное обновление

• «Перевод каркасов дизайна в доступный HTML/CSS»
  Харрис Шнайдерман
• «Создание настольных приложений с помощью Electron и Vue»
  Тими Омоени
• «Современные методы CSS для улучшения удобочитаемости»
  Эдоардо Кавацца
• «Как использовать Styled-Components в React»
  Адебии Адедотун Лукман
• «Как создать Porsche 911 с помощью эскиза»
  Никола Лазаревич

Стенограмма

Дрю Маклеллан: автор серии карманных руководств Vanilla JS, создатель программы обучения Vanilla JS Academy и ведущий подкаста Vanilla JS. Он разработал информационный бюллетень с советами, который каждый будний день читают около 10 000 разработчиков. Он обучал разработчиков в таких организациях, как Chobani и The Boston Globe. А его плагины JavaScript использовались такими организациями, как Apple и Гарвардская школа бизнеса. Больше всего ему нравится помогать людям изучать ванильный JavaScript. Итак, мы знаем, что он предпочел бы ванильный JavaScript, а не фреймворк, но знаете ли вы, что однажды он был выбран в полицейской очереди как человек с наименьшей вероятностью совершить преступление? Мои друзья Smashing, пожалуйста, поприветствуйте Криса Фердинанди. Привет, Крис. Как твои дела?

Крис Фердинанди: О, я в ударе. Спасибо, что пригласили меня.

Дрю: Я хотел поговорить с вами сегодня об этой концепции Lean Web, которая вызывает у вас некоторую страсть, не так ли?

Крис: Да, очень даже.

Дрю: Почему бы тебе не устроить для нас сцену? Когда мы говорим о бережливом Интернете, какую проблему мы пытаемся решить?

Крис: Да, отличный вопрос. В качестве предостережения для всех слушателей, этот эпизод может заставить маленького старика кричать на облако. Я постараюсь этого избежать. Когда я смотрю на то, как мы строим для Интернета сегодня, это немного похоже на раздутую, перепроектированную кашу. Я пришел к выводу, что многое из того, что сегодня мы считаем лучшими практиками, на самом деле может сделать сеть хуже.

Крис: Lean Web — это подход к веб-разработке, который фокусируется на простоте, производительности и опыте разработчика, а не на опыте разработчика. Скорее пользовательский опыт, а не опыт разработчиков, и простота создания вещей с точки зрения команды, что, я думаю, является тем, чему мы уделяем большое внимание сегодня и о чем мы, вероятно, поговорим в нашем разговоре.

Крис: На самом деле я пришел к выводу, что многие вещи, которые мы считаем улучшением опыта разработчиков, делают это для подмножества разработчиков, но не обязательно для всех, кто работает над тем, что вы создаете. Так что с этим тоже есть целая куча проблем, в которых мы можем разобраться. Но на самом деле, Lean Web заключается в том, чтобы сосредоточиться на простоте и производительности для пользователя и действительно расставить приоритеты или сосредоточить внимание на людях, которые используют то, что мы делаем, а не на нас, людях, которые это делают.

Дрю: По мере того, как Интернет развивается как платформа для разработки, кажется, что это постоянно усиливается стремление к специализации.

Крис: Да.

Дрю: Люди, которые раньше занимались Full Stack, а потом мы разделились на front-end и back-end. А затем этот интерфейс разделился на людей, которые занимаются разработкой CSS или JavaScript. А затем в JavaScript он становится все более специализированным. Кто-то может считать себя и позиционировать себя как разработчика React или разработчика Angular, и вся их идентичность и мировоззрение основаны на конкретной среде, в которой они хорошо разбираются. Является ли эта зависимость от сред, ядром нашей работы в Интернете, плохо?

Крис: Это нюанс. Раньше я был очень сильно в лагере «да, всегда». Я думаю в целом, я все еще чувствую, что да, наша одержимость индустрией фреймворками и инструментами в целом потенциально немного вредит нам. Я не думаю, что фреймворки плохи по своей сути. Я думаю, что они полезны для очень узкого подмножества вариантов использования. И в конечном итоге мы используем их практически для всего, включая множество ситуаций, когда они действительно не обязательно являются лучшим выбором для вас или для проекта.

Крис: Когда я думаю о многих проблемах, с которыми мы сталкиваемся сегодня в Интернете, суть этих проблем действительно начинается с нашей чрезмерной зависимости от фреймворков. Все остальное, что следует за этим, происходит по-разному, потому что мы бросаем так много не только фреймворков, а JavaScript в целом, в сеть. Я говорю это как человек, который профессионально учит людей писать и использовать JavaScript. Вот как я зарабатываю деньги. И я здесь говорю, что я думаю, что мы используем слишком много JavaScript, что иногда немного странно.

Дрю: До того, как появились большие фреймворки, мы использовали для создания пользовательских интерфейсов и прочего jQuery или что-то еще. А потом появились фреймворки, и они дали нам больше этой концепции пользовательского интерфейса на основе состояния.

Крис: Да.

Дрю: Итак, это довольно сложная инженерная часть, которую вам необходимо внедрить. Исключает ли работа с меньшим количеством JavaScript использование чего-то подобного, или вам нужно заново реализовать это самостоятельно? Вы просто создаете загруженный шаблон?

Крис: Многое зависит от того, чем вы занимаетесь. Если у вас неизменный интерфейс, вы можете создать пользовательский интерфейс на основе состояния с помощью… я не знаю, может быть, дюжины или около того строк кода. Если у вас есть неизменяемый интерфейс, я бы, честно говоря, вероятно, сказал, что пользовательский интерфейс на основе состояния. Это не обязательно правильный подход. Есть, вероятно, другие вещи, которые вы можете сделать вместо этого. Подумайте о генераторах статических сайтов, некоторой предварительно обработанной разметке, даже старомодных сайтах на WordPress или PHP.

Крис: Но что становится интереснее, так это когда вы попадаете в более динамичные и интерактивные интерфейсы. Не только приложения. Я знаю, что люди любят проводить грань между веб-сайтами и приложениями, и я думаю, что между ними существует странная смесь, и эта грань не всегда так четка. Когда вы начинаете углубляться, пользователь что-то делает, что-то меняется. Пользовательский интерфейс на основе состояния становится немного более важным. Но вам все еще не нужны тонны кода, чтобы это произошло.

Крис: Я смотрю на что-то вроде React или Vue, которые представляют собой совершенно потрясающие инженерные решения. Я не хочу отнимать у людей, которые над ними работают. Я закончил тем, что в качестве учебного упражнения построил свою собственную мини-инфраструктуру, просто чтобы лучше понять, как эти вещи работают под капотом. Действительно трудно учесть все различные движущиеся части. Поэтому я с огромным уважением отношусь к людям, которые создают и работают над этими инструментами. Но React и Vue занимают около 30 килобайт после минимизации и сжатия. Поэтому, как только вы распаковываете их, они значительно больше.

Крис: Не все, но значительная часть этого веса посвящена тому, что называется виртуальным DOM. Существуют альтернативы, использующие аналогичные API или подходы. Для React у вас есть Preact, который составляет 2,5 килобайта или около 3 килобайт вместо 30. Это десятая часть размера. Вместо Vue у вас есть Alpine JS, который занимает около 7 килобайт. Все-таки существенно меньше. Большая разница между ними и их старшими собратьями заключается в том, что они избавились от виртуального DOM. Они могут отказаться от метода или двух. Но в целом это тот же подход и тот же API в способе работы с кодом, и они существенно меньше.

Крис: Я думаю, что многие инструменты, которые мы используем, потенциально слишком сильны для того, что мы пытаемся сделать. Если вам нужен пользовательский интерфейс на основе состояния, вам нужны реактивные данные и эти динамические интерфейсы, это здорово. Я думаю, что одна из важных вещей, о которых я пытаюсь рассказать сегодня, это не… никогда не использовать инструменты. Для меня Vanilla JS — это не то, что вы пишете от руки каждую строку кода и каждый проект, который вы делаете. Это безумие. Я не мог этого сделать, я не делаю этого. Но это более избирательно в отношении инструментов, которые мы используем. Мы всегда выбираем многофункциональный инструмент, швейцарский армейский нож, в котором есть все это. А иногда все, что вам действительно нужно, это ножницы. Вам не нужны все остальные вещи, но они у нас все равно есть.

Крис: Это действительно долгий путь… извините, до ответа на ваш вопрос. Иногда это больше кода, чем вы могли бы или хотели бы написать сами, но это не так много кода, как я думаю, мы думаем, что для этого требуется. Когда я говорю, что вам не нужен фреймворк, я получаю много возражений по поводу этой идеи: «Ну, если вы не используете фреймворк, вы, по сути, пишете свой собственный». Тогда это приходит со своими проблемами. Я думаю, что есть что-то среднее между использованием React или Vue и написанием собственного фреймворка, и, возможно, это выбор чего-то немного меньшего размера. Иногда бывают причины, по которым написание собственного фреймворка может оказаться правильным решением, в зависимости от того, что вы пытаетесь сделать. Все очень текуче и субъективно.

Дрю: Весьма интересно, что в качестве учебного упражнения вы реализовали собственную структуру, основанную на состояниях. Я помню, в прошлом я думал, что каждый раз, когда я тянулся к библиотеке или чему-то еще, мне нравилось думать, что я могу реализовать это сам.

Крис: Конечно, конечно.

Дрю: Но поход в библиотеку избавил меня от хлопот. Я знал, что если мне придется писать этот код самому, я знал, какой подход я выберу для этого. И это было верно вплоть до использования таких вещей, как jQuery и тому подобное. В наши дни, я думаю, что если бы мне пришлось писать свою собственную версию Vue или React, я почти понятия не имею, что сейчас происходит в этой библиотеке, во всем этом коде.

Дрю: Для тех из нас, кто не знаком, когда вы говорите, что Preact отбрасывает виртуальный DOM и делает все намного меньше, что дает нам этот виртуальный DOM?

Крис: Чтобы ответить на этот вопрос, я хочу сделать небольшой шаг назад. Одна из самых приятных вещей, которые дают вам фреймворки и другие библиотеки, основанные на состоянии, — это сравнение DOM. Если вы не сильно обновляете пользовательский интерфейс, вы можете сказать: «Вот строка того, как должна выглядеть разметка. В HTML я просто добавлю всю эту разметку в этот элемент». Когда вам нужно что-то изменить, вы делаете это снова. Это немного дорого для браузеров, потому что вызывает перерисовку.

Крис: Но я думаю, что потенциально более важным является то, что одна из проблем, связанных с этим, заключается в том, что у вас есть какой-то интерактивный элемент, поле формы, ссылка, на которую кто-то обратил внимание. Этот фокус теряется, потому что элемент... даже если у вас есть новая вещь, которая выглядит похожей, это не тот же буквальный элемент. Поэтому, если фокус потерян, это может создать путаницу для людей, использующих программы чтения с экрана. С этим просто куча проблем.

Крис: Любая стоящая вещь пользовательского интерфейса на основе состояния будет реализовывать некоторые различия DOM, где они говорят: «Вот как должен выглядеть пользовательский интерфейс. Вот как это выглядит прямо сейчас в DOM. Что изменилось? И он пойдет и изменит эти вещи. Это эффективно делает то, что вы делаете, просто вручную обновляя пользовательский интерфейс, но делает это за вас под капотом. Поэтому вы можете просто сказать: «Вот как я хочу, чтобы это выглядело». И тогда библиотека или фреймворк выясняют это.

Крис: Небольшие разработки, такие как Preact или Alpine, на самом деле делают это напрямую. Они преобразуют предоставленную вами строку о том, как должен выглядеть пользовательский интерфейс, в элементы HTML. А затем они сравнивают каждый элемент с соответствующей частью в буквальном DOM. По мере того, как вы получаете пользовательские интерфейсы, которые становятся все больше и больше, это может сказаться на производительности, потому что повторные запросы к DOM становятся дорогостоящими. Если вы хотите получить представление о типе интерфейса, в котором это становится проблемой, щелкните правой кнопкой мыши и проверьте элемент на кнопке «Избранное» в Twitter или на кнопке «Нравится» в Facebook. И взгляните на вложенность div, которая приводит вас к этому элементу. Это очень, очень глубоко. Это похоже на дюжину или около того разделов, вложенных один в другой только для одного твита.

Крис: Когда вы начинаете опускаться на такое количество уровней, это начинает сильно влиять на производительность. Что делает виртуальный DOM, так это то, что вместо того, чтобы каждый раз проверять реальный DOM, он создает объектную карту того, как выглядит пользовательский интерфейс в JavaScript. Затем делает то же самое для пользовательского интерфейса, которым вы хотите заменить существующий, и сравнивает эти два. Теоретически это намного больше производительности, чем в реальном DOM. Как только он получает список вещей, которые ему нужно изменить, он просто запускает и вносит эти изменения. Но он должен атаковать DOM только один раз. Это не проверка каждого отдельного элемента каждый раз. Если у вас есть такие интерфейсы, как Twitter, Facebook, QuickBooks или что-то в этом роде, виртуальный DOM, вероятно, имеет большой смысл.

Крис: Сложность с этим в том, что… разница между Preact и React составляет 27 килобайт, прежде чем вы распаковываете все это в настоящую кодовую волну. Необработанная загрузка, распаковка и компиляция могут добавить немного задержки к начальной загрузке пользовательского интерфейса. Это становится еще более заметным, если ваши пользователи используют не самые последние устройства от Apple. Даже Android-устройство, выпущенное пару лет назад, или многофункциональный телефон, или если у вас есть люди в развивающихся странах, это действительно… время, чтобы начать работу, медленнее. Кроме того, фактическое интерактивное время медленнее из-за дополнительной абстракции.

Крис: Так что дело не только в том, что вы загружаете его, и они сопоставимы по скорости. Каждое микровзаимодействие, которое кто-то делает, и изменения, которые должны произойти, также могут быть немного медленнее только из-за всего этого дополнительного кода. Если у вас очень, очень сложный пользовательский интерфейс с большим количеством вложенных элементов и большим количеством данных, то прирост производительности виртуального DOM перевешивает дополнительный вес кода. Но любого типичного пользовательского интерфейса для типичного приложения, для которого большинство разработчиков, использующих React или Vue, преимущества, которые вы получаете от виртуального DOM, просто нет, и им было бы лучше. Даже если вы хотите сохранить удобство React, используйте Preact. Это часть размера, он будет работать точно так же, и он будет более производительным. Это то, за что я склонен спорить.

Крис: Нам нужно лучше подходить к выбору правильного инструмента для работы. Если вы пойдете с таким подходом, если вы дойдете до точки, где виртуальный DOM действительно имеет смысл, будет намного проще портировать Preact в React, чем если бы вы создавали свой собственный. Такова ситуация. Если вы действительно беспокоитесь об этом, вы также получаете встроенную защиту на будущее.

Дрю: Кто-то может возразить, что эти фреймворки, такие как Vue, React, настолько оптимизированы для производительности, что вы получаете так много преимуществ, что, безусловно, просто соедините их с менеджером пакетов в сборщике, чтобы убедиться, что вы повторно отправляет только тот код, который вы хотите. Конечно, вы уже далеко впереди, просто делая это?

Крис: Да. Я не согласен. На самом деле мне особо нечего сказать об этом, кроме… Наверное, может быть, но не совсем. Даже с упаковщиком вам все равно нужно ядро ​​React. Даже с пакетированием это все равно будет больше, чем использование чего-то вроде Preact.

Крис: Дрю, я очень благодарен вам за то, что вы задали этот вопрос. Потому что еще одна вещь, о которой я рассказываю в своей книге The Lean Web и в своем одноименном докладе, это то, как эти инструменты… Например, вы упомянули объединение. Одна из вещей, которую мы делаем, чтобы обойти падение производительности, которое мы получаем от использования всего этого JavaScript, заключается в том, что мы добавляем еще больше JavaScript во внешний интерфейс, чтобы учесть его. Один из способов сделать это — менеджеры пакетов и сборщики модулей.

Крис: Как вы упомянули… для тех из вас, кто не знает, это инструменты, которые… они будут компилировать все ваши маленькие отдельные кусочки JavaScript в один большой файл. Те, что поновее, и тем более… Задумчивыми их не назовешь. Но более новые будут использовать функцию, называемую встряхиванием деревьев, где они избавляются от любого кода, который на самом деле не нужен. Если в этом коде есть некоторые зависимости, которые не используются для того, что вы на самом деле сделали, они удалят некоторые из этих вещей, чтобы сделать ваши пакеты как можно меньше. На самом деле это неплохая идея, но она приводит к тому, что я обычно называю здоровьем зависимостей, когда у вас есть этот действительно хрупкий карточный домик зависимостей поверх зависимостей поверх зависимостей.

Крис: Настройка вашего процесса требует времени. И любой, кто когда-либо запускал установку NPM, а затем обнаруживал, что куча зависимостей устарела и должен был потратить час, пытаясь выяснить, какие из них нужно исправить, и о, на самом деле это зависимость в зависимости, и вы не нет возможности пойти починить самому. Это целое дело. Может быть, это работает для вас, но я бы предпочел потратить свое время, не возясь, пытаясь собрать свои зависимости.

Крис: Я начал собирать твиты от людей, в которых они жалуются на потраченное впустую время в своем рабочем процессе. Один из моих любимых, Брэд Фрост, пару лет назад говорил о удручающем осознании того, что то, что вы проделывали в современном JS, могло бы занять у вас 10 минут в jQuery. На самом деле я не фанат jQuery, но я чувствую эту боль, когда дело доходит до работы с фреймворками.

Крис: Другая проблема со многими из этих инструментов заключается в том, что они становятся привратниками. Я не знаю, насколько ты действительно хочешь погрузиться в это или нет, Дрю. Но одно из моих больших возражений против JS, все вещи в рабочем процессе. Особенно, когда вы начинаете говорить: «Ну, если мы уже используем JS для HTML, почему бы не использовать его и для CSS?» Вы начинаете исключать из процесса разработки множество действительно талантливых людей. Это просто очень большая потеря для проекта для сообщества в целом.

Дрю: Ну, конечно... Я начал изучать React в начале 2020 года, добавив его в свой набор навыков. Я делаю это уже почти семь месяцев. Я должен сказать, что есть одна часть, в которой я меньше всего уверен, — это настройка инструментов для запуска проекта.

Дрю: Кажется, нужно проделать очень много работы, чтобы что-то добавить в Hello World, и еще больше нужно знать, чтобы это было готово к производству. Это должно затруднить начало разработки, если это выдвигается как то, что вы должны делать в 2020 году, чтобы научиться быть веб-разработчиком. У кого-то, кто вступит в нее впервые, возникнут настоящие проблемы. Это будет настоящим барьером для входа, не так ли?

Крис: Абсолютно. Другая часть здесь заключается в том, что разработчики JavaScript не всегда единственные люди, работающие над кодовой базой или вносящие значимый вклад в эту кодовую базу. Чем больше мы делаем знание JavaScript требованием для работы с кодовой базой, тем меньше вероятность того, что эти люди смогут реально участвовать в проекте.

Крис: Примером этого, о котором я люблю говорить, является WordPress, который был недавно… я не должен говорить недавно в этом месте. Прошло уже пару лет. Но они все больше и больше перемещают свой стек бэкенда на JavaScript, а не на PHP, что по своей сути неплохо. Их новый редактор Gutenburg построен на React.

Крис: В 2018 году ведущий консультант WordPress по доступности Риан Ритвельд, чье имя я почти наверняка вырезал… она очень публично отказалась от своего положения и задокументировала, почему в очень подробной статье. Суть проблемы заключалась в том, что ей и ее команде было поручено проверить этот редактор, чтобы убедиться, что он будет доступен. WordPress составляет сейчас 30% Интернета. Их цель — демократизировать издательское дело, поэтому доступность — действительно важная часть этого. Это должно быть важной частью любого веб-проекта. Но для них, в частности, это остро важно. Вся работа ее команды состоит в том, чтобы убедиться… вся работа ее команды состояла в том, чтобы убедиться, что этот редактор будет доступен. Но поскольку ни у нее, ни у кого-либо из ее команды не было опыта работы с React, и поскольку они не могли найти добровольцев в сообществе специальных возможностей с таким опытом, ей и ее команде было очень трудно выполнять свою работу.

Крис: Исторически сложилось так, что они могли выявить ошибки, а затем пойти и исправить их. Но с новым рабочим процессом, основанным на React, они были сведены к выявлению ошибок и последующей регистрации тикетов. Они были добавлены в бэклог вместе со всеми другими запросами на разработку функций, над которыми работали разработчики JavaScript. Многие вещи, которые можно было бы легко исправить, не попали в первый релиз.

Крис: В мае 2019 года, примерно через год после того, как Райан ушел в отставку, в Гутенбурге был проведен подробный аудит доступности. Полный отчет составил 329 страниц. Только исполнительное резюме занимало 34 страницы. Он довольно подробно задокументировал 91 ошибку, связанную с доступностью. Многие из них были на самом деле… Я не хочу называть их простыми пустяками, но многие из них были базовыми вещами, которые команда Райана могла бы исправить, и это освободило бы разработчиков, чтобы они могли сосредоточиться на разработке функций. В конце концов, похоже, что они в конечном итоге и сделали: потратили много времени на разработку функций и отложили этот материал на потом. Но эта команда очень важна для проекта, и они внезапно оказались заблокированы в процессе из-за технического выбора.

Крис: Алекс Рассел — разработчик в команде Chrome. Пару лет назад он написал эту статью под названием «Приманка для разработчиков и переключение», где он говорил о соломенном аргументе фреймворков. Идея в том, что эти инструменты позволяют вам двигаться быстрее, и благодаря этому вы можете выполнять итерации быстрее и предоставлять лучший опыт. Это идея о том, что лучший опыт разработчика означает лучший пользовательский опыт. Я думаю, что это очень яркий пример того, что этот аргумент не всегда работает так, как думают люди. Это лучший опыт для некоторых людей, но не для всех.

Крис: Разработчики CSS, люди, работающие над системами дизайна, их способность создавать инструменты, которые могут использовать другие, иногда тоже ограничивается этим выбором инструментов. По моему опыту, раньше я лучше разбирался в CSS. За последние несколько лет он сильно изменился, и я далеко не так хорош, как раньше. По моему опыту, люди, которые действительно являются продвинутыми разработчиками CSS… и я имею в виду это в самом прямом смысле. Люди, работающие над CSS, — это настоящие веб-разработчики, работающие над языком программирования. Это очень особенная или может быть очень специализированная вещь. По моему опыту, люди, которые исключительно хороши в этом, не всегда очень хороши в JavaScript, потому что в конечном итоге вы очень глубоко погружаетесь в одно и немного скользите по другим вещам. Их способность работать с этими технологиями также снижается, что очень плохо, потому что раньше этого не было.

Крис: Когда стек был проще, людям из разных дисциплин было легче участвовать в процессе разработки. Я думаю, что это наносит ущерб как тому, что мы создаем, так и сообществу в целом, когда это уже не так.

Дрю: Недавно я обнаружил, что в проекте исследуются способы решения некоторых проблем с CSS, проблем с рабочим процессом, у нас много работы над проектом, размер пакета увеличивается, а старый CSS никогда не удаляется. Это был проект React, поэтому мы рассмотрели некоторые из этих подходов CSS в JavaScript, чтобы понять, что нам лучше всего использовать для решения проблем, которые у нас были. Что очень быстро стало очевидным, так это то, что для этого существует не только одно решение. Есть десятки различных способов сделать это.

Дрю: CSS в JS — это общий подход, но вы можете переходить от одного проекта к другому, и он совершенно по-разному влияет на него. Даже если вы занимаетесь CSS и изучаете определенный подход к проекту, эти навыки в любом случае нельзя передать. Очень сложно понять, как кто-то должен тратить слишком много времени на изучение этого, если он не очень хорошо разбирается в JavaScript.

Крис: Да. Другая интересная вещь, о которой, я думаю, вы только что немного рассказали, это то, что когда я говорю об этом, одним из самых больших возражений, которые я получаю, является то, что фреймворки навязывают соглашения. Вы собираетесь использовать ванильный JavaScript, у вас есть это зеленое голубое небо, вы можете делать все, что захотите, в проекте. С React есть способ React делать вещи.

Крис: Но одна из вещей, которые я обнаружил, это то, что есть подходы Reacty, но нет строгого единственно правильного способа делать что-то с React. Это одна из вещей, которые люди любят в этом. Это немного более гибко, вы можете делать что-то несколькими разными способами, если хотите. То же самое с Вью. Вы можете использовать эту вещь, основанную на HTML, где у вас есть свои свойства прямо в HTML, а Vue заменяет их, но вы также можете использовать более похожий на JSX синтаксис шаблонов, если хотите.

Крис: Я слышал, как многие люди жалуются на то, что когда они изучают React, одна из больших проблем заключается в том, что вы гуглите, как сделать X в React, и вы получаете дюжину статей, рассказывающих вам дюжину различных способов, как это можно сделать. Это не значит, что они не ставят некоторые ограничения на проект. Я не думаю, что это так однозначно, как «Я выбрал структуру. Теперь я строю именно так». Честно говоря, я тоже не уверен, что это обязательно то, чего я хотел бы. Я не думаю, что вы хотели бы, чтобы они были плотно закрыты… может быть, некоторые люди хотят. Но если вы преподносите это как преимущество, я не думаю, что это так явно выражено, как люди иногда изображают.

Крис: Вы попали в интересную вещь, хотя именно там, где вы упомянули CSS, который больше не нужен. Я думаю, что это одна из действительно интересных вещей, которые могут дать вам что-то вроде CSS и JS… или каким-то образом привязать ваш CSS к компонентам JavaScript, если этот компонент выпадет, то и CSS, теоретически, исчезнет вместе с ним. Во многом это похоже на то, как бросать инженерию на проблемы людей. Неизменно, вы по-прежнему зависите от людей где-то вдоль линии. Это не значит, что никогда не следует использовать эти подходы, но они, безусловно, не единственный способ решить эту проблему.

Крис: Есть инструменты, которые вы можете использовать для аудита вашего HTML и извлечения стилей, которые не используются, даже без использования CSS и JavaScript. Вы можете писать CSS «по старинке» и при этом анализировать неиспользуемые стили. Существуют авторские подходы к CSS, которые дают вам CSS в виде JS-подобного вывода и сохраняют размер вашей таблицы стилей, не выплевывая эти тарабарские нечитаемые имена классов, которые вы иногда получаете с CSS и JS. Типа X2354ABC, или просто эти бессмысленные слова, которые выплевываются.

Крис: Здесь я начинаю по-настоящему вникать в то, что старик кричит на облако. Здесь я действительно показываю свой возраст разработчика. Но да, это не обязательно, что эти вещи плохи, и они созданы для решения законных проблем. Иногда мне кажется, что есть что-то вроде… если это достаточно хорошо для Facebook, это достаточно хорошо и для нас, что происходит с ними. Что ж, Facebook использует этот инструмент. Если мы настоящая инженерная программа… команда, отдел, организация, мы тоже должны. Я не обязательно думаю, что это правильный способ думать об этом. Это потому, что Facebook занимается проблемами, которых нет у вас, и наоборот. Размер и масштаб того, над чем они работают, просто разные, и это нормально.

Дрю: Точно. Я вижу некоторые из этих вещей, таких как CSS и JavaScript, почти как полифилл. У нас есть законные проблемы, нам нужен способ их решить. Технология еще не дает нам способ решить эту проблему. Может быть, пока мы ждем, пока веб-платформа разовьется и решит эту проблему, то, что мы сейчас делаем с JavaScript, поможет нам пройти через это, и все будет в порядке. Мы знаем, что это плохо. Мы знаем, что это не лучшее решение, но сейчас оно помогает нам. И, надеюсь, со временем мы сможем вытащить его и использовать нативное решение.

Крис: Очень забавно, что ты поднимаешь эту тему. Потому что буквально прошлой ночью я смотрел прошлогодний доклад Джереми Кита о прогрессивных веб-приложениях. Но он говорил о том, как пару десятков лет назад пытался убедить людей использовать JavaScript. В то время это казалось смешным, но JavaScript был чем-то новым. Он показал людям, как вы можете делать классные вещи, например, изменять цвет ссылки при наведении курсора с помощью этого нового… Кажется абсурдным, что вам нужен JavaScript для этого сейчас, потому что это то, что CSS делает за вас. Но таких вещей, как атрибут или свойство фокуса, в то время просто не существовало.

Крис: Одна из вещей, которые он сказал в своем выступлении, которые, я думаю, действительно нашли отклик у меня, это то, что JavaScript во многих отношениях прокладывает эти коровьи тропы. Это очень гибкий и открытый язык, который мы можем использовать для создания или добавления функций, которых еще не существует. И затем, в конце концов, браузеры догоняют и реализуют эти функции более естественным образом. Но это требует времени. Я полностью понимаю, что вы говорите об этом. Это не идеальное решение, но это то, что у нас есть прямо сейчас.

Крис: Я думаю, что для меня самая большая разница между полифиллами и некоторыми из этих решений заключается в том, что полифиллы спроектированы так, чтобы их можно было вырвать. Если у меня есть функция, которую я хочу реализовать, которую браузер еще не поддерживает, но для нее есть какая-то спецификация, и я пишу полифилл… как только браузеры догонят, я могу вырвать этот полифилл, и мне не нужно изменить что-либо. Но когда вы идете по пути использования некоторых из этих инструментов, удаление их означает переписывание всей базы кода. Это очень дорого и проблематично. Это не значит, что никогда их не используйте, но я твердо убежден, что мы должны подумать о выборе инструментов, которые можно легко вытащить позже. Если они нам больше не нужны или платформа наверстывает упущенное, для их извлечения не требуется серьезного переписывания.

Крис: Итак, чтобы перейти к этому, у нас есть целая куча стилей, которые мы больше не используем, поэтому я бы лично предпочел технологию инструментов сборки, которая проверяет ваш CSS на соответствие отрендеренной разметке и извлекает то, что вам не нужно. Потому что в будущем, если платформа наверстает упущенное, вы можете вытащить эту часть инструмента сборки, не меняя все. Это просто расширение того, что у вас уже есть, в то время как CSS и JS не дают вам такого же преимущества. Я просто придираюсь к этому, но я думаю о многих из этих технологий в более широком смысле.

Крис: Я чувствую, что такие вещи, как React или Vue, вероятно, прокладывают некоторые коровьи тропы, которые браузеры в конечном итоге догонят и, вероятно, будут использовать похожие подходы, если не одинаковые, поэтому там может быть меньше необходимости переписывать. Многие вещи экосистемы, которые подключаются вокруг, могут быть меньше.

Дрю: Я думаю, это правильно, что веб-платформа движется медленно и осторожно. Вы думаете, если бы пять лет назад мы все размещали карусели JavaScript на наших страницах. Они были повсюду. Все внедряли JavaScript-карусели. Если бы веб-платформа подскочила и внедрила решение Carousel, чтобы удовлетворить эту потребность, оно бы не сидело там, пока никто его не использовал, потому что люди больше не делают этого с Carousel. Потому что это была просто причуда, тенденция дизайна. Чтобы противодействовать этому и не допустить раздувания самой платформы и превращения ее в проблему, требующую решения, она должна двигаться более стабильными темпами. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. Ты бы согласился с этим?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Абсолютно. Абсолютно. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Крис: Еще одна вещь, которой мы не уделяли столько внимания, сколько мне бы хотелось, но я думаю, что она действительно важна, это то, что за последние несколько лет платформа очень сильно наверстала. Принятие этого в максимально возможной степени приведет к тому, что веб-интерфейс для людей будет быстрее, менее хрупким, его будет легче создавать и поддерживать, поскольку он требует меньше зависимостей, таких как использование того, что браузер дает вам извне. -коробка. Раньше нам нужен был jQuery для выбора таких вещей, как классы. Теперь у браузеров есть встроенные способы сделать это. Людям нравится JSX, потому что он позволяет писать HTML на JavaScript более простым способом. Но у нас также есть литералы шаблонов в ванильном JavaScript, которые обеспечивают такой же уровень простоты без дополнительной зависимости. Сам HTML теперь может заменить многие вещи, для которых раньше требовался JavaScript, что совершенно удивительно.

Крис: Мы немного говорили о… это CSS, но наведение курсора по ссылкам и то, что раньше для этого требовался JavaScript. Но используя такие элементы, как детали и сводные элементы, вы можете создать раскрытие, например, развернуть и свернуть или элементы аккордеона изначально без необходимости написания сценария. Вы можете выполнять автозавершение ввода, используя всего лишь… Я не должен говорить просто, я ненавижу это слово. Но использование скромного элемента ввода, а затем связанного с ним элемента списка данных с некоторыми опциями. Если вам интересно, как все это работает на vanillajstoolkit.com, у меня есть куча материалов JavaScript, которые предоставляет вам платформа. Но у меня также есть некоторые, которые раньше требовали JavaScript, а теперь не такие вещи, которые тоже могут быть интересными, если вы хотите, чтобы некоторые примеры кода сопровождали это.

Крис: Что касается CSS, мой самый популярный плагин Vanilla JS — это библиотека, которая позволяет анимировать прокрутку вниз до якорных ссылок. Это очень большая. Это самый сложный кусок кода, который мне когда-либо приходилось писать. И теперь он полностью заменен одной строкой CSS, поведение прокрутки плавное. Это более производительно. Писать проще. Легче изменить его поведение. Это просто лучшее общее решение.

Крис: Еще одна вещь, которую я бы хотел, чтобы мы сделали больше, — это использование многостраничных приложений. Я чувствую себя здесь немного оправданным, потому что недавно я видел статью от кого-то из Google, которая на самом деле настаивает на этом подходе и сейчас. Я подумал, что это было довольно интересно, учитывая этот огромный Angular, а затем фреймворк… бум, все то, что Google начал несколько лет назад. Круто видеть, как они возвращаются к этому. Используя такие вещи, как генераторы статических сайтов и замечательные сервисы, такие как Netlify и кэширование CDN, вы можете создавать невероятно быстрые веб-интерфейсы для людей, использующих отдельные HTML-файлы для всех ваших различных представлений. Так что полагаюсь на некоторые из этих нестандартных вещей.

Крис: В ситуациях, когда это нереально для вас, когда вам нужно больше JavaScript, вам нужна какая-то библиотека, возможно, сначала взгляните на более мелкие и более модульные подходы, вместо того, чтобы просто обращаться к бегемотам отрасли. Вместо React подойдет ли Preact? Вместо angular… Я имею в виду, вместо Vue, будет ли работать Alpine JS? Также есть очень интересный предварительный компилятор, который теперь называется Svelt, который дает вам фреймворк, а затем компилирует весь ваш код в ванильный JavaScript. Таким образом, вы получаете эти действительно крошечные наборы, в которых есть только то, что вам нужно, и ничего больше. Не могли бы вы вместо CSS и JavaScript подключить какой-нибудь сторонний линтер CSS, который сравнит ваш HTML с вашим CSS и вытащит то, что там случайно осталось? Будет ли работать другой способ создания вашего CSS, например, объектно-ориентированный CSS от Николь Салливан? Нам не удалось поговорить об этом, но это действительно крутая вещь, которую люди должны проверить.

Крис: И затем я думаю, что, возможно, третья и самая важная часть здесь, хотя это не столько конкретный подход, сколько просто то, о чем я хочу, чтобы больше людей помнили, это то, что Интернет предназначен для всех. Многие инструменты, которые мы используем сегодня, работают для людей с хорошим интернет-соединением и мощными устройствами. Но они не работают для людей, которые используют старые устройства, имеют ненадежное подключение к Интернету. Это не только люди в развивающихся областях. Это также люди в Великобритании, в некоторых частях США, где у нас абсолютно ужасные интернет-соединения. В середине нашей страны очень медленный интернет. Я знаю, что в некоторых частях Лондона есть места, где по историческим причинам не могут подключить новый широкополосный доступ, поэтому у вас остаются эти старые интернет-соединения, которые действительно плохие. Такие места есть по всему миру. Последний раз, когда я был в Италии, то же самое. Интернет там был ужасный. Не знаю, изменилось ли оно с тех пор.

Крис: То, что мы создаем сегодня, не всегда работает для всех, и это очень плохо. Потому что видение Интернета, что мне в нем нравится, заключается в том, что это платформа абсолютно для всех.

Дрю: Если слушатели хотят узнать больше об этом подходе, вы подробно описали его в своей книге The Lean Web. И это доступно онлайн. Это физическая книга или цифровая книга?

Крис: И то, и другое понемногу. Ну нет. Это определенно не физическая книга. Вы заходите на сайт leanweb.dev. Вы можете прочитать все это бесплатно онлайн. Вы также можете, если хотите, есть версии EPUB и PDF, доступные за очень небольшую сумму денег, я уже забыл, сколько. Я не смотрел на это какое-то время. Все это бесплатно онлайн, если вы этого хотите. Вы также можете посмотреть доклад на эту тему, где я расскажу подробнее, если хотите.

Крис: Но я также создал специальную страницу для слушателей Smashing Podcast по адресу gomakethings.com/smashingpodcast, потому что я очень творчески подхожу к именованию вещей. Это включает в себя кучу ресурсов в дополнение к книге, вокруг вещей, о которых мы говорили сегодня. Это ссылки на множество различных техник, которые мы рассмотрели, другие статьи, которые я написал, которые углубляются в некоторые из этих тем и немного расширяют мое мышление. Если люди хотят узнать больше, это, вероятно, будет лучшим местом для начала.

Дрю: Это потрясающе. Спасибо. Я узнал все о Lean Web. Что ты узнал в последнее время, Крис?

Крис: Да, пару вещей. Я упоминал об этом немного раньше, когда смотрел видео Джереми о прогрессивных веб-приложениях. Я откладывал изучение того, как на самом деле написать свое собственное прогрессивное веб-приложение, в течение нескольких лет, потому что у меня не было особой потребности ни в чем, с чем я работал. Недавно я узнал от одного из моих студентов, который находится в Южной Африке, что они имеют дело с веерными отключениями электроэнергии из-за того, что у них там что-то происходит. В результате она не может работать над некоторыми проектами, которые мы регулярно делаем вместе, потому что отключается электричество, и она не может получить доступ к учебному порталу и продолжить обучение.

Крис: Для меня теперь создание опыта, в котором он работает, даже если у кого-то нет Интернета, стало более приоритетным, чем… Я понял, что, возможно, это было раньше, поэтому я просто начал копаться в этом и надеюсь собрать это воедино. ближайшие несколько недель. Посмотрим. Тем не менее, ресурсы Джереми Кейта по этому вопросу были абсолютным спасением. Я рад, что они существуют.

Крис: Я знаю, Дрю, вы упомянули, что одна из причин, по которой вы любите задавать этот вопрос, заключается в том, чтобы показать, что люди, какими бы опытными они ни были, всегда учатся. Просто небольшой анекдот по теме. Я работаю веб-разработчиком, думаю, около восьми лет. Мне все еще приходится гуглить свойство CSS, чтобы использовать его для выделения курсивом, буквально каждый раз, когда я его использую. По какой-то причине мой мозг по умолчанию использует оформление текста, хотя это и не правильно. Я пробую пару комбинаций разных вещей, и каждый раз у меня всегда одно слово неправильно. Я также иногда пишу курсивом вместо курсива. Да. Если кто-нибудь когда-нибудь почувствует, что я никогда не выучу этот материал… просто знайте, что независимо от того, насколько вы опытны, всегда есть какая-то действительно базовая вещь, которую вы гуглите снова и снова.

Дрю: Я работаю веб-разработчиком уже 22-23 года, и мне до сих пор каждый раз приходится гуглить различные свойства Flexbox. Хотя пользуюсь уже 23 года. Но да, некоторые вещи просто… вероятно, их станет больше, когда я стану старше.

Крис: Да. Честно говоря, я закончил тем, что создал целый веб-сайт с вещами, которые я гуглил снова и снова, просто чтобы иметь более удобную ссылку для копирования и вставки, потому что это было проще, чем гуглить.

Дрю: Это неплохая идея.

Крис: Вот такой я ленивый. Я создам целый веб-сайт, чтобы сберечь себя, как три секунды гугления.

Дрю: Если вы, как слушатель, хотели бы услышать больше от Криса, вы можете найти его книгу в Интернете по адресу leanweb.dev, его информационный бюллетень «Советы разработчикам» и многое другое на сайте gomakethings.com. Крис находится в Твиттере Криса Фердинанди. И вы можете проверить его подкаст на vanillajspodcast.com или там, где вы обычно берете свои подкасты. Спасибо, что присоединился к нам сегодня, Крис. У тебя есть напутствие?

Крис: Нет. Большое спасибо, что пригласил меня, Дрю. У меня было абсолютно потрясающее время. Это было очень весело. Я очень ценю возможность прийти поболтать.