6 ms·

Cobalt – a stripped down Chromium for apps, Linux and embedded systems

235 points by graderjs 4y ago

umvi 4y ago
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 4y ago
  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.html https://cobalt.dev/development/reference/supported-features.... but the result is more appropriate for some kinds of embedded environments.
- mihashco 4y ago
  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 4y ago
    does not support WebGL? thanks, gonna look into that.
  - c-smile 4y ago
    > 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 4y ago
      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 4y ago
        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/ https://sciter.com/chartjs-in-sciter/)? Seems like not as I do not see <canvas> in the list of its supported elements.
        The_Colonel 4y ago
        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 4y ago
        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.htm https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....
        The_Colonel 4y ago
        Sciter does not support CSS Flexbox. It supports a more or less equivalent, but incompatible feature. That's a critical distinction when you want to run the same codebase as you have on the web.
  - syndrig 4y ago
    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/ https://www.ekioh.com/flow-browser/
- nvrspyx 4y ago
  > 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 https://cobalt.googlesource.com/cobalt
TheDesolate0 4y ago
password4321 4y ago
So a browser supporting a subset of HTML maintained by Google employees with an MIT license supporting Linux (especially Raspberry Pi) and Android?
- zackees 4y ago
  Yes. I worked on this project for three years. This is exactly what it is. It’s also much more stable than chrome.
  - blooalien 4y ago
    > "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.
  - sandGorgon 4y ago
    strange question...but if you were to create a new mobile browser for android (with some custom features), would you recommend Chromium or Cobalt ?
    - kaveet 4y ago
      Cobalt isn't a great fit for general-purpose web browsing because it only supports a subset of HTML--lots of websites would appear broken. It's really meant for webapps you've designed with Cobalt in mind. Check out the supported features: https://cobalt.dev/development/reference/supported-features.html https://cobalt.dev/development/reference/supported-features....
      - scrollaway 4y ago
        That… sounds absolutely amazing. Very specific purpose yes but wow, the amount of times I've needed a stripped down HTML engine that doesn't suck. I suspect this could make an excellent renderer for an app doing markdown previews, CHM files, ebooks and such for example.
pier25 4y ago
I wonder how this compares to something like Ultralight. https://ultralig.ht/ https://ultralig.ht/
- devwastaken 4y ago
  Ultralight has proprietary components you cannot statically link to.
  - pier25 4y ago
    Yes but what about binary size and memory usage?
  - moralestapia 4y ago
    It also seems to be abandoned.
piskerpan 4y ago
From the footer: > © Google 2019 Not exactly a new or fully supported project, but I do see recent commits on the repo.
- phh 4y ago
  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 4y ago
    > has a pretty long-term and serious roadmap. Considering it comes from google, does that mean three months or six months?
unwiredben 4y ago
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.
- jeffbee 4y ago
  Interesting! I wonder if this is why the YouTube webOS app is 55MB while something like Hulu is 220KB. I believe the latter is just HTML that targets the webOS browser. The YouTube app is the only one, along with Netflix, that is smooth and usable on this platform. Amazon Prime video is a jankfest (and their app is 100MB) and Apple TV+ is a slideshow.
- captn3m0 4y ago
  The special version of YouTube TV is accessible still by changing your user-agent: https://news.ycombinator.com/item?id=28945542 https://news.ycombinator.com/item?id=28945542
- hdhdxkfchsk 4y ago
  that explains why it is "striped down" but still havefull DRM support. https://html5test.com/s/f95f2b5e8ee2ce08.html https://html5test.com/s/f95f2b5e8ee2ce08.html no form elements tho?!?
- matvp 4y ago
  How would one ship a full engine with an app on an OTT device? I've built a few TV apps but they all relied on the browser engines shipped with webOS and Tizen.
zackees 4y ago
phh 4y ago
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
haolez 4y ago
Can Cobalt be driven by Puppeteer, Playwright or Selenium?
- IceWreck 4y ago
  Pretty sure no
- rawoul 4y ago
  Yes, cobalt has support for a subset of the WebDriver protocol.
anaisbetts 4y ago
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 4y ago
  > 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 4y ago
    "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++)
    - GenerocUsername 4y ago
      It was forked from Chromium and there may be parts that are still pulled from the upstream.
niutech 4y ago
I've recently built Cobalt on Linux, here is how it looks: https://twitter.com/niu_tech/status/1592143515496206337 https://twitter.com/niu_tech/status/1592143515496206337
esprehn 4y ago
I think cobalt has about as much in common with chromium as chromium does with khtml these days. There's some vague shared lineage but it's entirely its own project now with different algorithms and approaches to implementing web standards. It's a pretty cool project, and the source is a fun way to learn about web standards (same with reading Ladybird browser code). The major browsers are so complex they're not as approachable.
password4321 4y ago
This might actually be pretty cool combined with a proxy to convert sites to the subset of supported HTML. It obviously is at least possible for it to have the blessing required for DRM content that is unobtanium.
divbzero 4y ago
Very cool project but I wish they had named it Manganese. Certain isotopes of chromium undergo beta decay Cr → Mn + e⁻ so it would have been a propos for the two derivatives of Chromium to be Manganese and Electron.
Spasnof 4y ago
I couldn't find it anywhere on the docs or in a few google searches. What is a porter? and how does it differ from a developer? I understand the general concept of porting (ie https://en.wikipedia.org/wiki/Porting https://en.wikipedia.org/wiki/Porting) but never heard of it as a specialization. Also what might people be porting from? If this intended as a migration guide.
- telotortium 4y ago
  Porters would be porting the codebase to run on a new OS by implementing the functions in the abstraction layer that Cobalt uses for OS-specific code.

