这段时间在学习PHP的一些知识,做为一个前端开发者,看到PHP中有大量的涉及前端HTML页面甚至JS的内容,感到不可思议。其实完全可以把这些工作交由前端JS来完成,server端一行HTML代码都没有是最美的。而前后端的交互,统一由REST API完成。
在进入到新公司后,正赶上公司从传统的server行为全面向REST API转型,这不仅引起了我的注意,也有了很多思考。基于REST API的方式,第一个显而易见的好处是适配移动端,方便实现HTML5版本的前端页面。而新的版本可以和旧有的web版共享server API。其次,从分工的角度讲,前端的事情完全交由前端完成,是比较科学的,否则需求变更,为了改一个页面,一会儿找前端一会儿找后端,这是非常麻烦的。
前两天刚刚看到这个项目:https://github.com/zensh/jsgen ,基于Nodejs的REST API实现的网站系统。真是让人眼前一亮。对于JSer来说,这个项目的出现是个福音,仅凭一个JS倚天剑,就可杀出自己的一片天地了。
虽然这种方式是比较科学以及专业的,但依然有矛盾。只是这个矛盾从过去的后端和前端的矛盾,转成了Builder和JSer的矛盾了。比如一个弹出收起的菜单,我们是应该让Builder准备好,还是让JS去渲染呢?Builder写在静态页面里自然方便,但是对应的工作量加大;JS去渲染的话可以读取页面配置,更加灵活,但修改起来比较麻烦,需要更新JS,非专业人员不能操作,哪怕你只是在菜单里增加或减少一项。当我们设计整个业务流程的时候,这点是需要重点考虑的。
从更广阔的的角度讲,这样的革命对创业者是利好消息,因为过去看似繁琐的建站过程,如今已经变得越来越简单。REST API的方式下,server端无需重度框架,仅仅一个小型的路由以及数据库操作类库就能搞定大部分事情,这样算下来对后端人员的要求大大降低,对应的人力成本会下降很多。此外,因为去掉了对重度后端框架的依赖,后端程序的运行效率也会大大提升,不仅消耗的服务器资源更少,响应也会更迅速,性能提升或许能达到十倍。更别说REST API架构下,server端基本上只返回小段的JSON数据,而HTML页面全都是静态的以及在前端渲染的,加上在前端做一些缓存配置,带宽的节约也能达到原有的十分之一。而前端方面,对JS开发者的依赖加重,这可以通过业界探索出的各种有效的框架对成本控制,不过目前业界在这块的进展仍不够顺利;而Builder这块,有丰富的人力可供取用,另外即使自己培养,也没有多大难度,可以很快上手。再不济也可以直接参考网路上成熟的页面。
这场革命目前来看,最大的短板在JS这块。不仅业界对此重视不足,对JS的映像停留在上个世纪,JS本身也并未进化出足够牛的特性支持大规模的软件项目。虽然诸如淘宝、百度、腾讯这些大型网络公司已经探索出了自己的JS框架,但业界对这些框架的功用、要素等等的认识依然没有统一。在实践层面,基本上是各自为战,去实现自己的模块系统、编译系统、ajax库、选择器库、兼容库以及单元测试方法等等。而原生的JS只在API层面不断加强,实现了更多的功能,包括HTML5新增的各种设备访问API。可是在构建大型工程项目方面,原生JS依然没有给出官方的支持,前端开发者依然要选择自己的方式去实现这样一套工具。
不过针对这个问题也有一些好消息,一方面是YUI自身不断进化,已经提供了全套的工具足以处理上述所有问题;另一方面是Nodejs的出现,对应大量的开源的工具,善加利用很容易就能构建自己的一整套工具。后者在我开发web-simulator项目的过程中已经有了深刻的体会。
技术发展日新月异,很期待未来能出现前端出身的架构师,统领整个网站的建设。这不仅是对JS的肯定,也是对用户体验的尊重。