web軟件開發難在哪裏(相比桌面軟件)以及一種新的軟件架構

時間 2019-12-01

原文原文鏈接

首先,我認爲WEB軟件的開發是比桌面軟件更爲複雜的. 起碼,開發方式遠遠不理想.javascript

桌面軟件的模塊化, 組件化已經至關成熟,好比當年的VB delphi 後來的visual c# ,java+ swt ,c++ QT. 而WEB開發,到目前爲止都沒有特別理想的組件化開發機制.html

爲了實現改善WEB軟件開發,業界作了許多嘗試.前端

2002年1月16日asp.net 1.0發佈, 當時真是讓人耳目一新, aspx簡直就是用VB的方式來開發web 啊!html5

Java後來也跟進,推出了JFaces方案, 與aspx相相似 .java

2006.05.16 ,google gwt 首次發佈! 與aspx不一樣, gwt的思路是像桌面軟件同樣的方式來開發,完成以後,經過將java代碼編譯成javascript來實如今瀏覽器中運行. 相似的方案還有pyjamas (如今的pyjs)node

同一年裏, January 2006, jquery首次發佈! 如今回過頭來看這個事情, 能夠認爲是業界逐漸發現問題在於javascript ! javascript 的低能, 束縛了人們的手腳 .react

The first version of the V8 engine was released at the same time as the first version of Chrome: September 2, 2008.jquery

2008年9月2號, 隨着google chrome瀏覽器的發佈, 新的javascript引擎v8 面世. linux

v8的面世讓javascript的運行速度大幅提高, 爲後來的前端技術革新創造了條件.c++

順帶說一下, google dart lang , First appeared‎: ‎October 10, 2011 . 2011年雙十節google推出了dart 語言,當時的想法是用來替換javascript .

Facebook reactJS Initial release‎: ‎March 2013 . (2013年3月,Facebook reactJS 首次發佈) reactJS 能夠認爲是組件化開發的一次重要嘗試.

然而,時至今日, 我認爲還不存在一種開發機制,能夠達到delphi之於桌面軟件開發的那種理想程度.

根據本人多年開發web後臺系統的經驗，我感受web比較比較困難的根本緣由在於幾點:

1.B/S軟件是一種分佈式軟件,即軟件的界面代碼數據不在同一計算機;B/S軟件基於HTTP協議,而HTTP協議有一個重大特色是不保持鏈接且無狀態.

2.javascript語言的特色以及運行速度,難以支持複雜的軟件開發, 而且別無它選,只能使用javascript . 雖然由於v8引擎,有了大幅改進.

3.html語言自己表現力不佳,且不支持擴展. 好比我須要一個datagrid功能,可是並無一種直接的方式能夠定義一個新的標籤<datagrid></datagrid>

重點說一說第一點. 當一個用戶使用瀏覽器打開一個網頁時,發生了什麼? 簡單地講是這樣的: 用戶計算機的瀏覽器程序, 經過http協議將html描述的界面從遠程服務器傳輸到本地, 瀏覽器將其渲染成圖形界面展現給用戶並提供交互功能.,

一旦用戶在網頁作了一些操做,則必然有一些數據須要傳輸回服務器保存(否則,服務器端是沒法感知到用戶的操做, 交互就沒有完成)

網頁上的交互就是這樣一個個"來回" 進行的.

這種模式有一個嚴重的問題: 交互界面與數據存儲是分離的, 交互界面在客戶端的瀏覽器上; 數據存儲發生在服務器端. 在這種模式下,若是想實現組件化的開發方式,就得面對服務端與客戶端組件狀態不一樣步的問題.

aspx的解決辦法是將組件狀態寫在viewstate隱藏字段中, 每一次與服務端的交互都是一次form提交, 經過viewstate隱藏字段把狀態傳遞給服務端. 隨着瀏覽器上的交互愈來愈依賴js組件, 這種方式愈來愈難以適應形式.市場份額於是也慢慢變小. 固然aspx還有一個重要缺點就是界面的美化和定製化比較麻煩.
google-gwt的方案是將組件所有實如今瀏覽器上, 服務端只是經過json接口來充當存儲層. gwt的理念能夠講是突破性的, 打破了以往的解決思路. gwt的缺點是瀏覽器端過重, js有點難以支撐;代碼所有在客戶端,要實現安全就須要在服務端再實現一次業務邏輯的驗證, 並且若是java代碼到js的轉換若是有bug ,調試會很是的不直觀.

reactjs最近兩年的事情, 還有待觀察.

我常常會想,若是使用遠程桌面的方式來把一個桌面軟件發佈給互聯網用戶, 每一個用戶在遠程桌面裏打開一個軟件窗口,那麼軟件開發起來會容易不少!

這樣能夠不受html語言束縛,各類桌面窗口組件直接使用. 並且經過遠程桌面, 用戶至關於站到了服務器面前. 界面與數據及邏輯代碼分離的問題也就不復存在了.

然而,遠程桌面這種方式爲何沒有成爲主流呢?

緣由不難理解:

1,網速不容許;

2.服務端資源沒法支撐這種開銷;

3.安裝麻煩,客戶端須要安裝RDP鏈接軟件. 遠不如瀏覽器直接打開方便.

4,直接把服務器遠程桌面開放給未受權的用戶,安全性難以控制.

那麼,出路在哪裏呢? 或者說,將來將往什麼方向發展?

這個嘛 ,我不是大師,我也不知道.

我想,現有的技術好比asp.net jfaces gwt 確定會繼續發展, 各類前端框架也層出不窮, 前端與後端一體化框架最近已經開始出現(server side:nodejs ), 隨着ES6標準的發佈,javascipt自己也在不斷進步.

並且,我有一種感受, 遠程桌面技術愈來愈成爲一種不錯的選擇. 隨着技術和社會的發展,前面提到的幾個問題,慢慢都有了解決方案.

1. 網速在不斷提高, 將來大陸人們可能都能使用GB級光纖網絡 ;

2, 服務端資源壓力, 也隨着雲計算的發展,而找到了解決方案,將來把計算都放在雲端服務器反而是更好的選擇;

3.關於安裝問題, 目前已經有了瀏覽器在經過(html5) websocket +canvas 實現的遠程桌面 . (須要服務端安裝websocket server 支持)

4. 安全問題. 若是能把遠程桌面配置爲受限模式. 即未受權用戶進入桌面後, 只能打開指定的應用程序, 閹割掉有風險的文件管理器(好比explorer.exe) 命令行(好比 cmd.exe linux-term) ,那麼安全就能夠放心. 根據我之前折騰linux的經驗,這個貌似在linux下更容易實現, 修改 ~/.xinitrc應該就能夠實現 .

這也是目前我正探索的問題.

2017-08-14 ,經過xpra初步測試成功!