на каком браузерном движке построен браузер mozilla firefox
Ликбез по браузерам для Windows в 2020
Доброго времени суток, Хабр! В очередной раз читая комментарии, наткнулся на мысль о том, что далеко не все понимают, как обстоит ситуация с браузерами для Windows на данный момент. От чего хотелось бы провести небольшой обзор текущего положения. Ну, и сразу к делу!
Браузерные движки
Браузер — программа не простая, это целый набор компонентов, взаимодействующих между собой. Для краткого обзора потребуются всего два компонента из множества — движок отрисовки содержимого и движок исполнения JavaScript.
Существующие движки отрисовки содержимого
Существующие движки исполнения JavaScript
И тут вроде бы очевидно, какие браузеры какие движки используют, но Microsoft внёс не много путаницы в понимание данной темы, поэтому рассмотрим браузеры отдельно.
Браузеры
Chromium
Chromium — это open-source ответвление браузера Chrome. Браузеры на основе Chromium составляют большую часть из всех используемых браузеров на планете Земля.
Обычно, браузеры на базе Chromium между собой отличаются только визуально, ведь у всех под капотом движки Blink и V8, хотя, какие-то компании пытаются привнести больше функционала в браузер, чем имеется.
Это в конечном итоге встанет разработчикам браузеров боком, потому что в любой момент главный разработчик Chromium — Google может вставить палки в колёса разработчикам модификаций.
Всех браузеров на основе Chromium подсчитать одному человеку вряд ли под силу, поэтому приведу список только тех, что помню:
Firefox
Firefox использует движки Gecko и SpiderMonkey для своей работы. Имеет небольшое количество базирующихся на Firefox браузеров, но самый известный — Tor Browser. Является единственным рубежом до полного перехода интернета на браузеры на основе Chromium.
Internet Explorer
Это любимая всеми утилита для скачивания браузеров. Как и Chrome — не нуждается в представлении. До 11 версии использовал движки Trident и Chakra JScript. В 11 версии, за исключением режима совместимости, стал использовать движки Trident и Chakra JavaScript. Этот браузер ещё долго будет использоваться для всякого рода систем видеонаблюдения, поскольку имеет, почему-то, популярный в узких кругах API для расширений. В Windows 8 и Windows 8.1 имел особую модификацию движка Trident на базе WinRT для Metro режима.
(Legacy) Edge
Браузер, начавший своё существование с кодовым названием Project Spartan, являлся новым браузером от Microsoft в 2015 году, использующим движки EdgeHTML и Chakra JavaScript. Конечной целью проекта была полная совместимость с сайтами, отлично работающими в Chrome. В итоге — получилось нечто своеобразное, но, очевидно, не выжившее под давлением Google.
Safari
Safari? А нет его больше, этого вашего Safari, кончился.
Нецелевое использование браузеров
Вроде бы браузеры — законченный продукт, ни добавить ни отнять. Однако, они используются в разного рода других приложениях. Причины в следующем (в порядке убывания значимости):
Приведу примеры подобного использования:
Chromium
Нынешние браузеры настолько сложны, что одному человеку создать собственный браузер не под силу (либо это должен быть гений). Они по сложности сравнимы с операционными системами! А, постойте, вот и первый кандидат на нецелевое использование — Chrome OS. Да, весь пользовательский интерфейс — просто модифицированный Chromium.
Однако, помимо этого, в виде CEF (Chromium Embedded Framework), Chromium используется в:
Internet Explorer
Почти любое Win32 приложение, умеющее отображать WEB-страницы и при этом в распакованном виде занимающее меньше 60 мегабайт использует внутри Internet Explorer. Кстати, это касается не только маленьких по размеру приложений, например, Visual Studio использует Internet Explorer для отображения WEB-страниц, когда это требуется в работе IDE. Ещё существуют HTA приложения — древний предшественник CEF на базе Internet Explorer. И ведь до сих пор работает.
(Legacy) Edge
Новым приложениям — новые движки! Любое UWP приложение, использующее внутри отображение WEB-страниц работает на базе Edge. Не то, чтобы Microsoft запрещали использовать что-то другое, но никто просто и не старался. Так же, пока что, в предварительных сборках Windows новая клавиатура с GIF панелью тоже использует Edge для рендеринга. В будущих версиях, полагаю, перейдут на Chr Edge.
Производительность
Постойте, столько приложений, а что там с производительностью? Лично я — не специалист в оценке производительности, но хочу поделится с вами некоторыми занимательными фактами.
Prefetcher
В Windows есть такая штука — Prefetcher. Она занимается подгрузкой программ в ОЗУ при старте ОС и на протяжении её работы. Штука эта достаточно умная, и она анализирует чаще всего запускаемые программы, чтобы в дальнейшем их подгружать.
Как это связано с браузерами? Идея в том, что это может смазать первый пользовательский опыт с другим браузером, например, пользуясь постоянно Chrome, имеете установленную версию Firefox. При запуске Firefox будет вести себя крайне медленно — медленнее, чем ваш основной браузер. Всё потому что он запылился в глазах Prefetcher. В конечном итоге всё будет работать быстро, но первое впечатление после долгого неиспользования будет ужасным. Особенно это касается пользователей с HDD или малым количеством ОЗУ.
Области распределённой памяти
Движки нормального человека
У людей часто возникают проблемы с UWP приложениями, а точнее — с их скоростью запуска. Всё дело в WinRT — огромном наборе библиотек, при помощи которых UWP приложение взаимодействует с ОС. Если не использовать UWP приложения часто, то этот набор библиотек не будет прогружен в памяти полностью, и придётся ожидать окончания этого процесса перед использованием приложения. Но забавный факт — используя два и более UWP приложения время их старта и общая производительность резко увеличиваются и часто даже превосходят Win32 программы. Исключением из этого является приложение «Фотографии» — тут отдельная история, покрытая туманом.
Движки курильщика
А вот с приложениями (в том числе и браузерами) на основе Chromium это так не работает. Каждое приложение комплектует с собой собственную сборку библиотеки CEF, что, кроме раздувания размера приложения, не позволяет операционной системе иметь только одну копию dll в ОЗУ. Итого это сильно замедляет производительность при использовании множества подобных приложений. Помимо того, сам размер CEF довольно удручающий.
Microsoft Store
У многих возникает вопрос — почему в Microsoft Store нет ни одного браузера(не считая нескольких кривых поделок на EdgeHTML)? Ответ, на самом деле, прост — все браузеры, включая Chr Edge имеют собственную систему обновления, что прямо запрещено правилами Microsoft Store. В остальном никто никого не ограничивает.
Как удалить новый Microsoft Edge
Заключение
Пожалуй, эта статья получилась даже больше, чем я предполагал. В любом случае, какой браузер использовать — выбор ваш, но, зато, вы теперь знаете чуточку больше. Всем спасибо.
Администраторы Хабра, пожалуйста, почините HabraStorage в Legacy Edge! Совсем не дело.
В данной статье я хочу поделиться мыслями на счёт создания собственного браузерного движка. Мы рассмотрим текущие браузеры и браузерные движки. Вспомним про Modest и узнаем его нелёгкую судьбу.
Это будет цикл статей в которых мы создадим свой собственный минималистичный браузерный движок. Каждая статья будет подкреплена реальным кодом и примерами.
По прошествии десяти статей у нас с вами будет минимальная рабочая версия браузерного движка, сильно минимальная. После этого, если запал не уйдёт и будет интерес сообщества, продолжим, и в итоге доберёмся до JS.
И конечно, первым делом необходимо понять, что такое браузер и браузерный движок.
Браузер и браузерный движок
Существующий мир сложно представить без браузеров. Они есть на многих устройствах: компьютеры, лэптопы, телефоны, игровые приставки. Если представить браузер в виде машины то браузерный движок это всё то, что скрыто под капотом вашего автомобиля.
Браузеры как и автомобили могут отличаться внешним видом и содержимым под капотом. Цвет, кнопочки на панели, аудиосистема. У кого-то под капотом двигатель V8, а у кого-то там масло течёт.
Браузер объединяет периферию и предоставляет функционал позволяющий манипулировать движком, его поведением, предоставляет дополнительные сервисы.
Браузерный движок выполняет всю «грязную» работу: загрузка, обработка, отрисовка данных и все возможные расчёты.
Всё как в автомобилях. Есть салон в котором присутствует педаль газа, тормоза и множество переключателей полезных и понятных пользователю. А есть большая механическая часть скрытая от пользователя под капотом.
Кто создает браузеры и движки
Разработкой собственного браузера занимается множество компаний: Google, Mozilla, Apple, Microsoft, Opera Software, Яндекс, Ростелеком, Vivaldi Technologies, много их…
Каждый добавляет какие-то свои «фишки», сервисы в создаваемый браузер. К примеру, Яндекс интегрирует свои сервисы, поиск.
С браузерными движками дела обстоят кардинально иначе. Вот список движков, их разработчиков и обладателей:
Это основные обладатели и разработчики движков. В разработке им помогают сторонние компании на определенных условиях.
Например, рассмотрим самый популярный проект от компании Google — Chromium. Данный проект содержит в себе движок Blink. Создавать данный проект Google помогают такие компании как Intel, Facebook, IBM, LG Electronics, NVIDIA, Yandex. Полный список можно посмотреть тут.
Условия на которых компании помогают создавать Blink/Chromium описаны в разделе Legal stuff на сайте проекта Chromium. Если кратко, то всё что вы создаёте принадлежит (не эксклюзивно) Google.
Браузеры компаний Opera, Яндекс, Ростелеком и другие используют именно этот браузерный движок. Если быть до конца откровенным то заявления вроде «у нас есть свой браузер» не совсем правда. Собственные сервисы — да, а вот всё остальное принадлежит другой компании(ям). И эта другая компания предоставляет свой браузерный движок на определенных условиях.
Лицензии браузерных движков
Любой открытый код содержит в себе лицензию с описанием условий по использованию данного кода, и браузерные движки не исключение.
Если сразу и кратко: лицензии сносные, прям вот из ряда вон ничего нет. Кроме EdgeHTML который закрыт. Легально утащить к себе какой-то проект и закрыто разрабатывать/изменять видимо не выйдет. Лицензии призывают к взаимной открытости.
Открытый исходный код, ответвление движка WebKit. Как и в WebKit заявлено четыре лицензии:
Самый популярный браузерный движок. Он входит в состав проекта Chromium. Именно на основе Chromium создают собственные браузеры.
Если верить файлу LICENSE проекта Chromium его основная лицензия 3-Clause BSD. Но у проекта есть директория third_party (третьи лица, третья сторона) содержащая множество стороннего кода от которого проект зависит. Иначе говоря, без этого кода собрать браузер не выйдет. У каждого компонента свои лицензии отличные от того что указано в LICENSE проекта:
Открытый исходный код. Заявлена одна лицензия:
Активно развивается компаний Mozilla и используется в собственном браузере компании — Firefox. Так же используется в браузере Tor Browser обеспечивающий анонимное пребывание в сети.
Как основа для производителей браузеров большой популярности не имеет.
Открытый исходный код. Заявлено четыре лицензии:
Развивается компанией Apple и используется в собственном браузере компании — Safari. Ранее многие компании использовали в своих разработках WebKit, но после покинули проект и переключились на Blink от Google.
Закрытый исходный код. Проприетарная лицензия.
Движок используется для браузера компании Microsoft под названием Edge, который пришёл на смену Internet Explorer. Это их новый движок. Предыдущий Trident (MSHTML) компания прекратила развивать.
Риски
Использование стороннего движка порождает очевидные риски:
Никто не может гарантировать, что исходный код свободного браузерного движка не будет закрыт для публичного доступа. Так же возможен выход ключевых компаний из разработки свободного движка, что фактически является его закрытием.
Компании развивающие собственные браузеры должны понимать, что всё будет «хорошо» пока они не составляют угрозу/конкуренцию разработчикам оригинального браузера/браузерного движка. Думаю это очевидно. Компания тратит на разработку движка свои ресурсы, но вдруг появляется другая компания которая используя их движок захватывает рынок. Реакция, думаю, очевидна — смотрим список рисков выше.
«Мы создадим копию движка на текущий момент и продолжим развивать сами» — именно так отвечают производители браузеров на сторонних движках. Большое заблуждение, не выйдет просто так продолжить разработку чужого движка. То есть, взять программистов и поставить им задачу — пишите браузерный движок. Написание браузерного движка сложный технологический процесс. Подтверждением этого служит список их обладателей.
Для примера, компания Microsoft создает свой движок, хоть и закрытый. Google вместе с Apple разрабатывали WebKit, но позже Google сделал форк и начал развитие собственного движка Blink.
При этом нужно понимать, что браузерный движок постоянно развивается. Постоянно обновляются спецификации, добавляются новые возможности, улучшаются текущие. Это живая работа. Если взять какой-либо движок на текущую дату и просто использовать его для своего браузера то, примерно, через год-два браузер на этом движке морально устареет.
Адаптация движков
Существует проблема адаптации стороннего движка под нужды собственного браузера. На адаптацию тратится не мало ресурсов. При этом нужно понимать, что браузерные движки часто обновляются, что создает систематические проблемы при интеграции в собственный браузер.
Собственный движок
Прежде всего стоит ответить на главный вопрос — зачем создавать свой браузерный движок? А точнее, кому не надо создавать свой движок?
Свой браузерный движок не стоит создавать если:
На текущий момент нет сложности создать собственный браузер на стороннем движке. Их наплодилось не мало и как-то выделиться среди всей этой массы можно только созданием браузера на исключительно своих компонентах, на собственном движке.
Стоит ли заниматься разработкой движка для «заработка», для создания стартапа?
Данный вопрос скорее к сфере его применения. Мне видится несколько направлений:
Кроме того, престиж компании разработчика браузерного движка значительно выше чем у клонов. Именно как технологической компании. Это сказывается на популярности компании и привлекательности для существующих и будущих сотрудников. Но это уже скорее о честолюбии, встать в одном списке с такими компаниями как Google, Mozilla, Microsoft.
Заключение
Без сомнения, создание браузерного движка процесс сложный и требующий значительных ресурсов. Подходить к этой разработки необходимо крайне серьёзно и с чётким планом по развитию. Кроме того, это не тот продукт прибыль от которого можно получать на промежуточном этапе разработки. Да, отдельные компоненты можно адаптировать под нужды компаний, но я уверен, что такой подход только отнимет время и значительно затянет разработку.
Развитие браузерного движка сильно зависит от метода его разработки. Каким он будет: открытым, закрытым?
Я уверен, что если компания занимается развитием браузера на основе стороннего браузерного движка то ей следует серьёзно подумать над перспективой создания собственного.
Компании далёкой от браузеров заняться разработкой браузерного движка тоже можно, и не только для того чтобы создать браузер. Если итоговый продукт будет полноценным браузерным движком превосходящим существующие то он будет востребован. Сферы применения были описаны выше.
Цикл статей
Судьба Modest
Кто-то из читателей, возможно, знает, что я занимаюсь разработкой браузерного движка. В моих публикациях можно найти предыдущие статьи на эту тему.
К сожалению, проект Modest пришлось завершить. Какое-то время проект развивался в компании, в которой я раньше работал. Мне пришлось покинуть компанию. Появились разногласия которые не позволили продолжить разработку проекта. Обычный рабочий процесс, такое бывает.
Не смотря на то, что у меня есть все права на Modest, на код никто не претендует (подписаны бумаги), я решил его «закопать». Чтобы ни у кого не возникало ложных ощущений. Тут надо понимать, что закапывается и весь основной код который развивался вне компании (mycore, myhtml). Но, есть и плюс, возможно, я стал чуть умнее.
Мной было потрачено очень много времени на изучение спецификаций, осознания их, поиск оптимальных алгоритмов, написание черновиков (прототипов), создание myhtml (самый быстрый парсер html) в свободное от работы время, и просто так забросить эту тему я пока не могу. Было потрачено много выходных, праздников, вечеров, ночей.
Теперь я занимаюсь разработкой нового браузерного движка. Разработка с ноля. Имени у него пока нет, только кодовое — lexbor. Вся основа уже написана: работа с памятью, общие алгоритмы, заложена будущая архитектура. Как всегда, всё краше и лучше чем было. В общем, у меня есть самое главное: технология и чёткое видение/понимание как и что развивать.
Одному мне такой проект не потянуть. Если поддержки не найду (финансирования) то прекращу разработку и присоединюсь контребьютером к существующему открытому движку (Blink или Gecko). Попробую побыть там волонтером и реализовать свои идеи. Занимаюсь всем этим исключительно в нерабочее время.
Тут видимо должна быть картинка «ты должен был бороться со злом, а не примкнуть к нему».
Движок, который смог: как Chromium удалось захватить 90% рынка браузеров
От браузерного движка, который изначально был малоизвестной альтернативой, применявшейся в непопулярном браузере, до чемпиона, захватившего весь рынок.
Вероятно, иногда вы встречаете в текстах понятие браузерное разнообразие. Под ним подразумевается равновесие на платформе веба, при котором в мире существует множество реализаций браузеров, достаточное для стимулирования инноваций и конкуренции между ними. Альтернативой этому является монокультура браузеров, при которой один браузер или реализация браузера контролирует весь рынок, а значит, и управляет развитием веба. Когда кто-то содействует браузерному разнообразию, он часто делает это ради процесса создания независимых веб-стандартов, поддерживаемых W3C, который работает только когда ни один из браузеров не может диктовать функции, включаемые в платформу веба.
У веб-сообщества есть достаточно причин опасаться отсутствия браузерного разнообразия. После того, как Internet Explorer захватил в начале 2000-х долю 90% от рынка браузеров, для выпуска нового браузера его разработчикам потребовалась добрая половина десятилетия. В тот период развитие веба остановилось, и начали возникать проблемы с безопасностью. Из-за этого веб стал хуже, поэтому мы часто стремимся к тому, чтобы браузеры конкурировали, а не монополизировали веб.
Но у этой проблемы есть и обратная сторона. Из-за существования нескольких создателей браузеров веб-разработчикам необходимо обеспечивать совместимость всех платформ. Между браузерами могут присутствовать хоть и незначительные, но несоответствия, что может усложнять разработку для веба.
Это беспокоило создателя веба Тима Бернерса-Ли. Даже в начале 90-х, когда веб был очень юным, по всему миру в процессе экспериментов разработчиков ПО начали появляться десятки браузеров. Бернерса-Ли волновало, что слишком большое количество браузеров усложнит тестирование сайтов и достижение консенсуса о способах парсинга и передачи HTML пользователям.
В 1992 году Тим Бернерс-Ли высказал своё беспокойство в списке рассылки, посвящённом гипертексту.
Никто не будет поддерживать 8 парсеров на 12 платформах, поэтому я немного обеспокоен развитием реализаций. (Да, разумеется, в то же время мне это приятно! Но я бы хотел видеть одну, может быть, две основные библиотеки (две, чтобы тестировать одну из них на наличие непротиворечивых багов), но не четыре. Мне кажется, это слишком много; будут возникать ситуации, когда небольшие тонкости работают в одной, но не в других библиотеках, потому что на поддержку каждой не хватило труда по поддержке.
Бернерс-Ли осознавал, что множественные реализации могут потребовать слишком много усилий со стороны веб-разработчика, поэтому разработчики могут испытывать искушение полностью избежать этой проблемы и проводить тестирование только в самом популярном браузере (он и не подозревал, что подобная проблема будет часто возникать в веб-разработке). То есть даже без монополии слишком большое количество браузеров может заполонить рынок и создать фактического победителя, относительно которого будут создаваться стандарты без учёта всех остальных. Обеспечение непротиворечивости всех реализаций браузеров стало причиной создания W3C и продвижения набора общих стандартов в веб-технологиях.
Озабоченность Бернерса-Ли имела основания. Иногда возникали ситуации, когда браузеры шли собственным путём, заставляя веб-дизайнеров изощряться, чтобы страницы выглядели везде одинаково. В последние годы устоявшийся процесс стандартизации во многом позволил решить проблему несоответствий между браузерами благодаря созданию чёткого процесса добавления новых возможностей веба, гарантирующего баланс в процессе принятия решений.
Фундаментальной основой для создания разнообразной группы браузеров является развитие совершенно разных браузерных движков. Браузерный движок — это программный код внутри браузера, который получает написанный вами код и рендерит его на странице. Если смотреть на более техническом уровне, то он парсит HTML, CSS и JavaScript для обработки структуры и рендеринга веб-страниц. Движок обычно включает в себя JavaScript-движок, обрабатывающий интерактивность. Чаще всего при обсуждении браузерного движка говорят и о связанном с ним JavaScript-движке, но так бывает не всегда.
До того, как разработчики браузеров начали использовать веб-стандарты, во время «войн браузеров», был длившийся десяток лет период доминирования браузера Internet Explorer компании Microsoft. В Internet Explorer использовался проприетарный браузерный движок Microsoft под названием Trident. Internet Explorer распространялся бесплатно и по умолчанию был установлен на всех компьютерах с Windows. Благодаря своей скорости распространения Trident на долгие годы стал наиболее широко используемым браузерным движком.
Однако вскоре начали набирать популярность несколько более мелких браузеров с открытым исходным кодом. Самым популярным из них был Mozilla Firefox (основанный на Netscape), в котором использовался движок под названием Gecko. Немного отставала от него Opera со своим браузерным движком Presto. А небольшому сообществу полюбился браузер Konqueror с движком KHTML, имевший крошечную долю рынка браузеров.
Исходный код всех этих браузерных движков, за исключением Presto, был открытым, то есть он был доступен любому и его можно было использовать в любом проекте. Это стимулировало совместный труд и здоровую конкуренцию между такими новыми браузерами, благоприятствовавшими процессу создания стандартов веба под управлением W3C. А благодаря открытости исходников на рынке появилось большое количество мелких, нишевых браузеров, построенных на основе тех же браузерных движков.
Примечательно отсутствие в этом списке Apple. В 2003 году казалось, что компания совершенно упустила из виду платформу веба. Она неудачно пыталась создать собственный браузер под названием Cyberdog. Без нативного для своей ОС браузера компьютеры Apple поставлялись с Internet Explorer, который привязывал их к одному из самых серьёзных конкурентов — к Microsoft.
Но затем начали циркулировать слухи, что Apple работает над новым браузером. В компанию пришло несколько ветеранов из Mozilla, от имени Apple внесших вклад в Mac-версию браузера Firefox с открытыми исходниками. А после первого провалившегося эксперимента инструменты и реализации стали намного лучше. Существовало уже много созревших решений на основе open source.
Изначально предполагалось, что Apple выберет в качестве браузерного движка Mozilla Gecko. У неё уже были нужные сотрудники и опыт работы с ним, к тому же этот движок использовался в подавляющем большинстве проектов браузеров, в том числе браузера для Mac под названием Camino, разработанного независимой командой, не относящейся к Apple. Некоторые считали, что Apple может выбрать Presto, заключив некий договор по лицензированию.
Стив Джобс завершил свою программную речь на Macworld 2003 долгожданным объявлением: Apple создаёт собственный браузер под названием Safari. И ко всеобщему удивлению, в нём будет использоваться движок из Konqueror. Не Gecko, не Presto. KHTML. Новость была громкой, и в следующие два десятилетия она изменила траекторию развития веба.
Браузер Konqueror, запущенный в среде рабочего стола KDE
Браузер Konqueror — это одно из множества приложений, являющихся частью среды рабочего стола KDE для компьютеров с Linux. Строго говоря, это не операционная система, а пакет программного обеспечения, выглядящий и ведущий себя как ОС. Аббревиатура изначально расшифровывалась как Kool Desktop Environment, но потом была сокращена просто до KDE. Konqueror — это одна из программ внутри KDE. А KHTML — это движок, на котором работает Konqueror. Как и сам Linux, вся KDE имеет открытый исходный код, в том числе и её браузер, а сообщество разработчиков с самого основания придерживалось принципов открытого программного обеспечения.
Именно поэтому важно, что в объявлении Apple присутствовал этот слайд:
В своём объявлении о выборе KHTML Apple заявила о приверженности идеям open source. Команда разработчиков Safari пообещала по возможности вносить сделанные ею изменения в проект KHTML. При адаптировании движка Apple разбила его на две части: WebCore, занимающийся рендерингом и структурой, и JavaScriptCore, занимающийся JavaScript. Обе этих части стали проектами с открытым исходным кодом, однако система отслеживания ошибок Safari и элементы браузерного движка остались закрытыми. И всё же такой уровень прозрачности был удивителен для компании, хорошо известной охраной своих секретов.
Первая публичная версия Safari была выпущена одновременно с объявлением, в январе 2003 года. Вскоре после этого Safari начал поставляться как стандартный браузер для всех Mac. В течение одного-двух лет Safari стабильно занимала два-три процента от рынка браузеров. Этого не было достаточно, чтобы доминировать, но придавало вес команде разработчиков из Apple.
Несмотря на обещание, данное сообществу open source, разработчикам Safari поначалу оказалось сложно портировать вносимые ими изменения обратно в проект KTHML. Часть кода была специфичной для операционной системы Mac. Другие части были просто несовместимыми с существующей кодовой базой. Это привело к небольшим разногласиям между командой Apple и соавторами KHTML, длившимся пару лет.
Со временем был найден устраивающий всех компромисс. В июне 2005 года Apple объединила JavaScriptCore, Webcore и остальные компоненты браузерного движка, выпустив их как единый проект open source с публичным баг-трекером и призывом участвовать в развитии. Таким образом компания показала сообществу KHTML, что готова к сотрудничеству, сохраняя при этом независимость кода.
Проект назвали Webkit.
Критически важным оказался выбранный момент. Веб как платформа ускоренно развивался и находился на этапе Web 2.0. В целом, Web 2.0 был просто красивым маркетинговым термином, попыткой дать название росту количества сложных приложений, существующих исключительно в вебе. В него вошли два самых первых веб-приложения Google — Google Maps и Gmail. В течение года Google добавила в этот список и YouTube.
В середине 2000-х годов инженеры Google пристально пригляделись к браузерам и обнаружили, что те неспособны удовлетворить потребность в создании сложных приложений. Особенно справедливо это было в отношении старых и необслуживаемых браузеров наподобие Internet Explorer (кстати, к стимулированию отказа пользователей от IE6 приложил руку и YouTube). Но основным приоритетом Google была скорость. Сооснователи компании однажды выразили желание создать «веб столь же быстрый, как перелистывание бумажного журнала». Такой стала цель компании, и Google чувствовала, что даже современные браузеры типа Firefox и Safari приближались к ней недостаточно быстро.
К 2006 году компания начала строить планы по созданию собственного браузера. Она хотела иметь самый быстрый на рынке браузер. Поэкспериментировав со множеством браузерных движков, разработчики Google обратили внимание на проект Webkit, который перешёл в open source. Его код был компактным и читаемым, а ресурсоёмкость оставалась относительно низкой по сравнению с движками с богатой историей наподобие Gecko или Trident (последний в любом случае не рассматривался из-за закрытости своих исходников). Но, что самое важное, он был быстрым. Как отправная точка он был быстрее всех остальных движков.
Если бы команда Safari не решила открыть исходники своего браузерного движка именно в этом время, история могла бы развиваться совершенно в ином направлении. Но разработчики поступили так, поэтому Google изучила эту возможность и решила использовать движок. В следующую пару лет она начала работать над новой, ещё более быстрой реализацией Webkit.
Её первым шагом стало избавление от JavaScriptCore и замена его на собственный JavaScript-движок под названием V8, названный в честь мощного поршневого двигателя. Как можно понять из названия, V8 был быстрым. На момент выпуска он оказался в десять раз более производительным, чем JavaScriptCore. Он добился этой скорости благодаря работе в виртуальной машине и немного иному способу исполнения кода, делавшему его модульным и независимым от остальной части браузерного движка. Кстати, спустя пару лет эта модульность обеспечила возможность создания языка программирования Node: его разработчики взяли движок V8, избавились от браузера и поместили его на сервер.
Второе, что сделала Google — добавила в свой браузер многопроцессную архитектуру. О многопроцессности можно сказать многое, но лучше всего её объяснить на примере вкладок браузера. Раньше с «вылетом» одной вкладки аварийно завершалась работа всего браузера. Однако Google удалось заставить выполняться процессы в каждой вкладке независимо, чтобы за раз «вылетала» только одна вкладка. После выпуска браузера это стало его основным привлекательным качеством. Кроме того, это оказалось важным решением, потому что стало серьёзным отходом от того, как Webkit работал ранее. Вскоре это решение ещё аукнется компании.
В сентябре 2008 года Google официально объявил о проекте своего браузера публике. Компания совместила объявление с нердовским веб-комиксом Скотта Макклауда, в котором подробно описывались все технические подробности проекта. Браузер мог обрабатывать веб-сайты быстрее всех на рынке, а благодаря своей многопроцессной архитектуре был способен сохранять активность страниц, даже когда зависал какой-нибудь другой сайт. Это было в те времена, когда браузеры до сих пор были перегружены панелями инструментов и аддонами, а также пакетами больших компаний, в которые была включена и почта. Имя, данное Google этому проекту, тоже соответствовало концепции. В мире браузеров под понятием «хром» (chrome) подразумевается всё дополнительное, что окружает веб-страницу — адресная строка, панели инструментов и файловые меню. Google избавилась от большинства этого хлама, поэтому и назвала браузер Google Chrome, надеясь, что ставка на простоту и производительность оправдает себя.
Фрагмент веб-комикса, с которого всё началось
Если не считать закрытого алгоритма поиска, Google многие годы делала вклад в проекты с открытым кодом и создавала новые. Поняв урок Apple, компания при разработке Chrome зашла ещё дальше. В тот же день, когда было объявлено о выпуске Google Chrome, компания сделала весь движок доступным как open-source-проект под названием Chromium. Это не просто несколько расширений для Webkit. Это не просто движок рендеринга. Открытым стало всё: Webkit, JavaScript-движок V8 и весь код самого браузера. Без особых усилий любой разработчик мог дополнить Chromium и выпустить собственный браузер. После его выпуска со многими браузерами так и случилось.
2008-й стал важным годом для веба. В том же месяце, когда был выпущен Chrome, Google показала прототип своей мобильной операционной платформы Android, собранной из нескольких проектов с открытыми исходниками. В него входила и мобильная версия Google Chrome. Это произошло чуть более года спустя официального выпуска iPhone, который поставлялся с модифицированной версией Safari. К тому времени, когда Стив Джобс приступил к безвозвратному «убийству» Flash и начал превращать в основной приоритет нативную платформу веба, эти устройства уже были повсюду.
То есть теперь в каждом мобильном смарт-устройстве работал Safari или Chrome. Сама Safari целиком благодаря покупкам iPhone всего за несколько лет удвоила свою долю на рынке. Популярность Chrome росла ещё быстрее. Используя Chromium, вы получали доступ к постоянно расширяющемуся списку независимых браузеров и браузерных проектов. Кроме того, Chromium стал основой языка программирования Node и фреймворка для десктопных приложений Electron.
И все эти проекты работали благодаря Webkit. За несколько лет он совершил путь от захвата небольшой доли рынка браузеров до доминирования на нём.
Такое состояние покоя было недолгим. В апреле 2013 года Google неожиданно объявила, что создаст ответвление (форк) проекта Webkit в новый движок под названием Blink. Google Chrome и проект Chromium будут переходить на этот новый движок.
У такого перехода было несколько причин, но важнейшая из них возвращает нас к вопросу многопроцессности. Несколько лет Google расширяла Webkit, чтобы добавить в свои браузеры многопроцессность, ставшую важнейшей особенностью и основанием роста производительности браузеров Chromium. В 2013 году проект Webkit должен был выпустить новую версию движка, которая улучшала в том числе и многопроцессность. Проблема заключалась в том, что её реализация стала бы совершенно другой и несовместимой с реализацией в Chrome. В нём уже использовался другой JavaScript-движок и это новое изменение слишком сильно бы отодвинуло Chromium от исходного проекта. Ядром Blink по-прежнему должен был оставаться и остаётся Webkit. Но он пойдёт по другому пути и создаст себе новый проект.
На этом этапе веб стал более сложным, чем кто-либо мог себе представить. Проблема, которую впервые изложил Бернерс-Ли — слишком большое количество независимых разработчиков, создающих собственные браузерные движки — больше не была проблемой. Для сборки и поддержки браузерного движка теперь требовались большие коллективы. С расширением платформы веба и укрепления его стандартов сложность рендеринга веб-сайта в страницу росла экспоненциально. Браузер должен был исполнять бесчисленное количество сайтов, закодированных бесчисленным количеством способов так, чтобы более-менее соответствовать всем остальным браузерам.
После этого момента браузерные движки начали исчезать.
За два месяца до выпуска Blink компания Opera объявила, что откажется от собственного движка Presto и перенесёт свой браузер на Chromium. Когда Google объявила о форке, Opera присоединилась к ней. В мае 2013 года она выпустила свой первый браузер на основе Blink.
Тем временем Microsoft многие годы придерживалась собственного движка с закрытым исходным кодом. Trident был преобразован в движок под названием EdgeHTML, созданный для браузера Microsoft Edge, впервые выпущенного в 2015 году. Но вкладывание ресурсов в разработку независимого движка оказалось слишком сложной задачей на уже заполненном рынке браузеров. В 2019 году компания объявила, что тоже переходит на Blink. С тех пор этот браузер тоже выпускается.
Потомков KHTML, то есть браузеры, имеющие движки из семейства Blink / Webkit, используют более 90% пользователей. От практического забвения до доли рынка в 90% за пятнадцать лет — потрясающее достижение. И оно имело последствия.
Blink и Webkit — это два разных движка, и в их исходном коде стало довольно много различий. Но они используют одинаковый подход к рендерингу веб-страниц, а бо́льшая часть кода внутри проекта остаётся такой же. Это означает, что на текущем этапе, по сути, осталось две группы браузерных движков — семейство Blink / Webkit и Gecko браузера Firefox. Даже если разделить Blink и Webkit, то всё равно остаётся только три.
И это возвращает нас к вопросу браузерного разнообразия. Инновации в браузерных технологиях не исчезли, и, к счастью, каждый серьёзный браузер привержен процессу стандартизации веба. Однако если сообщество Blink и Webkit решит, что оно хочет двигать веб в определённом направлении, то будет обладать всей необходимой для этого властью. Это справедливо даже сегодня, несмотря на то, что Gecko всё ещё держится.
Джеффри Зельдман хорошо резюмировал это в момент, когда Microsoft решила переходить на Blink:
Когда одна компания решает, какие идеи стоит поддерживать, а какие нет, какие проблемы с доступом важны, а какие нет, это подавляет инновации, уничтожает конкуренцию и открывает возможности исключения людей из работы с цифровой информацией.
С исторической перспективы траектория развития Webkit является настоящим чудом. И оно возникло благодаря открытости и поддержке сообщества. Но столь же важно поддерживать браузерное разнообразие и возможности инноваций.
В этом посте рассказано о пяти вехах истории развития веба.
Источники
На правах рекламы
Наша компания предлагает безопасные серверы с бесплатной защитой от DDoS-атак. Возможность использовать лицензионный Windows Server на тарифах с 2 ГБ ОЗУ или выше, создание резервных копий сервера автоматически либо в один клик.
Используем исключительно быстрые серверные накопители от Intel и не экономим на железе — только брендовое оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить.