谈谈Javascript

不可能，如果你的表现层完全是JS写出来的话，是很容易维护的。

正是这种做法可以大大降低维护的成本

在很多公司里面JS开发给人的印象是美工干的一些花哨活，不是技术，不是程序员做的事情，这就很难让一个工作了一段时间的JAVA程序员去做这些JS代码，做纯粹的JS开发工资水平上不去，因为在公司内部不是主流技术，程序员他们一般不干，做JS的小孩工作量显得就非常大，一个人要应付几个项目组，干一段时间后就想转岗，或者就是跳槽。

用JS的开发出桌面应用的效果，代码量不会小的，前年我们做产品开发时，个人工作平台的通讯录、活动、任务管理这些模块，界面和操作方式基本上和Outlook一致，一个前台程序员在一个多月里写了几千行的JS代码，因为公司以前很少想过做JS的积累，怎么设计出结构清晰，可复用的组件，并且怎么将这种设计技术和方法能做为一种知识积累留下来，让我很头疼。

对于JAVA开发，公司会制定编程标准、测试规范、公用API包，JS则很难，没人重视或者就找不到合适的人来制定标准和规范。

公司的技术体系是由技术决策人来制定的，往往这个决策人的好恶决定了公司的主流开发技术，采用这些主流技术的人能得到公司的重视，也可以占用公司更多的资源，而非主流技术即使你用的再好，公司也不会给你多投入资源。Dlee的公司技术决策人将XMLHTTP做为框架核心，也就决定JS在他们公司是一种程序语言，而不是页面脚本，但是其它的公司会吗？

至于JS技术，每种技术都有优缺点，倒不如大家把JS什么方面做的好，什么方面不适合做有案例来说清楚，怎样做好JS代码设计，有哪些JS的页面处理模式。

大家手上都有一些项目的页面模板，就找出一些通用的页面组件，大家来看看怎么设计，这些都是一些书本上没有的东西，整理出来也是一份功德无量的事情。

Javascript is good. However,
JavaScript is procedure language.  So it has the drawback of this kind of language. For example, if there is a global variable, it is very hard to maintain since we can change everywhere. But some changes will bring us big trouble if this variable is condition tag.

It is very hard to debug once our JS becomes very complicated.

Some function such as ParseInt() is not strong,which also gives us potential trouble.

By the way,  HTC is good component in reusability, although it is just for IE

说的是啊，可是你想想做出同样复杂的交互，写 Java 的代码量难道就会小吗？谁统计过 JS 的代码行数就一定会比 Java 要多？其实根据我写 JSP 的经验，我感到代码量在大部分情况下是相等的，因为复杂度并没有根本的变化，只是分布到了系统的不同的部分。但是因为现在可以做某些事情，例如不刷新页面更新页面的一部分，因此需要做得页面比以前少了。页面的工作量也是工作量啊，美工 mm/gg 不是人吗（他们也能算是人吗？垃圾活都交给他们就行了）？

如果从总共的工作量（代码+页面）来说我的估计是工作量会小一些的。而且达到了更好的交互，这种效果是传统的开发方式无法达到的。也许有人认为这些根本就不重要，但是我们现在是只要现有技术有这种潜力就一定要把它榨出来，因为我们很清楚更好的交互对于我们意味着什么。


我写的 JS 编程规范中明确规定：
除非在迫不得已的场合，不应该使用全局变量。而应该以函数参数和函数内部变量代替。

这个缺点似乎不是一个致命的缺点吧？Java 的 IO 包做得很差，所以我们不应该使用 Java 语言，这个理由是不是很合理？

我发现一个很有意思的现象，就是几乎所有技术人员在碰到对他信仰的置疑时，都像被别人戳到自己的痛处，表现出来非理性的排斥。我过去置疑EJB的时候看到这种现象，我现在置疑Javascript，仍然看到这种现象。好在我自己是一个喜新厌旧的人，总是喜欢不断在否定中培养对新事物的兴趣。

我知道我一旦否定什么技术，立刻就会有人跳出来置疑我是否懂xx技术，是否有xx技术的经验，是否有资格否定它，Javascript我2000-2001年的时候也搞了很久时间的，现在涌现出来了什么新的Bindows，HTC我确实不懂，也没有用过，不过Javascript本身好像没有增加什么功能罢，如果是这样的话，我还算是对Javascript比较精通的，我想我在用VBScript的时候，恐怕这里很多人都还没有开始他的Javascript编程经历吧。

我先强调一点，就是我从不反对Javascript技术本身，我是认为Web程序员必须掌握足够Javascript知识的，只是由于Javascript本身的局限，它适合做页面辅助性的交互工作，而不适合被扶上前台，以Javascript技术为核心构建浏览器端解决方案。

我最怕某些人用简单的非黑即白的逻辑给别人乱扣帽子，我提出对EJB的置疑观点，就有人说我是EJB的外行，没有EJB经验；我提出对Javascript的置疑观点，就有人说我不懂Javascript，没有Javascript经验，是Javascript的疯狂反对者，这是一种粗暴的无礼，好了言归正传。上面那么多挺Javascript，反驳我的观点的看得我眼花缭乱的，也没有办法一一反驳，挑出来几个地方随便谈谈。

1、关于JS.net

我预测Javascript终将被淘汰的依据其实很简单，就是HTML你是否承认会被淘汰？如果你承认HTML会被淘汰，那么OK，依附于HTML的Javascript也只能随之淘汰。

上面不止一个人把JS.net当做救 命稻草，但是我要提醒一下，不管JS.net，还是VB.net，与C#.net相比只有语法不同，而没有本质区别，他们同样要调用底层的dotnet framework，看看现在VB.net除了语法，有哪点像VB？学习语法简单，半天时间足够，但是你要熟悉整个应用程序框架和类库，那可不是一朝一夕的功夫了。

就算XAML搭配的事件处理代码是JS.net，JS.net也不过是C#.net换了一层皮而已，他本质还是dotnet framework，而与Javascript相去十万八千里了。所以如果你拿JS.net当做救 命稻草的话，最后就就会发现他原来还是C#，你还是不知不觉的走上我预测的路。

2、关于XAML是否应该绑定动态语言

其实是否绑定动态语言，例如JS.net，还是绑定动态语言，例如C#，这都不重要，既然现在Java平台都有了Groovy，Beanshell等等动态脚本语言，dotnet  平台做一个出来又有什么不可以？但是这种动态语言还是依托dotnet的，所以和C#仍然没有本质区别，而与Javascript相去甚远。

3、回归Rich Client

都说要回归Rich Client，但是是哪种形式的回归？我不知道你们有没有仔细考虑过Browser Application和Desktop Application之间的优缺点：

Browser Application优点是用简单直观的标记语言来描述界面，界面构造快速，简单，灵活，门槛低，易于美工和程序员分工协作；缺点是绑定的事件处理机制太弱，交互能力太差；

Desktop Application的缺点是用不直观的，复杂的二进制桌面应用程序框架来构造界面，界面的制作成本比较高、不灵活，无法实现美工和程序员的分工协作；优点是强大的事件绑定机制，交互能力强，表达能力强。

传统的C/S业务逻辑是放在客户端的，将来回归到Rich Client，与传统方式不同，业务逻辑是放在服务器端的，Desktop只处理用户交互，数据录入，校验，报表打印等等。

如何结合Browser Application和Desktop Application优点，避免两者的缺点，那么就是使用Browser Application的标记语言来描述界面，用Desktop Application的事件机制来处理用户交互。

Javascript本来就是Browser Application中的事件处理机制，也是Browser Application中最弱的一环，它怎么可能成为未来新的表现层技术的事件机制技术呢？那不是扬短避长吗？