235 points by graderjs 4y ago

umvi 4y ago

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 4y ago
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.html https://cobalt.dev/development/reference/supported-features.... but the result is more appropriate for some kinds of embedded environments.
mihashco 4y ago
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 4y ago
  does not support WebGL? thanks, gonna look into that.
- c-smile 4y ago
  > 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 4y ago
    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 4y ago
      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/ https://sciter.com/chartjs-in-sciter/)? Seems like not as I do not see <canvas> in the list of its supported elements.
      - The_Colonel 4y ago
        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 4y ago
        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.htm https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox....
        The_Colonel 4y ago
        Sciter does not support CSS Flexbox. It supports a more or less equivalent, but incompatible feature. That's a critical distinction when you want to run the same codebase as you have on the web.
- syndrig 4y ago
  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/ https://www.ekioh.com/flow-browser/
nvrspyx 4y ago
> 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 https://cobalt.googlesource.com/cobalt

TheDesolate0 4y ago

password4321 4y ago

So a browser supporting a subset of HTML maintained by Google employees with an MIT license supporting Linux (especially Raspberry Pi) and Android?

zackees 4y ago
Yes. I worked on this project for three years. This is exactly what it is. It’s also much more stable than chrome.
- blooalien 4y ago
  > "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.
- sandGorgon 4y ago
  strange question...but if you were to create a new mobile browser for android (with some custom features), would you recommend Chromium or Cobalt ?
  - kaveet 4y ago
    Cobalt isn't a great fit for general-purpose web browsing because it only supports a subset of HTML--lots of websites would appear broken. It's really meant for webapps you've designed with Cobalt in mind. Check out the supported features: https://cobalt.dev/development/reference/supported-features.html https://cobalt.dev/development/reference/supported-features....
    - scrollaway 4y ago
      That… sounds absolutely amazing. Very specific purpose yes but wow, the amount of times I've needed a stripped down HTML engine that doesn't suck. I suspect this could make an excellent renderer for an app doing markdown previews, CHM files, ebooks and such for example.

pier25 4y ago

I wonder how this compares to something like Ultralight. https://ultralig.ht/ https://ultralig.ht/

devwastaken 4y ago
Ultralight has proprietary components you cannot statically link to.
- pier25 4y ago
  Yes but what about binary size and memory usage?
- moralestapia 4y ago
  It also seems to be abandoned.

piskerpan 4y ago

From the footer: > © Google 2019 Not exactly a new or fully supported project, but I do see recent commits on the repo.

phh 4y ago
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 4y ago
  > has a pretty long-term and serious roadmap. Considering it comes from google, does that mean three months or six months?

unwiredben 4y ago

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.

jeffbee 4y ago
Interesting! I wonder if this is why the YouTube webOS app is 55MB while something like Hulu is 220KB. I believe the latter is just HTML that targets the webOS browser. The YouTube app is the only one, along with Netflix, that is smooth and usable on this platform. Amazon Prime video is a jankfest (and their app is 100MB) and Apple TV+ is a slideshow.
captn3m0 4y ago
The special version of YouTube TV is accessible still by changing your user-agent: https://news.ycombinator.com/item?id=28945542 https://news.ycombinator.com/item?id=28945542
hdhdxkfchsk 4y ago
that explains why it is "striped down" but still havefull DRM support. https://html5test.com/s/f95f2b5e8ee2ce08.html https://html5test.com/s/f95f2b5e8ee2ce08.html no form elements tho?!?
matvp 4y ago
How would one ship a full engine with an app on an OTT device? I've built a few TV apps but they all relied on the browser engines shipped with webOS and Tizen.

zackees 4y ago

phh 4y ago

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

haolez 4y ago

Can Cobalt be driven by Puppeteer, Playwright or Selenium?

IceWreck 4y ago
Pretty sure no
rawoul 4y ago
Yes, cobalt has support for a subset of the WebDriver protocol.

anaisbetts 4y ago

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 4y ago
> 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 4y ago
  "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++)
  - GenerocUsername 4y ago
    It was forked from Chromium and there may be parts that are still pulled from the upstream.

niutech 4y ago

I've recently built Cobalt on Linux, here is how it looks: https://twitter.com/niu_tech/status/1592143515496206337 https://twitter.com/niu_tech/status/1592143515496206337

esprehn 4y ago

I think cobalt has about as much in common with chromium as chromium does with khtml these days. There's some vague shared lineage but it's entirely its own project now with different algorithms and approaches to implementing web standards. It's a pretty cool project, and the source is a fun way to learn about web standards (same with reading Ladybird browser code). The major browsers are so complex they're not as approachable.

password4321 4y ago

This might actually be pretty cool combined with a proxy to convert sites to the subset of supported HTML. It obviously is at least possible for it to have the blessing required for DRM content that is unobtanium.

divbzero 4y ago

Very cool project but I wish they had named it Manganese. Certain isotopes of chromium undergo beta decay Cr → Mn + e⁻ so it would have been a propos for the two derivatives of Chromium to be Manganese and Electron.

Spasnof 4y ago

I couldn't find it anywhere on the docs or in a few google searches. What is a porter? and how does it differ from a developer? I understand the general concept of porting (ie https://en.wikipedia.org/wiki/Porting https://en.wikipedia.org/wiki/Porting) but never heard of it as a specialization. Also what might people be porting from? If this intended as a migration guide.

telotortium 4y ago
Porters would be porting the codebase to run on a new OS by implementing the functions in the abstraction layer that Cobalt uses for OS-specific code.