3 ms·

Make Your UI More Responsive with HTML5 Web Workers

42 points by johnrobinsn 13y ago

robmil 13y ago
Unfortunately they're not supported in IE9 or below, which this article oddly fails to mention. So a more accurate title might be "make your UI more responsive for ~60% of your users with HTML5 web workers".
- deleted 13y ago
  [deleted]
- Alphasite_ 13y ago
  I think this is the case for nearly every technology, new, or old, and although they wouldn't be amiss to mention it, 60% is a lot better than a lot of other techniques which get mentioned here.
  - robmil 13y ago
    Oh, absolutely. Web workers are awesome and hopefully the future, but it seems a bit disingenuous not to mention the huge caveat that currently prevents their being adopted in a more widespread way.
- polshaw 13y ago
  Sadly, can't even use it for cross-platform packaged apps (min requirement: chromium, iOS browser, android browser) because the android removed support after 2.1.
  - tuxracer 13y ago
    Chrome for Android supports web workers
- byroot 13y ago
  Browser marketshare is not a constant, it totally depends of your business. At my current job it's: - ~55% Chrome - ~35% Firefox - ~5% Safari - 1.5% IE 9+10 - 1% Opera So for us it make sense to use API even less supported than WebWorkers, like http://caniuse.com/pagevisibility http://caniuse.com/pagevisibility But if I was working for a chinese market place, or a bank intranet I'm sure it would be 80% IE6.
- deleted 13y ago
  [deleted]
- sksksk 13y ago
  There are a couple of polyfills available for Web Workers
addandsubtract 13y ago
Step 1. Make your server more responsive.
- dhruvbhatia 13y ago
  http://webcache.googleusercontent.com/search?q=cache:www.storminthecastle.com/2013/04/19/make-your-ui-more-responsive-with-html5-web-workers/&strip=1 http://webcache.googleusercontent.com/search?q=cache:www.sto...
- robmil 13y ago
  I realise this is snark about the article going down, but it's actually a good point too. Not much point in optimising the client side if all your dynamic requests take a second for the server to process.
  - mtrimpe 13y ago
    Good point. I once spent three months developing a highly optimized dynamically loading Google Maps point & line overlay library capable of smoothly scrolling through thousands of elements with hundreds on screen on 10 year old single-core Pentiums. In the end the server team ended up implementing a home-grown geo-search on an XML document store with an average query time of several seconds.
dreamdu5t 13y ago
What's a practical example of something that can't be done with proper evented programming, and has to be implemented using web workers? If you need to perform CPU heavy calculations or processing of video/audio it just doesn't make sense to do it on the client even with web workers.
- leeoniya 13y ago
  pdf.js uses background workers for parsing/processing pdf pages. really any other native format which could potentially js-processed for display in a browser directly
jdwissler 13y ago
If HTML 5/JS is going to become a serious platform for applications I think it is going to have to be able to leverage multiple threads/cores much more easily. I don't use Web Workers simply because they are too limited in scope in my opinion. Sometimes I just want to search through my local data in my main thread to process 'n' numbers to show some result to the user and I don't want to lock up the DOM for 'n' milliseconds. I also don't want to make an entire new script file just for processing 'n' numbers, what if I need access to data in my main thread? Do I package 'n' numbers up and then send it as JSON? Well that can take more time then actually processing the numbers....and timers...such a hack. I don't know all the design decisions behind web workers and I understand the safety of communicating with strings and events, but sometimes I really just want to call 'new Thread()' and have access to all my variables and data in my main thread. Yes it can be dangerous, yes you can fuck it up, but we still have that problem when we try to make our servers fast. However, maybe I just don't understand how Web Workers work.

42 points by johnrobinsn 13y ago

Unfortunately they're not supported in IE9 or below, which this article oddly fails to mention. So a more accurate title might be "make your UI more responsive for ~60% of your users with HTML5 web workers".

deleted 13y ago
[deleted]
Alphasite_ 13y ago
I think this is the case for nearly every technology, new, or old, and although they wouldn't be amiss to mention it, 60% is a lot better than a lot of other techniques which get mentioned here.
- robmil 13y ago
  Oh, absolutely. Web workers are awesome and hopefully the future, but it seems a bit disingenuous not to mention the huge caveat that currently prevents their being adopted in a more widespread way.
polshaw 13y ago
Sadly, can't even use it for cross-platform packaged apps (min requirement: chromium, iOS browser, android browser) because the android removed support after 2.1.
- tuxracer 13y ago
  Chrome for Android supports web workers
byroot 13y ago
Browser marketshare is not a constant, it totally depends of your business. At my current job it's: - ~55% Chrome - ~35% Firefox - ~5% Safari - 1.5% IE 9+10 - 1% Opera So for us it make sense to use API even less supported than WebWorkers, like http://caniuse.com/pagevisibility http://caniuse.com/pagevisibility But if I was working for a chinese market place, or a bank intranet I'm sure it would be 80% IE6.
deleted 13y ago
[deleted]
sksksk 13y ago
There are a couple of polyfills available for Web Workers

addandsubtract 13y ago

Step 1. Make your server more responsive.

dhruvbhatia 13y ago
http://webcache.googleusercontent.com/search?q=cache:www.storminthecastle.com/2013/04/19/make-your-ui-more-responsive-with-html5-web-workers/&strip=1 http://webcache.googleusercontent.com/search?q=cache:www.sto...
robmil 13y ago
I realise this is snark about the article going down, but it's actually a good point too. Not much point in optimising the client side if all your dynamic requests take a second for the server to process.
- mtrimpe 13y ago
  Good point. I once spent three months developing a highly optimized dynamically loading Google Maps point & line overlay library capable of smoothly scrolling through thousands of elements with hundreds on screen on 10 year old single-core Pentiums. In the end the server team ended up implementing a home-grown geo-search on an XML document store with an average query time of several seconds.

dreamdu5t 13y ago

What's a practical example of something that can't be done with proper evented programming, and has to be implemented using web workers? If you need to perform CPU heavy calculations or processing of video/audio it just doesn't make sense to do it on the client even with web workers.

leeoniya 13y ago
pdf.js uses background workers for parsing/processing pdf pages. really any other native format which could potentially js-processed for display in a browser directly

jdwissler 13y ago

If HTML 5/JS is going to become a serious platform for applications I think it is going to have to be able to leverage multiple threads/cores much more easily. I don't use Web Workers simply because they are too limited in scope in my opinion. Sometimes I just want to search through my local data in my main thread to process 'n' numbers to show some result to the user and I don't want to lock up the DOM for 'n' milliseconds. I also don't want to make an entire new script file just for processing 'n' numbers, what if I need access to data in my main thread? Do I package 'n' numbers up and then send it as JSON? Well that can take more time then actually processing the numbers....and timers...such a hack. I don't know all the design decisions behind web workers and I understand the safety of communicating with strings and events, but sometimes I really just want to call 'new Thread()' and have access to all my variables and data in my main thread. Yes it can be dangerous, yes you can fuck it up, but we still have that problem when we try to make our servers fast. However, maybe I just don't understand how Web Workers work.