… Эпоха неизменного XPCOM
К сожалению, проблемы начали постепенно накапливаться.
Когда вы разрабатываете большое приложение, вам нужно что-то изменить, чтобы исправить ошибки или добавить новые функции, или повысить производительность. В мире XPCOM это означало изменение компонентов XPCOM. Иногда для добавления новых функций в компонент. Иногда нужно полностью удалить один, потому что этот дизайн был заменен на лучший дизайн.
В первую эру механизма расширения на основе XPCOM это часто было запрещено. Если в надстройках использовался компонент XPCOM, его просто нельзя было изменить несовместимыми способами. Это было здорово для разработчиков надстроек, но быстро стало кошмаром для разработчиков Firefox. Потому что каждое изменение должно было быть выполнено с обратной совместимостью как внешне (для веб-разработчиков), так и внутри (для разработчиков надстроек). Это означало, что каждый компонент XPCOM nsISomethingбыстро сопровождался компонентом nsISomething2, который был лучшим – и оба должны были работать вместе друг с другом – Один случай был еще более сложным для разработчиков Firefox: надстройки на основе XPCOM могли заменить любой существующий компонент XPCOM. Излишне говорить, что это был очень хороший способ взломать Firefox, что озадачило исследователей сбоев Firefox.
Это означало, что разработка становилась все медленнее и медленнее, поскольку нам нужно было проверять каждую новую функцию или каждое улучшение не только с текущими функциями, но и с прошлыми/устаревшими функциями или просто старыми способами работы, которые были устаревшими в течение многих лет. Какое-то время этот налог на развитие был приемлемым. В конце концов, основным конкурентом Firefox был Internet Explorer, у которого были еще более серьезные архитектурные проблемы, и было очевидно, что неограниченное количество участников с открытым исходным кодом помогало. Кроме того, набор функций Интернета был намного меньше, так что это все еще было возможно.
… Эпоха, когда разработчики дополнений всегда были в курсе
Однако по мере роста Интернета стало очевидно, что эти варианты сделали просто невозможным исправить некоторые проблемы, в частности проблемы с производительностью. Например, примерно в 2008 году разработчики Firefox осознали, что на платформе просто слишком много компонентов XPCOM и что это значительно снижает производительность, поскольку компоненты XPCOM не позволяют компилятору JIT и C ++ оптимизировать код и требуют слишком большого количества преобразований данных. Так началось обеззараживание, заключающееся в переписывании критически важных для производительности участков кода без компонентов XPCOM. Что означало взлом надстроек.
В эту вторую эру механизма расширений на основе XPCOM разработчикам Firefox было разрешено удалять или реорганизовывать компоненты XPCOM при условии, что они связались с разработчиками надстроек и работали с ними, чтобы сделать возможным исправление их надстроек. Это разблокированное развитие, но налог на разработку каким-то образом сумел вырасти еще выше, поскольку это иногда означало недели мозгового штурма с внешними разработчиками, прежде чем мы могли внести хотя бы простые улучшения. Таким образом, также начался высокий налог на дополнительные разработки., поскольку некоторым разработчикам надстроек приходилось время от времени переделывать свои надстройки. В некоторых случаях между разработчиками Firefox и разработчиками надстроек были очень хорошие отношения, что иногда приводило к разработке разработчиками надстроек API, используемых в Firefox. В других случаях разработчики дополнений устали от этого бремени обслуживания и сдались, иногда переключаясь на зарождающуюся экосистему Chrome.
… Эпоха Snappy
Примерно в это же время Mozilla начала уделять Chrome серьезное внимание. Chrome начинал с очень разных принципов дизайна, чем Firefox:
- в то время Chrome не заботился о чрезмерном потреблении памяти или системных ресурсов;
- В Chrome использовалось множество процессов, которые благодаря дизайну обеспечивали этому браузеру повышенную безопасность и быстродействие;
- Chrome начинался без дополнительного API, что означало, что разработчики Chrome могли уйти от рефакторинга всего, что они хотели, без этого налога на разработку ;
- поскольку Chrome представил свой механизм расширения, они сделали это с помощью надлежащего API, который обычно можно было поддерживать независимо от изменений в серверной части;
- Кроме того, хотя Chrome изначально был медленнее, чем Firefox практически во всех тестах, он опирался на многочисленные дизайнерские приемы, которые заставляли его чувствовать себя быстрее – и пользователям это нравилось.
В течение многих лет для Mozilla было ясно, что Firefox необходимо перейти на многопроцессорный дизайн. Фактически, демонстрационные версии многопроцессорного Firefox циркулировали примерно тогда, когда был представлен Chrome 1.0. Проект назывался Electrolysis, или сокращенно e10s. Мы вернемся к этому.
В то время Mozilla решила приостановить работу e10s, которая должна была использовать гораздо больше памяти, чем было у многих наших пользователей, и сосредоточиться на новом проекте под названием Snappy (раскрытие: я был одним из разработчиков Project Snappy). Snappy использовал те же дизайнерские приемы, что и Chrome, чтобы Firefox работал быстрее, надеюсь, без необходимости реорганизовывать все.
Причина, по которой Firefox работал медленнее, чем Chrome, заключалась в том, что мы почти все делали в одном потоке. Когда Firefox записывал файл на диск, это блокировало визуальные обновления, поэтому количество кадров в секунду упало. Когда Firefox собирал список вкладок, чтобы сохранить их в случае сбоя, это блокировало обновления с тем же результатом. Когда Firefox очищал файлы cookie, это блокировало обновления и т. д.
Для этого было два решения, которые мы оба использовали:
- по возможности, вместо выполнения кода в основном потоке мы перемещали его в другой поток;
- всякий раз, когда это было невозможно, нам приходилось разбивать обработку на небольшие фрагменты, которые, как мы могли каким-то образом гарантировать, могли быть выполнены в течение нескольких миллисекунд, а затем вручную чередовать эти фрагменты и остальную часть выполнения основного потока.
Оба решения помогли нам гарантировать, что мы не пропустим кадры и что мы сможем немедленно ответить, когда пользователь щелкнет. Это означало, что пользовательский интерфейс казался быстрым. Преимущество первого заключалось в том, что в нем использовалась операционная система, тогда как для второго требовалось значительное количество измерений и тонкой настройки. Оба решения было сложно реализовать, потому что мы внезапно столкнулись с проблемами параллелизма, которые, как известно, сложно отлаживать. Оба решения также были трудны для разработчиков надстроек, поскольку они требовали изменения всех функций с синхронного на асинхронный, что часто означало, что надстройку нужно было переписывать с нуля.
Для меня это время памяти, поскольку именно тогда Ираклий , Паоло и я (я кого-то забыл?) Представили Promise и то, что теперь известно как async function кодовая база Firefox. Эти эксперименты (которые никоим образом не были единственными экспериментами по данной теме) послужили испытательной площадкой для последующего внедрения этих функций в Интернет. Более того, они значительно упростили написание асинхронного кода как для разработчиков Firefox, так и для разработчиков надстроек. Несмотря на эти улучшения (и другие, которые еще не дошли до стандартов), написание и отладка асинхронного кода оставались очень сложными.
Итак, снова был введен новый налог на обслуживание для разработчиков дополнений, который быстро стал действительно сложным. Что касается возможностей расширений, ситуация была еще хуже, когда мы переместили код из основного потока, потому что они обычно перемещались в потоки C ++, которые полностью отделены от потоков JavaScript. Компоненты XPCOM исчезали то тут, то там, теряя возможности расширения для разработчиков надстроек.
Я считаю, что именно на этом этапе многие разработчики дополнений начали серьезно жаловаться на этот налог на обслуживание – или, чаще, просто перестали обновлять свои дополнения. И они были правы. К тому времени, как разработчик дополнений, я уже давно отказался от обслуживания своих дополнений, это было чертовски много времени. Налог на обслуживание сжигал наше сообщество разработчиков дополнений.
И Mozilla серьезно подошла к поиску нового способа написания дополнений, который значительно снизил бы налог как для разработчиков Firefox, так и для разработчиков дополнений. В то время решением был Jetpack, и это было довольно здорово! Некоторое время сосуществовали два механизма расширения: более чистый Jetpack и более старая беспорядочная модель.
Начало:
Продолжение: