Pull to refresh

Comments 55

Это же тьма кода… При билде Андроида, например, самый долго компилируемый компонент, по моим наблюдениям, — это браузерный движек. Даже гиганты, с кучей финансов не успевают за всеми этими новомодными веб-стандартами, и так, чтобы не тормозило.
Можно, конечно, попробовать под импортозамещение это сделать: Даешь «Чебурек» для Чебурашки.
Вы правы, кода там очень много, очень-очень много. Исходники Blink, примерно, 1ГБ весят.
Я не любитель этого слова «импортозамещение» какое-то оно странное, на обман похоже. Но ход мысли верный.
Мусолю тему движков давно, объём я хорошо представляют, мне кажется задача решаема. Все сложные места я давно «попробовал». Именно из-за объёма кода я не берусь говорить, что смогу сделать один, нет, не смогу, даже если буду заниматься фултайм. Но попытаться всё же стоит, чего без дела сидеть?! :)
Нужен план, оценка трудоемкости и бюджета — без этого никто финансирование даст. И даже когда эти оценки будут, боюсь они будут такими страшными, что всё равно никто на это не пойдет. Так что можно придумать что-то более реальное.
Есть и план, и оценки. Они не такие страшные. Сложность создания браузерного движка сильно преувеличена. Более того, проект Модест подавал заявку в фонд содействия инновациям и стал одним из победителей программы Старт-1 (отдельное спасибо Стасу Ашманову за помощь в подготовке и написании бумаг). Но деньги мы так и не взяли. Там 2М на год, а этого даже не хватит на содержания себя. Зато подтверждение нужности, верного направления мы получили.

Мой бывший руководитель любил шутить так: «господа из влиятельных лагерных урок за размах уважали меня»
Да, рублей. Если бы $ то статьи были бы совсем другие :)
Да, действительно, это ниачом. Зарплата одного разработчика, край двух энтузиастов.
Честно говоря, выглядит как очередное изобретение велосипеда. Хотя, например, Маску удалось его переизобрести и в чём-то (может, и не надолго — посмотрим) переплюнуть тойтоты и форды… Чего и вам желаю!
Велосипеды бывают разные. Базы данных тоже, веб-сервера тоже. Все они чем-то отличаются, у каждого своя «фишка», сильные и слабые стороны. У меня есть четкое видение, что и как я хочу сделать. Конечно, не исключено что я ошибаюсь и это просто обычный велосипед.
Так же используется в браузере Tor Browser обеспечивающий анонимное пребывание в сети.

Если за последние несколько лет ничего не изменилось (в чём я сомневаюсь), Tor Browser — это вообще не браузер, а бандл из FF и торовского демона.
есть еще один выход — продать свои наработки кому то. может их и не будут даже использовать… но мб и лучше чем «похоронить совсем».
Вы правы, мне предлагали хорошую цену на мои наработки. Была возможность продать + обеспечить поддержку на год. Конечно, нудно было доработать до определенной стадии и нужд компании. Там речь далеко не о браузере. Я думал, общался, но в итоге отказался. Отказался по разным причинам. Одна из таких причин это некрасивый жест, только ушел из компании в которой разрабатывал часть кода и тут же продал. Я ушел не чтобы продать, причины другие, и не хочу чтобы так думали. Плюс условия продажи какие-то мутные были.
Да, они меня даже как-то хвалили, мол круто как вышло у меня. Года два назад звали заниматься ресерчем.
Заниматься ресёрчем браузера, это ли не то чего вы хотите достичь, судя по последнем абзацу?
Да, это очень круто. Но я всё же в мечтах создать свой.
UFO just landed and posted this here
Я не юрист, от слова совсем. MPL так же требует открытости. То есть, код где она используется так же должен быть под этой лицензией. А вот можно ли продавать её или нет, не могу понять. Но я не уверен, тут нужен специалист. Так же, люди пишут, что лицензия не совместима с GPL.

Добавьте в статью, что WebKit еще использует Epiphany Browser, он же GNOME Web.

не выйдет просто так продолжить разработку чужого движка. То есть, взять программистов и поставить им задачу — пишите браузерный движок.

Тема статьи — как писать браузерный движок. П — последовательность.

Начинание заслуживающее уважения.


Правда в статье ничего не сказано о будущей лицензии и о подходе к разработке. JS-движок тоже свой планируется или готовый?

Спасибо!
Лицензия, скорее всего Apache 2.0. Довольно свободная лицензия. Это обсуждаемо. JS, как уже не раз писал в статьях, возьмём поиграть у братьев старших. Скорее всего V8, не уверен. Но факт, что ещё и JS писать я припухну. У меня всё же семья, ребёнок, работа :)

Есть тот же JerryScript от Самсунг и тоже под Apache 2.0. Он заточен на IoT. Если взять его, то для продукта вырисовывается вполне востребованная ниша.

Вполне возможно вы правы, но до момента выбора движка JS ещё далеко.
Вероятность написать полноценный движок (такой, который будет нос-в-нос с FF/хромом) — маленькая.

