Flow Browser – A parallel, multithreaded HTML browser | Hacker News Reader

Flow Browser – A parallel, multithreaded HTML browser

ekioh.com

123 pointsrobin_reala46 comments

This is almost certainly going to be proprietary, so it's nothing to hold your breath over.

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.

Nevertheless perhaps it has a chance to conquer the market if it's so good otherwise. I love free software but have to admit a browser (or whatever an app) doesn't have to be open-source for this.

and then it takes over, does whatever it wants, and now you've got IE6 again.

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.

People can run legacy open-source code, too. I fail to see how open-sourcing IE would have solved the old versions. For a better example, look at python 2.7. Open-source legacy code every one's stuck with, drawn-out deprecation dates, etc. Old Java versions are the same thing.

While I agree with you, open source chrome didn't really help push for anything good.

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

> Thanks to chrome we now have AMP

How does Chrome enable AMP?

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

Then you know the answer

I honestly don't know what you might be thinking of Chrome doing that 'enables' AMP. If you said Google Search enabled AMP, by only allowing AMP documents in the carousel for example, I would agree. But I can't think of any Chrome-specific features that AMP depends on, and I believe Google (and Bing) currently serve AMP to Firefox, Safari, Edge, etc.

As opposed to having Chrome, which contributes to Google's ownership of the whole internet? Google does what it wants and developers write for Chrome. Users of Firefox find websites that won't work because someone used some Chrome extension to the spec.

People writing software are no match for behemoth.

At the very least Chrome allows forking (and has happened in practice multiple times), so a competitor need not start from scratch. That's will always be an insurance.

There's hardly any point forking if most or all websites are tested for Chrome and its idiosyncrasies, and don't work well on other browsers. We have seen that playing out for sometime.

It means we can’t end up in an IE6 scenario, where the caretaking company loses interest in developing the browser, and we are all stuck using old technology forever.

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.

Well, I think the argument was more about Webkit, then Chrome itself. Even flow here does not use a JS engine written from scratch - they use SpiderMonkey.

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

Interesting they choose Spidermonkey over Webkit's JS Engine .

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?

Remember when you could test on WebKit, to hit both Chrome and iOS, with OSX Safari as a bonus?

IE6 was the best browser by far when it was released. We got IE6 partly because of that: why to work on something, that is the best in the market. So the team was disbanded. When alternatives started to appear, one of them, and quite popular in some areas was Opera–also closed-source browser. Despite being closed-source they cared a lot about the Web Standards and many of the biggest advocates worked for Opera.

So this is a closed-source webkit fork? Nothing to see here, moving on then :)

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

> developed a clean room browser architecture

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

https://twitter.com/_Piers_/status/991328398910816256 says it's actually more than a year old. There is no download link on the OP, so I guess it's safe to assume it's only available to people who pay for their enterprise needs.

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

New rendering engine, new layout engine, and Spidermonkey for JS: https://twitter.com/FlowBrowser/status/1200098712816631809

I was indeed wondering the same: a new render engine seems like a huge and risky investment (even Microsoft gave up on the existing one they have, that says something). If it really is from scratch, it probably just supports only the most popular features, which would cut complexity and give a large performance boost by itself.

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.

I wonder how this compares to Servo[0] - on admittedly not very close inspection it seems like they have a lot of the same ideas.

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

Servo team started doing VR stuff maybe a year ago and since then haven't heard anything new about Servo .. I'm hoping that something comes of it

The Mozilla Gfx blog regularly posts updates. They have been porting subsystems from servo to firefox, and making substantial progress on a regular basis.

https://mozillagfx.wordpress.com

VR is only part of the focus, we're still working towards a general purpose browser, it's just a slow and long process.

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)

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-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/

Well it doesn't appear to be publicly available yet, so we'll have to wait to find out if this is real or just smoke and mirrors.

Pretty interesting. Conventional wisdom is that the web standards have become so complicated that it's prohibitively difficult to introduce a totally new browser that fully supports modern CSS and JS. Sounds like this one does.

Naming could be better or more differentiated -- "Flow" is already used in the closely related space of front-end development and javascript (flow typing).

It doesn't matter. There's thousands of basic words occupied by some more or less relevant Javascript tool or framework. Don't let that get in the way of naming your products.

Agreed. Also flow has been utterly demolished by typescript and is on the way out, so it will be even less of a problem in the future.

As well as a FTP app for macOS, Sharing service for the Opera browser, Microsoft Flow, Samsung Flow and so on. While it's a word used all over the place, i would try to name it to something more ”unique”.

Interesting claims, any 3rd party testing?

Will it have its lunch eaten by tools and techniques for lightweight web apps on Webkit/Quantum? Svelte made a headstart making 200k laggy Webkit devices snappy again while these guys will be selling proprietary licenses.

Frameworks like Svelte focus on reducing the time spent running JavaScript. This project focuses on reducing the time spent on layout and rendering.

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.

These things are actually pretty related: JS isn't particularly slow as a language; it only gets slow on the web because every time JS code touches the DOM/CSS a part of layout and style needs to be recomputed.

No video comparisons, nothing? Also why dont they release this for mobile?

I don't think there's that much to improve with current browsers anymore. 8 years ago maybe. Now you have web workers with shared memory, typed arrays, GPU acceleration for canvas and CSS, web assembly with SIMD. It's already possible to utilise all the cores and GPU in 2D. Not even mentioning 3D WebGL and incoming WebGPU. Websites are fast enough already(with ad blocker).

I believe that document.write prevent a lot of parallelism. Also as always, SIMD are underutilized. There is also transactional memory, heterogeneous computing, SYCL, etc...

what do you mean document.write prevents parallelism? Who's using document.write for anything these days?

"Who's using document.write for anything these days?" It doesn't matter if anybody use it, someone could use it, as such browser must adapt to this possibility and be performance constrained.

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

Is this released? Where does this thing download??

what do they mean by "full page animation" and why is that suddenly the benchmark for fast rendering?

How does it compare to servo?

Link to download?

I think it is not a freeware. They are probably planning to sell it to other distributors.

Reply on news.ycombinator.com