.net会取代JavaScript
1． JavaScript简单性：
2． 解释执行
3． 基于对象，弱类型
4． 独立的编程模型，开发效率过低，难以单独执行，功能太弱，适用范围太窄：除了写些低级的网页，没有任何其他用途。
5． 学习代价高.学习了这一门语言，但它并没有给你带来新的思维模式，没有新的东西，对开发人员没有任何思维上的启迪。不像c, c++, vc, win32, mfc, c#，lisp，都带来一种新的体验，而且你学了，有能用它做什么？仅仅是低级的网页制作。
6． JavaScript的设计不再适合现在网络的发展。这可以很容易从JavaScript的目标，JavaScript所解决的问题分析。JavaScript设计是为了扩从Html，而Html发展至今，以暴露出了太多的缺点，对之进行模式的改革，是一种必然的事情，只是现在没有人去做仅仅作协表面上的修改, 就像进行了简单修改的XHTML，DHTML，没有从另外的思维的角度重新设计，只是修修补补，难以担当重任。我们需要一种新的页面描述标记，新的控制语言。
为什么还要用JavaScript?在今后的历史中，JavaScript会仍然立足吗？
我认为。按照.net的发展趋势，在以后的版本中，会完全抛弃JavaScript.可以从以下几个方面来分析。
1．.net很庞大，功能全面，结构合理。除了一些Win32的遗留的代码，底层驱动，控制领域之外，人们将会很少用到Wind32代码。也就是说，基本上，除了VC会继续坚守阵地，并往核心部分聚集之外，不会再有别的Win32语言，以前流行的Win32版本的VB，Delphi, PowerBuilder必将逍声戾迹，取代之的是经过修改的新平台下的dotnet版本。
2. 作为后起之秀，dotnet有太多比Java高明的地方，部分或取代Java是一种历史必然
3．随着.net的普及，windows能克服由于WinApi带来的各种弊病，例如兼容性，可移植性，稳定性，安全性等，但Windows写卸掉这个最沉重的包袱之后，将会重新获得新生，大踏步的向前发展，而这更进一步促进了.net的普及。
4. dotnet平台的开放型很好，CLR为中心，而IL是一种经过抽象的高级汇编语言，对计算机软件的发展，将是革命性的。由于CLR是一种抽象的汇编语言，不局限硬件，因此比x86系列的汇编语言更适合于教学研究。人们可以从两个方面去研究IL,，从高级语言转换为IL和IL转换为本机机器代码的角度，研究各种转换原理算法，进行优化，组合，核心部分重组，以适合于各种电子平台，不仅是电脑。
而在C＃代替JavaScript，只要浏览器客支持.net就可以，虽然由于dotnet太过于庞大，实现难度比较大，但借着微软的实力，为了推广dotnet，浏览器完全可以实现dotnet的浏览器精简版，这时候dotnet将会给开发人员将带来多大的便利，开发效率，编程模型，思维模式，代码移植，只能编码…
真期望这一天的到来。
]
HTML在被创造出来的时候，只是用来描述文本信息，以及文本之间的关系的，Tim Benas Lee也不会预料到Internet时代的热潮。不论人们后来在Browser上面附加了多少功能，Javascript也好，Applet也罢，ActiveX(Flash)，都没有从根本上面改变HTML交互能力弱的问题。其实大部分人都意识到了，不彻底改变当前的HTML，就没有办法改变Browser的弱点。
然而彻底改变HTML的方式的前提就是Broswser功能的扩充，考虑到Windows操作系统和IE浏览器占据了绝大部分市场份额，这个功能最有希望完成的也只有MS公司了。
在MS下一代表示层技术Avalon中，XAML将取代HTML，Browser的功能被扩充，页面不再是扁平的，而是立体俄，事件处理代码不再是Javascript，而是C#。然而考虑到Longhorn在2006年上市，到普及推广，我觉得可能要到2010年前后，XAML才有可能全面取代HTML。那么在此之前，仍然会是HTML/Javascript的方式。
在过去，Browser端的主流是HTML/Javascript，在将来，Browser端的主流是XAML/C#，那么当前一些富Javascript技术的Browser方案是否会成为过渡时期的主流呢？我的看法是没有成熟的开源框架的情况下，是不会的。
我们过去也曾经比较多运用DHTML实现一些方便的页面操作，例如在一个页面里面隐藏很多层，当点击某个信息，察看明细记录的时候，层显示出来，层里面的内容也俨然像一个窗口一样，并且模仿Windows的桌面窗口，有关闭按钮，有标题栏什么的，还可以像Windows桌面窗口那样拖来拖去，把很多客户都骗了。并且可以在一个页面里面做很多的工作。
但是Javascript/DHTML是有很多缺陷的：
1、复杂的Javascript事件处理相当的消耗CPU资源，有时候甚至很惊人
2、Javascript本身语法简单，很难做到类似面向对象语言的扩充性，复用性，因此无法大面积复用
3、Javascript的触发严重依赖页面元素对象，因此很难抽象出来高度复用的代码，很难降低Javascipt和DHTML元素的耦合性
4、Javascipt的可视化效果是最差的，如果过多运用Javascript来控制页面显示的话，美工根本对页面无从下手，甚至程序员在没有把页面运行起来之前，也无法判断页面显示出来的样子。
5、Javascipt/DHTML在不同的浏览器，在浏览器不同版本之间的表现差异很大
6、一个富Javascipt/DHTML的页面开发效率是很低的，我的经验是，如果可以使用服务器端状态控制完成的需求，我用好几个页面，加上少量的服务器端代码可以在半天时间完成的工作，那么我如果单纯用Javascript来完成，可能一天都搞不定这个页面的控制(也许Javascript高手例外)
7、大面积运用Javascript，页面很难维护，甚至无法维护
因此，我个人是不赞成使用富Javascript的浏览器端技术的。我的主张是贫Javascript的浏览器端技术做为这几年的过渡。Javascript可以有限的运用在数据输入校验，页面跳转，数据选取，Area编辑，日历控件，动态菜单，树状显示等等方面，而不宜以Javascript为核心构建浏览器端解决方案。
HTML这种方式的本身就和传统的Desktop操作流程有所不同，非要勉强的通过富Javascript技术的方式来实现一些传统的Desktop的操作流程，我认为是代价比较大的。既然你运用了HTML，就应该接受多写一些页面，多一些流程跳转的这种Browser操作方式，而不是类似Bindows那样企图把所有状态控制都在一个页面搞定。
回想过去我们用Delphi/VB/PB写Desktop程序的方式，拖拉出来控件，然后给控件的事件编写响应代码。MS webforms在这方面迈进了一步，然而仍未摆脱HTML的桎梏，于是搞出来一个XAML，扩充操作系统和浏览器，摆脱HTML的限制，真正实现Desktop那样方便的事件响应式编程，同时又保留了Browser方式用简单的标记来描述窗口元素布局的优点。
这样看起来HTML/Javascript方式将来总归会被淘汰(至少在2010年以后吧)，其实不是Javascript有什么错，而是HTML太弱了，如果HTML被淘汰，Javascript也只好被淘汰了，这就是我对Javascript未来发展的一个预测。所以我自己不想在Javascript方面投入更多的学习成本，我原来搞Javascript的底子还在，我更愿意多关注一下XAML。
最后我要声明的是，我不是一个Javascript反对者，我在2000到2001年也下狠功夫钻研Javascript过，我也认为当前的Web开发人员必须掌握足够的Javascript编程知识，不能忽视Javascript的作用，我只是不赞同把Javascript/DHTML抬高到浏览器端解决方案核心地位的观点而已。