А вот разработать учебный движок (который ставит своей целью понятность исходников и удобность для написания) — очень даже.

Кстати, для операционных систем уже случилось чудо, и учебная ОС (minix) — самая распространённая ОС в мире.
Всё верно, но писать мы будем прям вот настоящий движок. Обгоним по скоростям существующие и обозначим главные цели: простота, скорость, безопасность, встраиваемость.

Но, опять же, вы правы, речь о том чтобы идти нос-в-нос с FF/хромом быть не может. Если найду инвестора, может заинтересую кого из БОЛЬШИХ компаний, то заживём, а если нет то буду контребьютить в блинк или геку, и Бог с ними.

Циклом статей я хочу показать, что не стоит боятся, всё вполне реально. Собственно, докажу это.
Очень трудно найти инвестора в ситуации, когда все три лидера рынка предлагают «такое же, но бесплатно и с отгрузкой в тот же день».

А вот как учебно-академический проект оно может реально взлететь, потому что, насколько я понимаю браузерную войну, в ней ради победы (скорости/фичи) уже давно принесли в жертву всё.

Вот сделать что-то такое, где порог вхождения (не во «встроить движок в свой браузер») будет существенно ниже, чем для существующих проектов — это круто. Это реально киллер-фича, которой нет ни у одного из существующих браузеров.

Более того, как показывает практика, академия медленно запрягает, зато потом получается круто.
Да, вы мыслите в верном направлении. Собственно, особых надежд на БОЛЬШИХ и нет, у них проблем хватает. Но, думаю многим будет интересно узнать как оно внутри с примерами кода и примерами как использовать.
Очень трудно найти инвестора в ситуации, когда все три лидера рынка предлагают «такое же, но бесплатно и с отгрузкой в тот же день».

Vivaldi же родился и хорошо себя чувстует
Вроде у них на сайте написано, что они без единого инвестора. Всё сами. Что, конечно же, вызывает уважение.
Судя по достаточно солидному количеству сайтов в закладках и на начальной странице при установке браузера, они таки нашли способ монетизировать браузер.
Они как раз наоборот, они делают браузер, а не движок. Т.е. имеют аудиторию пользователей (что само по себе ценно). А движок у них то ли WebKit, то ли blink.

Я слышал, что одной из фундаментальных проблем разработки браузерного движка является несоответствие стандарту большого количество сайтов. И много сил тратится на создание алгоритмов "восстановления" после ошибки. Если же этот этап пропустить, то получится, что многие сайты не будут правильно отображаться, что сильно затруднит распространение своего продукта. Одновременно с этой проблемой существует и смежная — сайт правильно работает/отображается только в браузере X. Мы видели это с Internet Explorer, мы видим это с Google Chrome. Насколько мне известно, когда Chrome только пытался завоевать рынок, в нём было куча логики для поддержки IE-only сайтов.


К чему это я? Сам стандарт реализовать не проблема, это вы верно говорите. Что делать с тяжёлым наследием? Мне пока видится только одно решение — встроить в свой движок другой и предлагать пользователю использовать его на избранных сайтах.

Эти тяжелые времена прошли. Благо они там на верхах договорились. Остаются лишь особенности реализации в том или ином браузере.

Почему бы не сосредоточиться на разработке браузера для веб-приложений? Сделайте основную базу из HTML и CSS, чтобы можно было рендерить GUI. Добавьте вебсокет или другой апи для IPC с бекэндом. Оптимизируйте, чтобы по памяти занимало крохи, запускалось на любой табуретке без тормозов и вам гарантирован успех.


А потом уже делайте полноценный браузер на донатах или коммерческих продажах выше приведенного решения.


Я это даже вижу без джаваскрипта, когда можно все это дело заэмбендить в ту же джаву и отмапить DOM API на джава код. Я бы даже помог на этом участке.

Джава то зачем?
Если все равно будет песочница, надо сразу машинный код (не сарказм). Чтобы можно было хоть джаву, хоть си, хоть жс.

Про песочницу ниже комментировал habrahabr.ru/post/349512/?reply_to=10681516#comment_10681100

>Джава то зачем?
Хороший и популярный ЯП для кроссплатформенной разработки. После джавы можно один в один сделать C++ и С# маппинг DOM API. У Rust и Go достаточно активное и компетентное комьюнити, чтобы они самостоятельно сделали эмбединг этого движка. Остаётся Node.js, но там и маппить, то нечего плевая работа.

Посмотрите. Есть, допустим, винда. Она не заставляет писать на джаве. Каждый пишет на том языке, на котором хочет.
Я считаю, что и в вебе должно быть тоже самое. Вы пишете, что Джава — "Хороший и популярный ЯП для кроссплатформенной разработки". Но некоторые её не любят, для некоторых она слишком тормозная и т.д. Возможность запуска кода на любом языке удовлетворит всех.
Также это позволит 1) не тащить в стандарт джаву 2) Не иметь зоопарк версий джавы
(Он заменяется зоопарком архитектур, который не такой и значительный).


После джавы можно один в один сделать C++ и С# маппинг DOM API.

