Flow Browser: Flow makes HTML faster | Hacker News Reader

Flow Browser: Flow makes HTML faster

ekioh.com

216 pointsksec41 comments

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

Google docs input handling is terrible. It still doesn’t properly handle long presses to select accented characters on Mac, but at least you get to see where the hidden input field is located.

Similarly on mac, the symbol/emoji/character picker doesn't work. (The keyboard command is acknowledged by the menu bar flashing, but nothing happens.)

But that's also broken in Slack, too. (& Linux's IME is broken in Discord, and…)

Probably a result of them rendering it from scratch in WebGL.

It'll be interesting to see how wide of a niche Flow ends up fitting into. Digital signage and in-store displays are the obvious shoe-ins, but the fact that they're also working on compatibility for things like Google Docs makes me wonder if they'll try to market it as a UI solution for low cost/low power devices as well.

"It’s a new layout engine and new rendering engine. Everything other than the JavaScript engine (SpiderMonkey) is written from scratch." https://twitter.com/FlowBrowser/status/1200098712816631809

Google Docs in a clean-room browser - https://news.ycombinator.com/item?id=28593070 - Sept 2021 (150 comments)

Flow Browser Preview on the Raspberry Pi 400 - https://news.ycombinator.com/item?id=25568650 - Dec 2020 (73 comments)

Flow browser passes the Acid tests - https://news.ycombinator.com/item?id=23508979 - June 2020 (321 comments)

Flow Browser – A parallel, multithreaded HTML browser - https://news.ycombinator.com/item?id=21658935 - Nov 2019 (46 comments)

God, I just want this to come out (for desktop platforms, linux at least). Even though their niche is embedded it looks like this browser will be competitive with the other modern ones. A new engine would be great for the web. They also have an advantage in architecting their browser for today's web. I hope they release an end-user browser.

A fast, light engine might be good for test automation as well. Last year I fixed a dependency graph issue with our application that was pulling in Electron on accident and holy hell is that a big boy.

I have a potentially untestable theory that the reason why browser testing is so complex is because there is no browser that was built for testing. I almost always find that if my code is becoming difficult to test it's because I've made choices that are antagonistic to automation. The better my code is for unit testing, the easier the integration tests tend to be.

Selenium and friends are clearly hamstrung by browsers being antagonistic to E2E testing.

Yes, a big boy indeed. Way too big, though to be fair it is that way simply because what it hopes to give developers takes an executable that big (Chromium + Node). I'm not sure how node-webkit compares in size. The webview library, which uses the system's available browser, is obviously minuscule. Though I guess you have to hope that the user hasn't deleted the default HTML5 browser of the OS (not sure if this is an issue; Win32 has chromium-edge-based webview included, right?).

However it's safe to assume that this browser would have a significantly lighter footprint given that it's built "embedded first".

The only problem is that the engine is proprietary. I'm not sure about licensing when it is released. Regardless, I assume there would be nothing stopping people from bringing it onboard for tests/whatever else they dream up.

I wonder if Flow could be compiled to WASM and run in another browser.

I'd love to see that!

Innovation in the browser? Where have you been for the past 5 years?

Note this is for Raspberry Pis.

From the linked page:

* Available for a wide variety of platforms including Linux, Android, Raspberry Pi and Windows

And:

* Linux, macOS and Android desktop builds for off-target content development

Only currently. From what I gathered from their site, they plan to support all major platforms.

Don't all browsers these days use multithreading and GPU acceleration?

Plenty of multi-threading in browsers, but multi-threaded layout is rare, as I understand it. Mozilla made an attempt with Servo, but their first attempt got too complicated and they dropped Servo before the second attempt got anywhere ( https://github.com/servo/servo/wiki/Layout-2020 ).

Given Flow isn't trying to support _everything_ , perhaps they made the task easier by ignoring the complex bits.

I'm curious if anyone could comment on the degree to which Servo's complexity is now answered by improvements in Rust in the interim. I know a lot of complexity in my work comes down to want of features. On this project in particular we have a whole bunch of business logic due entirely to deficiencies in our CI/CD pipeline. It's very much an 'Art of the Possible' situation and I get annoyed having to apologize about it to people. Yes, that would be a better way to do it, but we can't make that work around the bad assumptions made elsewhere.

> ignoring the complex bits

Hallelujah

License?

And if not opensource, business model and price?

Is this a genuinely new browser, or is it based on one of the others?

According to Wikipedia

Flow is a web browser with a proprietary rendering engine that claims to "dramatically improve rendering performance". Its JavaScript engine, however, is the SpiderMonkey engine of Firefox

it seems the plan is to sell it to embedded system manufacturers.

Servo, Mozilla's Rust based browser should take the same path.

Mozilla is no longer investing in Servo.

Here is the link: https://en.wikipedia.org/wiki/Flow_(web_browser)

"It’s a new layout engine and new rendering engine. Everything other than the JavaScript engine (SpiderMonkey) is written from scratch." https://twitter.com/FlowBrowser/status/1200098712816631809

IIRC their layout engine is a proprietary product written from scratch.

Found this on their website:

"The compact, feature rich, WebKit based browser from Ekioh"

That is, as far as I can tell, a different product.

Can these techniques be used to improve performance in other browsers?

They already are. Mozilla Firefox uses a lot of multi threading and offloads a lot of the rendering to the GPU. So does Chrome. That's a big reason why Mozilla invented Rust: to be able to do this without dealing with a lot of concurrency, security, and stability bugs.

The creator of Rust has been very clear that Mozilla did not invent Rust (https://twitter.com/graydon_pub/status/1492634815748739077)

I stand corrected.

But lets just say they were extremely early adopters and single-handedly propelled Rust into the mainstream by essentially bankrolling Rust development for several years until they finally spun it off into a separate foundation a few years ago.

I doubt it as it has a "proprietary rendering engine", but Servo (https://servo.org/) has been doing a similar thing and from what I remember, it is basically a safe multi-threaded rendering engine.

Looks like vaporware, I don't even see that you can download it.

You can download it for Raspberry Pi. They're a British company. I've been following it for while now. Definitely not vaporware.

I've tested the macOS build and can assure you it's not vaporware.

There's a download button : https://support.ekioh.com/download/

Reply on news.ycombinator.com