淘客熙熙

主题:【原创】新时代新潮流WebOS 【1】 -- 邓侃

共:💬594 🌺1902 新:
全看分页树展 · 主题 跟帖
家园 JavaScript 编译问题

是邓兄在回复,邓嫂这几天在忙别的。刚才晚饭的时候,邓兄把最近的讨论简略地向邓嫂做了汇报。邓嫂边听边剥虾,说,“你们先讨论着,回头我看看”。邓兄把头埋下,不敢正视,咕咚一声很响地喝了一大口汤。。

说正事,

1.

一个语言是否是script,是由其运行时间的状态决定的,跟语法无关。我们可以写一个C++的解释器,也可以做一个javascript的编译器,对用户的不同,就是运行速度。其实x86的汇编,也有hotspot runtime translator / optimizer,听起来很java,对不对?

反问一句,如果JS需要编译好了再发到浏览器上去,为什么需要保留JS,而不直接用Java?

换句话说,为什么浏览器一定要死抱着JavaScript,而不内置一个JVM,直接支持Java?

或许有人说,早年浏览器都支持Java Applet,后来没有人用Applet,因为JVM启动慢,版本匹配也经常出问题。启动的问题,在于每个网页的Applet都在一个独立的JVM上运行。如果有个全局的JVM,不管哪个网页都用它,就不存在启动慢的问题。版本的问题,在于浏览器厂商自行决定使用哪个版本的JVM,譬如MS的IE内置的JVM就不同于Sun的JVM。为了解决这个问题,Sun的办法是把JVM移出浏览器,搞了一个Java Web Start。但是这样做,代价是浏览器和外置的JVM之间数据交换的成本高。

所以我的偏激的看法是,美老爹分析得很对,但是结论有疑点,不是JS技术上有什么优点,它存在的理由仅仅是钻了空子,也就是浏览器内置JVM在商务上的纠葛。

2.

所以我想问:为什么不保留javascript的语法,在后端把它变化成高效率的编译器?其实google V8已经走出了javascript runtime optimization这一步。那么为什么对于手机,不把html+css+javascript用云去进行编译+优化,转化为紧凑高效的中间格式,发给移动终端呢?

对于Google手机而言,它已经有了Android/Dalvik VM,何不把手机上的WebKit和Dalvik联成一体?为什么还要保留JS这个第三者?

3.

对于javascript调用本地代码的事情,主要是一个安全性问题,M$干过ActiveX可以调用本地代码的事情,这倒不是不可为,只要仔细研究了调用本地代码的危险性,并把危险隔离在某个沙盒里,就是可以做的。

我的看法更极端,连Sandbox都不需要,只要规定好哪些native APIs能够被调用,哪些不能即可。

4.

其实我对google的某些做法不是很理解,比如当年收购sketchup,放着网络上面那么多VRML的东西不理,去买这么个公司,不是浪费资源么?google是靠梳理网络现有文档起家的,怎么走了这么一步?

同意,同时我也不理解,为什么Google不去收购一家做Online Visio的公司,丰富Google Docs。

5.

对于javascript,我的看法是:支持现有标准,保护众人已有的投资和努力,并发展之。

我比较激进,看不到JS存在的强悍理由,未来JS不看好。

观点比较偏激。无知出偏激,估计是有些问题我没有想明白,欢迎美老爹继续斧正。(你的评论很好,但是目前还没把我彻底驳倒。我是那种被按在地上动弹不得才服软认输的家伙。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河