JavaScript развивался с годами и ведет себя по-разному в разных браузерах… Ой, подождите! Это совершенно не так, некоторые из JavaScript, которые мы пишем для браузеров, даже не являются JavaScript. В этом нет никакого смысла? Продолжай читать…
Если мы вернемся примерно к 2002 году, действительно были разные реализации спецификаций JavaScript, но это изменилось примерно в 2009 году, когда исчезли последние версии IE (версия 8) с JScript (разветвленная версия JavaScript от Microsoft) и были созданы новые версии. .
В 2011 году, когда TC39 (комитет Ecma, отвечающий за развитие и разработку спецификации JavaScript) выпустил EcmaScript v5.1, они выдвинули так называемый принцип одного JS, это означает, что с этого момента все основные движки JavaScript или кто-либо, похожий на крупного игрока в области JavaScript (например, babel), будет иметь представителя в команде TC39, и что ничего не войдет в спецификацию, если только все они согласился реализовать его в соответствии со спецификацией, поэтому, если кто-либо из этих основных игроков не согласится с предложением и откажется реализовать его, он просто не попадет в соответствие со спецификацией.
Это означает, что будут разные реализации JavaScript, но все они будут строго соответствовать спецификации и иметь единообразное поведение для разных движков.
Вы можете узнать больше о предложениях TC39 в моей статье Улучшение JavaScript (предложения по сценариям Ecma) »
Выше было заявлено, что все основные браузеры, среды выполнения или проигрыватели в пространстве JavaScript имеют право голоса в отношении того, что входит в спецификацию, но давайте еще больше заявим об этом.
TC39 поддерживает набор из примерно 35 000 тестов, эти тесты гарантируют или проверяют соответствие каждой отдельной функции, синтаксиса или реализации языка спецификациям Ecma на различных платформах, таких как V8, Spider Monkey, Chakra и т. Д. Каждый тест выполняется как в строгом, так и в нестрогом режиме. Кроме того, прежде чем предложение сможет перейти на этап 4, приемочные тесты Test262 должны быть написаны для основных сценариев использования, объединены, и должны быть две совместимые реализации, которые прошли приемочные тесты. Вы можете найти визуальное представление тестовых примеров в разных средах выполнения в test262.report.
Хорошо, достаточно сказано о единообразии поведения JavaScript в разных движках. Почему все еще кажется, что JavaScript ведет себя по-разному в разных браузерах, хотя он единообразно реализован во всех их механизмах выполнения? Это потому, что JavaScript, который ведет себя по-разному в разных браузерах, не является JavaScript. Все еще не имеет смысла? Держи мой кокс ...
В средах JavaScript, таких как Browsers, Node, Deno, мы пишем много кода, который выглядит как JavaScript, но на самом деле не является «языком JavaScript», мы фактически взаимодействуем с API платформы через интерфейс JavaScript. Такие вещи, как объект документа, API геолокации, веб-RTC, indexedDB, локальные хранилища и т. Д., На самом деле не являются JavaScript, мы просто взаимодействуем с ними, используя синтаксис, подобный JavaScript, они не контролируются и не регулируются спецификацией EcmaScript, фактически , большинство из них фактически написано на C / C ++. Таким образом, расхождение, которое мы видим в браузерах, является результатом того, что браузеры (или среды выполнения) не имеют спецификации, определяющей реализации JavaScript, отличного от JavaScript. JavaScript на самом деле более стабилен, чем другие веб-технологии, потому что ни одна из них не имеет ничего похожего на принцип one JS. Теперь яснее? Определенно!
Так о каких особенностях я говорю конкретно? Потому что в наши дни это не кажется проблемой. Я имею в виду, что у нас больше нет проблем с совместимостью браузеров (кроме IE), правда в том, что у нас есть, но не так, как раньше. На самом деле, не совсем верно, что все проблемы, связанные с кросс-браузерной совместимостью, вызваны интерфейсами JavaScript на стороне браузера.
Несколько очень немногих примеров проблем несовместимости браузеров в JavaScript
Медленная / ранняя адаптация предложений
Медленная и / или ранняя реализация новых функций JavaScript, которые попали в спецификацию, могут вызвать некоторые проблемы. Хороший пример - предложение Числовой разделитель. Когда это предложение все еще находилось на стадии 3, некоторые основные движки (V8, SpiderMonkey, JavaScriptCore) уже реализовали его и отправили со своими последними версиями (экспериментально), хотя это только на пути к спецификации и еще не совсем там. Это действительно может создать впечатление, будто в некоторых браузерах есть функция, а в некоторых - нет.
Кроме того, предложение может быть внесено в спецификацию только в том случае, если оно хотя бы реализовано и соответствует test262 основными движками. Это означает, что некоторые движки могут двигаться быстрее, чем другие, при реализации новых функций, что может создать впечатление, будто существует проблема перекрестной совместимости, хотя на самом деле это просто разница во времени в реализации.
Теперь большой вопрос: почему движкам разрешено реализовывать предложение до того, как оно попадет в спецификацию? Ответ прост: предложения по JavaScript на самом деле более открыты, чем мы думали, и открыто обсуждаются на esdiscuss.org. Разработчикам нужен способ протестировать эти предлагаемые функции, чтобы внести свой вклад в обсуждения, поэтому движкам разрешено экспериментально поддерживать их, прежде чем они попадут в спецификацию.
Файловая система и FileWriter API
Filesystem & FileWriter API позволяет создавать и читать файлы на устройстве пользователя на стороне клиента. В настоящее время API поддерживается только Edge, Chrome, Opera и SamsungInternet и не поддерживается IE, Firefox и Safari. Вот сравнительная таблица по canuise.
API ориентации экрана
Вы когда-нибудь пробовали играть в веб-игру на своем мобильном телефоне, и вам предлагалось изменить ориентацию вашего мобильного устройства на альбомную? Это API ориентации экрана! Он отслеживает состояние ориентации экрана и запускает событие при изменении этого состояния.
API распознавания речи
API распознавания речи позволяет включать голосовые данные в веб-приложения. В настоящее время он поддерживается только браузерами Chrome, Samsung Internet, QQ и Baidu.
API статуса батареи
Этот API предоставляет информацию об уровне заряда батареи устройства и генерирует события, когда уровень заряда батареи изменяется или состояние меняется на зарядку. В настоящее время он поддерживается всеми основными браузерами, кроме IE, Firefox и Safari / IOS.
Вышеупомянутое дает представление о том, как одни браузеры могут иметь определенные API-интерфейсы (которые похожи на JavaScript), а другие - нет. Если мы взглянем на спецификацию объектной модели документа, мы заметим, что все приведенные образцы кода фундаментального интерфейса написаны строго на C ++, а не на JavaScript, как это могло бы показаться. Если вы посмотрите на исходный код хрома, вы заметите, что такие вещи, как webRTC, media, написаны на C ++.
Заключение
Так что, да, проблем с совместимостью браузеров избежать невозможно, но есть способы их решения (полифиллинг, транспилинг), о которых я не буду рассказывать в этой статье (надеюсь, напишу об этом в будущем). Но, надеюсь, теперь у вас есть хорошее представление о том, что их вызывает, и вы знаете лучше, чем винить JavaScript или, что более важно, Web API. Не вините их, они не JavaScript😁.
Если вам понравилось читать и, самое главное, вы извлекли из этого уроки, пожалуйста, бросьте аплодисменты, мне бы понравилось внимание!
