zoukankan      html  css  js  c++  java
  • Web桌面应用框架1:Electron与WEB桌面应用程序开发及其它

    这几天在构思项目,研究了一下Electron,记录下来。

    说起WEB桌面程序,当前最火的就是Electron了。

    Electron的架构用一句话总结,就是一个main.js进程加上一个或数个chrome窗口,每个窗口都包含一个独立的Node.js。

    这样的架构,使得这种桌面应用必须是一个(或数个)单页面应用(SPA),而这个SPA还拥有访问本地API的能力(Node.js)。

    一方面,程序对前端框架的依赖必然加强,想再JQuery打天下就不那么容易了;另一方面也大大加强了前端框架的能力与版图。

    这样它把前端与后端的战火,从服务器蔓延到了桌面。使得JS解决一切的宗旨,又得到了贯彻。

    相比较这种新的架构,还有三种早已出现在WEB桌面程序。一般基于嵌入式Chromium框架(CEF)。

    一种就是CEF+远程访问。这种程序体验极差,就是个单页面的网站。

    值得注意的是Electron+远程访问,是极度危险的,只需劫持JS,则可利用Node.js为所欲为。

    另一种就CEF+本地服务。本地服务常见的有.net和java,也有用PHP和Node.js的。

    这种组合与前一种组合体验类似,而且体积臃肿,但胜在页面延时较小。

    最后一种就是CEF+本地资源+远程API接口。这种是手机WebAPP的常用模式。体验尚可。

    和这些架构比较起来,Electron的体验和能力上得到很大的增强,但是有着天生的弱点。

    一、安全性,这是脚本语言的弱点

    二、投入大,SPA不同于原有的WEB开发,必然导致新的投入和旧资源的浪费。

    三、体验,虽然WEB应用的体验在不断增强,但天生就必然限制在chrome窗口中

    理想当中的混合应用应该是Electron作为模块嵌入其它编译型语言中,不必追求JS解决一切,更不要追求一切皆是WEB。

    强强联合,团队作战的效果远大于语言或平台大一统带来的好处。

    比如这个go-astilectron项目,使用GO语言开发主进程代替main.js,弱化JS的依赖是个不错的想法,但还远不成熟。

    (完)

  • 相关阅读:
    flask框架(一):初入
    .py文件打包成.exe文件
    gtk+-3.21.4 static build step in windows XP
    cairo-1.14.6 static compiler msys mingw32
    ffmpeg-20160811-bin.7z
    gtk+2.24.0-glib-2.28.1-staticLib-mingw32-x86-2016-08-10.7z
    ffmpeg-20160806-bin.7z
    glib-2.49.4-msys-x86-staticLib.7z
    Tesseract-OCR text2image.exe [ x86 支持 XP ]
    ffmpeg-20160803-bin.7z
  • 原文地址:https://www.cnblogs.com/windfic/p/7496077.html
Copyright © 2011-2022 走看看