web软件开发难在哪里(相比桌面软件)以及一种新的软件架构

首先,我认为WEB软件的开发是比桌面软件更为复杂的. 起码,开发方式远远不理想.

桌面软件的模块化, 组件化已经至关成熟,好比当年的VB delphi 后来的visual c#  ,java+ swt ,c++ QT.  而WEB开发,到目前为止都没有特别理想的组件化开发机制.

为了实现改善WEB软件开发,业界作了许多尝试.

2002年1月16日asp.net 1.0发布, 当时真是让人耳目一新, aspx简直就是用VB的方式来开发web 啊!

Java后来也跟进,推出了JFaces方案, 与aspx相相似 .

2006.05.16 ,google gwt 首次发布!  与aspx不一样, gwt的思路是像桌面软件同样的方式来开发,完成以后,经过将java代码编译成javascript来实如今浏览器中运行. 相似的方案还有pyjamas (如今的pyjs)

同一年里, January 2006, jquery首次发布! 如今回过头来看这个事情, 能够认为是业界逐渐发现问题在于javascript  !  javascript 的低能,  束缚了人们的手脚 .

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

2008年9月2号, 随着google chrome浏览器的发布, 新的javascript引擎v8 面世. 

v8的面世让javascript的运行速度大幅提高, 为后来的前端技术革新创造了条件.

顺带说一下, 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初步测试成功!

 

 

这是在CentOS_6.5服务器上运行的firefox及chromium浏览器 ,界面倒是显示在我本地的浏览器里.

 

能够看到,我是在windows7下打开的google浏览器,链接到xpra服务. 图上的小窗口浏览器,实际是运行在linux服务器上的.这个图是浏览器里套着一个浏览器, 可能不太容易看出来是啥意思!下面再上一张在服务器运行codeblocks开发工具的图.

没错, 这个codeblocks是运行在服务端的!

到此,基于实现了我上面构思的, 直接把GUI程序运行在服务端!  经过管道把界面展现给用户.

我想说的是, 通过合理的配置,这能够作为一种新的软件发布方式!客户能够经过浏览器直接使用服务端的GUI程序.

通过合理的配置以后,能够限制客户只能使用指定的程序.好比一个CRM系统. 而后在这个CRM中作好登录和权限管理.

这样就能够桌面开发技术来开发CRM，而经过web-html5来发布这个软件.

web传统的优点基本上都有, 客户惟一须要有的软件就是一个现代的浏览器.

固然,不只仅是CRM能够用这种方式.

想像空间很大哦!

未完...