腳本技術從最早的出現，到引起一陣瘋狂，到現在理性的拒絕，已經有了很長的一段的發展了，對于到底在網頁的技術中腳本起了一個什么作用，我覺得這么一個定位非常重要，我來談談我個人的一點粗淺看法：
1、作為一種分離內容與外觀的工具
這是一種很不尋常的用法。利用把頁面的數據寫入到腳本的變量之中，然后用客戶端的腳本把變量中的數據寫入到HTML之中。（非常不推薦的做法）
2、作為一種表現工具
我覺得在現在的網頁技術的條件下，應該以這么一種態度來對待HTML。HTML曾經是網頁的唯一，但是現在HTML僅僅是一種WEB的表現層的技術。同樣的數據，你可以用HTML來表現，也可以用FLASH來表現，也可以用其他的技術，比如SVG。HTML應該把自己定位為一種純粹的表現語言，就像美工手中的筆一樣。那么CSS和客戶端腳本就是幫助HTML更好的做表現的工具。
腳本能夠讓靜態的HTML，有一定動態的表現。當然你為了讓頁面能夠動起來，能夠有一定的交互（這種交互不是內容層面的，是用戶體驗層面的），你可以選擇不同的WEB表現技術。比如FLASH，或者是HTML+腳本。
3、作為一種幫助分離表現和邏輯的工具
你可以很輕易的使用XML或者其他的東西，把頁面模板化。但是有一點是經常被忽略的，頁面除了作為一種內容表現之外，還承載了一定的邏輯。那就是頁面中的窗體，鏈接往往是給服務器端腳本的一定輸入，如果我們想象一下就是數據從客戶端發出HTTP請求開始，到服務器執行PHP之類的腳本，到把HTML頁面傳回，再到客戶端發出另外一個請求，頁面其實在一種不僅僅扮演了服務器給瀏覽者“看”的角色，也扮演了讓瀏覽者“通知”服務器的角色。這是一個流程邏輯，如果把整個網站作為程序的化，就是程序的流程。
一般的情況是在PHP的模板，或者XSLT的模板或者別的什么之中，頁面中的鏈接位置，表單的元素以及發往位置都是由美工來填寫的。這是不應該的，美工應該不處理這個，但是這里服務器端的腳本無能為力，因為HTTP是一個主動的協議，必須是客戶端主動的把數據推到服務器那一端，所以美工必須把需要的數據發送到下一個程序流程流向的位置。而僅僅這其實給模板技術提出了一個問題，就是要分離的不僅僅是內容與外觀，而且要分離頁面與頁面流程。
在這里，有一個東西是能夠在客戶端起很大作用的，那就是客戶端的腳本，這里指的可能是JavaScript也可能是ActionScript。它們能夠控制頁面流向，而且能夠從頁面中抽取出用戶的順序。所以只要讓美工去調用程序員寫好的客戶端腳本，把客戶端的事件通知給腳本。而腳本是由程序員寫的，而且很有可能是由程序員寫的服務器端腳本動態生成的客戶端腳本，這樣就讓程序邏輯能夠貫穿在客戶與服務器兩邊，而美工這個角色完全被分離了出去。