Всякий раз, когда вы жалуетесь на текущую фрагментацию JS, помните, что 18 июля 2006 г. я опубликовал свой первый полифилл Стандартная библиотека JavaScript, ориентированный на браузеры вплоть до IE4, браузер, в котором никогда не реализовывался оператор try/catch. , браузер, который очень сложно обнаружить.

Большинство Array.prototype методов недоступно в IE, а XMLHttpRequest было недоступно в Firefox и других.

String.prototype.replace не принимал функцию в качестве второго аргумента, но большая часть документации по-прежнему предоставлялась Mozilla ♥

Отказ от IE4 и публикация V2

В конце 2007 года я окончательно отказался от поддержки IE4 с версией моей библиотеки на основе ECMAScript 4th Edition: JSL V2.

В то время были браузеры, не поддерживающие undefined, и оба setTimeout и setInterval поддерживали дополнительные аргументы везде, кроме, угадайте, кто, IE.

Это время в истории Интернета было известно как Web 2.0, время, когда IE5 все еще существовал, и вещи, которые мы считаем само собой разумеющимися, такие как Function.prototype.call и Function.prototype.apply, не были реализованы должным образом, а также Object.prototype.hasOwnProperty.

IE все еще был доминирующим

Несмотря на усилия MDN по документированию стандартов и хотя все разработчики использовали Firefox благодаря инструменту разработчиков Firebug, большинство веб-сайтов по-прежнему нацелены на IE, у которого была наиболее значимая доля рынка и, по общему признанию, довольно интересные, навязчивые или недружелюбные с точки зрения безопасности функции.

Эта ситуация отразилась на рынке таким образом, что многие разработчики знали о конкретных API IE, но не могли писать стандартный код.

Несмотря на использование очевидных библиотек, таких как jQuery, эти упорные разработчики «только ванильный JS» оставили огромное количество несоответствий.

Случай подкласса

В разные годы лишь немногие энтузиасты JS пытались создать подклассы для собственных функций в эпоху, когда Object.setPrototypeOf и class {} не использовались в спецификациях.

Уже в 2006 году Дину Эдвардсу удалось создать подкласс массива довольно ограниченным способом, и с того дня многие другие разработчики пытались создать подклассы наиболее часто используемых классов таким образом, чтобы это работало аналогично современным родным подклассам.

В течение 2008 года мне удалось выйти за пределы реализации Дина, но позже я также разделил подклассы в String в двух разных случаях.

На сегодняшний день у людей, ориентированных на браузеры ES5, все еще есть масса проблем с подклассами, так что даже если эта тема так же стара, как Интернет (или половина ее времени), я намекну, что вам, вероятно, следует не подклассифицировать что-либо, если вы транспилируете собственные классы ES2015, что-то также больше не нужно, если вы не нацеливаетесь на браузеры смерти, такие как IE11 или ниже.

Это справедливо и для TypeScript: классы там не работают, если вы нацеливаетесь на ES5.

Обратный проект

Примерно в апреле 2009 года у меня возникла идея полифиллинга браузеров в обе стороны.

Проект все еще размещен в архаичном пространстве Google Code, потому что в те дни GitHub не существовало, поэтому TortoiseSVN был инструментом, используемым профессионалами .

В те дни IE6 все еще существовал, и заядлые разработчики называли себя ninjas, в основном из-за jQuery и его 'John авторская книга, в которую я тоже внес свой вклад, по крайней мере, для части хака DOMContentLoaded.

Краткий обзор псевдонимов веб-разработчиков на сегодняшний день

  • ниндзя
  • Джедаи
  • Rockstar
  • полный стек
  • ваниль

Я не уверен, как мы прошли путь от ниндзя до ванили, но я надеюсь, что следующий раунд никнеймов будет звучать как коктейли, как в кровавая Мэри CSS или JD на камнях утилит … погоди, он уже существует 🤔…

… Но без геттеров и сеттеров

Пока я не начал взламывать VBScript в IE, единственном языке программирования, который конкурировал с JavaScript в Интернете и проигрывал практически все битвы, каждую библиотеку до 2011 года. не мог реализовать некоторую магию через аксессоры, в то время также стандартизированные для IE9 и выше, в мире, где все еще преобладали IE6, IE7 и IE8 с его неработающей реализацией ES5.

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

У этого взлома были некоторые ограничения, например, то, что практически частные поля не могли начинаться с _ подчеркивания, но они могли иметь подчеркивание в конце, потому что VBScript был настолько глупым, да!

… И много XPath…

В те годы селекторы CSS не были такими мощными, как сегодня, и XPath был подходящим средством для чего-то более сложного, чем идентификаторы или классы.

Есть еще вещи, которые XPath лучше, чем селекторы CSS, например, возможность сканировать родительский объект в любой момент, но я считаю, что современные разработчики забыли о XPath или перестали им пользоваться где-то лет 5 назад или больше.

От монолита к частичному

В 2011 году я был очень активен в качестве спикера, освещая конференции, такие как JSConf EU и falsy-values ​​ в Варшаве.

В те дни я ежедневно использовал ES5, полифиллинг для того или иного Desktop или Mobile браузера то, что было нужно, и никогда больше.

Примерно в то же время, или чуть позже, полный монолит-прокладка ES5 стал одним из самых популярных сценариев, которые можно разместить поверх любой веб-страницы.

