Всем привет!
В данной статье я хочу поделиться мыслями на счёт создания собственного браузерного движка. Мы рассмотрим текущие браузеры и браузерные движки. Вспомним про Modest и узнаем его нелёгкую судьбу.
Это будет цикл статей в которых мы создадим свой собственный минималистичный браузерный движок. Каждая статья будет подкреплена реальным кодом и примерами.
По прошествии десяти статей у нас с вами будет минимальная рабочая версия браузерного движка, сильно минимальная. После этого, если запал не уйдёт и будет интерес сообщества, продолжим, и в итоге доберёмся до JS.
И конечно, первым делом необходимо понять, что такое браузер и браузерный движок.
Браузер и браузерный движок
Существующий мир сложно представить без браузеров. Они есть на многих устройствах: компьютеры, лэптопы, телефоны, игровые приставки. Если представить браузер в виде машины то браузерный движок это всё то, что скрыто под капотом вашего автомобиля.
Браузеры как и автомобили могут отличаться внешним видом и содержимым под капотом. Цвет, кнопочки на панели, аудиосистема. У кого-то под капотом двигатель V8, а у кого-то там масло течёт.
Браузер объединяет периферию и предоставляет функционал позволяющий манипулировать движком, его поведением, предоставляет дополнительные сервисы.
Браузерный движок выполняет всю "грязную" работу: загрузка, обработка, отрисовка данных и все возможные расчёты.
Всё как в автомобилях. Есть салон в котором присутствует педаль газа, тормоза и множество переключателей полезных и понятных пользователю. А есть большая механическая часть скрытая от пользователя под капотом.
Кто создает браузеры и движки
Разработкой собственного браузера занимается множество компаний: Google, Mozilla, Apple, Microsoft, Opera Software, Яндекс, Ростелеком, Vivaldi Technologies, много их…
Каждый добавляет какие-то свои "фишки", сервисы в создаваемый браузер. К примеру, Яндекс интегрирует свои сервисы, поиск.
С браузерными движками дела обстоят кардинально иначе. Вот список движков, их разработчиков и обладателей:
- Blink: Google
- Gecko: Mozilla
- WebKit: Apple
- EdgeHTML: Microsoft
Это основные обладатели и разработчики движков. В разработке им помогают сторонние компании на определенных условиях.
Например, рассмотрим самый популярный проект от компании Google — Chromium. Данный проект содержит в себе движок Blink. Создавать данный проект Google помогают такие компании как Intel, Facebook, IBM, LG Electronics, NVIDIA, Yandex. Полный список можно посмотреть тут.
Условия на которых компании помогают создавать Blink/Chromium описаны в разделе Legal stuff на сайте проекта Chromium. Если кратко, то всё что вы создаёте принадлежит (не эксклюзивно) Google.
Браузеры компаний Opera, Яндекс, Ростелеком и другие используют именно этот браузерный движок. Если быть до конца откровенным то заявления вроде "у нас есть свой браузер" не совсем правда. Собственные сервисы — да, а вот всё остальное принадлежит другой компании(ям). И эта другая компания предоставляет свой браузерный движок на определенных условиях.
Лицензии браузерных движков
Любой открытый код содержит в себе лицензию с описанием условий по использованию данного кода, и браузерные движки не исключение.
Если сразу и кратко: лицензии сносные, прям вот из ряда вон ничего нет. Кроме EdgeHTML который закрыт. Легально утащить к себе какой-то проект и закрыто разрабатывать/изменять видимо не выйдет. Лицензии призывают к взаимной открытости.
Открытый исходный код, ответвление движка WebKit. Как и в WebKit заявлено четыре лицензии:
- The 3-Clause BSD License
- The 2-Clause BSD License
- GNU Lesser General Public License Version 2, June 1991
- GNU Lesser General Public License Version 2.1, February 1999
Самый популярный браузерный движок. Он входит в состав проекта Chromium. Именно на основе Chromium создают собственные браузеры.
Если верить файлу LICENSE проекта Chromium его основная лицензия 3-Clause BSD. Но у проекта есть директория third_party (третьи лица, третья сторона) содержащая множество стороннего кода от которого проект зависит. Иначе говоря, без этого кода собрать браузер не выйдет. У каждого компонента свои лицензии отличные от того что указано в LICENSE проекта:
- Apache 2.0
- Mozilla Public License 2.0
- MIT
- и так далее
Открытый исходный код. Заявлена одна лицензия:
Активно развивается компаний Mozilla и используется в собственном браузере компании — Firefox. Так же используется в браузере Tor Browser обеспечивающий анонимное пребывание в сети.
Как основа для производителей браузеров большой популярности не имеет.
Открытый исходный код. Заявлено четыре лицензии:
- The 3-Clause BSD License
- The 2-Clause BSD License
- GNU Lesser General Public License Version 2, June 1991
- GNU Lesser General Public License Version 2.1, February 1999
Развивается компанией Apple и используется в собственном браузере компании — Safari. Ранее многие компании использовали в своих разработках WebKit, но после покинули проект и переключились на Blink от Google.
Закрытый исходный код. Проприетарная лицензия.
Движок используется для браузера компании Microsoft под названием Edge, который пришёл на смену Internet Explorer. Это их новый движок. Предыдущий Trident (MSHTML) компания прекратила развивать.
Риски
Использование стороннего движка порождает очевидные риски:
- Закрытие исходного кода
- Выход ключевых компаний из разработки
- Смена лицензий на код
Никто не может гарантировать, что исходный код свободного браузерного движка не будет закрыт для публичного доступа. Так же возможен выход ключевых компаний из разработки свободного движка, что фактически является его закрытием.
Компании развивающие собственные браузеры должны понимать, что всё будет "хорошо" пока они не составляют угрозу/конкуренцию разработчикам оригинального браузера/браузерного движка. Думаю это очевидно. Компания тратит на разработку движка свои ресурсы, но вдруг появляется другая компания которая используя их движок захватывает рынок. Реакция, думаю, очевидна — смотрим список рисков выше.
«Мы создадим копию движка на текущий момент и продолжим развивать сами» — именно так отвечают производители браузеров на сторонних движках. Большое заблуждение, не выйдет просто так продолжить разработку чужого движка. То есть, взять программистов и поставить им задачу — пишите браузерный движок. Написание браузерного движка сложный технологический процесс. Подтверждением этого служит список их обладателей.
Для примера, компания Microsoft создает свой движок, хоть и закрытый. Google вместе с Apple разрабатывали WebKit, но позже Google сделал форк и начал развитие собственного движка Blink.
При этом нужно понимать, что браузерный движок постоянно развивается. Постоянно обновляются спецификации, добавляются новые возможности, улучшаются текущие. Это живая работа. Если взять какой-либо движок на текущую дату и просто использовать его для своего браузера то, примерно, через год-два браузер на этом движке морально устареет.
Адаптация движков
Существует проблема адаптации стороннего движка под нужды собственного браузера. На адаптацию тратится не мало ресурсов. При этом нужно понимать, что браузерные движки часто обновляются, что создает систематические проблемы при интеграции в собственный браузер.
Собственный движок
Прежде всего стоит ответить на главный вопрос — зачем создавать свой браузерный движок? А точнее, кому не надо создавать свой движок?
Свой браузерный движок не стоит создавать если:
- Нет задачи/стремления захватить рынок.
- Браузер нужен лишь номинально. Сейчас это модно, делают даже школьники.
- Создаваемый движок не будет отличаться от существующих: скорость, надёжность, адаптивность.
- Идёт освоение бюджета.
На текущий момент нет сложности создать собственный браузер на стороннем движке. Их наплодилось не мало и как-то выделиться среди всей этой массы можно только созданием браузера на исключительно своих компонентах, на собственном движке.
Стоит ли заниматься разработкой движка для "заработка", для создания стартапа?
Данный вопрос скорее к сфере его применения. Мне видится несколько направлений:
- Собственно, создание полноценного браузера. Сотрудничество с поисковыми системами, различными сервисами. Создание особых версий для государственных структур.
- Рынок IoT (интернет-вещей), а так же адаптация для телевизоров, приставок, портативных устройств.
- Сервисы на отдельных компонентах браузера. Например, умный анализ контента сайта на риски: запрещенные комментарии, посты от пользователей и так далее. Технический анализ сайтов.
- Продажа движка. Самое простое, написать под компанию.
Кроме того, престиж компании разработчика браузерного движка значительно выше чем у клонов. Именно как технологической компании. Это сказывается на популярности компании и привлекательности для существующих и будущих сотрудников. Но это уже скорее о честолюбии, встать в одном списке с такими компаниями как Google, Mozilla, Microsoft.
Заключение
Без сомнения, создание браузерного движка процесс сложный и требующий значительных ресурсов. Подходить к этой разработки необходимо крайне серьёзно и с чётким планом по развитию. Кроме того, это не тот продукт прибыль от которого можно получать на промежуточном этапе разработки. Да, отдельные компоненты можно адаптировать под нужды компаний, но я уверен, что такой подход только отнимет время и значительно затянет разработку.
Развитие браузерного движка сильно зависит от метода его разработки. Каким он будет: открытым, закрытым?
Я уверен, что если компания занимается развитием браузера на основе стороннего браузерного движка то ей следует серьёзно подумать над перспективой создания собственного.
Компании далёкой от браузеров заняться разработкой браузерного движка тоже можно, и не только для того чтобы создать браузер. Если итоговый продукт будет полноценным браузерным движком превосходящим существующие то он будет востребован. Сферы применения были описаны выше.
Цикл статей
- Браузер != Браузерный движок
- Браузерный движок. Архитектура, работа с памятью.
- HTML парсер. Токенизация, обработка токенов, построение дерева.
Пишем свой парсер. Из каких стадий состоит разбор HTML, в чём сложность и как разогнать HTML парсер в несколько раз. - Кодировки в HTML. Как определяются, как конвертируются.
Напишем свой кодировщик и обсудим положение дел. - CSS парсер и CSS модули. Токенизация, обработка токенов.
Создадим свой CSS парсер. Разберём основные аспекты обработки CSS. Выясним в чём сложность, на что тратятся ресурсы и как написать самый быстрый парсер CSS/модулей. - CSS парсер. Grammar.
Пишем собственный Grammar для CSS модулей формирующий быстрый, человеко-читаемый код. - CSS Selectors. Как устроены, быстрый поиск HTML элементов по селекторам.
- Layout. Скрещиваем HTML и CSS.
Назначаем CSS свойства HTML элементам. Разберём порядок назначения, приоритеты и что делать если CSS постоянно изменяется. - Layout. Потоки. Поддержка CSS свойства display: block.
- Шрифты. Как расчитывать размер символов, строк.
Напишем свой парсер шрифтов. Узнаем, что такое baseline, descender, x-height, как хранятся символы и углубимся в тему расчётов размера символов. - Layout. Поддержка CSS свойства display: inline.
Судьба Modest
Кто-то из читателей, возможно, знает, что я занимаюсь разработкой браузерного движка. В моих публикациях можно найти предыдущие статьи на эту тему.
К сожалению, проект Modest пришлось завершить. Какое-то время проект развивался в компании, в которой я раньше работал. Мне пришлось покинуть компанию. Появились разногласия которые не позволили продолжить разработку проекта. Обычный рабочий процесс, такое бывает.
Не смотря на то, что у меня есть все права на Modest, на код никто не претендует (подписаны бумаги), я решил его "закопать". Чтобы ни у кого не возникало ложных ощущений. Тут надо понимать, что закапывается и весь основной код который развивался вне компании (mycore, myhtml). Но, есть и плюс, возможно, я стал чуть умнее.
Мной было потрачено очень много времени на изучение спецификаций, осознания их, поиск оптимальных алгоритмов, написание черновиков (прототипов), создание myhtml (самый быстрый парсер html) в свободное от работы время, и просто так забросить эту тему я пока не могу. Было потрачено много выходных, праздников, вечеров, ночей.
Теперь я занимаюсь разработкой нового браузерного движка. Разработка с ноля. Имени у него пока нет, только кодовое — lexbor. Вся основа уже написана: работа с памятью, общие алгоритмы, заложена будущая архитектура. Как всегда, всё краше и лучше чем было. В общем, у меня есть самое главное: технология и чёткое видение/понимание как и что развивать.
Одному мне такой проект не потянуть. Если поддержки не найду (финансирования) то прекращу разработку и присоединюсь контребьютером к существующему открытому движку (Blink или Gecko). Попробую побыть там волонтером и реализовать свои идеи. Занимаюсь всем этим исключительно в нерабочее время.
Тут видимо должна быть картинка «ты должен был бороться со злом, а не примкнуть к нему».
Спасибо за внимание!
P.S.: Все ошибки в личку или считать авторским стилем.
Комментарии (49)
sfocusov
20.02.2018 12:18Честно говоря, выглядит как очередное изобретение велосипеда. Хотя, например, Маску удалось его переизобрести и в чём-то (может, и не надолго — посмотрим) переплюнуть тойтоты и форды… Чего и вам желаю!
lastmac Автор
20.02.2018 12:26Велосипеды бывают разные. Базы данных тоже, веб-сервера тоже. Все они чем-то отличаются, у каждого своя «фишка», сильные и слабые стороны. У меня есть четкое видение, что и как я хочу сделать. Конечно, не исключено что я ошибаюсь и это просто обычный велосипед.
untilx
20.02.2018 13:10Так же используется в браузере Tor Browser обеспечивающий анонимное пребывание в сети.
Если за последние несколько лет ничего не изменилось (в чём я сомневаюсь), Tor Browser — это вообще не браузер, а бандл из FF и торовского демона.
Burtanshy
20.02.2018 13:12есть еще один выход — продать свои наработки кому то. может их и не будут даже использовать… но мб и лучше чем «похоронить совсем».
lastmac Автор
20.02.2018 13:18Вы правы, мне предлагали хорошую цену на мои наработки. Была возможность продать + обеспечить поддержку на год. Конечно, нудно было доработать до определенной стадии и нужд компании. Там речь далеко не о браузере. Я думал, общался, но в итоге отказался. Отказался по разным причинам. Одна из таких причин это некрасивый жест, только ушел из компании в которой разрабатывал часть кода и тут же продал. Я ушел не чтобы продать, причины другие, и не хочу чтобы так думали. Плюс условия продажи какие-то мутные были.
Kain_Haart
20.02.2018 13:12На Servo не смотрели? https://servo.org/
lastmac Автор
20.02.2018 13:19Да, они меня даже как-то хвалили, мол круто как вышло у меня. Года два назад звали заниматься ресерчем.
fapsi
20.02.2018 14:50Допустимо ли использовать Gecko в коммерческих (прямая продажа, подписка, etc) проектах? И необходимо ли раскрывать весь код в соответствии с Mozilla Public License 2.0?
lastmac Автор
20.02.2018 15:33Я не юрист, от слова совсем. MPL так же требует открытости. То есть, код где она используется так же должен быть под этой лицензией. А вот можно ли продавать её или нет, не могу понять. Но я не уверен, тут нужен специалист. Так же, люди пишут, что лицензия не совместима с GPL.
RifleR
20.02.2018 15:22Добавьте в статью, что WebKit еще использует Epiphany Browser, он же GNOME Web.
OlegMax
20.02.2018 16:04не выйдет просто так продолжить разработку чужого движка. То есть, взять программистов и поставить им задачу — пишите браузерный движок.
Тема статьи — как писать браузерный движок. П — последовательность.
rumkin
20.02.2018 16:22Начинание заслуживающее уважения.
Правда в статье ничего не сказано о будущей лицензии и о подходе к разработке. JS-движок тоже свой планируется или готовый?
lastmac Автор
20.02.2018 16:38Спасибо!
Лицензия, скорее всего Apache 2.0. Довольно свободная лицензия. Это обсуждаемо. JS, как уже не раз писал в статьях, возьмём поиграть у братьев старших. Скорее всего V8, не уверен. Но факт, что ещё и JS писать я припухну. У меня всё же семья, ребёнок, работа :)
amarao
20.02.2018 18:25Вероятность написать полноценный движок (такой, который будет нос-в-нос с FF/хромом) — маленькая.
А вот разработать учебный движок (который ставит своей целью понятность исходников и удобность для написания) — очень даже.
Кстати, для операционных систем уже случилось чудо, и учебная ОС (minix) — самая распространённая ОС в мире.lastmac Автор
20.02.2018 19:22Всё верно, но писать мы будем прям вот настоящий движок. Обгоним по скоростям существующие и обозначим главные цели: простота, скорость, безопасность, встраиваемость.
Но, опять же, вы правы, речь о том чтобы идти нос-в-нос с FF/хромом быть не может. Если найду инвестора, может заинтересую кого из БОЛЬШИХ компаний, то заживём, а если нет то буду контребьютить в блинк или геку, и Бог с ними.
Циклом статей я хочу показать, что не стоит боятся, всё вполне реально. Собственно, докажу это.amarao
20.02.2018 19:34Очень трудно найти инвестора в ситуации, когда все три лидера рынка предлагают «такое же, но бесплатно и с отгрузкой в тот же день».
А вот как учебно-академический проект оно может реально взлететь, потому что, насколько я понимаю браузерную войну, в ней ради победы (скорости/фичи) уже давно принесли в жертву всё.
Вот сделать что-то такое, где порог вхождения (не во «встроить движок в свой браузер») будет существенно ниже, чем для существующих проектов — это круто. Это реально киллер-фича, которой нет ни у одного из существующих браузеров.
Более того, как показывает практика, академия медленно запрягает, зато потом получается круто.lastmac Автор
20.02.2018 19:54Да, вы мыслите в верном направлении. Собственно, особых надежд на БОЛЬШИХ и нет, у них проблем хватает. Но, думаю многим будет интересно узнать как оно внутри с примерами кода и примерами как использовать.
ozonar
21.02.2018 11:58Очень трудно найти инвестора в ситуации, когда все три лидера рынка предлагают «такое же, но бесплатно и с отгрузкой в тот же день».
Vivaldi же родился и хорошо себя чувстуетlastmac Автор
21.02.2018 12:25Вроде у них на сайте написано, что они без единого инвестора. Всё сами. Что, конечно же, вызывает уважение.
mbait
20.02.2018 21:20Я слышал, что одной из фундаментальных проблем разработки браузерного движка является несоответствие стандарту большого количество сайтов. И много сил тратится на создание алгоритмов "восстановления" после ошибки. Если же этот этап пропустить, то получится, что многие сайты не будут правильно отображаться, что сильно затруднит распространение своего продукта. Одновременно с этой проблемой существует и смежная — сайт правильно работает/отображается только в браузере X. Мы видели это с Internet Explorer, мы видим это с Google Chrome. Насколько мне известно, когда Chrome только пытался завоевать рынок, в нём было куча логики для поддержки IE-only сайтов.
К чему это я? Сам стандарт реализовать не проблема, это вы верно говорите. Что делать с тяжёлым наследием? Мне пока видится только одно решение — встроить в свой движок другой и предлагать пользователю использовать его на избранных сайтах.
lastmac Автор
20.02.2018 22:02Эти тяжелые времена прошли. Благо они там на верхах договорились. Остаются лишь особенности реализации в том или ином браузере.
Foror
21.02.2018 10:31Почему бы не сосредоточиться на разработке браузера для веб-приложений? Сделайте основную базу из HTML и CSS, чтобы можно было рендерить GUI. Добавьте вебсокет или другой апи для IPC с бекэндом. Оптимизируйте, чтобы по памяти занимало крохи, запускалось на любой табуретке без тормозов и вам гарантирован успех.
А потом уже делайте полноценный браузер на донатах или коммерческих продажах выше приведенного решения.
Я это даже вижу без джаваскрипта, когда можно все это дело заэмбендить в ту же джаву и отмапить DOM API на джава код. Я бы даже помог на этом участке.
MikailBag
21.02.2018 22:31Джава то зачем?
Если все равно будет песочница, надо сразу машинный код (не сарказм). Чтобы можно было хоть джаву, хоть си, хоть жс.Foror
22.02.2018 07:48Про песочницу ниже комментировал habrahabr.ru/post/349512/?reply_to=10681516#comment_10681100
>Джава то зачем?
Хороший и популярный ЯП для кроссплатформенной разработки. После джавы можно один в один сделать C++ и С# маппинг DOM API. У Rust и Go достаточно активное и компетентное комьюнити, чтобы они самостоятельно сделали эмбединг этого движка. Остаётся Node.js, но там и маппить, то нечего плевая работа.MikailBag
22.02.2018 12:52Посмотрите. Есть, допустим, винда. Она не заставляет писать на джаве. Каждый пишет на том языке, на котором хочет.
Я считаю, что и в вебе должно быть тоже самое. Вы пишете, что Джава — "Хороший и популярный ЯП для кроссплатформенной разработки". Но некоторые её не любят, для некоторых она слишком тормозная и т.д. Возможность запуска кода на любом языке удовлетворит всех.
Также это позволит 1) не тащить в стандарт джаву 2) Не иметь зоопарк версий джавы
(Он заменяется зоопарком архитектур, который не такой и значительный).
После джавы можно один в один сделать C++ и С# маппинг DOM API.
Возможно я вас не так понял, но вы предлагаете для каждого языка тащить в стандарт его рантайм?
Foror
22.02.2018 13:16+1>Я считаю, что и в вебе должно быть тоже самое.
Но в вебе не тоже самое. Все пишут на JavaScript или извращаются с трансляцией ЯП в JavaScript. Решить проблему хотят с помощью WebAssembly, но сейчас это очень обрезанный рантайм и все ждут следующую версию WebAssembly, которая уже как год проектируется.
По сути WebAssembly, та же JVM, но со своими тараканами. Поэтому не нужно «для каждого языка тащить в стандарт его рантайм». В стандарте есть описание байт-кода и вам нужно натянуть рантайм конкретного языка на этот байт-код.
Но когда выйдет WebAssemlbly 2.0 неизвестно. Поэтому сейчас можно сделать HTML и CSS движок, отказавшись от JavaScript, замапив работу с DOM напрямую, на методы конкретного ЯП. Тем самым можно манипулировать DOM из своего любимого ЯП, не нагружая рендеринг HTML и CSS прослойкой из JavaScript движка, полностью отказавшись от него.
Т.е. использовать HTML и CSS движок как кроссплатформенную GUI библиотеку, заместо QT и подобных решений. И ничего более я не предлагаю ) Единственно, для манипуляций с DOM, необходимо соблюдать все W3C стандарты. А значит придеться столкнуться с тем, что не всё API от W3C красиво ляжет на статически типизированные языки. Поэтому потребуется особый маппинг такого API. Но это проблема уже конкретного ЯП, а само стандартное API не должно как-либо изменяться.
skolot
21.02.2018 11:53У меня с некоторых пор вертится мысль — браузер нынче стал платформой по доставке кроссплатформенных приложений. И когда wasm окончательно выйдет — приложения можно будет писать на любом языке. Хотя этому всё-равно будет сопутствовать много сложностей: браузерное API и DOM API во многом спроектировано под работу с js и вообще имеет большое наследие — не избежать уймы костылей. А что если сделать wasm-ориентированный браузер, в котором рендеринг UI из wasm будет существенно проще? Сделать платформу которая действительно ориентированна на распространение веб-приложений. Вот тебе и особенность. Просто одно дело создать «ещё один браузер», другое — создать браузер с упором на другой сегмент разработчиков/целевой аудитории.
lastmac Автор
21.02.2018 12:33Так оно и есть. В самой первой своей статье, вроде в первой, я как раз и писал, что хочу добиться лёгкой встраиваемости движка. Там же я упоминал про игрушки, ui и что-то ещё. По этой причине я и пишу всё на Си без зависимостей. Это обеспечит лёгкую переносимость.
Я думал в направлении создать движок с простым и функциональным апи и предоставлять его по двум лицензиям: бесплатно для бесплатных/открытых проектов, платно для коммерческих. Именно с уклонов на веб-приложения.
Тут мне пока не понятно. Я больше программист. Решиться двигаться исключительно в одну сторону сам не могу. Нужен какой-то понимающий в этом деле партнёр, наверное.Foror
21.02.2018 12:59>Нужен какой-то понимающий в этом деле партнёр, наверное.
Если у вас будет, плохонький, но работающий прототип, с рендерингом HTML и CSS, то на электронную почту вам куча партнёров насыпится. Думаю можно даже на индигого стартануть с этим прототипом.
Я могу помочь в плане эмбединга с джавой и маппингом DOM API. Маппинг DOM API на джаву у меня готов, путем парсинга IDL в исхдниках Chromium. Сейчас работаю над веб-фреймворком по типу Angular, который базируется на этом маппинге (т.е. все пишется на джаве).
По итогу могу сделать сайт проекта, реально работающие приложения, на которые можно ссылаться как на примеры. Может быть даже сделаю какой-нибудь маркетинг в интернете, насколько я это умею делать.
Foror
21.02.2018 14:16Кстати, sciter.com/blog посмотрите на похожую идею. Реализация ужасна, маркетинг ужасен, но люди ведут блог с 2006 года, может даже что-то зарабатывают…
rumkin
21.02.2018 16:27Иногда бесплатные проекты превращаются в платные, любого разработчика отпугнет перспектива переписывать код в случае коммерциализации. Юридический интерфейс должен быть максимально простым: достаточно обязать указывать название в конечном продукте или на упаковке. А зарабатывать на внедрении, поддержке или инфраструктуре.
Foror
21.02.2018 12:42С wasm выйдет сложнее. Во-первых, непонятно когда будет wasm 2.0, а во-вторых, затем еще нужно рантайм каждого ЯП портировать или ждать пока портируют.
Проще отмапить DOM API на конкретный ЯП и эмдедить движок в этот ЯП. Это можно хоть сейчас делать и это всем нужно. И более того, этот маппинг DOM API также будет востребован в рантайме wasm 2.0
capslocky
21.02.2018 13:15Писать свой браузер — это в самом деле очень круто. Интересно видеть, что "большие" браузеры довольно активно релизятся.
Chrome:
https://www.chromestatus.com/features/schedule
Firfox:
https://wiki.mozilla.org/Firefox/Roadmap/Updates#2018-02-12
https://wiki.mozilla.org/RapidRelease/Calendar
https://wiki.mozilla.org/Features/Release_Tracking
Safari:
https://webkit.org/status/
https://webkit.org/blog/8088/release-notes-for-safari-technology-preview-49/
https://developer.apple.com/safari/technology-preview/release-notes/
fedorro
Это же тьма кода… При билде Андроида, например, самый долго компилируемый компонент, по моим наблюдениям, — это браузерный движек. Даже гиганты, с кучей финансов не успевают за всеми этими новомодными веб-стандартами, и так, чтобы не тормозило.
Можно, конечно, попробовать под импортозамещение это сделать: Даешь «Чебурек» для Чебурашки.
lastmac Автор
Вы правы, кода там очень много, очень-очень много. Исходники Blink, примерно, 1ГБ весят.
Я не любитель этого слова «импортозамещение» какое-то оно странное, на обман похоже. Но ход мысли верный.
Мусолю тему движков давно, объём я хорошо представляют, мне кажется задача решаема. Все сложные места я давно «попробовал». Именно из-за объёма кода я не берусь говорить, что смогу сделать один, нет, не смогу, даже если буду заниматься фултайм. Но попытаться всё же стоит, чего без дела сидеть?! :)
fedorro
Нужен план, оценка трудоемкости и бюджета — без этого никто финансирование даст. И даже когда эти оценки будут, боюсь они будут такими страшными, что всё равно никто на это не пойдет. Так что можно придумать что-то более реальное.
lastmac Автор
Есть и план, и оценки. Они не такие страшные. Сложность создания браузерного движка сильно преувеличена. Более того, проект Модест подавал заявку в фонд содействия инновациям и стал одним из победителей программы Старт-1 (отдельное спасибо Стасу Ашманову за помощь в подготовке и написании бумаг). Но деньги мы так и не взяли. Там 2М на год, а этого даже не хватит на содержания себя. Зато подтверждение нужности, верного направления мы получили.
Мой бывший руководитель любил шутить так: «господа из влиятельных лагерных урок за размах уважали меня»
Arris
2М рублей?
lastmac Автор
Да, рублей. Если бы $ то статьи были бы совсем другие :)
Arris
Да, действительно, это ниачом. Зарплата одного разработчика, край двух энтузиастов.