從Silverlight到Metro的心路歷程
趁有空，用文字整理一下沒能完整在研討會上分享的心情。
從Windows 8的Metro Style Apps開始有消息時，我們就在官方的Slides上，看到了針對Metro Style Apps的開發，寫明了是可以採用多種技術，包含HTML+JavaScript, 包含XAML+C++, 包含了XAML+C#(VB)...
那時候可能很多人覺得疑惑，咦? XAML+C#，那不就是Silverlight(或WPF)嗎? 那為何不乾脆寫Silverlight呢?
我們知道，早在.NET 3.0開始(2006年)，WPF就是用XAML來描繪UI，而Silverlight的出現比WPF晚上了幾個月(2007年)，沒想到在實務(實際使用)上，Silverlight後來比WPF更加的廣泛，同時也成為微軟在RIA上對抗Flash/Flex的利器。
(請回憶一下，在這個時間點， iPhone 才剛剛出現, iPad 還不知道在哪裡咧...)
後來沒多久，Windows Phone被迫出現了(2010年)，我們都知道，Phone/Pad成功的關鍵，與App的多寡有著非常大的關係，因此從現在回頭看，在2010那個時間點，當時要讓App快速出現，最好的方式就是選擇一個可以快速上手，並且已經有著一定數量開發人員的開發技術，這個技術又要支援多媒體效果，又要有現成的開發工具，還能夠很快速地讓Runtime可以Porting到當時Windows Phone所採用的Windows CE上面，在當時時間如此急迫的狀況下，幾乎沒有任何其他的選擇和可能性，因此Silverlight雀屏中選，成為WP7.0和WP7.5的主要開發技術。
好，知道歷史背景之後，我們回頭談XAML+C#, 前面說到, 因為當時Silverlight幾乎可以代表XAML + C#(VB)這一掛的開發技術，所以在我們看到Win8 Metro Style App所採用的主要開發技術是XAML+C#(VB)之後，很自然的覺得，Metro的開發技術可以用XAML+C#，那到底是不是說，Silverlight可以用在Metro Style Apps開發上呢?
現在回頭看，答案揭曉了，答案可以說是也可以說不是。但原因原來如此地簡單，因為：
Silverlight = XAML+C#(VB)
但
XAML+C#(VB) 卻不等於(而是大於、是包含) Silverlight
請注意，在今天這個時間點回頭來看，我們很容易理解，XAML+C#(VB)這樣的技術組合，至少有下面這幾種方式：
1.WPF = XAML + C#(VB) + Full .NET Class Library
2.Silverlight = XAML + C#(VB) + .NET Class Library Subset
3.Metro = XAML + C#(VB) + WinRT
別忘了，XAML是描述UI的技術，C#(VB)是Programming Language，但光這兩個還不夠，第三個組合(Runtime的Class Library Framework)也是一個重點，XAML只管UI(包含Binding、Animation...etc)而Programming Language就只是寫程式用的語法，早在.NET 3.0從WPF開始我們就在概念上把這兩種東西分開了，這樣的概念就好比是HTML搭配javaScript、或Asp.net的Code Behind概念一般，目的是讓邏輯程式碼與描繪UI的程式碼分離，好處顯而易見，就是降低相依性，讓開發團隊中的UX設計師與程式設計師可以分工，又不會彼此干擾。(這是近代展示層應用程式設計的一大重點)
所以，有了這樣的概念之後，其實我們如果從更宏觀的角度來看Metro/WPF/Silverlight，這幾種開發技術的Programming Model幾乎大同小異，XAML與Programming Language根本上都差不多，唯一的差別是Runtime的Class Library。
所以我在研討會上再次說了『流淚撒種的，必歡呼收割』，過去我們在XAML(Silverlight/WPF)上花的心思，事實上一點都沒有白費。
過去我們(公司、我個人、和我的學生、夥伴們)花了不少時間在XAML(Silverlight)上，今天不管在Silvelight(應用在Internet/Intranet、Windows Phone)，在WPF(應用在Desktop)，在Metro(應用在Windows 8、Windows Phone)，都可以得心應手，你過去熟悉的開發技術(XAML/C#(VB))其實並沒有改變，你用這套開發技術在微軟的世界中，可以橫跨 Web / Desktop / Phone / Pad 這幾種不同的平台(當然，我指的是在微軟的設備上)，也因為如此，很多人擔心的Silverlight是否還會活著的問題，其實或許並不存在。
我們剛才說了，Silverlight是XAML+Programming Language(C#/VB)+Run Time Class Libraries的集合， 如果你可以更宏觀的看，如今的Metro Style App開發技術，與Silverlight不僅僅是系出同門，更可以說是攣生兄弟。
那這樣是否代表著兩者完全相同? 當然也不是，即便是攣生兄弟，在不同的環境下長大，也需要面對不同的生活環境， Metro / Silverlight / WPF 之間的差異大致上就是這樣，因為這三種同父同母、系出同門的開發技術，在應用上Metro是要面對平板、智慧型手機，Silverlight是要面對Web環境、WPF是要面對Desktop，自然會衍生出不同的個性。(也因此，我會在後面陸續慢慢分享一些Silverlight與Metro Style App開發之間的差異與相同之處，你會慢慢發現，其實你累積下來的經驗比你想像的還有用)
在分工比較細的公司或專案團隊，我們大概不會要求開發人員Metro/Silverlight/WPF三種都會，但很抱歉，你在台灣，你是全能Developer，而我們過去也都受過這種全能開發人員的養成教育，所以我得說如果你是.NET Developer，那Metro/Silverlight/WPF三種通吃針對你來說應該也是很自然的狀況才對。
更嚴格地說起來，Metro/Silverlight/WPF三種開發技術從某個角度來說，根本就是一種(而不該當成三種來看)。
這也是我在研討會上，特別提醒開發人員，不要只看到改變，要多看看你留下來的經驗，你才會發現，其實過去的經驗很有價值。同時，在這個多變的時代，你擁有或掌握的學習能力與經驗，價值遠勝於你擁有或掌握的技術。技術是會變的，但你的學習能力與經驗，則是可以累積並且重用的。
至此，我可以說，Silverlight有沒有死去，開始不是一個問題，(如果你堅持要討論，我會說我覺得還早)，不僅如此，熟悉XAML( WPF/Silverlight )的開發人員，比起傳統的開發人員來說，有著更廣泛的發展空間，對於未來的專業領域生涯規劃，也將有著相當大的可能性。
我在討論這件事情的時候有沒有立場? 我要說：『或許有』! 公不公道? 『我想可能有些人覺得不一定!』 但至於這個判斷正不正確? 就由讀者來決定囉 :)
端午佳節將至，建議各位放鬆心情，吃飽粽子之後，我們再回來繼續衝刺。
~祝大家 佳節愉快~
從Windows 8的Metro Style Apps開始有消息時，我們就在官方的Slides上，看到了針對Metro Style Apps的開發，寫明了是可以採用多種技術，包含HTML+JavaScript, 包含XAML+C++, 包含了XAML+C#(VB)...
那時候可能很多人覺得疑惑，咦? XAML+C#，那不就是Silverlight(或WPF)嗎? 那為何不乾脆寫Silverlight呢?
我們知道，早在.NET 3.0開始(2006年)，WPF就是用XAML來描繪UI，而Silverlight的出現比WPF晚上了幾個月(2007年)，沒想到在實務(實際使用)上，Silverlight後來比WPF更加的廣泛，同時也成為微軟在RIA上對抗Flash/Flex的利器。
(請回憶一下，在這個時間點， iPhone 才剛剛出現, iPad 還不知道在哪裡咧...)
後來沒多久，Windows Phone
好，知道歷史背景之後，我們回頭談XAML+C#, 前面說到, 因為當時Silverlight幾乎可以代表XAML + C#(VB)這一掛的開發技術，所以在我們看到Win8 Metro Style App所採用的主要開發技術是XAML+C#(VB)之後，很自然的覺得，Metro的開發技術可以用XAML+C#，那到底是不是說，Silverlight可以用在Metro Style Apps開發上呢?
現在回頭看，答案揭曉了，答案可以說是也可以說不是。但原因原來如此地簡單，因為：
Silverlight = XAML+C#(VB)
但
XAML+C#(VB) 卻不等於(而是大於、是包含) Silverlight
請注意，在今天這個時間點回頭來看，我們很容易理解，XAML+C#(VB)這樣的技術組合，至少有下面這幾種方式：
1.WPF = XAML + C#(VB) + Full .NET Class Library
2.Silverlight = XAML + C#(VB) + .NET Class Library Subset
3.Metro = XAML + C#(VB) + WinRT
別忘了，XAML是描述UI的技術，C#(VB)是Programming Language，但光這兩個還不夠，第三個組合(Runtime的Class Library Framework)也是一個重點，XAML只管UI(包含Binding、Animation...etc)而Programming Language就只是寫程式用的語法，早在.NET 3.0從WPF開始我們就在概念上把這兩種東西分開了，這樣的概念就好比是HTML搭配javaScript、或Asp.net的Code Behind概念一般，目的是讓邏輯程式碼與描繪UI的程式碼分離，好處顯而易見，就是降低相依性，讓開發團隊中的UX設計師與程式設計師可以分工，又不會彼此干擾。(這是近代展示層應用程式設計的一大重點)
所以，有了這樣的概念之後，其實我們如果從更宏觀的角度來看Metro/WPF/Silverlight，這幾種開發技術的Programming Model幾乎大同小異，XAML與Programming Language根本上都差不多，唯一的差別是Runtime的Class Library。
所以我在研討會上再次說了『流淚撒種的，必歡呼收割』，過去我們在XAML(Silverlight/WPF)上花的心思，事實上一點都沒有白費。
過去我們(公司、我個人、和我的學生、夥伴們)花了不少時間在XAML(Silverlight)上，今天不管在Silvelight(應用在Internet/Intranet、Windows Phone)，在WPF(應用在Desktop)，在Metro(應用在Windows 8、Windows Phone)，都可以得心應手，你過去熟悉的開發技術(XAML/C#(VB))其實並沒有改變，你用這套開發技術在微軟的世界中，可以橫跨 Web / Desktop / Phone / Pad 這幾種不同的平台(當然，我指的是在微軟的設備上)，也因為如此，很多人擔心的Silverlight是否還會活著的問題，其實或許並不存在。
我們剛才說了，Silverlight是XAML+Programming Language(C#/VB)+Run Time Class Libraries的集合， 如果你可以更宏觀的看，如今的Metro Style App開發技術，與Silverlight不僅僅是系出同門，更可以說是攣生兄弟。
那這樣是否代表著兩者完全相同? 當然也不是，即便是攣生兄弟，在不同的環境下長大，也需要面對不同的生活環境， Metro / Silverlight / WPF 之間的差異大致上就是這樣，因為這三種同父同母、系出同門的開發技術，在應用上Metro是要面對平板、智慧型手機，Silverlight是要面對Web環境、WPF是要面對Desktop，自然會衍生出不同的個性。(也因此，我會在後面陸續慢慢分享一些Silverlight與Metro Style App開發之間的差異與相同之處，你會慢慢發現，其實你累積下來的經驗比你想像的還有用)
在分工比較細的公司或專案團隊，我們大概不會要求開發人員Metro/Silverlight/WPF三種都會，但很抱歉，你在台灣，你是全能Developer，
更嚴格地說起來，Metro/Silverlight/WPF三種開發技術從某個角度來說，根本就是一種(而不該當成三種來看)。
這也是我在研討會上，特別提醒開發人員，不要只看到改變，要多看看你留下來的經驗，你才會發現，其實過去的經驗很有價值。同時，在這個多變的時代，你擁有或掌握的學習能力與經驗，價值遠勝於你擁有或掌握的技術。技術是會變的，但你的學習能力與經驗，則是可以累積並且重用的。
至此，我可以說，Silverlight有沒有死去，開始不是一個問題，(如果你堅持要討論，我會說我覺得還早)，不僅如此，熟悉XAML( WPF/Silverlight )的開發人員，比起傳統的開發人員來說，有著更廣泛的發展空間，對於未來的專業領域生涯規劃，也將有著相當大的可能性。
我在討論這件事情的時候有沒有立場? 我要說：『或許有』! 公不公道? 『我想可能有些人覺得不一定!』 但至於這個判斷正不正確? 就由讀者來決定囉 :)
端午佳節將至，建議各位放鬆心情，吃飽粽子之後，我們再回來繼續衝刺。
~祝大家 佳節愉快~
留言