ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)
Сегодня мы живем в постквантовую эпоху. По возможности в Rust реализованы новые функции.
По умолчанию Rust плохо работает с XPCOM. Rust имеет другой механизм взаимодействия с другими языками, который работает очень хорошо, но не поддерживает XPCOM изначально. Написание или использование кода XPCOM в Rust возможно и постепенно достигает стадии, на которой он работает, без особых усилий, но большую часть времени существования кода Rust в Firefox это было просто слишком сложно сделать. Следовательно, даже если бы оставили доступным механизм расширения на основе XPCOM, большинство функций, реализованных в Rust, просто не были бы доступны для надстроек, если бы явно не опубликовали для них API – возможно, как API WebExtension.
История будет разворачиваться аналогичным образом. Сначала нет XPCOM. Позже, постепенно будет некоторая поддержка XPCOM, но только после явного решения сделать это. Возможно, позже будет представлен как API WebExtension.
Кроме того, после Project Electrolysis идет Project Fission. Это еще один крупный рефакторинг Firefox, который идет намного дальше в направлении, впервые выбранном Electrolysis, путем дальнейшего разделения Firefox на процессы для повышения безопасности и, надеюсь, в дальнейшем производительности. Хотя это напрямую не влияет на XPCOM, это означает, что любое дополнение, использующее механизм на основе XPCOM, которое было перенесено в Project Electrolysis, необходимо будет снова полностью переписать.
Все эти причины подтверждают, что выбор избавиться от аддонов на основе XPCOM можно было в лучшем случае изменить, чтобы продлить агонию технологии, но этот вывод был предрешен.
Но подождите, это еще не все! До сих пор мы упоминали только XPCOM, но XPCOM представляет только половину технологии, лежащей в основе надстроек Firefox.
XUL, язык пользовательского интерфейса XML, был одной из революций, осуществленных Firefox. Впервые декларативный язык для пользовательских интерфейсов, который просто работал. Представьте, что вы размещаете кнопки, стилизуете их с помощью CSS, соединяете их с помощью небольшого количества JavaScript, добавляете немного метаданных для обеспечения доступности, локализации, настроек хранения … Также отличный механизм под названием XUL overlays, который позволяет легко вставлять компоненты в существующие интерфейсы, например, к расширить меню или добавить новую кнопку и т. д. без необходимости изменять другой документ.
На протяжении большей части существования Mozilla именно так был написан пользовательский интерфейс Firefox – и, конечно же, так был написан пользовательский интерфейс надстроек. И это сработало как шарм. Как разработчик дополнений, которому надоело писать пользовательские интерфейсы на Gtk, Win32 и Swing, я впервые смог разработать UX, который выглядел бы намного лучше, чем все, что я когда-либо достигал с помощью любого из этих наборов инструментов, плюс только мне потребовалось несколько секунд вместо часов, я мог просто перезагрузить, чтобы увидеть, как оно выглядит, вместо того, чтобы сначала перестраивать приложение, и, противодействуя Gtk и Win32, мне не приходилось бояться сбоев, потому что код был написан на безопасный для памяти язык.
Если вы думаете, что это очень похоже на HTML5 (и, возможно, Electron) с правильными библиотеками/фреймворками, вы полностью правы. XUL был разработан во времена HTML4, когда веб-спецификации застряли в подвешенном состоянии, и был разработан в основном как преемник HTML, предназначенный для приложений, а не для документов. Почти двадцать лет назад Mozilla выпустила первую версию XULRunner, которая, по сути, была более ранней версией Electron, использующей XUL вместо HTML (HTML также можно было вставить в XUL).
Если вы писали надстройки на основе XUL, вы быстро понимали, что предотвратить их нарушение было… сложно. Несколько надстроек могут изменять одну и ту же часть пользовательского интерфейса, что приводит к нечетным результатам. Несколько надстроек могут случайно внедрить функции JavaScript с тем же именем или с тем же именем, что и существующая функция, что приведет к всевозможным сбоям.
Точно так же очень просто было написать вредоносное дополнение. Вы можете легко регистрировать все нажатые пользователем клавиши, улавливая все их пароли, но зачем вам беспокоиться, если вы можете просто пропатчить диспетчер паролей, чтобы отправлять все пароли на удаленный веб-сайт? И, чтобы было понятно, это не научная фантастика. Хотя я не знаю ни одного расширения, которое зашло бы так далеко, я знаю установщики для других несвязанных продуктов (по крайней мере, два из них являются лидерами рынка, которые останутся неназванными в этом посте), которые незаметно устанавливали невидимые надстройки Firefox, которые взяли на себя управление ключевых функций и нарушенной конфиденциальности.
Были внесены предложения по повышению безопасности, но было совершенно ясно, что, пока мы сохраняем XUL (и XPCOM), мы ничего не можем сделать, чтобы помешать вредоносному надстройке делать все, что нужно.
Как только началась работа над HTML5, Mozilla с энтузиазмом предоставила возможности XUL. Постепенно HTML5 получил хранилище, редактируемое содержимое, перетаскивание, компоненты (которые были известны как XBL в XUL), управление историей, аудио, криптографию… а также достаточную поддержку, позволяющую клиентским библиотекам реализовать доступность и интернационализацию.
Хотя HTML5 по-прежнему не обладает всеми функциями XUL, в конечном итоге он достиг стадии, на которой многие функции, которые были реализованы в Gecko для поддержки XUL, также необходимо было реализовать в Gecko для поддержки HTML5. Как и в случае с XPCOM, это превратилось в налог на разработку, поскольку каждая новая функция в HTML5 должна была быть реализована таким образом, чтобы она не нарушала ни одну из функций XUL, даже если разработчики дополнений каким-то образом попытались объединить их.
Это значительно замедлило разработку Gecko и увеличило количество ошибок, которые случайно убили надстройки на основе XUL, что привело к увеличению налога на обслуживание разработчиков надстроек.
К тому времени Mozilla уже давно решила прекратить улучшать XUL и сосредоточиться на HTML5. Поскольку производительность HTML5 для многих задач стала лучше, чем у XUL, разработчики Firefox начали переносить компоненты с XUL на HTML5. Результат был лучше (потому что дизайн был новым), быстрее (потому что Gecko был оптимизирован для HTML5), и расширение его с помощью надстроек на основе XUL стало более сложным. Кроме того, стало проще нанимать и обучать разработчиков интерфейса для Firefox, потому что они внезапно смогли использовать свои знания HTML5 и свои фреймворки HTML5 в Firefox.
Примерно тогда же впервые появился Jetpack. Jetpack позволил авторам надстроек писать свои расширения на HTML5 вместо XUL. Это было лучше для большинства авторов дополнений, так как они могли использовать свои знания и фреймворки HTML5. Конечно, поскольку в HTML5 отсутствовали некоторые функции XUL, это сработало не для всех.
Параллельно с этим в Mozilla началась работа над движком рендеринга Servo. Хотя движок не был полнофункциональным (и до сих пор), чрезвычайно крутые демонстрации продемонстрировали, как Servo (или, по крайней мере, его части) могут однажды заменить Gecko (или, по крайней мере, часть Gecko) кодом, который было легче читать и изменять, безопаснее и намного быстрее.
Конечно, была загвоздка: у команды Servo не было ресурсов для повторной реализации XUL, тем более что Mozilla давно решила прекратить работу над этой технологией. Чтобы иметь возможность в конечном итоге заменить Gecko (или его части) на Servo, Mozilla сначала необходимо было перенести пользовательский интерфейс Firefox на HTML5.
В Firefox это продолжило благоприятный круг: уменьшение количества XUL означало, что Gecko можно было упростить, что снизило налог на разработку Gecko и позволило разработчикам Gecko улучшить скорость всего HTML5. Это также означало, что разработчики пользовательского интерфейса и надстроек могли использовать технологии, которые были лучше оптимизированы, и существующие веб-библиотеки / фреймворки.
Опять же, это также означало, что использование XUL для пользовательских интерфейсов становилось все менее и менее целесообразным и уменьшало количество вещей, на которые могли надеяться надстройки на основе XUL.
А потом появился Project Quantum. Как обсуждалось выше, каждый день, который Mozilla проводил без поставки Electrolysis, был днем, когда Firefox был хуже Chrome с точки зрения безопасности и сбоев.
Когда был разработан XUL, многопоточность все еще считалась темой исследования, Linux и System 7 (предок macOS) даже не имели должной многопоточности, и лишь немногие люди за пределами академических кругов всерьез считали, что любому пользовательскому приложению когда-либо понадобится любой вид параллелизма. Итак, XUL был разработан для одного процесса и одного потока.
Когда пришло время внедрить Electrolysis для Firefox, многие функции XUL оказались непригодными для использования. Вполне возможно, что новая версия XUL могла быть разработана для лучшей поддержки этой многопроцессорной парадигмы, но это снова увеличило бы налог на разработку, не уменьшая задачу поддержки разработчика дополнений, поскольку им пришлось бы переносить свои дополнения к новому XUL независимо. Поэтому был сделан выбор, что функции, которые необходимо переписать во время продвижения Electrolysis, будут переписаны в HTML5.
После Project Electrolysis идет Project Fission. Глядя на то, как нам нужно реорганизовать код Firefox для Fission, кажется очень вероятным, что Project Fission потребовал бы XUL3 или, по крайней мере, снова сломал бы все надстройки.
Хотя XUL не будет полностью удален из Firefox или Gecko еще несколько лет, эра XUL официально закончилась. Опять же, выбор продлить механизм расширения на основе XUL можно было изменить, чтобы продлить агонию, но вывод был давно предрешен.
Что ж, для разработчиков надстроек Firefox настоящее и обозримое будущее называется WebExtensions.
По замыслу WebExtensions более ограничен, чем механизм беспорядочного расширения. По дизайну тоже работает лучше. Большая часть налога на разработку Firefox исчезла, так как нужно защищать только API WebExtensions, а не весь код Firefox. Большая часть налога на обслуживание исчезла, поскольку API WebExtensions работает стабильно (к сожалению, было несколько исключений). Он также намного проще в использовании, позволяет разработчикам надстроек обмениваться кодом между надстройками Firefox и Chromium и в конечном итоге должен упростить написание расширений, которые безупречно работают на настольных и мобильных устройствах.
Главный недостаток, конечно, заключается в том, что WebExtensions не дает разработчикам надстроек такой же мощности, как беспорядочный механизм расширений. Надеясь, что вся мощь, необходимая разработчикам надстроек, в конечном итоге может быть добавлена к WebExtensions API, но это то, что требует инженерной мощи, важного ресурса, которого нам очень не хватает.
Хотя мы понимаем, что все описанные выше действия дорого обходятся разработчикам надстроек и пользователям надстроек, выбор, сделанный Mozilla, был необходим для сохранения Firefox и его участия в гонке против Chrome.
Начало:
(3 оценок, среднее: 5,00 из 5)
Загрузка...
