One Ring to rule them all?

2019 年 03 月 03 日

生活中,老婆想要一个方便处理她的培训班数据的工具,所以打算写一个Web应用。用标准的前后端分离模式开发两个工程。前端用Angular,后端用Spring Boot把数据库放出HATEOAS也就是Restful接口。好处就是可以轻松跨平台运行。

工作中,要用Rust写一个工具库,并加以验证。因为涉及的交互比较复杂,所以打算写一个带交互的CLI来验证这个库。

前几天碰巧QA同事有需求,就随手把Rust写的那个不完整的CLI编成Windows版本发给他们,然后很容易的就用起来了。结果,QA同事来了一句,要是有界面就好了。我开玩笑说,你要是给我一个服务器,我可以给你们做一个Web版。

玩笑归玩笑,昨晚在考虑时突然发现,原来用Rust写前后端分离模式Web应用,不仅是可行的,而且是相当好的选择。

从用途角度,用户需要GUI界面来简化对应用的理解。CLI甚至IDE作为程序员自己调试是肯定够用了,但要让其他非技术出身的用户使用,GUI是必需品。而要写一个跨平台的GUI界面,最好的方式应该是以Web为基础,而不是传统的跨平台GUI的SDK如Qt/SDL/Swing/Swt等等。因为:

  • 学习成本,Web应用只需要学习html5,通常要加上某种框架,而且这些技术可以用在其他地方;其他SDK需要研究SDK本身,并且技术的适用范围很窄
  • 自由度,Web应用可以选择自己习惯的框架,或者根本不用框架,甚至可以选择语言(如TypeScript等);其他SDK都被限制在某种语言环境下
  • 适用范围,Web应用可以用于任何带全功能Web浏览器的操作系统,而现在几乎任何有窗口系统的操作系统都会有全功能的Web浏览器;其他SDK通常必须有对应的移植环境,如Qt/SDL需要对应平台的库,Swing/Swt需要Java虚拟机

所以很明显,由于浏览器的普适性,Web是最好的GUI实现选择之一,当然,如果考虑到使用移动操作系统上的服务,将来原生移动应用选择flutter可能更合适;但Web方式对移动操作系统仍然是可用的,也有其他方案可以将Web应用封装成原生应用,如electron等。

既然用Web方式开发GUI界面是较好选择,那么,我们比较一下使用不同语言做后端有什么差别。

  • C/C++,几乎没有合适的框架来做后端
  • JavaScript,自然是NodeJS+Express,开发方面简单的后端可以轻松实现,但部署时需要对应平台的NodeJS引擎
  • Python我不了解,大概是用Flask来做框架,跟NodeJS相同,需要Python运行环境
  • Java是目前最常规解决方案,开发方面Spring Boot非常强大,各类工具库(如数据库版本控制 / Restful接口生成 等)一应俱全,部署时可以生成war或jar方式,也就是说可以选择在Container或JRE下运行,相对NodeJS和Python略有优势
  • 至于Rust,开发方面有Rocket.rs作后端框架,工具库方面可能比Java略逊,但差距应该不大,有跨平台编译支持,由于是直接生成可执行档,不需要特定Runtime,部署方面全无压力

本质上,选择任何语言开发后端都是可行的,需要考虑的问题只有需求和成本。这里的讨论实际隐含了两个前提,一是尽可能(而不是强制)在更多常见平台(Windows/Linux/Mac+x86/x64/arm)上使用,二是省略了语言和工具框架的学习成本。

这样一比较就可以看出,Java和Rust在实现后端时相对其他语言有较大优势,而在这两者之间对比的话,前者目前的优势只有各类成熟的工具库,这是后者可以慢慢迎头赶上的;而后者最大的优势是直接生成可执行档,对于前者来说基本是不可能补全的(虽然也有各类wrapper工具可以将jar打包成可执行程序,但这样就需要针对不同平台做不同实现了,而且要整合JRE进去,应用体积会比较大)。

这样分析下来,Rust在开发和部署后端方面,的确有相当大的潜力。随着时间的推移和Rust本身的进化,一方面,Rust有可能在各类应用开发的场景下都占有一席之地;另一方面,在某些特定类型应用开发的场景下,Rust因其本身特点,有特定的优势,且仍有进步的空间。这两方面会相互促进,使Rust的地位不断提升。所以,我想,有可能,仅仅是有可能,Rust会成为那种“One Ring to rule them all”的语言。


P.S. 现在有了tauri,实现了用rust做后端,web做前端,来开发跨平台GUI应用。

Top