Live data from Hacker News

A Taste of JavaScript's New Parallel Primitives

hacks.mozilla.org

61–70 of 107 posts

Re: A Taste of JavaScript's New Parallel Primitives

#61
post #15

Earlier quoted context omitted.

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

Great point. I find myself reminding people about this all too often.

Re: A Taste of JavaScript's New Parallel Primitives

#62

Earlier quoted context omitted.

> "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us" I don't see this quote within your linked issue and, as far as I can tell, there's no discussion of multi-threading.

I use quotes differently than journalists. I use them to indicate "this is a separate sentence that expresses an idea mid-sentence" and to indicate tone shift, not as a quote for a specific person. I use a > prefix for direct quotes. That exact string isn't from the Github issue, it's a summary of one argument dismissing some of the OpenSSL RNG's worst issues. Here are two direct quotes if that's what you want: > for…

Forking and threading are different things. Forking creates new processes and duplicates memory. It raises entirely different issues from multi-threading, which does neither. See: http://stackoverflow.com/q/2483041/331041

They discussed forking, but did not discuss multi-threading.

Re: A Taste of JavaScript's New Parallel Primitives

#63
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…

Maybe for your standard web app, but try porting Unity or Unreal Engine over without better parallelism.

Re: A Taste of JavaScript's New Parallel Primitives

#64
post #58
post #33

Earlier quoted context omitted.

One reason might be that native app distribution platforms are getting progressively more closed, whereas the web is getting/remaining open.

I might get downvoted for this, but I think it is an important point to really consider. The claim that the web is getting/remaining open is somewhat dubious. As JavaScript and web browsers get increasingly complex, it is harder for anybody to just start up and write a usable, compliant web browser from scratch, which in fact entrenches the status quo. And why do we simply trust the existing browsers? Google has very…

I'm not sure that being able to write a competing browser is a requirement for the platform to be open. Just that anybody can write and deploy code to it.

(Full disclosure: I'm employed by Mozilla, but these opinions are entirely my own.)

Re: A Taste of JavaScript's New Parallel Primitives

#65
post #33

Earlier quoted context omitted.

One reason might be that native app distribution platforms are getting progressively more closed, whereas the web is getting/remaining open.

Closed has benefits. "Curated" is a nice euphemism for closed. It's much easier to childproof a curated app store than The WWW for example. I'm not saying closed is better -- they're just different and that's ok. In fact I like how different they are. It means each has its own unique strengths and doesn't have to worry about trying to do it all.

IMO what you want are curated views into open platforms. Some arbiter deciding what is/isn't acceptable for the platform is very far from ideal. Consider all the great games that have been prevented from going on iOS.

Admittedly, something like this seems difficult to do for the web.

Re: A Taste of JavaScript's New Parallel Primitives

#66
post #58
post #33

Earlier quoted context omitted.

One reason might be that native app distribution platforms are getting progressively more closed, whereas the web is getting/remaining open.

I might get downvoted for this, but I think it is an important point to really consider. The claim that the web is getting/remaining open is somewhat dubious. As JavaScript and web browsers get increasingly complex, it is harder for anybody to just start up and write a usable, compliant web browser from scratch, which in fact entrenches the status quo. And why do we simply trust the existing browsers? Google has very…

Distribution. It's what copyrights are about. GPL and open source licenses are all concerned with terms of distribution. App stores and walled gardens are about controlling and charging rent for distribution. It's basically all about trade.

The web for software distribution is free or very near free in a lot of cases.

Your point about browser vendors monetizing their users is valid, but that is unrelated with distribution of software that targets the browser.

I choose Mozilla; I trust them the most of all of the browser vendors and I appreciate how they continue to drive so many web standards forward.

Re: A Taste of JavaScript's New Parallel Primitives

#67
post #2

> This leads to the following situation where the main program and the worker both reference the same memory, which doesn’t belong to either of them: If only Mozilla had some technology that could deal with ownership of memory... Seriously, if rust doesn't have an ASM.js optimized target yet, it really should.

It's planned.

https://github.com/rust-lang/rust/issues/33205

Re: A Taste of JavaScript's New Parallel Primitives

#68
post #38

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

But more importantly, you just can't beat the URL. How many more times will we convince the entirety of humanity to know how to visually parse "www.zombo.com" on a billboard or in a text message? It's easy to take the Web for granted, it's fun to snark about its warts, and there's a cottage industry of premature declarations of its death. But I personally believe that the humble little hyperlink is at the heart of the Web's power, competitive strength, and longevity. It was a century-old dream passed on from Vannevar Bush to Doug Englebart to Xerox PARC and ultimately to TBL who made it real.

URLs are great, but they don't have to be limited to the web. Or, rather to say, the thing on the other end of the URL doesn't necessarily need to be something the browser handles directly.

I'd like to see something developed that lets you do something like:

    x11://myapp.example.com
where clicking on that link in a browser launches the remote app and then renders the UI locally using X11 remoting - as opposed to trying to render the application UI in the browser.

OK, I know, go ahead and say it.. X11 sucks, X11 remoting doesn't work on WAN links, etc. To which I say:

a. Fine, let's invent something better, that still avoid the need to pack every ounce of functionality in the universe, into a web browser.

and

b. That doesn't jibe with my experience anyway. Just earlier this week I was playing around and decided to launch a remote X app using X forwarding over ssh, over a public Internet link. Worked like a champ. In fact, it reminded me of how fucking awesome X11 remoting really is, and makes me long for either a resurgence of interest in it, OR (see a above) the invention of a newer, better version that everybody can be happy with.

There's also a lot to be said for delivering applications using Java Web Start as well. JWS is wicked cool technology that is tragically under-utilized. IMO, anyway. :-)

Re: A Taste of JavaScript's New Parallel Primitives

#69

> 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 want the web to be a desktop app replacement That ship has sailed a long time ago. >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. Because ...?

Because ...?

Not the poster you're replying to, but I'll share my thoughts:

1. Trying to make the browser ideal for both browsing content, and rendering rich application UIs bloats the browser.

2. Time spent trying to make the browser a poor imitation of an X server is time that could go into making the browser better at, ya know, browsing. FSM only knows, Firefox could use a LOT more developer time spent on improving performance and reducing the memory footprint. (Yeah, I know, sometimes that those goals overlap. But not always, which is the point)

3. For all the talk about how X11 remoting doesn't work over the Internet, I've done it and it worked just fine. YMMV, but it certainly can work just fine in at least some situations.

4. Trying to create a rich experience in the browser inevitably leads to conflicts that don't exist in a desktop app. For example, typically the F1 key is the "Help" key. So if I'm sitting in a web application, and I hit F1, what happens? Do I get help for my application, or for the web browser? Likewise, can my app easily use the F11 key? No. And look at the UI inconsistency between web "apps". There's none. With desktop apps, most apps adhered (mostly) to one of a relatively small set of standards... CUA, or whatever. With web apps, the experience is all over the damn place.

I'm sure there are other good reasons, but those jump out to me.

Re: A Taste of JavaScript's New Parallel Primitives

#70
post #15

Earlier quoted context omitted.

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

Exactly. Threading actually enables a simple asynchronous blocking programming model through locks (at the expense of introducing loads of potential locking hazards).
Post reply on HN