最近更新: 2007-01-08

Markup language 對應用軟體設計工作的影嚮,以及微軟的 WPF/XAML 策略

我參加 2006年「微軟應用平台架構優化」研討會時,在《 建立新一代使用者操作經驗的 Windows 與 Web 應用程式》議程中,我寫下一句話 "Write only one Control/Model with two or more Views." 此為我對該議程內容的總結。

該議程主要介紹使用微軟的 WPF/XAML 技術開發「新一代使用者操作經驗」的應用軟體,然而我看到的只是微軟將一個舊技術按自己的策略量身打造的專有規格。我說的舊技術,是指使用標籤語言 (markup language) 設計應用軟體呈現層的方式。這句話聽來很玄,但其實早已非常普遍, HTML 就是這種技術的最佳代言人。

何謂應用軟體呈現層?說白了就是軟體的使用介面 (UI) 。當我用 HTML 語法在 html 文件中寫下一個 table 、一個 form 以及一個個 button 、 select 時,就是在進行呈現層的設計工作,告訴應用軟體要如何顯示資料,以及如何安排按鈕、選單等使用者輸入元件的位置。毫無疑問,我們這時就是在用 markup language 設計應用軟體的呈現層,而不是使用 programming language 做這項工作。

很久以前,當我準備從 DOS 環境轉移到 32位元作業系統環境時,我同時十分猶豫於要不要將程式開發工作轉移到 MS Windows 下。那時我非常熱衷於 QuickBASIC + 組合語言的開發方式,理所當然地也就嘗試用 VisualBASIC 3.x 版開發軟體。遺憾的是 VB 並沒有我想要的東西,一種讓我不用特定工具就能自由設計使用者介面的方法。基於我在 DOS 下的開發經驗,我非常厭煩於使用 programming langauge 設計使用者介面的事,而 VB 不能令我從中解脫。所幸不久後我就直接轉移到 OS/2 Warp 3.0 和 Linux 作業環境下,並為了維護學校官方 BBS 系統而開始一段不算短的 Linux 系統程式開發經驗,讓我暫時忘了圖形介面程式的事。一直到 HTML/CGI 出現在我面前時,我才發現不用 programming language 就可設計應用軟體呈現層的時候到了。

CGI 規格並沒有規定使用的工具,因此,只要你使用的工具,能夠進行 CGI 所規範的運作方式,就可以用來做 Web programming 。一個有趣的情形是,一個符合 CGI 運作方式的程式,都是傳統的文字介面程式,但使用者在使用時,卻是以視窗模式在操作。 Web programming (in 1999)

Web programming 的概念主要是以分散式架構吸引人們目光,但當時吸引我跳過 Window programming 直接轉到 Web programming 的原因,卻是因為它不需要我使用龐大的 GUI library 而僅靠 HTML 就能設計圖形介面的應用軟體。

所幸這是個 web application 當道的時代, C/C++ programmer 專心開發 server 和 model 就行了,那才是 programming language 擅長的領域。 C++ library 的發展困境

讓我義無反顧地投身 Web programming 的理由就在於 Web programming 允許混合不同語言實現單一軟體的 MVC 架構。把 View 的設計工作交給 markup language 吧, programmer 專心開發 server 和 model 就行了,那才是 programming language 擅長的領域。

我前面說的已是十年前 (1996,1997) 的往事。但十年過了, Web application 還是無法提供如同 Window application 的使用者經驗, programmer 在從事 Window programming 工作時,還是用 programming language 在處理使用者介面。算起帳來,我認為微軟絕對是罪魁禍首。當年的瀏覽器大戰,爭的其實就是誰能主導 markup language browser 的發展方向,結果微軟勝出,帶來是長達五、六年的發展停滯。這段期間 markup language 及瀏覽器本身皆無重大變化,能夠展現的圖形化使用者元件一成不變。一直到 Ajax 出現後,人們才再度將目光放回 Web programing 在使用者經驗上的改良。

慢吞吞的微軟,終於在這股壓力下加快腳步,將推動 WPF/XAML 策略所必須的 IE7 準備妥當。唯有將 Vista 和 IE7 都準備妥當,微軟才能對 programmer 說:「看哪,你們現在只要用 XAML 設計一個頁面 (View) ,這個頁面就可以同時用在視窗和 Web 應用軟體的呈現上了」。在我看來,微軟的 WPF/XAML 是種策略,企圖將微軟在 Windows programming 的優勢延續到 Web programming 。所以微軟無視 HTML5, WHATWG ,弄了個自定的 XAML ;無視 SVG, Canvas ,弄了個 Vista/IE7 only 的向量式 UI 引擎。我們要用 WPF/XAML 技術開發軟體,更要在 Vista/IE 7 下運行,我們才能打造「新一代使用者操作經驗」的應用軟體。這就是微軟的策略。

Programmer 可以普遍地使用 markup language 完成應用軟體呈現層的工作固然可喜,但我卻擔心微軟的作法只會帶來另一次瀏覽器大戰。

相關文章
樂多舊網址: http://blog.roodo.com/rocksaying/archives/2560181.html

樂多舊回應
HACGIS@gmail.com(tokimeki) (#comment-3828789)
Tue, 09 Jan 2007 07:24:28 +0800
我倒不擔心微軟的作法,我比較擔心的是 C Like Family 的程式語言已經很久沒進步了。
相對於微軟的陽謀,這種不進則退的氣氛才令人憂心~
未留名 (#comment-3831895)
Wed, 10 Jan 2007 09:50:47 +0800
C like 程式語言的進步是指哪一方面呢?是一些 syntax sugar 不夠嗎?

從語法看, PHP 是最接近 C 語言的動態語言了。甚至還保有許多 ANSI C like 函數,如 File IO, strXXX。不妨把它視為 C-like 的進步。

C/C++ 本家其實也在縕釀著一些變革,像下一版的 ANSI/ISO C++ 標準 (即 C++0x),還有微軟主導的 C++/CLI 。

關於 C/C++ 語言,我主要關注它的 template 語法 (see C++ library 的發展困境) ,希望未來有更簡單易讀的語法。
HACGIS@gmail.com(tokimeki) (#comment-3834028)
Wed, 10 Jan 2007 18:43:39 +0800
語法糖衣還好,有一些根本的東西,我說不太上來。
有點類似語言應該進化,但進化的目標在哪,看不到...

現在的狀況事實作廠商掌握某些東西,卻又找不到放諸四海皆準的、讓大家能夠遵循的xxx

我個人認為現在大家都在講哪個Class Libray如何又如何,眼球都跑到那裡去了,程式語言本身呢?似乎不怎麼重要。
反正你在C/C++/P3P裡面都找的到C Libray,那.NET呢?別鬧了,用MS的東西就同意他的邏輯(Mono裡面有沒我我就沒研究了)~

我一直有在看見鍵盤上那32個「特殊」的符號,想找到他們跟程式語言間一致的對話,希望能提一個Draft,讓程式語言對這些符號有一致的認定。