NativeApp與WebApp表面差異很多，但究其本質，差別只兩個：效能與商業價值。一個執行在本機，效能更佳，一個要聯網，當然慢。在理想情況下即使網路奇快無比，時延也永遠無法忽視，想象一下，如果切水果遊戲改在網路伺服器上執行，你想切西瓜肯定經常誤碰炸彈。NativeApp存放在本機，它的表現形式，無論是程式，還是依附於程式的資料，均由使用者自行掌控，但WebApp依賴網路，開發商或運營商借此構造商業價值，實現途徑通常是施加限制或附加增值服務，即使不限制也沒追加服務，商家把你的資料探勘一遍也一樣創造價值。基於上述差異，我斷定NativeApp與WebApp永遠不會合二為一，尤其是商業方面的驅動因素，不可能無端消失。但NativeApp向WebApp靠攏的趨勢是必然的，沒錯！是Native向Web靠近，而不是Web向Native靠，因為WebApp更代表最終價值。當有一天人們不再關注這兩者還有什麼差別時，多半是因為大家理解的程式（Application）預設就指WebApp，NativeApp與WebApp的差別，就像現在我們把文件存到C盤還是D盤那樣單純，到那時，開發人員仍會關注Native與Web的差異，但只在API層面去關注。我想，提問者是想搞清導致兩者趨同的“技術變遷”是什麼？問題焦點不是NativeApp與WebApp各自優缺點，或誰該成為主流。我嘗試從下面幾個方面敘述，按重要程度排序：1、系統化的開發方法、開發平臺及開發工具，是目前妨礙WebApp發展的最大瓶頸。NativeApp有成熟的開發平臺與軟體工具，但WebApp相差甚遠，大家看看java script調測手段有多濫就知道了。這還只是一方面，情況更糟的是，現在業界還缺少一套能有效貫徹“web化”開發的技術體系，不說服務端程式設計，只說客戶端，現有事實標準是java script，但你能用它搭建幾十萬行程式碼規模的系統時，可用性有多高？開發與維護的成本有多高？抱著美好願望，我寧願相信10年後web開發標準不再是java script，因為它承擔不了web開發的敏捷性與程式碼高效性需求。請注意，這裡我論述的基點是WebApp與NativeApp能夠趨同，Web開發足以承受NativeApp一樣的程式碼規模。OK，情況有點悲觀了，否定了JS，HTML5的根基有點動搖了。大家對HTML5抱很高期望，但它的標準尚未定稿，其發展狀態與WebApp的整體狀況倒是相稱的。2、解決效能問題Web開發的特質是指令碼化，因為當前技術手段下，只有指令碼化開發，才與敏捷釋出的需求是相稱的。大家普遍認同Web開發是：改一下文字上傳到網站，或調整一下表單，或最佳化JS指令碼，線上更新一下。需要編譯佈署的通常不認作Web開發，其實，是否編譯並不重要，沒人規定Web開發一定是不要編譯的，像Google的Native Client就藉助LLVM編譯，它佈署的就是二進位制編譯碼。問題關鍵在於，現有藉助編譯手段的開發方法，在滿足快捷釋出、輕量級維護方面還有不小差距。 促使效能問題解決的技術變遷是什麼？是CPU主頻提升，或多核方案嗎？我認為，CPU或多核只能輕度解決一些問題，CPU很難再成倍提升了，多核開發增加複雜性，有違Web開發的敏捷特質。那借助即時編譯等機制，提升直譯器效能是否可以？V8跑得夠快了，想跑得更快，大概只能換語言了，這如Dart語言的發展初衷，但Dart是我們的救星嗎？未必，它並沒太脫離JS框架，效能提升有限。3、網速、資費，是否隨時隨地可接入這幾方面影響是現實的，當前的影響程度也算得上是致命級別。但長遠來看，障礙並不大，我們要考慮的因素是：離4G普及還有多遠？4、渠道、生態系統以Web的開放性，不大容易構造類似iOS那樣的體系，但開放也有開放的好處，封閉並非打造良好生態的唯一途徑，只是對系統的安全性有更高要求而已，Android是個例子（儘管它的品質還要改良）。我期待在iOS、Android、Win8等幾大平臺基礎上能衍生出一個跨平臺系統，智慧平臺的OS已太擠，優勝劣汰，主流作業系統會減少，其趨勢不是增加。換一個角度，在主流平臺之上發展另類生態系統尚有空間，因為跨平臺是使用者與開發者的共同需求，不是幾個大鱷想抑制就能抑制的。5、還有其它因素，包括：工具欠缺、WebApp操作原生裝置能力受限、WebApp的離線能力（或NativeApp的線上能力）。這些基本上屬於“成長的煩惱”，不是本質性的，有需求就有人做，熬過讓人焦慮的青春期就好。
NativeApp與WebApp表面差異很多，但究其本質，差別只兩個：效能與商業價值。一個執行在本機，效能更佳，一個要聯網，當然慢。在理想情況下即使網路奇快無比，時延也永遠無法忽視，想象一下，如果切水果遊戲改在網路伺服器上執行，你想切西瓜肯定經常誤碰炸彈。NativeApp存放在本機，它的表現形式，無論是程式，還是依附於程式的資料，均由使用者自行掌控，但WebApp依賴網路，開發商或運營商借此構造商業價值，實現途徑通常是施加限制或附加增值服務，即使不限制也沒追加服務，商家把你的資料探勘一遍也一樣創造價值。基於上述差異，我斷定NativeApp與WebApp永遠不會合二為一，尤其是商業方面的驅動因素，不可能無端消失。但NativeApp向WebApp靠攏的趨勢是必然的，沒錯！是Native向Web靠近，而不是Web向Native靠，因為WebApp更代表最終價值。當有一天人們不再關注這兩者還有什麼差別時，多半是因為大家理解的程式（Application）預設就指WebApp，NativeApp與WebApp的差別，就像現在我們把文件存到C盤還是D盤那樣單純，到那時，開發人員仍會關注Native與Web的差異，但只在API層面去關注。我想，提問者是想搞清導致兩者趨同的“技術變遷”是什麼？問題焦點不是NativeApp與WebApp各自優缺點，或誰該成為主流。我嘗試從下面幾個方面敘述，按重要程度排序：1、系統化的開發方法、開發平臺及開發工具，是目前妨礙WebApp發展的最大瓶頸。NativeApp有成熟的開發平臺與軟體工具，但WebApp相差甚遠，大家看看java script調測手段有多濫就知道了。這還只是一方面，情況更糟的是，現在業界還缺少一套能有效貫徹“web化”開發的技術體系，不說服務端程式設計，只說客戶端，現有事實標準是java script，但你能用它搭建幾十萬行程式碼規模的系統時，可用性有多高？開發與維護的成本有多高？抱著美好願望，我寧願相信10年後web開發標準不再是java script，因為它承擔不了web開發的敏捷性與程式碼高效性需求。請注意，這裡我論述的基點是WebApp與NativeApp能夠趨同，Web開發足以承受NativeApp一樣的程式碼規模。OK，情況有點悲觀了，否定了JS，HTML5的根基有點動搖了。大家對HTML5抱很高期望，但它的標準尚未定稿，其發展狀態與WebApp的整體狀況倒是相稱的。2、解決效能問題Web開發的特質是指令碼化，因為當前技術手段下，只有指令碼化開發，才與敏捷釋出的需求是相稱的。大家普遍認同Web開發是：改一下文字上傳到網站，或調整一下表單，或最佳化JS指令碼，線上更新一下。需要編譯佈署的通常不認作Web開發，其實，是否編譯並不重要，沒人規定Web開發一定是不要編譯的，像Google的Native Client就藉助LLVM編譯，它佈署的就是二進位制編譯碼。問題關鍵在於，現有藉助編譯手段的開發方法，在滿足快捷釋出、輕量級維護方面還有不小差距。 促使效能問題解決的技術變遷是什麼？是CPU主頻提升，或多核方案嗎？我認為，CPU或多核只能輕度解決一些問題，CPU很難再成倍提升了，多核開發增加複雜性，有違Web開發的敏捷特質。那借助即時編譯等機制，提升直譯器效能是否可以？V8跑得夠快了，想跑得更快，大概只能換語言了，這如Dart語言的發展初衷，但Dart是我們的救星嗎？未必，它並沒太脫離JS框架，效能提升有限。3、網速、資費，是否隨時隨地可接入這幾方面影響是現實的，當前的影響程度也算得上是致命級別。但長遠來看，障礙並不大，我們要考慮的因素是：離4G普及還有多遠？4、渠道、生態系統以Web的開放性，不大容易構造類似iOS那樣的體系，但開放也有開放的好處，封閉並非打造良好生態的唯一途徑，只是對系統的安全性有更高要求而已，Android是個例子（儘管它的品質還要改良）。我期待在iOS、Android、Win8等幾大平臺基礎上能衍生出一個跨平臺系統，智慧平臺的OS已太擠，優勝劣汰，主流作業系統會減少，其趨勢不是增加。換一個角度，在主流平臺之上發展另類生態系統尚有空間，因為跨平臺是使用者與開發者的共同需求，不是幾個大鱷想抑制就能抑制的。5、還有其它因素，包括：工具欠缺、WebApp操作原生裝置能力受限、WebApp的離線能力（或NativeApp的線上能力）。這些基本上屬於“成長的煩惱”，不是本質性的，有需求就有人做，熬過讓人焦慮的青春期就好。