Приветствую всех в третьей и последней части этой серии, посвященной выходу из строя oldIE и изменениям, произошедшим в этом событии в области фронт-энда. До сих пор мы рассматривали устаревшие методы, которые можно безопасно отбрасывать, и свойства HTML5 и CSS3, которые теперь имеют полную встроенную поддержку в основных браузерах . Сегодня мы сконцентрируемся на нативных методах JavaScript и всем остальном, что не вписывается в категории, упомянутые ранее.
Еще раз, большая заслуга в CanIUse.com, который оказался бесценным ресурсом. Я также повторю свой отказ от ответственности в прошлый раз:
Эта статья не имеет ничего общего с решением отказаться от поддержки oldIE . Вы и только вы должны принять это решение на основе конкретных деталей вашего веб-сайта или приложения.
С учетом всего сказанного, давайте продолжим!
1. JavaScript API
В этом разделе мы пройдем довольно широкий список функций JavaScript, API и функциональных возможностей. Что у них общего? Ни один из них не может быть реально использован на oldIE , требуя либо использования различных полифилов, либо их эффект должен быть достигнут с помощью различных других сред и библиотек (если это вообще возможно). В текущем контексте (IE11 + Edge) они имеют встроенную поддержку, встроенную в браузер, что означает, что они могут использоваться прямо из коробки.
Кодирование и декодирование Base64 (btoa и atob)
Base64 — очень полезный инструмент для веба. Многие из вас уже использовали это, вероятно, для встраивания шрифтов или изображений в CSS. Другое распространенное использование — обработка различных ресурсов, которые обычно мешали бы транспортным протоколам. Прекрасным примером этого является базовая аутентификация доступа, где пара username:password
Наличие встроенной поддержки операций кодирования / декодирования означает, что их можно выполнять намного быстрее. Вот несколько ресурсов для начала:
Создание блобов
Большой двоичный объект или большой двоичный объект — это набор необработанных данных, хранящихся в виде единого объекта в системе управления базами данных. Это может быть аудиоклип или изображение, сохраненное в формате Base64. Или коллекция изображений. Во многих случаях поля BLOB-объектов используются для данных, которые не так жестко структурированы, как их можно выразить через обычную таблицу или схему таблиц, например, объект JSON. Некоторые из вас могут вспомнить предка интерфейса Blob, а именно BlobBuilder
Этот подход, однако, не рекомендуется, и настоятельно рекомендуется, чтобы все манипуляции с BLOB-объектами осуществлялись через новый интерфейс.
Кроме того, поскольку эта коллекция очень похожа на файл, собственный интерфейс для объектов Blob был использован в качестве основы для интерфейса File()
В результате есть одна приятная функция, называемая «Blob URLs», которая позволяет разработчикам создавать URL для объектов BLOB, которые могут использоваться везде, где может использоваться файл. Учитывая это, очень важно, что встроенная поддержка теперь распространяется на все основные браузеры.
Канал обмена сообщениями
Обычно двум сценариям, работающим в разных контекстах браузера, запрещено обмениваться данными друг с другом, чтобы избежать многих ошибок безопасности. Однако бывают случаи, когда такое общение не только желательно, но и действительно необходимо. Именно здесь вступает в игру API обмена сообщениями. Этот интерфейс позволяет нашим двум сценариям взаимодействовать друг с другом по двустороннему каналу. Это похоже на передачу каждой рации на одном канале. Аккуратно, не правда ли?
Константы и переменные уровня блока
const
let
В то время как var
Это означает, что переменные, созданные с помощью const
let
В то время как let
const
Он не может быть переназначен, он не может быть переопределен и не может иметь то же имя, что и любая другая переменная или функция в той же области видимости. Единственное исключение — когда константа является объектом со своими собственными атрибутами. Эти атрибуты не защищены от изменений и ведут себя как обычные переменные.
При этом взгляните на правильный способ использования констант и переменных уровня блока в вашем коде:
- Константы по МДН
- Давай на мдн
- Подготовка к ECMAScript 6: пусть и const на SitePoint
- ES6 пусть VS константные переменные по Wes Bos
Ведение журнала консоли
Большинство разработчиков интерфейсов согласны с тем, что веб-консоль — это один из наиболее полезных инструментов, который может быть под рукой, когда ваши скрипты не ведут себя должным образом. Однако Internet Explorer по своей природе довольно медленно интегрировал его в свой код, и только версия 10 начала обеспечивать полную поддержку. Теперь, когда oldIE ушел в отставку, ничто не мешает нам максимально использовать эту функцию. И если вам нужно обновить свои знания или даже открыть для себя новые способы использования консоли, взгляните на спецификации ниже:
Обмен ресурсами между источниками
Обмен ресурсами между источниками (CORS) — это API-интерфейс HTML5, который позволяет запрашивать ресурсы за пределами своего собственного домена. Он описывает набор заголовков HTTP, которые позволяют браузерам и серверам запрашивать удаленные ресурсы при предоставлении определенного разрешения. Следующие ресурсы являются хорошей отправной точкой для изучения правильного использования этой функции:
- Управление доступом DOM с использованием совместного использования ресурсов из разных источников в Dev.Opera
- Контроль доступа HTTP (CORS) на MDN
- Углубленный взгляд на CORS на SitePoint
API веб-криптографии
Сегодня безопасность и конфиденциальность являются двумя наиболее востребованными функциями любого приложения, что означает, что хорошая (и быстрая) криптография действительно ценится. Теперь все основные браузеры имеют согласованную поддержку API веб-криптографии, за исключением IE11 (который реализует старую версию спецификации) и Safari (для которого требуется префикс crypto.webkitSubtle
К счастью, некоторые специфические функции (например, генерация случайных значений) реализованы лучше. В результате стало проще, чем когда-либо, реализовать элементы криптографии с встроенной поддержкой. Вот несколько рекомендаций о том, как сделать это правильно:
- Криптообъект на MDN
- getRandomValues на MDN
- Оболочка API веб-криптографии для старых браузеров на GitHub
интернационализация
В настоящее время повсеместный доступ к Интернету означает, что посетители ваших веб-сайтов могут приезжать со всего мира. Поскольку люди больше доверяют вещам, знакомым им, хорошей практикой является представление всей вашей информации как на их языке, так и в том формате, к которому они привыкли. Вот где вам нужны интернационализация (также известная как i18n
локализация (или L10n
Это звучит как бред? Давайте процитируем Аурелио Де Роса из его статьи « Как реализовать интернационализацию (i18n) в JavaScript» :
Интернационализация (также известная как i18n) — это процесс создания или преобразования продуктов и услуг, чтобы их можно было легко адаптировать к конкретным местным языкам и культурам. Локализация (также известная как L10n) — это процесс адаптации интернационализированного программного обеспечения для конкретного региона или языка. Другими словами, интернационализация — это процесс адаптации вашего программного обеспечения для поддержки нескольких культур (формат валюты, формат даты и т. Д.), А локализация — это процесс внедрения одной или нескольких культур.
Поддержка браузеров немного лучше, чем в начале года, когда Safari v10 вступил в строй в сентябре. Звучит достаточно интересно? Вот несколько ресурсов, которые помогут вам выбрать правильный путь:
- Интернационализация API на MDN
- API Интернационализации JavaScript — простое введение
- Как реализовать интернационализацию (i18n) в JavaScript
Обработка медиа-запросов
Адаптивный веб-дизайн является текущим стандартом для эффективных веб-сайтов, и ключевой особенностью, которая делает это возможным, является наличие медиа-запросов. matchmedia
Хорошим примером может служить переход с портретного на альбомный режим и обратно для мобильных телефонов и планшетов. Хотя существует API, который обрабатывает определение ориентации устройства , поддержка является частичной для большинства браузеров, в то время как полная поддержка предоставляется только Microsoft Edge. Вот несколько ресурсов, чтобы вы начали эту тему:
- Тестирование медиазапросов на MDN
- Window.matchMedia на MDN
- Как использовать медиазапросы в JavaScript на SitePoint
Расширения медиаресурсов
Расширения Media Source Extensions (MSE) добавляют дополнительную функциональность к элементам видео и аудио без использования плагинов. Это дает вам такие вещи, как адаптивная потоковая передача мультимедиа, прямая трансляция, объединение видео и редактирование видео. YouTube использует MSE со своим проигрывателем HTML5 с сентября 2013 года. Поддержка браузеров также довольно хорошая, только в iOS Safari и Opera Mini эта функциональность отсутствует. IE11 имеет полную поддержку только при использовании в Windows 8+. К сожалению, пользователи IE11 / Win7 не могут воспользоваться этой технологией. Если вы просто любопытны или действительно хотите начать работать с этим API, вы найдете следующие ресурсы весьма полезными:
- MediaSource API на MDN
- Расширения медиаресурсов на MSDN
- HTML5 Media Source Extensions: передача производственного видео в Интернет на Smashing Magazine
Наблюдатели Мутации
Приложения JavaScript становятся все более и более сложными с каждым днем. Как разработчик, вы должны контролировать изменения, которые происходят на странице, особенно когда дерево DOM изменяется или «мутирует». Необходимость такого рода мониторинга не нова, и действительно, уже было решение — мутационные события. Проблема с этим интерфейсом заключается в том, что оба события являются синхронными (запускаются при вызове и могут препятствовать запуску других событий) и должны регистрироваться или передаваться через DOM. Это, в свою очередь, может вызывать другие события, перегружающие поток JavaScript и порождающие, в некоторых особых случаях, полные сбои каскада, приводящие к краху вашего браузера.
В результате события мутации были объявлены устаревшими и заменены наблюдателями мутаций. В чем разница, спросите вы? Первое и самое главное, наблюдатели асинхронны. Они не удерживают ваши скрипты от запуска. Вместо того, чтобы стрелять по каждой мутации, они дают пакет результатов после завершения основного действия. Более того, вы можете точно настроить наблюдателей, чтобы они наблюдали либо за всеми изменениями в узле, либо только за конкретными категориями изменений (например, только за изменениями в списке дочерних элементов или только за атрибутами и т. Д.) Начните изучать, как это сделать, используя следующие ресурсы:
Видимость страницы
Просмотр вкладок изменил способ взаимодействия с Интернетом. Многие люди нередко открывают десятки страниц одновременно. Каждая из этих страниц делает свое дело, запускает свои сценарии, загружает имеющиеся у них ресурсы и так далее. Даже если в данный момент времени может быть активна только одна вкладка, все открытые страницы потребляют процессорное время и пропускную способность. Некоторые приложения могут периодически отправлять и получать обновления через соединение. Тем не менее, если у вас нет этого приложения на активной вкладке, нужно ли обновлять каждые X секунд в фоновом режиме? Кажется расточительным, не так ли? Особенно на мобильных устройствах и тарифных планах, где каждый ресурс стоит дорого.
Именно здесь вступает в игру API видимости страницы. Этот интерфейс позволяет разработчикам узнать, находится ли их приложение на активной вкладке или в фоновом режиме. Давайте рассмотрим случай, когда приложение делает обновления, о которых я упоминал ранее. С помощью API видимости страницы вы можете определить, когда приложение находится в фоновом режиме, и вместо обновления каждые 5 или 10 секунд вы делаете это каждые 60 секунд или даже меньше. Как только страница снова станет видимой, вы сможете вернуться к нормальной скорости обновления. Довольно круто, не правда ли?
Чего же ты ждешь? Взгляните на следующие руководства и запустите свои приложения для видимости страницы. Ваши пользователи будут благодарны вам за это:
События перехода страницы
Вы когда-нибудь пользовались веб-формой, в которой при попытке отодвинуть или закрыть страницу появилось сообщение о том, что у вас есть несохраненные данные? В настоящее время это довольно часто встречается на страницах, где вы меняете настройки, детали профиля и т. Д. Как скрипты на странице узнают, что вы хотите покинуть? Они слушают событие из pagehide
pagehide
pageshow
Выше мы видели, для чего в основном используется первый. Основное использование для просмотра pageshow
Не самое распространенное использование, но, если вам нужна какая-либо функциональность, взгляните на ресурсы ниже:
requestAnimationFrame
Анимация в Интернете прошла долгий путь, от первых дней <marquee>
<blink>
Постоянной среди всех этих методов является необходимость управлять потоком анимации и сделать его максимально плавным.
Первоначальный метод использовал setInterval
setTimeout
Проблема в том, что результаты не являются надежно согласованными, а анимация часто бывает грубой. Вот почему был задуман новый интерфейс — requestAnimationFrame
Основным преимуществом этого подхода является то, что браузер имеет свободу сопоставлять запросы с собственными циклами рисования, заметно сглаживая анимацию. Вместе с аналогом cancelAnimationFrame
Как обычно, ниже приведены некоторые ресурсы, которые помогут вам освоить эту функцию.
- requestAnimationFrame на MDN
- cancelAnimationFrame на MDN
- Простые анимации с использованием requestAnimationFrame на SitePoint
- Смотреть: Производительность с requestAnimationFrame на SitePoint
Сроки API
Производительность в сети — это тема дня, и каждый старается изо всех сил сокращать ресурсы, оптимизировать сценарии и максимально эффективно использовать все имеющиеся в их распоряжении инструменты. Существует два основных подхода к этой теме: производительность сети (скорость доставки сайта и ресурсов) и производительность пользователя (скорость работы самого приложения).
Производительность сети обслуживается двумя API: Navigation Timing
Resource Timing
Оба они предоставляют всевозможную информацию, связанную с производительностью сети, такую как DNS, CDN, время запроса и ответа и т. Д. Единственное отличие состоит в том, что Navigation Timing
Resource Timing
С точки зрения производительности пользователя у нас есть один API: User Timing
Этот API имеет дело с двумя основными понятиями, которые называются Mark
Measure
Использование этих концепций позволяет разработчикам измерить скорость выполнения своего кода и определить места, которые требуют оптимизации. К сожалению, этот API все еще не поддерживается в Safari, поэтому может потребоваться полифилл.
Овладение использованием этих интерфейсов становится жизненно важным навыком в стремлении обеспечить оптимальную производительность вашего веб-сайта или приложения. Вот почему мы даем вам некоторые материалы для начала обучения:
- Время навигации
- Сроки ресурса
- Время пользователя
Типизированные массивы
Типизированные JavaScript-массивы являются объектами, подобными массивам, и предоставляют механизм доступа к необработанным двоичным данным. Для максимальной гибкости и эффективности реализация разделена на две концепции: буферы (порции необработанных данных) и представления (которые предоставляют контекст, в котором можно интерпретировать данные буфера). Существует ряд веб-API, которые используют типизированные массивы, такие как WebGL, Canvas 2D, XMLHttpRequest2, File, Media Source или Binary WebSockets. Если ваш код имеет дело с такими технологиями, вас могут заинтересовать следующие ресурсы:
WebSockets
Ранее мы говорили о Channel Messaging и о том, как он позволяет двум различным сценариям напрямую взаимодействовать друг с другом. WebSockets похож и намного больше. Использование этого API создает постоянный канал связи между браузером и веб-сервером.
Как и HTTP, протокол WebSocket имеет две версии: незащищенный ( ws://...
wss://...
Он также учитывает прокси-серверы и брандмауэры, открывая через них туннели. Фактически, соединение WebSocket начинается как обычное соединение HTTP, обеспечивая совместимость с существующей инфраструктурой.
WebSockets — это увлекательная технология (у них даже есть специальный веб-сайт), о них можно многое узнать. Чтобы начать, вот несколько избранных ресурсов:
Веб-работники
По умолчанию все задачи JavaScript выполняются в одном потоке. Это означает, что все сценарии на странице должны совместно использовать одну и ту же очередь для обработки. Это было хорошо и просто, когда у процессоров было одно ядро. Но современные процессоры имеют как минимум двухъядерные процессоры, на некоторых моделях они достигают 4, 6 или 8. Не было бы неплохо, если бы некоторые задачи можно было перенести в отдельные потоки, которые могли бы обрабатываться доступными дополнительными ядрами? Для этого и были изобретены веб-работники.
Используя API Web Workers, разработчик может делегировать именованный файл сценария работнику, работающему в отдельном потоке. Работник отвечает только на сценарий, который его создал, взаимодействуя через сообщения в обоих направлениях, может запускать вызовы XMLHttpRequest
window
В категории исключений мы можем упомянуть WebSockets
IndexedDB
Нет ничего лучше, чем иметь собственных миньонов, обрабатывающих второстепенные задачи, в то время как основной поток фокусируется на запуске всего приложения.
Чтобы начать работу с этой функцией (включая список функций и классов, доступных веб-работникам), проверьте ресурсы ниже:
- API Web Workers на MDN
- Функции и классы, доступные веб-работникам на MDN
- JavaScript Threading с веб-работниками HTML5 на SitePoint
XMLHttpRequest расширенные функции
Принятие XMLHttpRequest
Теперь можно обмениваться данными между браузером и сервером без перезагрузки всей страницы. AJAX был новым стандартом, который позволил существовать одностраничным приложениям, которые все любят сегодня.
Вполне нормально, что такая полезная технология будет развиваться еще дальше. Таким образом, XHR получил новые функциональные возможности, такие как загрузка файлов, информацию о ходе передачи или возможность прямой отправки данных формы. И все эти функциональные возможности (с небольшими исключениями в случае IE11 или старых версий Android) поддерживаются в основных браузерах после удаления oldIE .
Для более подробной информации, не стесняйтесь просматривать следующие ресурсы:
2. Разные особенности
Современный веб — это не только HTML, CSS и JavaScript. Есть много невидимых (и незамеченных) героев, трудящихся за кулисами, чтобы сделать наш онлайн-опыт как можно лучше. Ниже мы обсудим несколько таких функций, которые, как и вышеперечисленные, нельзя было использовать в старых браузерах (которые были известны своими дырами в безопасности и отсутствием поддержки современных функций).
Неблокирующая загрузка JavaScript с помощью «async» и «defer»
Каждый веб-разработчик узнает, что скрипты «блокируют загрузку» и будут держать всю страницу в заложниках, пока не завершат загрузку. Мы все помним рекомендацию загружать jQuery прямо перед </body>
Такой подход бесполезен, хотя в случае одностраничных приложений, где все поведение веб-сайта определяется JavaScript. Что возвращает нас на круги своя.
Но правда в том, что в большинстве случаев вашему веб-сайту или приложению требуется только часть загружаемого им JavaScript-кода. Остальные понадобятся в будущем, или они будут делать вещи, которые не влияют на DOM. Очевидный подход состоит в том, чтобы загружать только критические сценарии обычным способом, а остальные — способом, который не окажет негативного влияния на приложение. И действительно, есть два таких способа загрузки.
Первый использует атрибут defer
В большинстве случаев эти сценарии обрабатывают взаимодействия с пользователем, что делает их безопасными для загрузки таким образом. Второй использует атрибут async
Однако нет гарантии, что порядок загрузки будет таким же, как порядок выполнения.
Со всеми преимуществами этих двух аргументов они становятся важным инструментом повышения производительности веб-сайтов и приложений. Посмотрите на ресурсы ниже, чтобы узнать больше о том, как и когда использовать эту технику:
- Удалить блокировку рендеринга JavaScript в Google Developers
- Загрузите неблокирующий JavaScript с асинхронным HTML5 и отложенным в SitePoint
Политика безопасности контента
С самого начала безопасность в Интернете строилась вокруг модели «того же происхождения», что означает, что только сценарии из одного домена могут взаимодействовать с данной страницей. Однако со временем нам пришлось интегрировать сторонние сценарии в наши страницы: библиотеки JavaScript из CDN, виджеты социальных сетей из Facebook, Google+ или Twitter и другие подобные случаи. Это означает, что мы открыли ворота и позволили «гостевым» сценариям бегать в наши метафорические дворы. Проблема возникает, когда вредоносные скрипты скользят внутри и выполняются так же, как и остальные — метод атаки, который мы все знаем как межсайтовый скриптинг или XSS .
Политика безопасности контента — главное оружие в борьбе с XSS . Этот механизм содержит набор политик и директив, которые определяют, какие сценарии разрешено выполнять, откуда он может загружать ресурсы, может ли он выполнять встроенные стили или сценарии и т. Д. CSP основан на белом списке, что означает, что по умолчанию все запрещено, и доступны только указанные ресурсы. Это означает, что, когда правила настроены правильно, даже если вредоносный скрипт вставлен в наш сайт, он не будет выполнен.
Вот несколько ресурсов, которые помогут вам лучше понять этот механизм:
- Справочник по политике безопасности контента
- Улучшение веб-безопасности с помощью политики безопасности контента в SitePoint
- Введение в политику безопасности контента на HTML5Rocks
Протокол HTTP / 2
С самого начала Интернет работал поверх протокола HTTP. Тем не менее, хотя первый эволюционировал очень сильно, HTTP остался в основном без изменений. В сложной экосистеме современных веб-сайтов и приложений HTTP может стать узким местом в производительности. Конечно, есть методы и практики, которые могут оптимизировать процесс, но есть только так много, что можно сделать.
Вот почему была разработана вторая итерация протокола, названная HTTP/2
SPDY
Он был утвержден в феврале 2015 года, а спецификации были опубликованы как RFC 7540 в мае 2016 года. Пока что основные браузеры поддерживают HTTP / 2 только через зашифрованные соединения, и весьма вероятно, что в обозримом будущем так и останется, чтобы поощрить владельцев сайтов переключиться на HTTPS.
Принятие HTTP / 2 — это не просто изменение некоторых параметров конфигурации. Некоторые из лучших практик, используемых для повышения производительности по HTTP, могут влиять на производительность по HTTP / 2. Чтобы узнать, готов ли ваш сайт для HTTP / 2, вы можете обратиться к ресурсам ниже:
- Подготовка к HTTP / 2: руководство для веб-дизайнеров и разработчиков на Smashing Magazine
- Как HTTP / 2 меняет лучшие практики веб-производительности в новом блоге Relic
- HTTP / 2 для веб-разработчиков на блоге Cloudflare
Подсказки к ресурсам: предварительная выборка
Производительность в Интернете — это все повальное увлечение в наше время и по уважительной причине. Как известно всем работающим в этой области, загрузка ресурса занимает много времени. Не было бы неплохо, если бы можно было использовать время после загрузки страницы для предварительной загрузки ресурсов для следующих шагов? Это именно то, для чего нужны ресурсные подсказки.
Подсказки о ресурсах — это ряд директив, которые сообщают браузеру заранее предоставить конкретные ресурсы, которые понадобятся позже в будущем. Список содержит пять подсказок, а именно:
- ДНС для упреждающей
- preconnect
- упреждающей
- предварительная нагрузка
- PreRender
Из этих пяти возможных вариантов только одна с хорошей поддержкой браузера на данный момент — prefetch
Этот совет указывает браузеру кэшировать документы, которые пользователь, скорее всего, запросит после текущей страницы. Это ограничивает его использование элементами, которые можно кэшировать. Использование его с другими типами ресурсов не будет работать.
Если вы заинтересованы в этой теме, вот список ресурсов, чтобы предоставить более подробную информацию:
- Статья о ресурсах Советы по среде
- Предварительная загрузка, предварительная загрузка, предварительный просмотр на CSS-хитрости
- Советы по ресурсам в блоге KeyCDN
Строгая транспортная безопасность
HTTPS становится новым стандартом для просмотра, и все больше и больше веб-сайтов принимают только защищенные соединения. Обычные соединения (по HTTP) обычно перенаправляются на версию HTTPS, и все идет как обычно. Однако этот подход уязвим для атаки «человек посередине», когда перенаправление происходит вместо этого на клон поддельного веб-сайта, который вы хотите (обычно на банковский сайт), чтобы украсть ваши учетные данные для входа.
Здесь вступает в игру заголовок Strict Transport Security. При первом подключении к нужному веб-сайту с помощью HTTPS заголовок отправляется в браузер. При следующем подключении, даже если вы используете только HTTP-версию URL-адреса, браузер перейдет непосредственно к HTTPS-версии, не пройдя цикл перенаправления. Поскольку по HTTP не установлено соединение, описанная ранее атака не может произойти.
Дополнительные сведения о заголовке Strict Transport Security можно найти на следующем веб-сайте:
Соотношение пикселей устройства
Window.devicePixelRatio
Таким образом, разработчики могут обнаруживать экраны высокой плотности (например, дисплеи Retina от Apple или экраны высокого класса для Android). Используемое вместе с Media Queries и MatchMedia (о чем мы говорили выше), это свойство позволяет предоставлять оптимизированные ресурсы для наилучшего опыта.
Веб-видео текстовые треки
Текстовые дорожки веб-видео (или WebVTT) — это формат для разметки текстовых заголовков для мультимедийных ресурсов. Он используется вместе с элементом HTML5 <track>
Наличие этой текстовой информации делает медиа-ресурс намного доступнее.
Инструкции по началу работы с этой функцией см. В следующих ресурсах:
Завершение дела
Вот мы, в конце этой серии статей, которые начинались как простое интеллектуальное упражнение: « OldIE ушло! Давайте веселиться! (… Часов спустя…) И что теперь? ». Мы затронули широкий круг тем: от техник и практик, которые больше не нужны, до всего нового, что мы теперь могли свободно делать без полифилов, будь то HTML, CSS или нативный JavaScript. Мы даже затронули более широкие темы, такие как оптимизация производительности и повышение безопасности.
Должны ли вы просто вмешаться и начать рефакторинг всего своего кода? Скорее всего нет. Такое решение должно быть принято в зависимости от баланса между стоимостью рефакторинга и стоимостью технологического долга. Но если вы начинаете новый проект, во что бы то ни стало, постройте его для будущего, а не для прошлого.