[HN Gopher] Cobalt - a stripped down Chromium for apps, Linux an...
___________________________________________________________________
Cobalt - a stripped down Chromium for apps, Linux and embedded
systems
Author : graderjs
Score : 156 points
Date : 2022-11-22 14:34 UTC (8 hours ago)
(HTM) web link (cobalt.dev)
(TXT) w3m dump (cobalt.dev)
| phh wrote:
| PSA: I strongly recommend not to use Cobalt (unless of course you
| are a Google employee, with support from Cobalt team).
|
| Cobalt's roadmap is 100% Youtube on TV roadmap. I've never seen
| anyone use Cobalt professionally for anything else. Even Android
| TV doesn't trust Cobalt for anything but Youtube.
|
| It mentions "subset of HTML5" which begs the question of "which
| subset", and the answer is pretty much "whatever Youtube on TV"
| uses.
|
| Please note that I'm not speaking of the actual quality of the
| project which in my experience is fine.
|
| If you're wondering what to use then for an embedded Linux web
| browser: I don't have a professional experience on it, but most
| people I know use WPE WebKit/COG
| niutech wrote:
| I've recently built Cobalt on Linux, here is how it looks:
| https://twitter.com/niu_tech/status/1592143515496206337
| TheDesolate0 wrote:
| pier25 wrote:
| I wonder how this compares to something like Ultralight.
|
| https://ultralig.ht/
| devwastaken wrote:
| Ultralight has proprietary components you cannot statically
| link to.
| anaisbetts wrote:
| Where did OP discover that this is based on Chromium? I don't
| actually think that it is - I'm fairly certain it is _not_ based
| on Chromium (at least the parts that matter), it 's a separate,
| extremely cut-down HTML engine
| xcdzvyn wrote:
| > The Cobalt Authors forked H5VCC, removed most of the Chromium
| code -- in particular WebCore and the Chrome Renderer and
| Compositor -- and built up from scratch an implementation of a
| simplified subset of HTML, the CSS Box Model for layout, and
| the Web APIs that were really needed to build a full-screen SPA
| browse and play application.
|
| So it's based on Chromium, but pretty far from it at this
| point.
| anaisbetts wrote:
| "Based on Chromium" implies that the core rendering code that
| comprises Chromium is in this codebase, but this is not at
| all the case if you browse the source. Basically the only
| thing that this codebase shares with Chromium is a build
| system and some very low-level libraries (libbase, which is
| basically a standard library for C++)
| zackees wrote:
| haolez wrote:
| Can Cobalt be driven by Puppeteer, Playwright or Selenium?
| IceWreck wrote:
| Pretty sure no
| umvi wrote:
| I was hoping this article would tell me how it is different from
| Electron. Does anyone know? I'm guessing the main difference is
| that electron is "full chromium" while cobalt is using a modified
| smaller chromium.
| mike_hearn wrote:
| It's not Electron, it appears to be pretty much a browser-like
| rendering engine from scratch but for a very limited subset of
| HTML. Only a handful of tags are supported:
|
| https://cobalt.dev/development/reference/supported-features....
|
| but the result is more appropriate for some kinds of embedded
| environments.
| mihashco wrote:
| I don't know electron, but cobalt has some limitations. On page
| you can find what html5 and css3 tags are supported. List is
| limited. Cobalt also does not support WebGL. But binary has
| ~45mb and works really fast compared to other engines on
| embedded devices. I was not able to run react app on Cobalt,
| but preact works really well. I've also been doing experiments
| with the Vue framework and it also works.
| egberts1 wrote:
| does not support WebGL? thanks, gonna look into that.
| c-smile wrote:
| > But binary has ~45mb ...
|
| Even this is too much I think.
|
| Sciter is 7 Mb on Windows and 11 Mb on RaspberryPi. Extra 3
| Mb is Skia for rendering on Vulkan and/or OpenGL. And it
| supports full set of HTML5 elements. JavaScript is at full
| ES2020 level.
|
| The only reason I think why 45 Mb is there is because of
| video codecs. Sciter does not have them in core. But as
| loadable ffmpeg based plugin.
| hungryforcodes wrote:
| I would understand your argument if you were talking about
| more constrained systems, but RPIs have GOBS of storage and
| memory. A 45mb executable vs 7mb executable is totally
| negligible.
| c-smile wrote:
| It is not about binary size per se, but of
| features/binary ratio.
|
| Can Cobalt run, say, ChartJS as it is
| (https://sciter.com/chartjs-in-sciter/)? Seems like not
| as I do not see <canvas> in the list of its supported
| elements.
| The_Colonel wrote:
| Well, does Sciter support CSS Flexbox? It doesn't ...
|
| Features which the project actually needs will be
| decisive.
|
| Does the project need Canvas? Sciter is the better
| choice.
|
| Does the project need CSS Flexbox? Cobalt will be a
| better fit.
|
| The binary size may play a role if all else is equal ...
| c-smile wrote:
| Sciter supports flex units but not flexbox. Flex units
| (and grid layouts) are in Sciter since 2007, ~10 years
| before browsers got them. Flexibility is the must for
| desktop UIs so it was in the engine from the very
| beginning.
|
| Sciter's flex units + CSS flow property is a superset of
| flexbox and grid features. For example paddings, margins,
| border widths, left|right|top|bottom can be expressed in
| flex units.
|
| Everything that can be defined by flexbox can be
| expressed by flex units / flow:
|
| https://terrainformatica.com/w3/flex-layout/flex-vs-
| flexbox....
| mihashco wrote:
| Thanks I will check Sciter! I almost forgot, Cobalt has a
| very well designed porting layer. Therefore, it is
| relatively easy to run it on custom Linux embedded devices.
| It also uses Skia as a backend for rasterization. As many
| people here have already written Cobalt is designed as a
| youtube player, but it can be successfully used for other
| purposes.
| syndrig wrote:
| Another data point: Flow's[1] executable is ~20MB on
| Raspberry Pi (under 26MB for a 64bit build; both are smaller
| than the ICU data bundled with public releases). WebGL, video
| playback and Javascript JIT are included.
|
| Disclosure: I work at Ekioh.
|
| [1] https://www.ekioh.com/flow-browser/
| nvrspyx wrote:
| > The Cobalt Authors originally maintained a port of Chromium
| called H5VCC, the HTML5 Video Container for Consoles, ported to
| each of the major game consoles, designed to run our
| HTML5-based video browse and play application [read YouTube]...
|
| > After wrestling with [the constraints of] this for several
| years, we imagined an environment that was not designed for
| traditional scrolling web content, but was intended to be a
| runtime environment for rich client applications built with the
| same technologies -- HTML, CSS, JavaScript -- and designed from
| the ground-up to run on constrained, embedded, Living Room
| Consumer Electronics (CE) devices...
|
| > The Cobalt Authors forked H5VCC, removed most of the Chromium
| code -- in particular WebCore and the Chrome Renderer and
| Compositor -- and built up from scratch an implementation of a
| simplified subset of HTML, the CSS Box Model for layout, and
| the Web APIs that were really needed to build a full-screen SPA
| browse and play application.
|
| https://cobalt.googlesource.com/cobalt
| piskerpan wrote:
| From the footer:
|
| > (c) Google 2019
|
| Not exactly a new or fully supported project, but I do see recent
| commits on the repo.
| phh wrote:
| It's definitely fully supported, it gets many upgrades and has
| a pretty long-term and serious roadmap.
|
| I strongly recommend not to use it though.
| znpy wrote:
| > has a pretty long-term and serious roadmap.
|
| Considering it comes from google, does that mean three months
| or six months?
| unwiredben wrote:
| Cobalt is the primary engine that's used for running YouTube and
| YouTube TV on set-top boxes and smart TVs. If you notice that it
| looks the same on a Roku device or a Fire TV stick or a Samsung
| TV, that's because all of those are running a port of Cobalt and
| a special version of the YouTube website.
| password4321 wrote:
| So a browser supporting a subset of HTML maintained by Google
| employees with an MIT license supporting Linux (especially
| Raspberry Pi) and Android?
| zackees wrote:
| Yes. I worked on this project for three years. This is exactly
| what it is. It's also much more stable than chrome.
| sandGorgon wrote:
| strange question...but if you were to create a new mobile
| browser for android (with some custom features), would you
| recommend Chromium or Cobalt ?
| blooalien wrote:
| > "It's also much more stable than chrome."
|
| I find that exceedingly easy to believe... Chrom(e|ium) as it
| currently stands (for a rather long while now) is a massive
| resource hog. Stripping it down and re-writing huge portions
| of it (pretty much) from scratch can only be an improvement.
___________________________________________________________________
(page generated 2022-11-22 23:00 UTC)