3 ms·
WebWorkers have nothing to do with threading. They will not let you share memory, and this means that you waste time on seriazlizing/deserializing anything you
by fiedzia 10y ago
WebWorkers have nothing to do with threading. They will not let you share memory, and this means that you waste time on seriazlizing/deserializing anything you pass to them, so from optimization point of view, they are more like processes. This makes js completely unsuitable for things that are data-heavy and cpu-bound (just cpu-bound may work, but it still not the best choice).
- astrodust 10y agoThey do have a lot to do with concurrency, which is often what threads are used for. They do have limitations to fit in with the JavaScript model. JavaScript is generally a lot better at compute intensive tasks than contemporaries like Ruby, Python, PHP and Perl due to the incredible performance of the V8 engine and others like it. The language is ugly, but it's more easily optimized by the JIT compiler. If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
- fiedzia 10y ago> If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development. Java and Go work just fine here and both are used for webdevelopment. My point is that js in not suitable for many cpu-bound operations and neither webworkers nor multiple processes are enough to help it with that. In the browser you don't have other option, but on the server you can (and in practice people do) use other languages like java or go (not to mention C/C++). This is were things like image processing or full-text search goes.