[HN Gopher] Flow Browser: Flow makes HTML faster
___________________________________________________________________
Flow Browser: Flow makes HTML faster
Author : ksec
Score : 157 points
Date : 2022-03-01 14:45 UTC (8 hours ago)
(HTM) web link (www.ekioh.com)
(TXT) w3m dump (www.ekioh.com)
| theandrewbailey wrote:
| Note this is for Raspberry Pis.
| MarcellusDrum wrote:
| Only currently. From what I gathered from their site, they plan
| to support all major platforms.
| djrogers wrote:
| 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
| johnhenry wrote:
| Can these techniques be used to improve performance in other
| browsers?
| jillesvangurp wrote:
| 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.
| favorited wrote:
| The creator of Rust has been very clear that Mozilla did not
| invent Rust
| (https://twitter.com/graydon_pub/status/1492634815748739077)
| nebster wrote:
| 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.
| svnpenn wrote:
| Looks like vaporware, I don't even see that you can download it.
| arnaudsm wrote:
| There's a download button : https://support.ekioh.com/download/
| kizer wrote:
| You can download it for Raspberry Pi. They're a British
| company. I've been following it for while now. Definitely not
| vaporware.
| marcodiego wrote:
| License?
| trulyme wrote:
| And if not opensource, business model and price?
| pier25 wrote:
| Don't all browsers these days use multithreading and GPU
| acceleration?
| scratcheee wrote:
| 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.
| throwawayninja wrote:
| > ignoring the complex bits
|
| Hallelujah
| hinkley wrote:
| 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.
| jccalhoun wrote:
| "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
| pjc50 wrote:
| Is this a genuinely new browser, or is it based on one of the
| others?
| was_a_dev wrote:
| 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_
| nebulous1 wrote:
| it seems the plan is to sell it to embedded system
| manufacturers.
| stuaxo wrote:
| Servo, Mozilla's Rust based browser should take the same
| path.
| favorited wrote:
| Mozilla is no longer investing in Servo.
| jccalhoun wrote:
| "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
| shiomiru wrote:
| IIRC their layout engine is a proprietary product written from
| scratch.
| Tade0 wrote:
| Found this on their website:
|
| "The compact, feature rich, WebKit based browser from Ekioh"
| shiomiru wrote:
| That is, as far as I can tell, a different product.
| [deleted]
| dgreensp wrote:
| 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.
| [deleted]
| TheOtherZech wrote:
| 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.
| unilynx wrote:
| 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.
| deathanatos wrote:
| 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...)
| kizer wrote:
| 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.
| hinkley wrote:
| 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.
| kizer wrote:
| 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.
| dang wrote:
| Related:
|
| _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)
| easrng wrote:
| I wonder if Flow could be compiled to WASM and run in another
| browser.
___________________________________________________________________
(page generated 2022-03-01 23:01 UTC)