Smashing Podcast Episode 32: Обзор года 2020

В этом выпуске мы оглядываемся на 2020 год. С кем мы разговаривали в наших выпусках в этом году и чему мы научились? Давайте послушаем несколько клипов, чтобы узнать.

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

Вы можете найти все наши прошлые выпуски, включая полную стенограмму каждого интервью, на podcast.smashingmagazine.com.

До встречи в 2021 году, все!

Стенограмма

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

Эми Хьюп: Мы начали очень рано. Так что задолго до того, как у нас появилась своего рода публичная система дизайна, мы начали взаимодействовать с людьми, которые, как мы думали, будут заинтересованы в содействии. Здесь я должен упомянуть, что у нас в команде был блестящий сервис-дизайнер. Она присоединилась к нам… Сейчас я не могу точно определить даты, но я думаю, что она работала с нами в течение всего 2018 года, и ее зовут Игнасия. Она просто проделала фантастическую работу по обходу и привлечению людей. Так что одна из вещей, которые она сделала, заключалась в том, чтобы пойти и определить все различные модели в правительстве и все различные виды вариаций этих моделей. Итак, выходя и как бы говоря: «Хорошо. Есть 10 различных способов попросить адрес в правительстве. Давайте посмотрим на них все вместе и решим, какой подход, по нашему мнению, является наиболее подходящим. Как мы можем объединить их в одно?»

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

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

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

Дрю: К нам присоединились Стефани Стимак из Microsoft и Аарон Густафсон, чтобы поговорить о том, что Edge использует Chromium в качестве механизма рендеринга. Я спросил Аарона о конкурентной среде между браузерами и о том, где несколько браузеров, объединяющихся на одном и том же движке рендеринга, уничтожат эту здоровую конкуренцию и, следовательно, навредят открытому Интернету.

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

Аарон Густафсон: Но я думаю, что сейчас что-то изменилось, так это то, что во время первоначальных войн браузеров у вас были все эти проприетарные движки, и все были как бы в игре на превосходство с точки зрения попыток внедрить новые функции платформы и новых функций JavaScript или, в случае Microsoft, обратного проектирования JavaScript, чтобы создать JScript и попытаться выяснить, как совместить все это вместе.

Аарон Густафсон: Но теперь у нас есть возможность работать вместе над проектами с открытым исходным кодом, вести диалог и все же… не знаю. Бороться — не то слово, но вести серьезные дискуссии о влиянии различных подходов и не соглашаться друг с другом, и действительно работать над тем, чтобы сделать спецификации действительно хорошими, а также иметь конкурирующие подходы к базовому коду в контексте, скажем, Chromium. project или WebKit или что-то в этом роде или Missoula в пространстве Firefox.

Аарон Густафсон: Так что да. С одной стороны, мы потеряли еще один движок рендеринга, и я почувствовал ту же боль, когда Opera решила перейти на Chromium. Но я чувствую себя несколько воодушевленным, находясь внутри Microsoft и видя, насколько мы привержены реальному участию в проекте Chromium осмысленным образом, а не просто сидеть сложа руки и просто принимать все, что идет дальше по течению от Chromium, но на самом деле как бы проверять, что происходит. платформу и участвовать в этом… Да.

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

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

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

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

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

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

Эдуардо Букас: Точно. Да. То, как это могло бы… Я вижу два разных способа использования инструмента, который может помочь разработчикам. Один из них — сделать Sourcebit частью вашей процедуры развертывания. Итак, если вы используете хостинговую платформу, такую ​​как Netlify, например, и вы настраиваете свои команды развертывания, я не знаю, Hugo build, это команда сборки для Hugo или что-то вроде команды, которая генерирует статические файлы для Hugo. У вас также будет другая команда как часть этой процедуры. Это было бы что-то вроде выборки Sourcebit. Таким образом, во время сборки Sourcebit извлечет все остальные данные, сгенерирует все файлы, которые нужны Hugo, а затем все развертывание уже будет использовать эти файлы и развертывать весь контент, поступающий из CMS.

Эдуардо Букас: Это один из возможных вариантов использования Sourcebit. Другой — использовать Sourcebit в качестве локальной разработки в рабочем процессе локальной разработки. Таким образом, вы можете запустить Sourcebit с тем, что мы называем режимом просмотра. Таким образом, Sourcebit продолжает искать изменения в удаленном источнике данных, в данном случае в безголовой CMS. Поэтому всякий раз, когда вы публикуете статью или изменяете запись в CMS, Sourcebit подтвердит это и восстановит все файлы для вас локально.

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

Дрю: Оптимизация конверсии была темой дня. Когда я разговаривал с опытным подкастером и консультантом Полом Боугом. Мы говорили о некоторых методах, которые используют сайты для преобразования посетителей в клиентов. Но я хотел спросить Пола, как вы измеряете влияние изменений, которые вы вносите. Пол объяснил.

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

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

Пол Боаг: Существует множество механизмов, которые вы можете использовать для измерения этих разных вещей. Есть несколько отличных инструментов, а также несколько хороших показателей, которые вы можете использовать. Так, например, в отношении юзабилити существует нечто, называемое шкалой юзабилити системы, которая может быть очень полезной метрикой для измерения. Но в равной степени есть такие инструменты, как maze.design, который я часто использую, который измеряет, сколько времени требуется человеку, чтобы совершить покупку, например, пройти через кассу. Так что да. Имея такой широкий набор показателей, вы не просто сосредотачиваетесь на том, сколько продаж мы сделали в этом квартале? Вы должны смотреть на более широкую картину.

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

Лаура Калбаг: У меня есть классический пример, который произошел со мной несколько лет назад. Итак, я был на Facebook, и моя мама только что умерла, и я получал объявления о распорядителях похорон. Я подумал, что это было действительно странно, потому что никто из моей семьи ничего не сказал в социальных сетях в тот момент. Никто из моей семьи ничего не сказал на Facebook, потому что мы договорились, что никто не хочет узнавать подобные вещи о друге или члене семьи через Facebook. Так мы и не говорили об этом.

Лаура Калбаг: Я спросила своих братьев и сестер: «О, кто-нибудь из них сказал что-нибудь на Facebook, что могло бы вызвать это странное?» Потому что я обычно просто получаю рекламу косметики, платьев, тестов на беременность и всех тех забавных вещей, о которых они любят говорить. Это женщины определенного возраста. Вместо этого моя сестра вернулась ко мне. Она сказала: «Ну да. Мой друг живет в Австралии». Поэтому я отправил ей сообщение в Facebook Messenger и сказал, что наша мама умерла. Конечно, Facebook знал, что мы сестры. У него есть эта связь отношений, которую вы можете добавить туда. Я имею в виду, что он, вероятно, мог догадаться, что мы сестры, по местам, где мы были вместе, по тому факту, что у нас одна фамилия, и решил: «О, это подходящая реклама, чтобы поставить ей ноги».

Дрю: Это отрезвляет, не правда ли, думать, что технологии принимают эти решения за нас, что на самом деле потенциально влияет на людей в этом примере довольно чувствительное или уязвимое время?

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

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

Рэйчел Ан Дрю: Очень, очень быстро, как только мы поняли, что нам придется отложить Сан-Франциско, очевидно, у нас есть семинары, и я, и Виталий проводим семинары в smash and comp, и они были распроданы в Сан-Франциско, оба из наши мастерские. Очевидно, что у нас есть много других людей, которые приходят и проводят семинары для нас, людей, с которыми мы работаем долгое время, и они обнаружили, что все их семинары, а те из нас, которые проводят семинары, на самом деле ключевая часть нашего дохода.

Рэйчел Ан Дрю: Выступая публично, вы не заработаете много денег, обычно выступая публично. Большинству людей не платят много, если учесть, сколько времени уходит на написание докладов и так далее. Семинары, как правило, являются хорошим способом заработать немного денег для людей, которые хорошо обучают этому материалу. Таким образом, они представляют собой доход людей. Так что не только я нуждался, но и Виталий потерял наши мастерские в начале этого года. Мы также поняли, что многие наши колонки Smashing также зависели от этих семинаров.

Рэйчел Ан Дрю: Итак, мы подумали: «Ну, а почему бы просто не выложить их онлайн?» Очень, очень быстро, буквально в течение нескольких дней после того, как это произошло, мы решили, что мы с Виталием будем первыми, кто поднимет голову над властью, но, учитывая, что это мы, мы могли бы придумать, как это сделать. У нас также есть очень разные мастерские. Виталий гораздо более склонен к сотрудничеству. У него групповые занятия и прочее. Я преподаю классный стиль. Итак, между нами, мы подумали: «Ну, мы как бы охватываем все основы». Поэтому мы подумали: «Давайте просто сделаем это. Посмотрим, сработает ли это». Поэтому мы их рекламируем. Мы как бы выяснили, сколько времени занял каждый, а затем как бы сели и сказали: «Ну, а как на самом деле выглядит онлайн-семинар? Что это?"

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

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

Дрю: Когда наступила усталость от Zoom и мир начал приспосабливаться к тому, что быстро называлось новой нормой, я поговорил с Филом Смитом о том, как технологии могут помочь нам реагировать на такие ситуации, как COVID-19. Создание приложения React Native CardMedic всего за 10 дней. Я спросил Фила, как он находит баланс между выбором лучшей технологии для работы и технологиями, с которыми он знаком и с которыми может работать быстро.

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

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

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

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

Бен Фрейн: Я думаю, особенно если вы работаете в компании, которая производит приличные офисные стулья, вы просто принимаете их как должное, и только когда вы смотрите на эту конкретную марку и марку, вы думаете: «Боже мой, это стул за 700 долларов». Когда вы понимаете, что черт возьми, люди думали об этом и многое сделали для вас, а затем, очевидно, вы приходите в свою домашнюю обстановку и думаете: «Почему бы не потратить X сотен долларов на стул?» Но, возможно, оно того стоит. Особенно, если вы здесь надолго.

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

Энджи Байрон: Я думаю, есть три основных сценария. Например, если вы используете Drupal 8, и каждый раз, когда выходит новый второстепенный выпуск Drupal 8, вы сразу же обновляете его до релиза и начинаете использовать новые возможности. Ваш путь будет в основном пустым. Вы уже сделали всю работу, и вы в порядке. Если вы недавно перешли на Drupal 8 и не следите за изменениями BC, у вас есть немного работы.

Энджи Байрон: В любом случае, это определенно самое простое обновление нашего программного обеспечения за более чем десятилетие, и у нас есть масса различных инструментов, которые помогут вам в этом. Есть панель инструментов, которая показывает все добавленные модули и их ситуацию с Drupal 9. Существуют автоматизированные инструменты для просмотра и проверки вашего кода и пометки любых устаревших функций, которые у вас есть, и есть инструменты для автоматического просмотра и поиска: «О, это последняя версия вашего модуля, и она готова для Drupal 9? Вы должны скачать его», и все в таком духе.

Энджи Байрон: Итак, начиная с Drupal 8 и заканчивая 9, я бы сказала, что эта часть довольно хорошо освещена. Если вы переходите с предыдущей версии Drupal, скажем, с Drupal 7 или ниже на Drupal 9, это начинает выглядеть немного сложнее. Среди изменений, которые мы сделали в Drupal 8, где, например, мы полностью перешли на объектно-ориентированный PHP и начали использовать шаблоны проектирования, которые были найдены в других программных проектах, что действительно разумно с архитектурной точки зрения, но это не так. Это означает, что если в вашей старой жизни у вас была тонна пользовательского кода, то в Drupal 9 вам нужно будет найти для него альтернативу.

Энджи Байрон: Итак, Acquia — это продукт и разработка под названием Acquia Migration Accelerator, который направлен на решение этой проблемы, когда мы создаем хорошее приложение, определяемое React, которое считывает ваши старые данные Drupal 7 и создает для вас эквивалентные данные Drupal 8. вместе со всеми модулями, которые вам понадобятся, которые сопоставляются с вашими старыми модулями Drupal 7, где это возможно, чтобы попытаться немного ускорить этот процесс, потому что мы хотим убедиться, что все, кто работает на более старых версиях, все еще могут переходить на новый мировой порядок, где все используют одну и ту же версию, и мы все работаем вместе.

