Ekioh, a company building the Flow browser engine, posts about its closed-source, independently developed browser and its progress on web standards tests.
HN links it in threads on independent browser engines, alongside Ladybird and Servo, noting that Flow passes Acid3 but is closed source.
> Opera was trying to make money in a commoditized environment.
From what I can tell, Ekioh appear to be doing the same[0]
> that doesn't mean writing a new browser engine is impossible, it only means that it doesn't make much economic sense for a company to do so. Those two are not the same thing.
This is basically what I said in my first comment above: it's always technically possible, but is it practically possible. One needs a certain small amount of economic support to continue any project (no matter how small) these days. Whether it's feasible via donations/etc. or whether some kind of commercial setup is required isn't really super-relevant. The only question here is: if it's the former, can the income support employing devs to work on it, or can voluntary developer contributions maintain the project long term (for which you typically need a large community, with which you typically get further scaling & cost concerns).
It's notable also that Flow is not open source, so Opera is actually a very good comparison here (and much of the above donation/volunteer-based thoughts are not options here).
[0] https://www.ekioh.com/company/#partners
I was curious, did some research. They do mention Servo in some places[0][1]. They also have their own white papers[2][3], & blog posts outlining their approach, things like how to make borders with triangles[4]. Fun stuff!
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-engine/
[2]: https://www.ekioh.com/wp-content/uploads/Designing-a-Browser-to-Benefit-from-Multi-core-Silicon.pdf
[3]: https://www.ekioh.com/wp-content/uploads/An-Optimal-Browser-Design-for-GPU-Utilisation.pdf
[4]: https://www.ekioh.com/devblog/gpu-rendering/
If you haven't encountered this browser before, I find it fascinating. It's meant for devices that aren't necessarily computers. For example, someone making a digital "sign" can use HTML and CSS, or dynamic HTML motion graphics, to create their content, and run it in Flow. It doesn't have to be able to run, say, Google Docs. However, the developer wrote a blog post about getting Google Docs to run, by fixing the necessary bugs and adding the necessary features: https://www.ekioh.com/devblog/google-docs-in-a-clean-room-browser/ For example, Google Docs keeps the focus in a hidden iframe, apparently, and Flow wasn't firing the right series of events when the focus traveled between frames.
The way I look at it, for a custom "browser engine" whose goal is to let you use an independent implementation of the DOM to create graphics and UIs that render on the GPU of an embedded device, it's delightfully over-engineered.
> Why is a browser expensive?
Read this: https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
To quote,
--- start quote ---
The total word count of the W3C specification catalogue is 114 million words at the time of writing.
If you added the combined word counts of the C11, C++17, UEFI, USB 3.2, and POSIX specifications, all 8,754 published RFCs, and the combined word counts of everything on Wikipedia’s list of longest novels, you would be 12 million words short of the W3C specifications.
--- end quote ---
This is why. It's currently impossible to start a greenfield browser [1]. And even forking an existing engine and trying to keep up is almost impossible [2]
[1] There's Flow browser, https://www.ekioh.com/flow-browser/ I don't know if it's truly from scratch
[2] Microsoft forked Chromium and is still almost 2000 APIs behind, https://web-confluence.appspot.com/#!/confluence
WebKit is a bad example, considering the KHTML history alone. These things don't just take devpower, but time - consider, for example, this: http://www.ekioh.com/flow
They've managed to actually get GMail to render - a not insignificant task: https://www.ekioh.com/devblog/full-google-mail-in-a-clean-room-browser/
The timeline on this page alone is in years: https://www.ekioh.com/company/#team
From what I understand, that team is relatively small in comparison, but actually does have this widely-ish deployed. So it theoretically could be done with less... but it's still insane to even consider. This isn't simple, and anyone who's trying to imply otherwise is wrong.
The other commentator you're responding with also never discloses they worked with Apple previously, while pretty much endlessly pumping up their work here. shrug
There are a few others but all with their own caveats -
https://www.ekioh.com/flow-browser/ is fully independent and can run Gmail, but it's commercial / non-FOSS. It's funded by contracts in the set-top-box industry.
https://sciter.com/ is non-FOSS with a free edition but you shouldn't run untrusted javascript on it
And there are some lightly-maintained forks of the leaked Presto 12.x engine from before Opera became a Chromium derivative, but of course it's copyright infringement.