Ads
Comments 34
Не особо вчитывался, но есть что-то в этой идее, ибо как понимаю качество кода там высокое, все кому не лень статикчекеры прогоняют, конкурсы на уязвимости проходят.
Скажите честно, вы действительно изучали код Chromiun?
Если да, то каких именно его частей?
Я с этой кодовой базой работаю каждый день, и могу сказать, что он написан действительно очень и очень неплохо, насколько это возможно для такого большого и сложного проекта.
Используются современные стандарты плюсов, код покрывается тестами и постоянно рефакторится, всякие ASAN'ы и подобное используются.
Да, иногда попадаются плохо документированные или страшнодревние места (типа layout'илки в Blink), но и по их улучшению работа ведётся.
Поэтому не совсем понятен ваш наезд на качество кода Chromium.
Изучаю webrtc. Постоянно возникает желание прибить программистов за их код. Я не помню, чтобы у меня какая-то фича завелась сразу же. Последнее AudioDeviceModule. Если создать свой указатель даже на стандартный код и передать в CreatePeerConnectionFactory, опа не работает. Если код надо постоянно рефакторить, значит он изначально делается некорректно. Этот рефакторинг бесит. Если в одной версии работает, то выкачиваем более новую версию — опа не работает. Да как же так-то :) Возвращают указатель, который может быть nullptr и его вызывают без проверки на nullptr — могут получить av. Но кого это волнует :)
До 64 версии msvc++ компилировал библиотеку FFmpeg — а потом вдруг перестал.
Приходится все заново пересобирать. И это только часть проблем! Это нормально?
Изучаю webrtc
WebRTC — это все-таки не Chromium, обсуждаемый в статье,
Подавляюще большая часть WebRTC для Chromium — это внешняя зависимость, и хоть и он и хостится на googlesource, по факту его пилит совершенно другая команда, и в разработке так же активно участвуют, например, люди из Mozilla и многих других компании, и более того — Mozilla использует тот же самый код у себя в Firefox.
Если код надо постоянно рефакторить, значит он изначально делается некорректно.
Рефакторится старый код.
Что для проекта с более чем 10-летней историей (а некоторые компоненты ведут свою родословную вообще с начала 2000-х), который активно развивается, является естественным и необходимым процессом.

Приглашаю Вас оставить гневный, но конструктивный комментарий в WebRTC баг трекере. Судя по объему претензий в Вашем комментарии, может быть даже Вам стоит составить несколько баг-репортов.


Если это действительно косяк, то его исправят. Если вы используте какие-то недокументированные, не стандартизованные вещи, то никто не гарантирует, что оно при следующем обновлении не сломается. Так везде.


Подпишитесь на mailing list, что бы быть в курсе грядущих изменений. Если API как-то меняется, то заранее бросают PSA там. Там же можно попросить о помощи и посоветоваться о вашем сценарии использования.

Так-то в Хромиуме есть еще и Views, так что вполне реально и даже нативный GUI на нем делать.

Тянуть Chromium на десктоп — это так себе занятие. В принципе не нужно тянуть монстра без необходимости. Авторы приложений на електроне должны приплачивать пользователям за используемые ресурсы.

Вы статью читали? Речь идёт вообще не про Electron.
Никакой монструозности тут не будет, все ненужно вырежет линковщик при линковке.


P.S. А на Electron кстати тоже есть хорошие приложения, например отличный VS Code.

Не обращайте внимания, у комментатора видимо душевная травма от электрона, что видно по его комментариям, а о чём на самом деле статья он так и не понял.

Многие жалуются на Electron, а хотелось бы
почитать более подробную статью с результатами профилирования или более объективного анализа. Может не так уж и страшен чёрт как его малюют.

30 Гб кода загрузить только для того, чтобы сделать загрузку странички — это отличная работа в мире :)
А вы посмотрите, какие оптимизации применяют современные JS- и WASM-движки для ускорения производительности (JIT там только вершина айсберга), какое количество медиа- и стриминговых технологий поддерживают современные браузеры (плюс интеграция с другими устройствами типа chromecast, DLNA и DIAL), почитайте про актуальные стандарты CSS (это вообще по сути дела тьюринг-полный язык теперь), в конце концов, загляните в современные веб-стандарты от W3C и WHATWG, где будут не только HTML и все что с ним связано, но и SVG, WebAudio, WebGL, WebUSB, Accessibility (в том числе распознавание и синтез речи), и еще очень много всего.
И браузер все это должен поддерживать. И работать на разных платформах, от десктопов до крохотных телефонов и встраиваемых систем. И давать разработчикам удобно иметь с этим дело.
Поэтому когда речь заходит о современных браузерах, простым «сделать загрузку странички» тут дело далеко не ограничивается. современные браузеры — это среды исполнения веб-приложений, по сложности они уже приблизились чуть ли не к операционным системам и IDE, и это вовсе не потому что их разработчикам просто так захотелось.
У него бэк на C++, иначе был таким же тупым, как все, что делается на электроне

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

Если не хочется тащить Хромиум в кодовую базу, теоретически можно собирать его отдельно как набор shared-библиотек (это у них называется component build) и цеплять их. Правда, хедеры все равно понадобятся.
есть проект cef для встраивания chromium. Довольно удобная вещь и там заголовков минимум
Это вообще другое, CEF — это для встраивания хромиумовского WebView в приложения.
Статья — про использование проекта Chromium, а CEF — это большой и хорошо работающий пример использования проекта Chromium.

Статья — про использование наработок проекта Chromium в качестве основы для своего приложения, а CEF — проект для встраивания браузера в своё приложение.

Кто-нибудь, скажите пожалуйста, почему в Google 75 выпилили поддержку *.mhtml?
Быдлокод в Chromium зашёл так далеко, что поломал поддержку *.mhtml и сотрудники Google решили не париться над его исправлением?
Или *.mhtml ухудшает загрузку страниц?

Кто в теме, объясните пожалуйста.
Код для работы с MHTML никуда не делся.
75-ая версия нормально открывает сохраненные *.mht-файлы, а на Android, насколько я знаю, MHTML используется для сохранения offline pages.
Почему выпилили явную возможность сохранения на десктопах — вопрос хороший, на баг-трекере уже об этом спросили, причем сами же участники проекта.
Возможно это связано с тем, что при загрузке MHTML, уже давно осознанно отключено выполнение JavaScript на страницах по соображениям безопасности за неимением возможности как-либо это пофиксить в принципе (кстати, репортер получил за эту дыру награду в 1000$), в итоге, учитывая тотальную обскриптованность современного веба, эту фичу посчитали малополезной для обычных пользователей и выпилили из интерфейса. Но это только догадки.
Она и так была отключена по-умолчанию для всех смертных, и только некоторые, кому действительно нужно — гуглили как её включить у себя обратно. А так и это выпилили. Кому мешала отключенная функция — действительно хз. Тем более что на андройде она осталась.
UFO landed and left these words here
Только что проверил, но опция --save-page-as-mhtml НЕ работает в Win 7.
Похоже, придётся в старых версиях сохранять mhtml, а в новых уже бегать по вебу.

Теперь я на своей шкуре ощутил заботу Google.
UFO landed and left these words here
Спасибо за статью.
Вроде вполне логично, но никогда не задумывался о таких кейсах использования этого движка.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

October 15, 1998

Location

Россия

Employees

5001–10000 человек

Registered

9 August 2008