Catchy title eh! Oh well at least it describes the post ;-). Anyway following my trip to the Google Developer Day in San Jose, I noticed a
worrying trend. Obviously people were very focused on Google Gears and how it can be used to "on a plane" enable web applications. Fine, that's all very nice, and I can definitely see where it can be used, with Google Reader being the
shining example. No what worried me more was the addition of the worker
thread pool.
Now don't get me wrong, I can see why they've
built it, Javascript runs in the browser thread and hence any long
running Javascript hangs the browser until it has completed execution,
this functionality in essence gives you multi-threaded Javascript.
However
my gripe is that the general advice that seemed to be emerging from
the speakers is that with this "worker thread pool" you can now perform
complex computation on the client using Javascript. The short of it is
that Javascript is dog slow when doing computation, so to me it's using
the wrong tool for the job, just because you can do it doesn't mean you
should. In the upcoming Dojo Toolkit release with Gears integration it
was announced at the Google Developer Day that they will have local
Javascript encryption going on.....that just doesn't sit right with me.
Javascript's strength is manipulating the DOM and I don't think it
should be misused for other purposes, as misuse generally has
consequences.
Now I think there is a solution to be able to do efficient client
side computation and this is where Silverlight can step into the fray
and TimS has a great post here pointing out that Silverlight isn't just
about presentation.I
can definately see the scenario where I have a small Silverlight
application on the page that's sole job is to handle intensive computation I require
thanks to the CLR. A Silverlight computation component maybe a suitable name for it....probably not as I am rubbish with names, but I hope you get the idea.
Now that to me is using the right tool for the job.