Cobalt – a stripped down Chromium for apps, Linux and embedded systems(cobalt.dev)
cobalt.dev
Cobalt – a stripped down Chromium for apps, Linux and embedded systems
https://cobalt.dev/overview.html
54 comments
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.
The special version of YouTube TV is accessible still by changing your user-agent: https://news.ycombinator.com/item?id=28945542
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.
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.
that explains why it is "striped down" but still havefull DRM support.
https://html5test.com/s/f95f2b5e8ee2ce08.html
no form elements tho?!?
https://html5test.com/s/f95f2b5e8ee2ce08.html
no form elements tho?!?
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.
So a browser supporting a subset of HTML maintained by Google employees with an MIT license supporting Linux (especially Raspberry Pi) and Android?
Yes. I worked on this project for three years. This is exactly what it is. It’s also much more stable than chrome.
> "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.
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.
strange question...but if you were to create a new mobile browser for android (with some custom features), would you recommend Chromium or Cobalt ?
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....
Check out the supported features:
https://cobalt.dev/development/reference/supported-features....
Can you get Cobalt to return an error status "HTML outside of supported subset - need full browser", for applications where you need a fast-launching embedded browser?
Is there some tool for evaluating pages for "will they run in Cobalt"?
I can see uses for this if you can do that. If you can't, it's limited to sites designed for it.
Is there some tool for evaluating pages for "will they run in Cobalt"?
I can see uses for this if you can do that. If you can't, it's limited to sites designed for it.
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.
I suspect this could make an excellent renderer for an app doing markdown previews, CHM files, ebooks and such for example.
no <canvas> though ;-(
Chromium. Cobalt doesn't work for the majority of websites.
Websites kind of have to be built specifically for Cobalt to work well.
Websites kind of have to be built specifically for Cobalt to work well.
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.
I've recently built Cobalt on Linux, here is how it looks: https://twitter.com/niu_tech/status/1592143515496206337
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.
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.
https://cobalt.dev/development/reference/supported-features....
but the result is more appropriate for some kinds of embedded environments.
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.
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/
Disclosure: I work at Ekioh.
[1] https://www.ekioh.com/flow-browser/
does not support WebGL? thanks, gonna look into that.
> 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.
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.
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.
Sciter works on Windows, MacOS, Linux, Android and is packaged in two forms: windowed and windowless engines (a.k.a. headless).
It supports rendering trough Direct2D/DirectX, GDI+, CoreGraphics, Cairo and (through Skia) DX12, Vulkan, Metal.
It supports rendering trough Direct2D/DirectX, GDI+, CoreGraphics, Cairo and (through Skia) DX12, Vulkan, Metal.
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.
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.
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.
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 ...
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 ...
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....
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....
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.
That's a critical distinction when you want to run the same codebase as you have on the web.
CSS was designed for running on different UAs and there is special mechanism built in it. If you take a look into source of that demo page, you will see:
/* browser */
@supports (display:flex)
{
section { display: flex; }
section > * { flex: 1; margin:1em; }
...
}
/* sciter */
@supports (flow:horizontal)
{
section { flow:horizontal; }
section > * { width:1*; margin:1em; }
...
}
> there is special mechanism built in it
Yes, a return to the dark days of UAs having their own proprietary extensions / prefixes to do the same thing. Why bother when there's an actual industry standard?
> You should not assume that all browsers support same set of features.
You can certainly target only user agents which support CSS Flexbox. I would even say it's the advisable default unless you have some very special needs.
Yes, a return to the dark days of UAs having their own proprietary extensions / prefixes to do the same thing. Why bother when there's an actual industry standard?
> You should not assume that all browsers support same set of features.
You can certainly target only user agents which support CSS Flexbox. I would even say it's the advisable default unless you have some very special needs.
[deleted]
> 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
> 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
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
> 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.
So it's based on Chromium, but pretty far from it at this point.
"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++)
It was forked from Chromium and there may be parts that are still pulled from the upstream.
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
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
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) but never heard of it as a specialization. Also what might people be porting from? If this intended as a migration guide.
I understand the general concept of porting (ie 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.
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.
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.
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.
I wonder how this compares to something like Ultralight.
https://ultralig.ht/
https://ultralig.ht/
Ultralight has proprietary components you cannot statically link to.
It also seems to be abandoned.
Yes but what about binary size and memory usage?
From the footer:
> © Google 2019
Not exactly a new or fully supported project, but I do see recent commits on the repo.
> © Google 2019
Not exactly a new or fully supported project, but I do see recent commits on the repo.
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.
It obviously is at least possible for it to have the blessing required for DRM content that is unobtanium.