Я участвовал в таком проекте, но практически никогда не использовал его, просто потому, что оптимизация общего размера JS любого сайта по-прежнему была моей самой важной ежедневной задачей, и просто потому, что я разрабатывал для Mobile Web, где 3/4 кода присутствовать в этом монолите было бесполезно: нас не заботил IE 🎉

Неполифилируемый корпус

Когда ECMAScript предложил WeakMap и WeakSet, мы впервые столкнулись с чем-то действительно невозможным для 100% -ного полифилла, с чем-то, что ни одна библиотека не могла бы надежно исправить, даже через специализированный API.

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

Аналогичным образом появился Symbol, и именно здесь транспилеры могли быть единственным вариантом для получения typeof thing === "symbol", потому что любое другое исправление времени выполнения не могло решить эту проблему.

Поставленный под эгидой es-shims, мой полифилл Symbols все равно начал использоваться, несмотря на несколько ограничений, по крайней мере, хорошо задокументированных.

Сломанный кейс полифилла

Для монолитного полифилла легко работать с его внутренними корпусами. Однако, когда у вас есть другие библиотеки или патчи, и полифил ломает ваш код, все легко становится совсем неприятно.

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

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

Вавилонская эпоха

С появлением множества новых функций к выпуску ES2015 Babel стал лучшим, если не единственным, инструментом для обновления вашего JS-кода, не беспокоясь о несовместимости браузеров.

С тех пор проект практически основан на core-js, который представляет собой инкрементный полифилл, способный на лету предоставлять помощников в соответствии с кодом, который вы переносите.

Это было революционным и вводящим в заблуждение по следующим причинам:

  • как только вы нацеливаетесь на старый браузер, все современные браузеры тоже подвержены влиянию потенциально полифилированного кода.
  • очень легко получить нежелательное раздувание, если вы не следите за созданным кодом, чего, как мне кажется, в большинстве случаев никто не делает.

Тем не менее, Babel сегодня по-прежнему остается лучшим транспайлером, на который вы можете сделать ставку, и его внутренние полифиллы также прошли супертестирование благодаря принятию его сообществом.

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

Бабель убил все полифиллы?

Еще не совсем. Существуют сотни проектов, не использующих Babel или кода доставки, которые должны сопротивляться транспиляции Babel (то есть библиотеки, которые можно импортировать).

Для всех этих случаев есть как минимум три альтернативы:

  • использовать монолиты поверх каждой веб-страницы
  • использовать CDN, который полифицирует браузеры после сниффинга пользовательского агента
  • используйте частичные полифиллы только при необходимости

Хотя первый подход по-прежнему преобладает на сайтах старого стиля, но я бы не стал предлагать такой подход ни одному сайту 2019+, случай polyfill.io на основе CDN очень интересен, его превосходит только недавний проект Pika CDN, способный встраивать полифиллы только в том случае, если они нужны используемому коду, аналогично тому, что делает Babel в ядре, за исключением того, что он абстрагирует все инструменты, необходимые для обслуживания того или иного браузера. .

Но где найти современные частичные полифилы, которые решают как JS-, так и DOM-случаи?

Не только JavaScript

Хотя большинство монолитов, упомянутых в этом посте, исторически имели полифилированные функции ECMAScript, я сохранил полифиллинг, поскольку наоборот проецирует все общие пробелы между браузерами, когда дело доходит до DOM API.

Custom Elements V0 / V1 polyfill и dom4 перед ним, или даже IE8 - это всего лишь несколько примеров различных проектов, над которыми я продолжал работать, чтобы принести современные стандарты в старые браузеры.

Однако в наши дни я решил сосредоточить в одном месте все мои наиболее важные исправления, чтобы упростить даже себе поиск по исправлению современных пробелов.

Проект Ungap

Как и ожидалось, если вам по-прежнему нужны частичные полифилы вместо монолитов, и вы не можете контролировать, где в конечном итоге будет выполняться ваш код, ваш проект одна остановка, чтобы управлять ими всеми - откатить. .

Это совместный проект даже не под моим именем, с очень маленькими правилами, но с отличным качеством кода и кросс-браузерной совместимостью.

Вместе с лучшими практиками постепенного обслуживания полифилов по запросу лучшая часть пространства имен @ungap состоит в том, что оно легко превращается в парную программу.

Мало того, что Pika CDN не будет предоставлять дополнительный код при импорте модулей unngap, @ungap/degap проект может использовать Rollup для полного пропуска / игнорирования определенных модулей.

Вдобавок ко всему существует плагин babel-plugin-remove-ungap, который аналогичным образом может нацеливаться на современные браузеры, избегая раздуваемых полифилов.

Продвижение Интернета вперед

Когда дело доходит до разработки, я в некотором роде сторонник JS, так что транспилеры с их косвенными действиями обычно не то, чем я пользуюсь или чему сильно доверяю.

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

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

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

В конце концов, как это уже сделано для всего пространства имен ungap, полифиллы станут вашим бесполезным программным обеспечением завтрашнего дня, делая ваш код быстрее, надежнее и тоньше с годами.

И последнее, но не менее важное: для меня это были 13 лет полифиллов, но я почти уверен, что автор полифиллов останется до конца времен Интернета ... ну, если, конечно, и стандарты, и браузеры не будут основываться на та же команда или робот, но, честно говоря, этот научно-фантастический финал не был моим намерением 😜