Ekioh makes enterprise software for set-top boxes. They do know their browser rendering, though: they stripped Webkit down to have a 24mb memory footprint.

Webkit a comparably easy target to strip down and embed elsewhere. See Apple watch.

Implies that this isn't a webkit fork, they started from scratch.

See also: https://twitter.com/FlowBrowser/status/1200098712816631809

open source is our insurance policy against the next IE6. One may come again, but we can head it off at the pass before it dominates the market.

Thanks to chrome we now have AMP and basically total web domination by the GOOG company.

How does Chrome enable AMP?

(Disclosure: I work for Google, speaking only for myself)

People writing software are no match for behemoth.

Someone can simply fork it, with all its idiosyncrasies, then build new versions with new features.

Do you want a browser that natively supports a language other than JavaScript? Chromium is a great starting point.

PS: As a webkit-based Chrome alternative, Brave browser does really well.

I could sort of understand not choosing v8 which is now quite bloated as it is also optimising for lots of other things, but Spidermonkey?

So, sounds interesting, but not for the public masses.

Alternatively: Chrome 1.0 was also super fast compared to the competition. And I remember switching from a full browser on Android to my custom browser that was like 10 lines of code around a webview element, which was really an order of magnitude faster. If they modified an existing render engine and wrote their own browser UI, that could also deliver this speed boost.

So this seems relatively doable to me, but you get fewer features.

Let's see if they make this available for a broad audience and if, in five years when they accumulated all the features, it's still faster.

[0]: https://servo.org/

Quote: Back in 2012, Mozilla’s Servo project had started hitting headlines about multithreaded, parallel algorithms, and we decided to see if we could do similar, initially targeting our historic market of STBs[0]

Quote: Some of our early thinking was shaped by the parallel web page layout research done by Meyerovich & Bodík. That research also influenced the Servo project which was started by the Mozilla foundation around the same time that we started developing our multithreaded browser.[1]

[0]: https://www.ekioh.com/devblog/svg-browser-to-html-browser/

[1]: https://www.ekioh.com/blog/developing-a-faster-browser-engin...

[2]: https://www.ekioh.com/wp-content/uploads/Designing-a-Browser...

[3]: https://www.ekioh.com/wp-content/uploads/An-Optimal-Browser-...

[4]: https://www.ekioh.com/devblog/gpu-rendering/

https://mozillagfx.wordpress.com

Webrender is being actively worked on and is in the final stages of integration into Firefox (I believe it's enabled by default for some combinations of GPU and OS already). Servo's experimenting with a new layout system written from-scratch to be modular as well, and that's making good progress.

(We're rewriting the layout system because the original one, while it proved that parallel layout was doable, wasn't very maintainable/extensible given that it was written through experimentation while the language itself was changing a lot. We now know how to do parallel layout, and writing a clean, modular, maintainable system will enable us to fill in all the missing features)

Theoretically they'd complement each other, but in practice I imagine UIs for super-resource-constrained set-top boxes are already written in pretty efficient JavaScript.

"what do you mean document.write prevents parallelism?" I don't remember the details but it force some critical browser operations to be sequential.