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

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


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


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

+3

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

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

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


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

+8

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

+2

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

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

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

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

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

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

Кто в теме, объясните пожалуйста.
+1
Код для работы с MHTML никуда не делся.
75-ая версия нормально открывает сохраненные *.mht-файлы, а на Android, насколько я знаю, MHTML используется для сохранения offline pages.
Почему выпилили явную возможность сохранения на десктопах — вопрос хороший, на баг-трекере уже об этом спросили, причем сами же участники проекта.
Возможно это связано с тем, что при загрузке MHTML, уже давно осознанно отключено выполнение JavaScript на страницах по соображениям безопасности за неимением возможности как-либо это пофиксить в принципе (кстати, репортер получил за эту дыру награду в 1000$), в итоге, учитывая тотальную обскриптованность современного веба, эту фичу посчитали малополезной для обычных пользователей и выпилили из интерфейса. Но это только догадки.
+1
Она и так была отключена по-умолчанию для всех смертных, и только некоторые, кому действительно нужно — гуглили как её включить у себя обратно. А так и это выпилили. Кому мешала отключенная функция — действительно хз. Тем более что на андройде она осталась.
+1
Я нашел обсуждение:
groups.google.com/a/chromium.org/forum/#!msg/offline-dev/qO1B8kkWkoM/kO30ODfRBgAJ

TL;DR: разработчики решили, что эта фича нужна только для других разработчиков, и убрали флаг из интерфейса.

Опция командной строки "--save-page-as-mhtml" осталась и работает.
0
Только что проверил, но опция --save-page-as-mhtml НЕ работает в Win 7.
Похоже, придётся в старых версиях сохранять mhtml, а в новых уже бегать по вебу.

Теперь я на своей шкуре ощутил заботу Google.
0
Вы явно что-то делаете не так.
Всё отлично работает, более того, при запуске с этой опцией вариант «Webpage, Single file» становится активным по умолчанию.
https://habrastorage.org/webt/hk/xx/lt/hkxxltuufdbs0-1s7fjoea0p0k0.png
image
+2
Спасибо за статью.
Вроде вполне логично, но никогда не задумывался о таких кейсах использования этого движка.
Only those users with full accounts are able to leave comments. , please.