论坛首页 Web前端技术论坛

给Ajax技术初学者的一些建议

浏览 65402 次
该帖已经被评为精华帖
作者 正文
   发表时间:2007-05-16  
非常感谢。如今想学AJAX真愁不晓得那些书好呢
0 请登录后投票
   发表时间:2007-05-16  
风之印 写道
非常感谢。如今想学AJAX真愁不晓得那些书好呢


推荐《ajax实战》,如果觉得吃力,可以看《ajax基础教程》,在看不懂第一本的情况下,千万不要看《ajax模式与最佳实践》,要不会郁闷死的,呵呵,我看起来都很头大……
0 请登录后投票
   发表时间:2007-05-16  
winterwolf 写道
jindw 写道
感觉这个帖子应该封贴了。

这个问题或许有点仁者见仁,智着见智的味道。
都在兴头上,思想更容易走向极端。

既然都没有办法短时间说服对方,不如让时间去证明一切。


要是能打出点创意就好了。 可惜buaawhl不在了


buaawhl不在了 什么意思 我的偶像哦
0 请登录后投票
   发表时间:2007-05-16  
jianfeng008cn 写道
winterwolf 写道
jindw 写道
感觉这个帖子应该封贴了。

这个问题或许有点仁者见仁,智着见智的味道。
都在兴头上,思想更容易走向极端。

既然都没有办法短时间说服对方,不如让时间去证明一切。


要是能打出点创意就好了。 可惜buaawhl不在了


buaawhl不在了 什么意思 我的偶像哦


最近看不到了
0 请登录后投票
   发表时间:2007-05-18  
我有一本《ajax基础教程》,感觉还可以。
0 请登录后投票
   发表时间:2007-05-18  
终于回到正题上了
《ajax基础教程》是入门的第一推荐
0 请登录后投票
   发表时间:2007-05-21  
dlee 写道
另外,你的那个JSI,其实设计方向有些偏。现在确实需要有一个更高的抽象层能够更紧密地将一些常用的UI组件库(包括Ext、Dojo、Prototype等等)集成在一起,解决它们之间存在的严重的互操作的问题,但是UI组件库主要的一些设计关注,包括分离页面的结构/表现/逻辑,Unobtrusive、Progressive Enhancement、代码的可测试性、可维护性等等,并没有在你的JSI这里体现出来。你一味地强调JavaScript代码本身的侵入性,这是很奇怪的。我以前曾经追问过你为何你认为Dojo的JavaScript代码侵入性很大,而你本人貌似很不屑于回答这样的问题。

使用你的库做开发,开发成本并不会有明显的下降,而且还附带有一些额外的学习成本在里面。DHTML开发我还有一点经验,也许经验没有你丰富,但是我还是有能力区别出好的UI组件和不好的UI组件的。


