下面我就个人观点猜测一下,并行运算将会怎样支持前端javascript的.

1 不太可能的进化

显示线程的支持
如果在Javascript中支持显示线程,那么可能是一种灾难,目前的浏览器解析Javascript并执行都是在浏览器的ui线程中工作的.
比如你可以在Javascript中运行while(true),这时浏览器界面就会停止响应.或者通过我之前的文章(编译Javascript引擎,为JavaScript提供睡眠功能:http://www.cnblogs.com/ioriwellings/archive/2010/08/16/1800416.html)了解UI界面被阻塞的过程.
另外如果显示支持线程必然也会支持线程间数据同步的同步原语功能,那就会出现这样的问题:
在一个函数中获取锁,而在另一个函数中释放锁,但是如果另一个函数出错怎么办,或者另一个函数是从另一个文件中引用的,又碰巧那个文件由于某些原因(网络问题,编码问题)没有加载进来,这时就会发生死锁.
所以根据上面的一些原因,在JavaScript支持显示线程还不太现实.

2 有可能的进化

隐式的并行支持
类似于openMP的宏指令,
下面代码声明并行运算FOR循环:
复制代码 代码如下:
#pragma omp parallel for
for (i = 0; i < N; i++)
　　a[i] = 2 * i;

这种方式可以避免前面遇到的各种麻烦,并行的运算被托管于Javascript引擎内部,所以Javascript引擎有更多的空间处理优化这些并行运算,比如在内部调用openMP,Intel TBB的并行功能.
所以我推测这种方式将会很可能被采用.

3 处理并行异常

由于Javascript代码被隐式托管于并行线程处理,所以你可能不会马上得到某个线程的异常状态,而是要等到全部的线程运行结束后才会知道某些代码出现异常.

4 调试器的进化

会产生支持线程感知的Javascript调试器,能够分析每个线程中的信息,并且能够冻结/恢复某个线程的运行.
当然了,类似于firebug这样的用Javascript脚本写的调试器也将会有更大的提升,但是我想更理想的还是本地应用程序的调试器将会成为主流,比如:visual studio.

5 结语

　　并行运算将会影响前台Javascript的执行性能,很多用Javascript写的前台效果,Javascript游戏的性能将得到改变与提升. 可是我会看到javascript的这种转变吗?

如果实在等不到,还是可以编译现有的js引擎,并添加并行运算接口,然后自已发布浏览器,让客户下载,多核的功能还是可能利用到的.

但是还要兼容现在javascript规范,不然其它浏览器将不能识别你的代码,所以就需要在js引擎内部对原有串行代码分析,而且要准确,将可以转换为并行的代码进行优化.我想这个任务还是很坚巨的.