Ajax开发20个问题
历经多年的发展,Web仍停留在点选、换页的浏览方式。 Ajax出现后,改写了此种网页必须不断重新载入的互动模式,运用非同步技术,网页只更新局部的内容,因此提供使用者更顺畅、即时的互动模式。 少了「重新载入」的动作,Ajax呈现的是比传统更酷炫效果,但是否该全面采用Ajax,企业除了看热闹外,更想了解「门道」。 Ajax会不会拖慢效能?主要的学习门槛是什么?搜寻引擎会不会因此找不到网页内容,而影响了网站曝光度?其他RIA(Rich Internet Application)技术是否会取而代之?更重要的是,会不会引发资安的问题? 让我们一网打尽所有关于Ajax的问题,帮助你打通任督二脉,快速了解Ajax美丽与哀愁。 概念 Q1:采用Ajax技术,除了酷炫效果之外,还有什么好处? 其实最直接而明显的好处,是减少网页重新载入的次数。 根据统计,购物网站每刷新一次网页,就会有10%的消费者在等待的过程中「清醒」,发觉未必有购买的需要,而取消交易。当网页不再因为少部分的资料被修改,就必须重新载入整个网页,即可减少使用者等待的时间,提供更流畅的操控体验。 无论是酷炫效果、精致的画面,或者顺畅的流程,对于网站的形象、商品销售及使用者体验都具加分的效果。 Q2:操控流畅对网站是有加分效果,但从企业的角度,关心的层面还包括Intranet的应用,Web应用程式适合加入Ajax技术吗? 注意力持续,有效提升生产力 在Web化的时代,企业最担心的问题,并不是浪费了那几秒等待载入网页的时间,而是人在等待的空闲,很自然地会开启另一个网页,注意力就被导引到其他更有趣的资讯上,再次回神时,可能是半小时以后。 所以,对购物网站而言,注意力的持续是订单的保证;对企业而言,则是生产力的提升。 延续桌面应用程式的操控体验 以Yahoo!邮件信箱与Mail 2000为例,在Ajax化之后,使用者体验的是与Outlook极其类似的操作方式。网擎资讯从用户的回馈发现,由于操控方式的改变,使直觉与便利性向前跃进一大步,因此使用者满意度明显提升。 Q3:会不会拖慢Web伺服器效能? Ajax技术与传统网页与Web伺服器沟通方式各有不同。传统的作法是用户端送一个请求(Request)至Web伺服器,即使只需更动一个栏位的值,Web伺服器仍需重组一个完整的网页,回应(Response)给用户端,也因此浏览器必须重新载入一次。 相较之下Ajax技术使网页具备程式能力,当使用者修改资料,触发了JavaScript程式,浏览器便将使用者输入的资料传送至Web伺服器,Web伺服器会再把需要回传的资料送至浏览器,当JavaScript接收到资料之后,再把结果呈现在网页上。 过程中完全没有触发提交动作,Web伺服器只回传需要修改的内容,而且浏览器也没有重新载入的动作。这对伺服器负载、频宽使用量及用户端的操作体验是三赢的局面。 根据UrMap改用Ajax技术传递地图资讯的经验,在使用人数成长了10倍以上的情况下,伺服器的负担相较于以往仍是减少,而频宽使用量也没有增加太多。 再以网擎资讯Mail 2000 4.5 Beta版改采Ajax技术为例,观察的结果发现,伺服器需要运算的资料量减少,频宽成本也下降。以一页的信件列表为例,过去100封邮件约需要传送 120KB的资料量,现在则降为30KB。点选「新信检查」功能,递送的资料量约略是过去的1/5~1/4。 Q4:AutoComplete这类的Ajax机制,频繁地向伺服器要资料,应该会拖慢效能,是否有方法可解? 不过,此类问题可从设计上解决,例如设定快取机制、延长反应的时间、每填入3个英文字母才查询一次,或者限制使用资料等,都是可能的解法。 带领开发UrMap的友迈科技董事长卓政宏形容:「这是一种程式管理资源的方法。」他举例:UrMap下载的地图资讯,其实略多于网页显示的范围, 使用者微幅地拖拉或缩放地图时,其实叫用的是本机资料,并没有对伺服器发出请求。所以,只要根据使用者的行为模式调整设计,就可以降低伺服器的负担。 Q5:那么Ajax对用户端的执行效能有何影响? 不过,首次登入网站时,下载的资料除了页面呈现的内容外,还包含强化互动性的JavaScript程式时,你可能会发现载入时间变长。针对用户端的执行效能,Yahoo!国际资讯软体工程师蒋定宇认为:「尽量缩短JavaScript程式码,就可以将影响降到最低。」 Q6:企业如果要导入Ajax,人才好不好找? 其实Ajax主要是JavaScript的应用,但蒋定宇从面试JavaScript工程师的经验发现:「台湾比较重视ASP、Java和 PHP。」过去JavaScript是设计警告讯息或文数字检查等辅助网页输入的稿本语言,所以开发者普遍认为JavaScript、HTML、CSS只 是网页设计的辅助语言,所以好的JavaScript人才难寻。 网擎资讯研发经理张嘉渊提出类似观点:「技术都不是问题,JavaScript不难,但要写得好,不容易。开发者必须用写『核心』的心态开发JavaScript。」 Q7:那么对于懂JavaScript的程式开发人员而言,Ajax的门槛在哪里? Ajax技术超出单纯程式开发的范围,开发者需要与设计人员合作,并了解网页相关的CSS、DHTML、DOM等技术。即便成熟的工具相对降低学习的难度,但要学的东西变多了,同样形成一种门槛。 Q8:这么看来,网页开发团队的角色定位与合作方式,是否因为导入Ajax而必须改变? 而今在VD与RD之间,多了一个WD(Web Developer,网页开发人员),举凡「检视原始码」可看到的内容,包括HTML、CSS、JavaScript都是WD负责的范围。 工作方式将产生明显的变化,VD描绘出网页应该有的样子,WD则思考HTML标签的语义,使用正确的标签做出正确的网页结构,再搭配CSS给予外观样式。此外,最重要的工作就是运用JavaScript撰写网页的前端互动行为。 网页设计流程到WD为止,仍是非真实的页面,尚未连接后端真实的连结与资料。当网页交给RD之后,RD人员负责套上真实的连结与资料。 这样的开发流程并非台湾Yahoo!特有的设计,在美国Yahoo! ,他们称WD为Front-end Engineer;而蕃薯藤称为Web Master;趋势科技则称之为Prototyper。 工作形态的转变是必然的趋势。当前端网页的设计,除了美工之外,还包含程式化机制,人员角色与开发流程都会随之变化。即使在有限人力的情况下,必须 一人分饰两角(通常是RD再身兼WD的工作),但设计(Designer)与开发(Developer)两者的合作模式,仍不同于以往。 Q9:网页包含CSS、HTML,还有JavaScript程式,是否会不好维护? 不过,虽然维护Ajax网页并不困难,但相较于其他程式语言,即使JavaScript的开发工具已经逐渐成熟,除错(Debug)方面的功能仍有 瓶颈。主要是因为各种浏览器针对使用者的操作,所触发的各种事件仍有差异,除非浏览器走向标准化,否则开发工具要模拟各种浏览器的行为仍有难度。 不过还是有一些选择。就像IE浏览器已经推出Internet Explorer Developer Toolbar,或者可以选择IE Inspector推出的AxScripter等,而Firefox则提供Firefox Debugger。透过这些外挂套件的协助,已经逐渐降低除错的难度。 Q10:既有的网站或Web应用程式,是否建议以Ajax技术改写吗? 然而,对既有的网站而言,「为技术而技术」是非理性的行为。卓政宏认为:「技术的进步总是会有帮助,但必须考量是否有投资的价值?企业应该思考Ajax能做什么?」 邱继弘建议:「针对特定问题,运用Ajax解决技术上的瓶颈就好。」许多功能往往是牵一发而动全身,稍加更动就必须全部改写,全盘翻新的风险太高。 Ajax原本就是众多技术的集合。对于初学者而言,Ajax的门槛不低。即使只是微幅的修改,在测试与上线的过程中,仍有许多琐碎的工作要面对,所以冒然采用未必是明智的决定。 Q11:Ajax技术会不会有跨平台的限制? Q12:Ajax技术跨浏览器的问题该如何解决? 或者,最简单的方式,就是套用YUI等Framework,透过平台解决相容性问题。 Q13:Ajax开发的应用能否平顺地在电脑、手机、PDA等不同装置上顺畅运行? 再者,每款手机的萤幕大小都不同,况且一般网页的资料量灌入手机萤幕会显得冗长。若要讲求美观,都必须针对行动装置提供特殊化的内容。例如国外知名的微型部落格网站Twitter,便针对手机平台设计特制的网站m.twitter.com。 Q14:听说用Ajax开发的网页内容,搜寻引擎可能找不到,那不就会影响网站的能见度? 若是改由JavaScript动态产生内容,那么将变成是由事件驱动(Event Driven),也就是使用者「开启」网页或「点选」连结才会产出内容,那么搜寻引擎机器人便无法找到资料。 邱继弘说:「这是网站设计的一种思维。希望增加曝光度,就要能够被搜寻引擎找到。」推推王中关于Ajax技术多半都用在视觉上,每笔资料都有独立的网址,他们绝对不破坏「Content Unique」的原则。 Q15:什么样的应用不适合采用Ajax? 网页需要变动的范围比例很高 排序 需要换页的应用 Web应用程式之所以适合采用Ajax技术的原因,也在于应用程式没有换页的概念。因此,在开发Ajax应用时,设计者也应在操作思维上,避开使用者会想按「上一页」的可能性。 Q16:若讲究高互动性,其他RIA技术例如微软的Silverlight及Adobe的Flash,可以提供更即时互动的效果,为什么选择Ajax? Ajax会不会只是过渡性的技术? Silverlight或Flash的门槛更高 从微软展示的Silverlight案例中,德国的女性购物网站OTTO、法国的法雅客购物网站,它们的图像化、直觉式的流畅设计确实令人目炫神迷。 假如是没有专业美工人才的网站,他们更难以面对Dreamweaver或Expression Blend,要接受以时间线(Timeline)结合图层产生动感效果的概念,开发人员需跨过的门槛更高。 Flash、Silverlight与Ajax可以并用 而Flash的应用,程式化采用的稿本语言是ActionScript,它的语法非常类似JavaScript,但仍可能令开发者感到排斥。 Adobe现已提出解决的方案,为了强化Flash与Ajax的互动,Adobe推出Flex-Ajax Bridge,让JavaScript与ActionScript可以相互沟通,那么Ajax与Flash元件就可以并存。 安全性 Q17:使用Ajax,是否让网站曝露在更高的风险中? JavaScript本身是用户端的程式语言,是在网站使用者的电脑中执行,不像伺服器端的脚本程式,因此对网站本身造成威胁的机会极低。 有些人认为Ajax程式能够透过检视程式码的方式看到它的程式逻辑与变数使用方式,而增加对网站的攻击面,不像伺服器端的程式,能隐藏程式语法。 事实上,一个安全的网站,原本就必须在前端资料传递到后端时,做好过滤与把关的工作,不要相信前端传来的东西,这是一个网站开发人员必须牢记在心的 金科玉律。如果伺服器端程式在设计时能谨守本份,重视程式的安全规画,那么无论前端是由使用者输入资料传来的,或是由JavaScript程式传递而来, 都一样安全。 反而是由伺服器端发展出来的Ajax解决方案,例如DWR,能让使用者能从前端程式使用后端Java语法,即可能有潜在的安全威胁。 Q18:使用XMLHttp Request进行非同步传输时,难道没有潜在风险? 不过Web 2.0盛行的混搭(Mashup)方式,透过开放API进行资料交换,而这种方式的确就是绕过同一网域的限制,会产生一定的风险。设计这类API时,必须特别注意它的存取限制,以免让骇客有机可趁。 Q19:Ajax会向伺服器频繁要求资讯,是否会对网站形成阻断式攻击(Denial of Service)的效应? 就拿Google搜寻时会采用自动完成的功能,列出可能的搜寻关键字,或是雅虎奇摩的字典查询服务,也有相似设计,只要输入文字,便会向伺服器要求待选字。 这个安全性问题应该就两个层面来看。首先应用这类Ajax语法时,原本就必须做好效能考量与测试,例如善用快取功能,记录反覆查询高的关键字,反而能降低伺服器的负担。 其次,如果骇客打算使用DoS对一个网站发动攻击时,事实上无论是不是采用Ajax都一样,而且利用Ajax发动DoS,不见得是有效率的作法。 Q20:如果Ajax对伺服器端的危害有限,那么对用户端呢? 过去使用者还可以透过关掉JavaScript方式,以降低浏览网站时的风险,不进入Ajax网站关掉JavaScript,形同使用者拒绝进入该网站,因为基本功能都无法使用。 由这观点来看,的确Ajax盛行,让骇客更有机会透过XSS的手法侵害使用者,不过XSS之所以能成功,通常是网站本身已经存在资安防线上的漏洞, 例如没有检查使用者上传的资料,或是应用程式、系统本身有漏洞,如果能做好这些资安防护,那么即使采用再多的Ajax功能,使用者一样安全无虞。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |