Live data from Hacker News

Flow Browser – A parallel, multithreaded HTML browser

ekioh.com

31–40 of 48 posts

Re: Flow Browser – A parallel, multithreaded HTML browser

#31
post #26

Earlier quoted context omitted.

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.

Re: Flow Browser – A parallel, multithreaded HTML browser

#32

Earlier quoted context omitted.

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.

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.

Re: Flow Browser – A parallel, multithreaded HTML browser

#33

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.

Re: Flow Browser – A parallel, multithreaded HTML browser

#35
post #29

Earlier quoted context omitted.

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

Re: Flow Browser – A parallel, multithreaded HTML browser

#36
post #29

Earlier quoted context omitted.

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

Re: Flow Browser – A parallel, multithreaded HTML browser

#37
post #26

Earlier quoted context omitted.

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.

Re: Flow Browser – A parallel, multithreaded HTML browser

#38

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/

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/

Re: Flow Browser – A parallel, multithreaded HTML browser

#40

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

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)

Post reply on HN