隨著喬布斯所培育的大蘋果越發清香誘人後，安卓、谷歌等也難耐不住寂寞，紛紛推出自己的智能手機或平板電腦。隨著這股潮流，湧現出一批又一批的開發者，有開發游戲的、有開發應用的，也有開發企業軟件的。而選擇的語言和技術也多種多樣，HTML5、Silverlight、Java、Objective-C等，尤其是當HTML5推出後，整個開發世界好像地震了一般。以上這些，說明什麼呢？移動軟件開發商和開發人員們又如何在這場撲朔迷離的大變革中選擇出一條最穩妥的路呢？
觀點一：HTML5是趨勢，但不是你的優勢
HTML5是趨勢，但它絕對不是最佳選擇，現階段它無法給你銀彈。那為什麼它會如此之熱，而火熱的背後又會給你帶來什麼？微軟、谷歌、蘋果等各大廠商紛紛瞄准HTML5，這將是他們瓜分Web的最佳武器，誰利用的好，誰就會贏得最終的勝利。在這驚心動魄的戰役中，誰也不服誰，你“創新”了HTML5這個特性，嗯，很好，我也實現它，實現的比你更好，那朋友們可能會疑問了這不是很好的良性競爭麼，HTML5將會越來越繁榮的啊。可是，朋友們不要忘記，HTML5現階段只是一份草案。尚未定標准。如果這樣話，各種各樣的所謂的“創新”，就形成了五花八門的API，好吧，這對開發者來說又是一番兼容苦戰。也許你還挺喜歡浪費時間寫一些本不應該有的兼容代碼，而且你還喜歡用大概一半的時間去調試javascript。在來看中國浏覽器用戶的生態環境，IE6為什麼占的比重那麼大？我覺得有幾點原因：
1、盜版XP系統太多。
2、網吧基本上全是IE6。
3、國企或大型企業內部都用IE6。
想要干掉IE6，您覺得要多久？在回頭看HTML5，手機都要做兼容的，何況應用到PC浏覽器？那反過頭來看Silverlight，這時候優勢就體現出來了，SL開發的軟件不僅僅可以運行在手機上，PC上也可以，因為SL顯示是基於分辨率的，所以用戶體驗是一致的，那這算不算一種跨平台？用戶對浏覽器的版本更替是不敏感的，也別指望在我以上說的三點中找突破口。然後我們看看App Store的盈利模式，然後再想一想，Web App是否也有對應的盈利模式，並且有的開發商已經開始盈利了？如果沒有？你是否敢第一個吃螃蟹，並且不怕別人踏著你的屍體走過去？如果想用HTML5跨所有平台，還需要很長一段路要走，首先那幾大巨頭先達成協議再說。當你從迷霧中，看清楚整個格局後，才會發現Web世界正在被不斷被瓜分著，而你所使用的技術（HTML5+CSS3+Javascript）正是他們各自的領地，整個格局被他們打破，重新開始新一輪的麻將中，當然他們打的不是小牌。
觀點二：Silverlight要完蛋了？
首先，HTML5標准近幾年肯定不會定下來，設計+幾萬項測試+各大巨頭談判+浏覽器廠商實現，這段時間可不太短，那就算這些咱不管他，就當HTML5標准已經訂好了，大家可以用他開發了，而且大部分用戶也很自覺的裝上了您最新版的浏覽器，並且您最新版的浏覽器支持XP系統，這些先決條件很完美不是麼？用戶的需求是無止境的，糟糕，HTML5實現不了，軟件廠商抓耳撓腮，只好對用戶說，您的需求我們滿足不了啊，HTML5不能實現。除非，除非標准在次更改（PS：標准貌似十幾年改一次？），軟件廠商無奈的苦笑著。看到這裡，您想到什麼了？沒錯，標准一旦制定要更改它簡直千難萬難，而用戶對於標准之上的功能實現可視眼饞的緊，這時候您會怎麼抉擇？無疑是這些浏覽器擴展：插件。所以，放下您的成見，讓HTML5和插件友好相處吧，他們未來的作用一定是互補的。
觀點三：Flash為什麼會占據PC富客戶端的大半個江山？
微軟擅長生育晚產兒，Silverligh無疑是其中的一個，當各大頁游廠商用Flash做出可以賺錢的產品後，Silvelight才被各大廠商熟知，但熟悉就未必會用他，結果導致其默默無聞的成長，首先我們分析一下，這其中的問題所在。
1、Flash成熟作品多，開源社區活躍。
為啥要放棄現在的深厚底蘊，而用你Silverlight，難道你比他多什麼亮點？晚產兒的優勢在哪裡？
2、Silverlight低調，無人所知。
用Silverlight開發的大部分是企業應用，默默無聞，誰也不知道有哪一個軟件是用Silverlight做的，這樣就產生了一個莫名其妙現象，做的東西比較多，但就是沒有知名度，造成推廣障礙。
3、職位稀少，工作機會稀少
各大軟件開發商提供的職位太少，讓開發人員總以為Silverlight沒有前途。大家可以去大型招聘網站，搜索一下Silverlight關鍵字，在北京地區、全職、最近一周，反正我只找到20個。在這樣一個大環境裡，誰還敢去學習Silverlight？這就是短板所在。
觀點四：創新工場
我用三個比喻來說明創新工場的創新之處。
其一：雞和蛋：
用一個不恰當的說法，創新工場相當於雞，其孵化的公司相當於蛋。雞負責雞蛋的孵化以及後勤工作，她有豐富的渠道、資源、名氣供蛋使用，蛋的職責就是破殼而出，然後快速成長，子母連環鎖就此產生。雞生蛋、蛋生雞依然是永恆不變的話題，互利共生可能就是诠釋這句話最佳答案。
其二：娛樂公司和明星：
“想發財，先出名”，不知道這是哪位前輩提出的見解，當真是獨具眼光。娛樂公司提供舞台，其他就靠你的手段，是被潛還是作秀，還不是隨手沾來。這套也可以用創新工場身上，場子把後勤給你打理的井井有條，你的工作就是：不成功，先出名，出完名，在賺錢。先讓大眾你知道有你這麼號人後，在慢慢出產品。娛樂圈都趕潮流，不管這流是寒流還是暖流，游一遍在說，沒准就游出位了呢。創新工場孵化的公司也是同理，啥流行，先游一圈在說。哥們這麼做，我也可以理解，傳統互聯網想出頭要幾年沉澱，無法短期見成果，而且成本也相對就較大。咱還總結了新詞：“流行效應”，解釋：用流行的平台更容易做出流行的產品。
其三：主服務器和子服務器
服務器集群之優勢在於可以更好的資源利用與負載均衡，隨著這種優勢的不斷突出，雲的概念呼之欲出，那麼當這團“集團雲”以創新工場為中心服務器，其孵化公司為子服務器全面運作的時候，高負載，高效率，高資源利用率仿佛就不是那麼遙不可及了。當創新工場轉身為“商戰黑客”，試問誰能抵擋住其DDOS攻擊？沒有疑問。
總結一下吧：
母憑子貴、子憑母貴、子母連環鎖，一條互利共生的鏈條就被巧妙地連接起來了，子母公司共享資源、產品、財富、經驗等等，假以時日“集團雲”就會脫穎而出，不得不贊歎這種模式的巧妙之處。
觀點五：太子 —》 HTML5
說一下HTML5帶給移動互聯網產業的變化。
其一：那麼多的平台，移植起來真的很悲劇
粗略算一下：目前移動設備大概有一下幾種平台：Symbian、Windows Phone、Android、iPhone、iOS以及未來的Windows 8等，移植的代價可想而知。反觀HTML5，基本上已經可以實現跨平台開發了，而且各大手機浏覽器對HTML5的支持也都是“爭先恐後”，生怕晚了一步，而且開發web app也有一些開源框架非常不錯，例如PhoneGap、QT、JQuery Mobile 等等。
其二：趨勢、趨勢
Windows平台似乎也經歷過C/S向B/S轉變的過程，當然一些C/S軟件是不可替代的，但B/S後的軟件優勢也非常明顯，那麼手機開發似乎也正在踏上這條路，版本更新更容易、自由性更高等優勢。
其三：被腐蝕的應用商店
移動應用開發者對軟件商店的“黑卡”也許不會陌生，當然更加黑的手段刷排名也許還未曝光，但是這塊神聖地正逐漸被黑暗吞沒。
其四：我想要自由
應用商店越來越高的門檻與審核制度讓許多開發商望店興歎。一些好的應用也許會被討厭你軟件的審核員所淘汰，我想這種情況你可能接受不了，但這就是事實。
觀點六：JavaScript不是很給力
說實話，我是JS的堅決擁護者，她編程方式靈活多變，寫程序簡直是一種享受，但是一些問題總該需要提出來。
其一：缺少一款強大的IDE
只要JS文件上了2000+行，調試和開發就非常的不方便，加一個空格都要等待一段時間，期待一款可以加快代碼解析與智能感知自定義屬性和方法的IDE，不知道誰有好的可以推薦給我。我目前用的是VS2010 SP1。
其二：坑爹的兼容性
無盡的兼容性測試與調整仿佛占了總開發量的一半時間，對於我這樣有“代碼潔癖”的人來說，是絕對不能容忍的。總之，這是件浪費時間和精力的事情。不過，事情都有轉機，一些第三方類庫，例如JQuery，就可以讓我們不去關注兼容性問題。但是，一些場景就不適合用這麼大的庫，例如HTML5游戲開發。另外，吐槽一下，HTML5在各浏覽器表現也不一致，而且支持的也不到位，更加大了工作量，太坑爹了。
其三：源碼保護
JS混淆 + 加密 + 壓縮 = 開源。
任何JS代碼，不管如何做手腳，都是表面文章，真正的代碼卻還是需要在JS引擎中執行的。
而JS引擎執行的代碼，永遠都是最真實的，而我恰恰就可以得到這些真實的代碼。
除非各大浏覽器廠商考慮到這個問題，並做出合理的措施，才有可能真正的實現源碼保護。
觀點七：程序員一定要有的觀念
當我們操作那些API開發軟件的時候，是否想過自己曾經用過的語言中，有那麼多地方是相似的，for、if.。..。.在這些相似的語法中，我們是否發現自己沒有了創造力，一切都是以自己掌握多少類，多少個方法而驕傲？浮華下面掩蓋的都是本質。而殊不知思想是最重要的。朋友們，放下浮躁的心吧，別在討論什麼技術有前途，什麼技術沒前途。當我們掌握思想這種原動力的時候，什麼武器都是順手牽來，招招指向要害。HTML5是趨勢，是未來的大趨勢，Silverlight和Flash是現在的解決方案，也是未來HTML5的有力武器，他們是相輔相成的關系。我昨天開源了一個庫《也把咱的小類庫拿出來曬曬》，很多朋友下載，我很高興，希望這些能幫助到你，我也希望你們也可以把自己的庫共享出來，因為這不只是簡單的分享，而是解放你的思想，讓你學會抓住本質，培養思路，丟棄這種API式的編程方法。