4、技术延续性保证Javascript的生命周期

这种观点只说对了一半，HTML/Javascript将在Internet Website中长期存在，也许一直有可能存活到2015年，但是HTML/Javacript在Intranet Web Application中，存活期绝不可能到2010年，如果Longhorn在2006年如期上市，预计到2008年，在企业Web项目中，XAML/C#就无疑将成为主流。

既然你们现在承认以Javascript/XMLHTTP为核心构建浏览器端解决方案，可以只考虑IE的某个版本，放弃其他浏览器兼容性，那么2008年，当客户公司批量购买的品牌电脑全部预装Longhorn操作系统，给客户公司实施公司内部的Web系统，我凭什么不可以放弃HTML/Javascript兼容性，而只考虑XAML/C#兼容性呢？同时还将解决HTML/Javacript解决不了的问题，我为什么不这么做呢？

XAML/C#能统一UI，干脆我们都用.net吧。前台.net，后台j2ee，增加维护量。
不过XAML/C#是否能统一UI，我觉得很难说，ms不是每次都会那么顺利的。
听说flash 下个版本actionscript完全跟javascript一样了。
js玩熟了，转玩flash也不错，毕竟flash的UI组件比js丰富。

我觉得前台UI主要用js有个缺点，就是开发周期太长了。
做复杂的UI，还有一定的风险，有时候出错，都找不到那里有问题。
我们有个项目，本来是想用html+js+jsp做的，用以做好的模版，可是系统
存在太多问题，我们打算自己重做（原来是跟别人合作）。
4月份之前一定要做出几个模块，如果用js做UI，恐怕来不及。
曾经想过用webstart,但是swing开发太麻烦，效率也不是很好。
后来想用dephi+com桥——ejb，后来想，直接用.net不是更好？
开发相当快速。

我现在用的操作系统是是win2k.win2k在1999年已经出来了。我觉得用起来还不错。虽然winxp也还不错，但我从来就不喜欢使用，我买的T40带了合法的xp,我还是把他换回win2k.没有为什么，因为我觉得从98-2k过渡很平滑。而且我也打算就这么用下去了，xp我是不想用了也许直接跳到2003.
我上面的话的意思是假如Longhorn2006年能如期的发布，并且很顺利，而且功能的确很强大，那你认为客户公司完全购买新的机器并且全部装Longhorn大概会到什么时候？据我所知道的电脑的折旧是3年，也就是说比较顺利的话有部分公司在2008－2009左右才会大量的安装Longhorn。按照这种非常理想化的进展，2010年左右XMAL会想今天的HTML成为下一代的事实标准。
但很显然的一点Longhorn中的浏览器假如还是IE,绝对不会不支持HTML.M$绝对不会给别人这么一个大的机会。也就是说HTML/Js 2010年还是有市场的，当然可能不如今天。但谁有能保证XMAL/C#就一定会比HTML/Js拥有更多的市场呢？
其实我真真想说的是，现在对2010年去做预测没有任何意义。因为并不是最好的技术就一定有市场。就像80年代风云一时的DEC公司，最后下场很惨淡。有很重要的一点需求产生市场。而不是市场决定需求。
也许过几年会有更好的方案出现，谁知道呢？所以至少在今天我们还是只能面对HTML/Js,虽然我也不喜欢。客户也不喜欢。没办法，如果你给我更多的钱，我就帮你做更好的方案。降低成本是一个企业永远的主题。

对阿，当支持Avalon的Longhorn普及之后，你就会发现用XAML比HTML降低成本了，很多HTML解决不好的问题，你用XAML可以很轻松的解决，这时候你怎么选择？

还有想说的就是谁有保证,HTML/Js不会发展呢？我没有去留意XHTML的进展如何，也许在这几年中XHTML发展的还不错呢。也许XUL.Flex也会有很不错的进展呢？我为什么要把宝压在XMAL/C#上去？没有理由。