4 ms·

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

by 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

by umvi 4y ago

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