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