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

A Taste of JavaScript's New Parallel Primitives

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 107 posts

Re: A Taste of JavaScript's New Parallel Primitives

#41

Post by schmichael »

dherman wrote: post #38
schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

I don't know if there's a uniform Mozilla position on this, but here's mine! :) The main reason I care about the Web is because it's the world's biggest software platform that isn't owned. If someone can deliver their app to the world without submitting it for review by an app store and without paying a company a %-age of the revenue, and if they can market it through the viral power of URLs, then they have a lot mor…

> without paying a company a %-age of the revenue

It may not be a %-age of revenue, but you definitely can't host a non-trivial webapp for free either.

You could even argue that in many webapps scaling costs are proportional to revenue, which makes it awfully similar to an app store.

> But also I think there's a false dichotomy between "the Web should just be for documents" and "the Web should just be for apps."

Yeah, I don't have a clear idea on where the web should "end", but wow... web pages able to eat all my cores and have data races seems like a line to be crossed with great caution and care.

Re: A Taste of JavaScript's New Parallel Primitives

#42

Post by snissn »

pfooti wrote: post #3

You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…

> On the other hand, I quite like the single-threadedness of javascript.

Douglas Crockford's strategy of taking a language, identifying a subset of it, calling it "The Good Parts" and sticking to it is a great motivation to welcome new features, let them evolve but keep your distance from them until they're fleshed out. This has pretty much been the M.O. of Javascript and IMO has worked great..

Re: A Taste of JavaScript's New Parallel Primitives

#43

Post by Klathmon »

cpeterso wrote: post #24

Are JavaScript workers implemented using real OS threads or green threads? How heavyweight is a worker?

They are real OS threads in all implementations i've seen.

As for how heavy, they are definitely a bit heavier than i'd like. But rather than me try to describe it, [1] is a really good benchmark with results that you can run yourself if you want.

[1]https://github.com/gmarty/web-workers-benchmark

Re: A Taste of JavaScript's New Parallel Primitives

#44

Post by warfangle »

schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

So, you're pretty negative on WebGL then?

Re: A Taste of JavaScript's New Parallel Primitives

#45

Post by _getify »

I'm excited about the `SharedArrayBuffer` addition, but quite meh on the `Atomic.wait()` and `Atomic.wake()`.

I think CSP's channel-based message control is a far better fit here, especially since CSP can quite naturally be modeled inside generators and thus have only local-blocking.

That means the silliness of "the main thread of a web page is not allowed to call Atomics.wait" becomes moot, because the main thread can do `yield CSP.take(..)` and not block the main UI thread, but still simply locally wait for an atomic operation to hand it data at completion.

I already have a project that implements a bridge for CSP semantics from main UI thread to other threads, including adapters for web workers, remote web socket servers, node processes, etc: https://github.com/getify/remote-csp-channel

What's exciting, for the web workers part in particular, is the ability to wire in SharedArrayBuffer so the data interchange across those boundaries is extremely cheap, while still maintaining the CSP take/put semantics for atomic-operation control.

Re: A Taste of JavaScript's New Parallel Primitives

#46

Post by Klathmon »

schmichael wrote: post #39
Klathmon wrote: post #34

Earlier quoted context omitted.

For me, it's because "native apps" still fail at the first step, installation. Whether it's a website, or web-app, "installing" it is as easy as going to a URL. You can go to that same URL on your PC, phone, tablet, your friend's computer, etc. and it will run the same. It's easy to share, easy to remember, and if it takes more than 5 seconds from the time you hit enter to the time you are using it, we consider that…

Support for more advanced features like WebGL, DRM, codecs, etc vary by browser and platform. Even the protocols underlying the web - HTTP and TLS - have varying levels of support that affect app developers and portability. Not to mention sharing a link between mobile devices and desktops doesn't always work very well. Don't get me wrong: I appreciate the portability of the web. I just worry the focus on making it mo…

Per the more advanced features.

The one thing that the web has that native doesn't, is a standards body that works to unify and standardize these features so they can eventually work across all platforms.

There have been hiccups in the past (probably the most notable one being the WebSQL vs IndexedDB, but luckily that's mostly sorted out now), but for the most part it's been pretty smooth sailing.

Yeah, you definitely need to wait longer to use new features that can't be "polyfilled" or "shimmed", but the "reward" is that the entire platform is at least moving in the same direction.

While I agree that native has some pretty massive upsides, I personally feel that they should be reserved for things that need them, much like how assembly is treated when compared to higher level languages. And bringing those upsides to the web in a safe and consistent manner isn't a bad thing.

Re: A Taste of JavaScript's New Parallel Primitives

#47

Post by schmichael »

warfangle wrote: post #44
schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

So, you're pretty negative on WebGL then?

Pretty meh. I'm sure there are some excellent uses of it that I encounter and enjoy without realizing it, but few of the advanced demos work for me (Chrome on Linux w/Intel gfx) or bring my computer to its knees rendering at very low FPS.

It feels like something that was more interested in competing with native than offering a constrained and portable approach.

Re: A Taste of JavaScript's New Parallel Primitives

#48

Post by btown »

schmichael wrote: post #41
dherman wrote: post #38

Earlier quoted context omitted.

I don't know if there's a uniform Mozilla position on this, but here's mine! :) The main reason I care about the Web is because it's the world's biggest software platform that isn't owned. If someone can deliver their app to the world without submitting it for review by an app store and without paying a company a %-age of the revenue, and if they can market it through the viral power of URLs, then they have a lot mor…

> without paying a company a %-age of the revenue It may not be a %-age of revenue, but you definitely can't host a non-trivial webapp for free either. You could even argue that in many webapps scaling costs are proportional to revenue, which makes it awfully similar to an app store. > But also I think there's a false dichotomy between "the Web should just be for documents" and "the Web should just be for apps." Yeah…

> web pages able to eat all my cores

We're already there:

    var code = "while(true){}";
    var Blob = window.Blob;
    var URL = window.webkitURL || window.URL;
    var bb = new Blob([code], {type : 'text/javascript'});
    code = URL.createObjectURL(bb);
    for (var i = 0; i

Re: A Taste of JavaScript's New Parallel Primitives

#49

Post by chrisseaton »

zzzcpan wrote: post #15
pfooti wrote: post #3

You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…

> I understand exactly when and where my javascript code will be interrupted That's why callbacks, promises, async/await and all that are neither multitasking, nor multithreading. They are all about control, while multithreading is all about parallelism and is essentially a very low-level specialized thing, that nobody should be using, unless absolutely necessary.

> multithreading is all about parallelism

This just isn't true. Why do you think people wrote multi-threaded applications back when almost all machines had just one processor and just one core? Threads give you concurrency as well, even if you don't want or need parallelism.

Re: A Taste of JavaScript's New Parallel Primitives

#50

Post by atoponce »

CiPHPerCoder wrote: post #22
pfooti wrote: post #3

You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…

A multi-threaded JavaScript also means this becomes more troubling: https://github.com/nodejs/node/issues/5798 Node.js uses OpenSSL instead of the operating system's CSPRNG. The biggest argument for "WONTFIX" is "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us". If JavaScript becomes multi-threaded, it's not unreasonable to expect Node.js to follow. If it does follow, expect random numbers…

Meh. Operating system CSPRNGs can be slow, whereas userspace CSPRNGs seeded from the OS CSPRNG can be fast, fast, fast. Explain how the OpenSSL RNG is broken, and why it's a bad idea to rely on it.
Post reply on HN