Возможно я вас не так понял, но вы предлагаете для каждого языка тащить в стандарт его рантайм?

>Я считаю, что и в вебе должно быть тоже самое.
Но в вебе не тоже самое. Все пишут на 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 не должно как-либо изменяться.
UFO just landed and posted this here
У меня с некоторых пор вертится мысль — браузер нынче стал платформой по доставке кроссплатформенных приложений. И когда wasm окончательно выйдет — приложения можно будет писать на любом языке. Хотя этому всё-равно будет сопутствовать много сложностей: браузерное API и DOM API во многом спроектировано под работу с js и вообще имеет большое наследие — не избежать уймы костылей. А что если сделать wasm-ориентированный браузер, в котором рендеринг UI из wasm будет существенно проще? Сделать платформу которая действительно ориентированна на распространение веб-приложений. Вот тебе и особенность. Просто одно дело создать «ещё один браузер», другое — создать браузер с упором на другой сегмент разработчиков/целевой аудитории.
Так оно и есть. В самой первой своей статье, вроде в первой, я как раз и писал, что хочу добиться лёгкой встраиваемости движка. Там же я упоминал про игрушки, ui и что-то ещё. По этой причине я и пишу всё на Си без зависимостей. Это обеспечит лёгкую переносимость.

Я думал в направлении создать движок с простым и функциональным апи и предоставлять его по двум лицензиям: бесплатно для бесплатных/открытых проектов, платно для коммерческих. Именно с уклонов на веб-приложения.

Тут мне пока не понятно. Я больше программист. Решиться двигаться исключительно в одну сторону сам не могу. Нужен какой-то понимающий в этом деле партнёр, наверное.
>Нужен какой-то понимающий в этом деле партнёр, наверное.
Если у вас будет, плохонький, но работающий прототип, с рендерингом HTML и CSS, то на электронную почту вам куча партнёров насыпится. Думаю можно даже на индигого стартануть с этим прототипом.

Я могу помочь в плане эмбединга с джавой и маппингом DOM API. Маппинг DOM API на джаву у меня готов, путем парсинга IDL в исхдниках Chromium. Сейчас работаю над веб-фреймворком по типу Angular, который базируется на этом маппинге (т.е. все пишется на джаве).

По итогу могу сделать сайт проекта, реально работающие приложения, на которые можно ссылаться как на примеры. Может быть даже сделаю какой-нибудь маркетинг в интернете, насколько я это умею делать.
Кстати, sciter.com/blog посмотрите на похожую идею. Реализация ужасна, маркетинг ужасен, но люди ведут блог с 2006 года, может даже что-то зарабатывают…

Собственно, исследователей и страждущих легковесного встраиваемого/переносимого решения много. Можно добавить electrino, альтернатива electron'у для десктопных приложений.

Иногда бесплатные проекты превращаются в платные, любого разработчика отпугнет перспектива переписывать код в случае коммерциализации. Юридический интерфейс должен быть максимально простым: достаточно обязать указывать название в конечном продукте или на упаковке. А зарабатывать на внедрении, поддержке или инфраструктуре.

С wasm выйдет сложнее. Во-первых, непонятно когда будет wasm 2.0, а во-вторых, затем еще нужно рантайм каждого ЯП портировать или ждать пока портируют.

Проще отмапить DOM API на конкретный ЯП и эмдедить движок в этот ЯП. Это можно хоть сейчас делать и это всем нужно. И более того, этот маппинг DOM API также будет востребован в рантайме wasm 2.0
UFO just landed and posted this here
Да, у них гонки там, почти на выживание.
Вы почему-то совсем обошли главную проблему: миру не нужно большое количество движков. Для вебмастеров каждый новый движок – боль, поэтому поддерживать ваш они не будут до тех пор, пока он не появится в аналитике в достаточном количестве. А это значит, что у всех пользователей вашего движка будут проблемы с сайтами. Это допустимо для личного проекта, создаваемого с целью получения опыта, но это неприемлемо для массового продукта.

Обычные пользователи не выбирают браузеры по движку. Они выбирают именно «браузеры», т.е. продукты со своими особенностями и возможностями. Поэтому во всех смыслах более выгодно вкладываться в уже существующие открытые проекты и вместе двигать веб. Есть риск закрытия кода? Конечно, есть. Но если такое случится, то вы просто форкнете последнюю версию и продолжите его развитие, потому что у вас уже накопится опыт работы с этим движком. Вы сможете продолжить с текущего уровня развития, а не с нуля.

P.S. Откуда пошёл миф, что Яндекс.Браузер – это только свой поиск и сервисы? Это даже близко не так. Так же вагон других особенностей.
То что новый движок нужен, у меня сомнений не вызывает. Радует, что кто-то это не только понимает, но и делает.
Но в статье не увидел конкретики.
Насколько ваша реализация быстра относительно уже существующих?
Насколько быстрее парсит чем вебкит и блинк? Насколько быстрее рендерит?
Уверен, если появятся эти цифры заинтересованных будет заметно больше.
Sign up to leave a comment.

Articles