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