Энджи Байрон: Кроме того, мы также расширили Drupal 7… Сообщество открытого исходного кода Drupal, конец их жизни в Drupal 7 в ноябре следующего года. В любом случае, сейчас нам нужно обсудить, повлияет ли COVID на это или нет. Но есть несколько разных компаний, и Acquia — одна из них, которая предлагает расширенную поддержку Drupal 7 после этого, по крайней мере, до 2024 года. Таким образом, у людей, у которых есть легкое обновление, есть полтора года, чтобы сделать это, у людей, у которых есть менее простое обновление, потенциально есть три с половиной года, чтобы сделать это, или больше, если им нужно, и мы очень стараемся сделать так, чтобы каждый мог перейти, а затем разрабатываем такие инструменты, как Acquia Migrate Accelerator, чтобы ускорить этот процесс.

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

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

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

Дрю: Я говорил с Энди Беллом о CUBE CSS, методологии стилизации наподобие BEM, SMACSS и OOCSS. Многие подходы к CSS пытаются работать против естественных свойств CSS, таких как каскадность. CUBE очень поддерживает такое поведение. Вот Энди.

Энди Белл: Хорошая аналогия: SCSS, как и Sass, является расширением естественного языка CSS, не так ли? Вы все еще правы в CSS. Итак, CUBE CSS такой. Итак, это расширение CSS. Так что мы все равно должны писать CSS, как и должен CSS… ну, он должен быть написан. Давайте будем честными, так и должно быть написано. Название говорит само за себя — каскадные таблицы стилей. Так что это снова охватывает это, потому что я обнаружил, что я прошел весь путь до уровня микрооптимизации. Я был на пути, по которому я вижу много людей, которые в последнее время идут вниз, где… Я также упомянул об этом в статье, где я вижу… Недавно появились некоторые свидетельства этого. Я заметил, что люди создают компоненты-распорки и тому подобное, и я понимаю эту проблему. Я был в такой ситуации.

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

Энди Белл: Теперь у нас есть такие вещи, как Grid и Flexbox, которые делают это гораздо более достижимым, и вы можете, по сути, поместить все, что хотите, внутрь макета скелета. Это не имеет значения. Затем компоненты должны вести себя так, как вы хотите, с контейнерными запросами или без них.

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

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

Марси Саттон: Помимо этого, многое зависит от того, что вы используете на своем сайте, что в конечном итоге окажется в этом пакете JavaScript. Но для вещей, которые используют много интерактивности, таких как доступные интерфейсы, это хорошее место. Что касается меня, мне действительно нравится, что JavaScript всегда доступен для меня, и моя разметка просто находится в хорошем месте. Я знаю, что это вопрос предпочтений, хотите ли вы, чтобы ваш HTML, ваш JavaScript и ваш CSS были аккуратно связаны, и есть место для вариаций в построении Гэтсби. Вам не всегда нужно использовать что-то вроде CSS и JS. Но на самом деле речь идет о том, чтобы предоставить вам всю мощь этого динамического слоя JavaScript, пока вы пишете свой веб-сайт. Не нравится это дополнение в отдельном файле.

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

Марси Саттон: Это да. Гэтсби будет использовать Node.js во время сборки, он будет проходить через ваши компоненты React и компилировать их в HTML-файлы, что, честно говоря, когда я впервые посмотрел на Гэтсби, я бы не стал отключать JavaScript и подумал: «Хорошо, здесь есть другие страницы? Что это?" Я был так счастлив, что Гэтсби работает так по умолчанию. Он создаст встроенные файлы из ваших компонентов React, и это здорово.

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

Марси Саттон: Таким образом, они решили создавать сайты таким образом, и мы всегда оцениваем, лучший ли это способ? Что нам нужно сделать, чтобы дать нашим пользователям то, что они просят? Таким образом, мы проводим некоторые внутренние исследования, продолжающиеся просто для того, чтобы убедиться, что Gatsby делает лучшую работу, которую он может сделать при создании веб-сайта, поэтому сохраняем небольшие размеры пакетов и следим за тем, чтобы компромиссы для того, что мы называем производительным кодом с предварительным - fetching, у нас есть данные, подтверждающие это? Это то, что меня как защитника разработчиков очень интересует: убедиться, что то, что мы упаковываем и объединяем на веб-сайтах, действительно необходимо и действительно сделает лучший сайт Gatsby, который он может сделать.

Дрю: Разговаривая с Крисом Фердинанди в июле, я спросил, вредны ли современные передовые методы для Интернета. Крис поддерживает движение, известное как Lean Web, и я спросил его, что это влечет за собой. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. Я пришел к выводу, что многое из того, что сегодня мы считаем лучшими практиками, на самом деле может сделать сеть хуже. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. Но на самом деле, Lean Web заключается в том, чтобы сосредоточиться на простоте и производительности для пользователя и действительно расставить приоритеты или сосредоточить внимание на людях, которые используют то, что мы делаем, а не на нас, людях, которые это делают.

Drew: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Но вы также можете выбрать языки препроцессора. Допустим, вам нравится Sass. Вы включаете Sass в CSS и пишете Sass. Ну, что-то должно обрабатывать Sass. В наши дни Sass написан на Dart или что-то в этом роде. Theoretically, you could do that in the client. Но эти библиотеки, выполняющие предварительную обработку, довольно велики. Я не думаю, что хочу отправлять вам всю библиотеку Sass только для того, чтобы запустить эту штуку. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Но вот как это работает сейчас, есть ли лямбда. Он обрабатывает Sass. У него есть одна крошечная, крошечная, крошечная, маленькая работа. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Вам не нужно беспокоиться о масштабе. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Но есть один для Сасса. Есть один для Меньше. Есть один для Баббеля. Есть один для TypeScript. Есть один для… Все это отдельные лямбда-выражения, которые мы запускаем. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Но мы используем его для гораздо большего, даже в последнее время.

Chris Coyier: Here's an example. У каждого пера на CodePen есть скриншот. Это круто, да? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Если вы поделитесь им в Slack, вы получите небольшой предварительный просмотр. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Это все равно не анимация. Просто прирост производительности такой.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. Это рабочий. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Служи ему как этим измерениям». Мне не нужно делать изображение в этих размерах. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Они становятся точками входа в ваше приложение, которыми вы можете поделиться через все виды носителей.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js также, что очень и очень приятно, автоматически предварительно выбирает остальные страницы, которые подключены к этой точке входа, так что это похоже на одностраничное приложение. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Так что в первую очередь была мотивация к изменению реактивности. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Но ладно. Мы вас все равно научим.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. Это был TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Наталья Теплухина: Так что это опять была огромная часть. Последним было то, что мы как бы упустили функциональность для абстрактной логики с точки зрения не компонентов, а составных частей логики, таких как вспомогательные функции и т. д., но они также должны иметь возможность включать активность Vue. Хорошим примером здесь могут быть React Hooks, верно? Они позволяют абстрагировать части функциональности, чего явно не хватало во Vue. Я знаю, что сейчас это звучит как «Вы украли функцию у React». На самом деле нет. Я считаю, что перекрестное опыление идей — большая и приятная часть нашей экосистемы, а также помогает разработчикам переключаться между фаворитами, верно? Поэтому мы работали над этими основными функциями, чтобы создать основную версию Vue 3.

Дрю: После этого мы погрузились в TypeScript со Стефаном Баумгартнером, чтобы выяснить, как он может помочь нам писать более качественный код с меньшим количеством ошибок. Наблюдая за тенденцией организаций полностью переводить свой код на JavaScript, я спросил Стефана, является ли TypeScript тем, от чего больше выигрывают большие команды, чем отдельные люди.

Штефан Баумгартнер: Сейчас я нахожусь в том же переходном состоянии. Так что у нас есть много разработчиков Java и C++, которые в будущем собираются написать много JavaScript. TypeScript может быть своего рода руководством по тем страшным областям нового языка программирования. У JavaScript много причуд, богатая история и множество предубеждений, если вы пришли из другого языка программирования. Таким образом, TypeScript может быть руководством, поскольку в системе типов есть некоторые понятия, с которыми вы знакомы.

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

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

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

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

Дэвид Дарнс: Что касается меня, то я сразу перешел к нунджаку, потому что нунджак — это язык шаблонов по умолчанию внутри Eleventy. Это означает, что я могу использовать расширение dot HTML и оставить его как есть. Теперь я просто еще больше запутаю людей и скажу: «Вы все равно можете называть это как хотите. С ним можно по-настоящему повеселиться». Но можно использовать руль. Я думаю, вы можете просто использовать обычные шаблоны JavaScript и повторять их таким образом. Рули достаточно популярны и у Liquid тоже. Я не могу думать обо всех из них сразу, но если вы настроите все это в конфигурации, вы можете просто выбрать то, что хотите.

Дэвид Дарнс: Я бы сказал, что я большой поклонник языков шаблонов в целом. Это было не так давно, когда я узнал, что вы можете использовать twig внутри WordPress, и это поразило меня. Я подумал: «О, слава богу. Мне не нужно обрабатывать цикл for внутри PHP». Опять же, я думаю, что-то немного более удобное и понятное, а также более читаемое. Так что да. У Eleventy есть множество различных вариантов шаблонов, и он должен понравиться людям, которым удобно пользоваться этими разными вариантами.

Дрю: Я говорил с Лесли Кон-Вейн о том, как Netlify использует свою собственную платформу для создания Netlify и как их функциональность Deploy Preview становится эффективной промежуточной платформой для внесения изменений во внешний интерфейс.

Лесли Кон-Вейн: Возможно, мне больше всего нравится во всем этом процессе волшебство Deploy Previews, которое мы получаем через Netlify. Итак, вы работаете в GitHub, продвигаете свой PR. Итак, вы открываете свой PR в GitHub, и это автоматически создает сборку вашего приложения Deploy Preview. Таким образом, мы фактически используем Deploy Previews самого приложения для тестирования, чтобы убедиться, что все работает так, как должно. Мы запускаем наши тесты. Это то, что мы используем для ручной проверки во время проверки кода. Таким образом, у нас есть все это непрерывное развертывание, настроенное прямо из GitHub.

Лесли Кон-Вейн: Еще одна интересная вещь, которую мы настроили, — это то, что у нас есть пара разных сайтов Netlify, которые загружаются из одного и того же репозитория, где находится наше приложение. Итак, у нас есть оба приложения. У нас есть экземпляр Storybook, в котором есть что-то вроде наших компонентов пользовательского интерфейса для приложения. Итак, у нас есть как само наше приложение. У нас есть компоненты пользовательского интерфейса Storybook, и у нас есть в основном сайт Netlify, который показывает наш пользовательский интерфейс Storybook, а затем у нас также есть третий сайт, на котором работает анализатор пакетов веб-пакетов. Таким образом, это своего рода визуальный пользовательский интерфейс, который дает вам древовидную визуализацию всех пакетов приложений, и мы можем как бы оценить их размер, и это просто напоминание для нас о том, чтобы перепроверять что-то вроде каждого развертывания приложения. out, мы можем проверить и убедиться, что мы не делаем ничего странного с нашим размером пакета.

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

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

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

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

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

Крис Мерфи: Он провалился сквозь трещины, и есть много других людей, которые провалились сквозь трещины. Я бы сказал, что это проблема дизайна, и мы должны смотреть на это как на проблему дизайна. Но если я также рассмотрю этот более широкий вопрос о COVID, правительстве и всех этих вещах, не вдаваясь в политику, я вчера прочитал статью в Guardian о соседе Мэтта Хэнкока, и о любом, кто слушает, кто не из Великобритании, Мэтт Хэнкок министр здравоохранения. Его сосед, который занимался бизнесом, писал ему и спрашивал совета: «Как мне поставлять продукты для этой штуки с COVID?» Ужасно много слухов вокруг хумократии, как ее называют в газетах, друзей друзей министров правительства, которые, кажется, получают работу, потому что знают нужных людей.

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

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

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

Ева Порселло: Теперь, что касается бэкенда, это действительно собственная часть, потому что мы можем собирать много данных из множества разных источников. Итак, у нас есть данные в REST API и базах данных и во всех этих разных местах, и GraphQL предоставляет нам этот приятный маленький уровень оркестровки, чтобы действительно разобраться в хаосе, где находятся все наши данные. Так что это действительно полезно для всех во всем стеке.