Smashing Podcast Episode 45 с Джереми Вагнером: что такое ответственный JavaScript?

Этот эпизод был любезно поддержан нашими дорогими друзьями из Wix, платформы, на которой профессионалы могут создавать клиентские сайты, управлять сложными проектами и развивать бизнес в Интернете. Спасибо!

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

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

• Ответственный JavaScript-сайт
• Купить книгу в A Book Apart
• личный сайт Джереми
• Джереми в Твиттере

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

• Закон Фиттса в эпоху осязания, написанный Стивеном Хубером
• Хорошо выполненный веб-дизайн: совершенно бессмысленно, написанный Фредериком О'Брайеном
• Все, что вы хотите знать о создании голосовых пользовательских интерфейсов, написанное Ником Бабичем и Глебом Кузнецовым
• Последствия присоединения WordPress к блочному протоколу, написанному Леонардо Лосовизом
• Мысли об уценке, написанные Кнутом Мелваром

Стенограмма

Дрю Маклеллан: технический писатель, специалист по веб-производительности, разработчик и спикер, в настоящее время работает в Google. Он написал для A List Apart, CSS-Tricks и Smashing Magazine, а также является автором нового названия Responsible JavaScript for A Book Apart. Итак, мы знаем, что он опытный техник и коммуникатор, но знаете ли вы, что он хочет совершить кругосветное плавание на доске с веслом? Мои потрясающие друзья, пожалуйста, поприветствуйте Джереми Вагнера. Привет, Джереми, как дела?

Джереми Вагнер: Я разбиваю. Как твои дела?

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

Джереми: Я буквально говорю об ответственном использовании JavaScript. Таким образом, согласно HTTP-архиву, мы наблюдаем почти 58-процентное увеличение объема JavaScript, загруженного мобильными устройствами, примерно на 58 % с примерно 290 килобайт до почти 500 килобайт за последний год.

Дрю: Вау.

Джереми: Итак, когда я говорю об ответственном использовании JavaScript, это прежде всего подход пользователя, чтобы сказать… критически оценить то, что мы создаем, и цель того, что мы создаем, обслуживается современными методами веб-разработки, поэтому говорить. И я предполагаю, что это своего рода… может быть, не ирония, но я не критикую современную веб-разработку, но одним из побочных продуктов современной веб-разработки является то, что очень легко добавлять зависимости к проектам. Все это установка MPM, и каждая установка MPM имеет свою стоимость, которая варьируется. Но что мы действительно видим, так это то, что в этих данных HTTP-архива 95-й процентиль… что означает 5% процессов, которые являются самыми медленными… или не самыми медленными, но которые предоставляют больше всего JavaScript, которые выросли за последний год примерно на 875 килобайт примерно до 1,4 мегабайта.

Дрю: Вау.

Джереми: Таким образом, передается огромное количество JavaScript, и это влияет как на производительность загрузки, так и на производительность во время выполнения.

Дрю: Итак, вы упомянули производительность. С моей точки зрения, современный веб-интерфейс состоит из 10% HTML и CSS и 90% JavaScript. И для этого должны быть какие-то соображения производительности. Я имею в виду, вы говорили о каком-то объеме данных, которые мы передаем, но есть и другие соображения по поводу производительности, связанные с наличием большого количества JavaScript.

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

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

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

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

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

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

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

Джереми: И идея этой статьи заключается в том, что если мы сможем сосредоточиться на 90-м или 95-м процентиле, который мы… и улучшим этот опыт для этих людей, мы создадим более быструю сеть для всех, в том числе для тех, кто работает на быстрых устройствах. И атакуйте точку данных в США, и это просто из statcounter.com. Что-то вроде 28 точек… около 28% людей используют устройства iOS, которые захватывает этот инструмент. И около 21% из них — Android. И Android, как правило, представляет собой значительную часть этого длинного хвоста устройств, потому что Android не является монолитным. Многие производители устройств производят телефоны Android, но для сравнения с миром, потому что мир — это больше, чем просто Соединенные Штаты, около 16% людей используют iOS и около 41% людей используют Android. Так что действительно выгодно расставлять приоритеты для более медленных или потенциально более медленных процессов.

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

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

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

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

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

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

Дрю: Итак, мы пишем JavaScript для всего спектра устройств, начиная с новейшего процессора Apple M1 Max, не так ли? От ноутбуков до устройств, у которых едва хватает оперативной памяти для отображения веб-страницы. Но веб начинался не так, младшим слушателям может быть интересно узнать, что раньше мы создавали интерактивные веб-интерфейсы вообще без JavaScript. Наш большой, тяжелый каркас нас погубит.

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

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

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

