Skip to main content
 Web开发网 » 站长学院 » 浏览器插件

前端开发中,模板引擎方式和纯静态页面+ajax,这两种方式哪个更好?

你说的模板引擎应该是指后端模板引擎。从网站全栈开发程序员的角度来看:从前,前端[不考虑原生app]只要“哄好”浏览器(包括微信内嵌的、app内嵌的)就可以了,服务端都是Nginx/Apache/IIS + php(大部分程序依赖于php-fpm[不能常驻内存],少量运行在CLI[也就是命令行]),大家都用MVC, 都在热烈讨论视图文件与模板引擎的“家长里短”。后来,前端爆出了“微信小程序”,不少前台页面“弃暗投明”,好在后台页面/对/浏览器/“忠心耿耿”。再后来,swoole异军突起,php可以常驻内存、运行速度“风驰电掣”,同时开发方式大变[大部分运行在CLI],比如:echo会输出到终端而不是浏览器---然而,模板引擎都是用echo输出动态数据到浏览器的---这就尴尬了。

现在,访客的客户端既有小程序,又有浏览器。小程序的页面只能由js渲染,php模板引擎对小程序页面无可奈何。php接口不得不设计为API,以便返回json给小程序,这种API倒是可以加以包装,这样,浏览器那边的前台页面可以继续使用模板引擎。后台页面,直接使用模板引擎。

一但用上swoole,要是坚持使用模板引擎,由于模板引擎将视图文件(view.html)翻译成模板文件(tpl.php),都会用到“echo”,(如果用到的视图文件都没有修改过,就直接)include tpl.php之后,为了防止输出到终端,使用ob_get_clean(), 再使用swoole的接口输出到浏览器,

倒也是可以。

结论:

后端模板引擎,只是开发一时爽,不适宜团队合作,适合全栈开发者,缺点:

应变能力差:使用全新装修的话,后端开发就要套页面,繁琐。

浪费人力资源,加重后端团队的负担:前端折腾完html页面,后端需要经手一遍。不得不提一点:分页条。thinkphp框架的分页条是写在php的page类里面,如果分页条样式变了,前端写完html代码,后端要誊写一遍。

如果需要翻译视图文件,则后端负担相对较重,用户等待时间相对较长:比如:编辑数据的页面。php从数据表里边拉取到数据,已经仁至义尽了,却还要翻译html文件,即使不用翻译,也需要查看用到的视图文件是否修改过。

后端模板引擎的渲染是一次性的,而前端模板引擎可以反复渲染,利于沉浸式体验。同一段html代码,要么由后端模板引擎循环处理,要么由前端模板引擎循环处理。举个例子:进入购物车页面(/cart/index),对某个商品重新挑选促销方案后,该商品需要挪到新的分组,再次计算受影响的组的优惠、赠品,然后再次计算总优惠。(后端更改促销方案, 不应由/cart/index处理,不然就“千人排、万人坑”,越来越“牵一发而动全身”。) 假设是由/cart/selectPromotion处理, 如果使用前端模板引擎,即便反复挑选,页面也无需刷新,不会打断沉浸式体验,否则,等待转圈结束,页面还要需要刷新,页面无论如何都是要经历空无一物的白色,反复刷新几次,真的沉浸不下来。

由于css样式的影响,部分php错误信息未能及时发现,直到:打开控制台,查看源码,偶然看到额外的html元素直接查看网页源码,看到额外的html元素js出错:比如说,取不到指定html元素,json字符串转换成对象失败。好处:

共同的html可以抽出来作为公用文件,用php加载公用文件。

可以用php读取静态文件的上次修改时间,引入静态文件时,将这个时间作为版本号,静态文件有变化则重新请求,否则使用本地缓存。调试过程中,不需要同时按shift + F5, 也不需要手动更改版本号,比较省事。

纯静态页面+ajax:适宜团队合作,也适合全栈开发者,应变能力强,不会浪费后端的人力资源,php负担相对较轻,用户等待时间相对较短,体验更好,除了开发时繁琐了点。

评论列表暂无评论
发表评论
微信