Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flow Browser – A parallel, multithreaded HTML browser

ekioh.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Flow Browser – A parallel, multithreaded HTML browser

#41

Post by Manishearth »

csande17 wrote: post #23
aitchnyu wrote: post #18

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.

Re: Flow Browser – A parallel, multithreaded HTML browser

#42

Post by The_rationalist »

touchpadder wrote: post #30

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

Re: Flow Browser – A parallel, multithreaded HTML browser

#43

Post by ksec »

palashkaria wrote: post #37
true_religion wrote: post #31

Earlier quoted context omitted.

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?

Re: Flow Browser – A parallel, multithreaded HTML browser

#44

Post by touchpadder »

The_rationalist wrote: post #42
touchpadder wrote: post #30

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?

Re: Flow Browser – A parallel, multithreaded HTML browser

#46

Post by The_rationalist »

touchpadder wrote: post #44
The_rationalist wrote: post #42

Earlier quoted context omitted.

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.

Re: Flow Browser – A parallel, multithreaded HTML browser

#47

Post by Terretta »

wtmt wrote: post #26
gpderetta wrote: post #25

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.

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

Re: Flow Browser – A parallel, multithreaded HTML browser

#48

Post by Chanderton »

anonytrary wrote: post #14

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

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”.
Post reply on HN