冤之一:对搜索引擎的支持不好
这个好像跟搜索引擎扯不上关系吧。
还有谁说WEB设计就一定要有超连接在里面啊。可能告诉我哪里有制定这样的标准啊?
冤之二:编写复杂、容易出错
javascript只是没有直接创建类的方法,javascript是一个完全的面向对象的东西,每种类型的值,甚至函数都可以看做是对象。javascript虽然没有直接创建类的方法,但同样可以用其它方法创建出类,如用function创建的函数可以当做类来new一个对象出来。
至于debug工具不是没有而是比较少,MS的Visual InterDev,Mozilla中的DOM察看器和Javascript Debugger扩展都可以用来调试的。同样也可以用javascript写一些简单的调试程序。
冤之三:冗余代码更多了
会有很多JS代码我承认,但是如果减少了JS代码,就不会增加HTML代码吗?增多的HTML代码分部到不同的页面的每打开也要占用网络。然而大多的HTML都是通过服务器上的脚本产生的,这不是加大了服务器的负担了。把数据的处理放到客户端用JS处理可以分担服务的很多任务。
冤之四:破坏了Web的原有标准
我绝对是一个W3C的支持者,但我不明白用<span οnclick="location.href='detail/';">而不用<a>跟标准有什么冲突的。我记得以前我有看到一个W3C的页面里面,也有这么写的。
冤之五:缺少一个没有标准之争、没有back和history的浏览器
没有back但还是有这个页面的history。可是没有back不觉得对会更好吗,做为用Web开发系统的开发人员来说,常见的一个问题,就是因为back了,引起重复提交。的确有不同浏览器中创建XMLHTTP对象的方法不一样,但使用上是差不多的。开发者可以把这些封装到一个类里面,使用上就从这个类里面创建的一样的。还有这样跟那两个网站有没有什么关系吧,他们爱怎么开发就怎么开发,总不能因为就那两个网站而打死一大片吧。
冤之六:XML只是用来打幌子
这个我是为XML鸣冤的,Jesse James Garrett是不是趋于流行我不知道。但我认为XML的创建就是为了数据格式更明了,开发者之间更容易沟通。所以XML文件是有可能会比较大,难道HTML就不会了吗?本是同根生嘛!(据说下一个版本的XML会加强数据的压缩)在客户端要对XML进行解释,那是肯定的,我觉得这样者使XML的使用上更灵活。你用数组或字符串就不用要对要传送的数据封装成数组或字符串了吗?客户端的脚本解释器就不用解释了吗?