> 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

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.

> 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.

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.

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.

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 ...

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 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.

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; }
     ...
   }

You should not assume that all browsers support same set of features. And needless to say, that Sciter is not a universal browser. And so is Cobalt in that respect - it is a browser for particular site / application.

> 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.

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/

does not support WebGL? thanks, gonna look into that.

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.