这一方面,我不同意dlee的说法。我很能理解jsi的意义,因为我本人也有类似的想法和项目(pies: http://sourceforge.net/pies)。UI库是实际的需求没错,但路要一步一步走,饭要一口一口吃。jsi或者我的pies首先考虑的是,解决传统js基础架构的缺失。越是program-in-large,基础架构的作用越是显著。而且jsi和pies对于dlee说的Unobtrusive、Progressive Enhancement、代码的可测试性、可维护性等问题确实会有帮助。

关于js的侵入性问题,其实非常重要,因为这是做类库的人的痛点!金同志所说的侵入性首先是指你的代码或其他人的第三方代码纳入框架后,是否要对自己作出改动,如果要被迫作出改动,实际上就是被框架侵入了,剩下的只是看侵入的程度如何了。例如jspkg,虽然侵入但是程度很低,只是代码要做一下包装而已。相反dojo以及许多需要显式增加命名空间定义的,恐怕就大很多了。在实际当中,这样很麻烦。例如我用了一个第三方的开源类库,它自己会频繁更新,结果每次更新我都需要重新修改它的源码以适应框架,这是不可忍受的。

第二个问题,更加关键,就是引入第三方代码后,是否会造成框架中其他部分甚至框架自身的毁坏?最简单的例子,就是namespace冲突,原先框架自己所需的一个方法被第三方代码冲掉了。这就可以说是框架的抗侵入性。现在许多框架通过一定的手段(如closure),基本能保证自己不被侵入,但是绝大多数框架不能保证两组第三方代码不会互相冲突。例如prototype和jquery乃至许多框架都使用了$这个名字,那能否同时使用两个类库?进一步,有些库基于prototype,有些基于jquery,我能否两者和平共处?

目前就我所知,只有jsi, pies, jspkg(需要对代码进行简单包装)可以做到。

所以也许在只有少数脚本的时候,使用jsi或pies并不能带来很多益处,但是牵涉代码越多,特别是第三方代码很多的时候,jsi和pies这样的框架不仅是提高效率的问题,更重要的是能避免很多潜在的名称冲突造成的问题,而这类问题,不用说,是出了名的难以调试。

另一方面,上述这三个框架都带有类似的log机制可用于debug和简单的unit测试。

最后再说一下UI组件。这就比单纯的js问题要复杂很多。我私意是较为怀疑现在的各种ui组件的方式,最主要的原因是他们虽然可能易用,但是可能打破了web的典型架构即semantic markup+css,而且如何面向未来的html5(webapp1)和xhtml2,存在很大的问题。
0 请登录后投票
   发表时间:2007-05-21  
很感谢hax所做的深入的分析。其实关于JSI,我也需要再多做一些深入的理解和学习,也希望它能够发展成熟,这对于国内的Ajax开发者非常有价值。

我其实和jindw私下通过站内短信交流过,目前我们两个的观点其实并没有很严重的冲突。唯一的冲突就是jindw目前尚未将客户端与服务器之间的关系作为比较优先的考虑方面。这当然是与JSI本身的定位有很大的关系,这样做有助于他集中精力来解决一些关于DHTML和JavaScript组件开发的问题。

不过一个好用的UI组件开发出来之后,还必然会遇到如何将它使用好的问题,这对于改善Web应用的可用性是非常重要的。其实我们无论使用Ajax还是RIA,最终的目标只有一个,那就是真正地改善Web应用的可用性,而不是因为我特别喜爱DHTML或者特别崇拜M$和Bill Gates。有了好用的基础UI组件之后,还要设计师恰到好处地使用它们,才可能建造出一个可用性良好的Web应用。这就是我并不认为使用上了WPF之后,世界就会立即变成一个我们心目中的理想国的原因。实际上,WPF等RIA技术仍然没有从Web应用可用性的高度为开发者提供全面的指导(如果我的理解错误,WPF Fans请赶快来纠正)。当然我相信达到相同的可用性,使用WPF所基于的XAML应该会比使用DHTML更容易一些。做Web表现层开发,深入理解什么才是真正的软件可用性是非常重要的,我们当然不会满足于创造出一个又一个会跳舞的熊,所以我在前几年花了相当多的时间阅读和学习这方面的书籍。

说到Web应用的可用性,那可是一个相当大的话题了,关于这方面的书籍也出了不少。我不推荐大家去读很多很厚的书,只给大家推荐一本书《Don't Make Me Think中文版》,这本书只有100多页,读起来也相当的轻松。如果大家有很多的时间,可以考虑阅读《About Face 2.0中文版》和《面向使用的软件设计》。

Web应用的可用性,其实会严重受到应用性能的约束,一个性能很差的应用,根本谈不上有什么可用性。Ajax应用会涉及到大量的网络交互,如果架构设计不当,很容易带来严重的性能和可伸缩性问题。所以我希望大家能多关注一些这方面的问题,而且这方面的问题对于各种RIA技术来说都是相通的。

前面大家关于REST架构设计的激烈争论,我并没有积极参与。其实证明REST架构设计确实能够做目前基于Web MVC或者其他架构风格能做的全部的事情,我觉得价值也不是非常大。即使能够证明,这群人还是会说,既然都能做同样的事情,我继续使用传统的架构设计方法不是就足够了吗?为何还要学习REST呢?实际上并非如此,REST不仅仅让你能够做自己想做的事情,而且让你以一种最有效率的方式来做这些事情。基于REST的架构设计,可以得到Web应用所能得到的最佳的性能和可伸缩性,这对于改善可用性是非常重要的。所以如果有人跟我争论JSF就是比REST好1000倍(如果他恰好脑子里面哪根弦不对了,一定要将JSF与REST完全对立起来。当然,说SOAP比REST好1000倍也类似),我只需要举一个理由就足以把他打倒了,那就是REST的可伸缩性会比JSF(或者SOAP)好的多。
0 请登录后投票
   发表时间:2007-05-21  
dlee 写道

前面大家关于REST架构设计的激烈争论,我并没有积极参与。其实证明REST架构设计确实能够做目前基于Web MVC或者其他架构风格能做的全部的事情,我觉得价值也不是非常大。即使能够证明,这群人还是会说,既然都能做同样的事情,我继续使用传统的架构设计方法不是就足够了吗?为何还要学习REST呢?实际上并非如此,REST不仅仅让你能够做自己想做的事情,而且让你以一种最有效率的方式来做这些事情。基于REST的架构设计,可以得到Web应用所能得到的最佳的性能和可伸缩性,这对于改善可用性是非常重要的。所以如果有人跟我争论JSF就是比REST好1000倍(如果他恰好脑子里面哪根弦不对了,一定要将JSF与REST完全对立起来。当然,说SOAP比REST好1000倍也类似),我只需要举一个理由就足以把他打倒了,那就是REST的可伸缩性会比JSF(或者SOAP)好的多。


rest的论文看了一些.

jsf技术就不谈了 设计的太笨了. leebai的框架还有点意思

我多看热闹少发言 希望大家继续辩论.
0 请登录后投票
   发表时间:2007-05-21  
dlee 写道

前面大家关于REST架构设计的激烈争论,我并没有积极参与。其实证明REST架构设计确实能够做目前基于Web MVC或者其他架构风格能做的全部的事情,我觉得价值也不是非常大。即使能够证明,这群人还是会说,既然都能做同样的事情,我继续使用传统的架构设计方法不是就足够了吗?为何还要学习REST呢?实际上并非如此,REST不仅仅让你能够做自己想做的事情,而且让你以一种最有效率的方式来做这些事情。基于REST的架构设计,可以得到Web应用所能得到的最佳的性能和可伸缩性,这对于改善可用性是非常重要的。所以如果有人跟我争论JSF就是比REST好1000倍(如果他恰好脑子里面哪根弦不对了,一定要将JSF与REST完全对立起来。当然,说SOAP比REST好1000倍也类似),我只需要举一个理由就足以把他打倒了,那就是REST的可伸缩性会比JSF(或者SOAP)好的多。


rest的论文看了一些.

jsf技术就不谈了 设计的太笨了. leebai的框架还有点意思

我多看热闹少发言 希望大家继续辩论.
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics