-1

I am fascinated with non-blocking architectures. While I haven't used Node.js, I have a grasp of it conceptually. Also, I have been developing an event-driven web app so I have a fundamental understanding of event programming.

How do you write non-blocking javascript in the browser? I imagine this must differ in some ways from how Node does it. My app, for example, allows users to load huge amounts of data (serialized to JSON). This data is parsed to reconstitute the application state. This is a heavy operation that can cause the browser to lock for a time.

I believe using web workers is one way. (This seemed to be the obvious choice, however, Node accomplishes a non-blocking, event-driven architecture I believe without using Web Workers so I guess there must be another way.) I believe timers can also play a role. I read about TameJS and some other libraries that extend the javascript language. I am interested in javascript libraries that use native javascript without introducing a new language syntax.

Links to resources, libraries and practical examples are most appreciated.

EDIT:

Learned more and I realize that what I am talking about falls under the term "Futures". jQuery implements this however, it always uses XHR to call a server where the server does the processing before returning the result and what I am after is doing the same thing without calling the server, where the client does the processing but in a non-blocking manner.

http://www.erichynds.com/jquery/using-deferreds-in-jquery/

Mario
  • 6,572
  • 3
  • 42
  • 74
  • Do you mean multi-threading? Are you doing computationally intensive client-side work? – SLaks Oct 11 '11 at 17:14
  • Why do you need non-blocking javascript in a browser environment? – Raynos Oct 11 '11 at 17:19
  • non blocking on client side ?? the whole idea behind using javascript for node was the non blocking event driven model of javascript – Anil Shanbhag Oct 11 '11 at 17:33
  • @Raynos: To provide a positive user experience where the browser does not EVER lock up. – Mario Oct 11 '11 at 18:04
  • @Anil: I thought Node.js is a server-side paradigm. I believe Node does exactly what I'm after. Nevertheless, my application locks the browser sometimes. That's because it has computationally-expensive processes. If how coded your javascript was not a factor, the browser would never lock up. – Mario Oct 11 '11 at 18:07
  • @SLaks: Yes, computationally-intensive client-side work. – Mario Oct 11 '11 at 18:13
  • Actually, Nicholas Zakas in High-Performance Javascript, Ch6 also refers to Web Workers and timers (as well as Ajax, Ch7, where processing is sent to the server). – Mario Oct 11 '11 at 18:20
  • @Mario as mentioned hacks (`setTimeout`) or web works are tools to solve this problem. the other option is never doing expensive work and making an ajax request to some server to do expensive work for you – Raynos Oct 11 '11 at 18:25
  • @Raynos: Thanks. I'd have marked your answer as right if it weren't just a comment. :) – Mario Oct 11 '11 at 18:49

2 Answers2

2

Three are two methods of doing non-blocking work on the browser

  • Web Workers. WebWorkers create a new isolated thread for you to do computation in, however browser support tells you that IE<10 hates you.
  • not doing it, expensive work in a blocking fashion should not be done on the client, send an ajax request to a server to do this, then have the server return the results.

Poor man's threads:

There are a few hacks you can use:

  • emulate time splicing by using setTimeout. This basically means that after every "lump" of work you give the browser some room to be responsive by calling setTimeout(doMore, 10). This is basically writing your own process scheduler in a really poor non optimized manner, use web workers instead
  • creating a "new process" by creating a iframe with it's own html document. In this iframe you can do computation without blocking your own html document from being responsive.
Raynos
  • 166,823
  • 56
  • 351
  • 396
0

What do you mean by non-blocking specifically?

The longest operations, Ajax-calls, are already non-blocking (async)

If you need some long-running function to run "somewhere" and then do something, you can call

 setTimeout(function, 0)

and call the callback from the function.

And you can also read on promises and here as well

Community
  • 1
  • 1
Guard
  • 6,816
  • 4
  • 38
  • 58
  • ew don't use `setTimeout` as a mediocre time splicing mechanism, use web workers – Raynos Oct 11 '11 at 17:35
  • Some of my processing is expensive. For example: I allow the user to load huge JSON files (serialized information) that need to be parsed and converted to objects for use by the app. This can lock up the browser. – Mario Oct 11 '11 at 18:00
  • @Raynos Web Workers aren't available in older versions of IE, and there is definitely a limit to what can be achieved (can't touch the DOM, can only pass JSON-serializable object, etc.). `setTimeout` should be used responsibly of course, but it's very useful under certain conditions. – keeganwatkins Oct 11 '11 at 18:07
  • Mario, then you should probably investigate promises (see https://github.com/briancavalier/when.js as well) – Guard Oct 11 '11 at 20:29
  • @Guard: Yes, promises is very similar to what I'm looking for. The only aspect is that promises that make Ajax calls appear to be non-blocking. I don't know if the same would hold true of Promises that perform their processing in the client. – Mario Oct 11 '11 at 20:53
  • That's true if the processing itself is not blocking - as @Raynos suggests look into creating a web worker that once its operation is complete call's deferred operation .resolve – Guard Oct 12 '11 at 14:03