Джереми: На этот вопрос сложно ответить. Одним из аспектов этого является то, что сам фреймворк представляет собой объем кода, который вы никогда не сможете оптимизировать. Так что наличие такой тонкой структуры, как предварительное действие или любое количество подобных… Или, например, заклинаний, это очень помогает. Но проблема, которую я заметил, и я думаю, что данные из HTTP-архива как бы подтверждают эту точку зрения, заключается в том, что каждый раз, когда у нас появляются эти достижения в микропроцессорах и ускоряются сети, мы склонны потреблять этот выигрыш, верно?

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

Дрю: В книге вы говорите о веб-сайтах и ​​веб-приложениях и о том, как понимание различий и того, с каким из них вы работаете, помогает вам выбрать стратегию разработки и оптимизации. Расскажите нам немного об этом.

Джереми: Это действительно хороший вопрос. И я пишу об этом в статье с одноименным названием, которую я написал для A List Apart под названием Responsible JavaScript Part One, которая является своего рода прелюдией к этой книге. Разве что мы как бы много нагружаем этой терминологией. Как технический писатель, я вижу, что они взаимозаменяемы. Что я вижу, так это то, что с веб-сайтами подразумевается, что это что-то вроде многовекового опыта, верно? Это сборник документов. Теперь документ… эти документы могут иметь встроенную функциональность, такую ​​как эти маленькие островки, как это недавно называлось, эти маленькие островки функциональности, которые позволяют людям добиваться цели.

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

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

Джереми: Это сложный вопрос. Так-

Дрю: Мне было трудно сказать.

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

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

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

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

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

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

Дрю: Это как бы возвращает нас к тем дням, когда мы встраивали остров Флэша или…

Джереми: Да.

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

Джереми: Да, как и Flash, Боже мой, три версии моего личного портфолио после колледжа были действительно паршивыми для продвинутых подделок Flash и подобных эффектов наведения. И это было очень, очень весело. И я иногда скучаю по этому, потому что есть огромное количество контента, который просто исчезнет, ​​потому что мы больше не используем Flash. И это действительно отстой, но в каком-то смысле это был своего рода предшественник островов, о которых мы говорим. То есть вы могли бы просто иметь статическую веб-страницу и все такое, но тогда у вас был бы этот действительно богатый интерактивный опыт, просто как бы плюхнувшийся прямо в его середину.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

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

Джереми: А недавно я обновлял блог. То есть… Я большой поклонник Final Fantasy, как и Final Fantasy II, которую я только что переиграл, и так, их около 15, и 16 когда-нибудь выйдут, но это своего рода ретро-сфера. Поэтому я использовал API рисования CSS для создания случайного мира с использованием разных плиток. Так что есть реки и прочее, что течет по ним, травяные плитки, деревья и тому подобное. И параметризуя это так, например, если пользователь посещает мой веб-сайт в темном режиме… эта работа по рисованию будет отображаться так, как будто это ночь. Это будет просто своего рода наложение на него и тому подобное.

Джереми: Но API рисования потрясающий. Я должен отдать должное Тиму Холману. Он, я видел его на JSConf Australia, и он говорил о генеративном искусстве. Это было действительно просто, это действительно меня заинтересовало. А затем Сэм Ричард, выступая накануне на CSSConf, говорил об API рисования CSS, когда эти две вещи сошлись для меня, я подумал: «Вау, это так круто». И поэтому я действительно сделал вещь под названием Paintlets! Это Paintlets.Herokuapp.com, если вы посещаете Chrome, и вам, к сожалению, придется, потому что он еще не очень хорошо поддерживается. Вы можете увидеть кучу разных случайных рисунков, случайно сгенерированных рисунков и… да, я просто… это то, чем я был занят, извините. Долгая история об этом.

Дрю: Удивительно. Звучит здорово.

Джереми: Да. Да.

Дрю: Если вы, дорогой слушатель, хотели бы услышать больше от Джереми, вы можете найти его в Твиттере, где он @malchata, и найти его письменные презентации, видео и проекты на его личном веб-сайте, jeremy.codes. Ответственный JavaScript теперь доступен от A Книга Апарт. И вы можете найти больше информации об этом на ответственном js.dev. Спасибо, что присоединился ко мне сегодня, Джереми, у тебя есть напутствие?

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