后端语言 PHP 这样的模板引擎 lavarel 等，为什么没有称为前端工程化？

[liudaqi]

比如 vue 的模板和组件的实现，lavarel 不都有类似的组件化实现吗？@extends @import @section 等，加上 block ，include 这样的概念，基本上就能把组件拼接起来，形成 templates （或者叫 pages ）。

只需改造 js 实现一下 pushState ，就可以在前端拦截路由，通过 ajax 加载所需的 template 或者 component 、section ，就可以实现单页应用 SPA 了。

这样还是原生 SS'R 服务端渲染，纯正的按需加载，初始化加载速度极快。其他的 for ，if 控制这些后端模板也一样用。

和 vue ，react 现代前端工程化相比，少了虚拟 dom ，该实现的工程化概念基本都在。关于 state 传递，哪种方式都少不了的，都要 js 做的活，没有很大区别。

并不是否定 vue ，react 这些的作用，而是觉得后端语言的模板引擎，工程化能力看起来也没差。从 SS'R 服务端渲染回潮的情况看，这不是以前一直在干的嘛

[512357301]

技术不是决定因素。
前端就是从后端独立出来的，前端为了自己生存的更好，就得用自己擅长的技术造出适合自己技术栈的轮子的，哪怕是模仿后端呢。
说到底还是个话语权的问题，试问前端这些技术栈对于后端来说还能看得懂吗，还能拿来就用吗，不能了吧，这样前端的独立性就能保证了。
那 CTO 为什么就支持前端这么搞呢，因为花的是公司的钱，无所谓的，而且前后端各成一派，总团队人数还壮大了呢，何乐而不为呢。
技术不是决定因素，政治永远是决定因素，哪怕是办公室政治

[sheeta]

这不就是 pjax 吗。。。

[shapl]

感觉你对前端工程化有点误解。

[Cbdy]

因为 php 不方便在浏览器执行

[cmdOptionKana]

因为模板引擎还是要依赖后端，无法做到 severless ，自然就不是前端工程化了。

举个例子，比如静态博客，如果用模板引擎来做就必须要有后端，但纯前端可以挂在 github 里。

再比如网页版的 vscode （或各种类似的编辑器），你靠后端模板渲染，如何能实现一个浏览器里的编辑器？

[ChefIsAwesome]

1.你讲的是如何通过 ajax 渲染，不是前端工程化。
2.mvc ，mvvm 等概念的本质是 view = render(state) 。渲染放在前端还是后端，是替换 html 字符串，修改 dom ，或是通过虚拟 dom 这层代理来修改 dom ，都是 render 的具体实现方式。各有利弊。
3.前端技术是以如何提供更好的用户体验为导向的。所有的界面变化都可以通过你讲的 ajax 到后端再返回 html 替换的方法实现，但用户能接受点个单选框都要先等上一秒钟，等后端返回请求才有响应吗？

[liudaqi]

@CheflsAwesome

1. 我讲的对比有 3 点（加上对比首次加载 SS'R 总共 4 点），1 组件化思路、2 前端路由、3 状态传递。1 和 2 我认为差别不大，3 是纯前端传数据，怎么实现都是 js 的活。

2. 如你所说 vdom + json 渲染，和 html section 渲染本质都是实现 view 。在粒度上，前后端都可以控制组件大小的粗细粒度，看不出区别来。

3. 后端 API 返回 json 的速度，和返回封装的 html 片段，速度差别肉眼基本不可见。真遇到复杂的渲染，前端也只能用灰色背景、雪花标转圈让用户等着。

简单的表单交互感觉不到什么区别，感觉现代前端最大的优势场景，就是云服务商控制台那种超大的表单交互、数据可视化这些场景，后端模板几乎无能为力。


@cmdOptionKana

按应用数量来看的话，前端计算 /渲染工作量超重的应用还是少数。你说的这两个 case 基本上是纯前端应用，后端可以没有。

[joesonw]

你这个只能算是 BigPipe 流派。

[wdhwg001]

实际上 Vue 的一个重要应用场景就是后端直接输出 json 为 js 在页面上，然后前端拿 Vue 去渲染，需要用到 json 以外的东西的时候再 ajax 。
从这个角度看，实际上也属于一种 SSR 了，而且这种方式不依赖模板引擎，还可以很好地搭建在微服务架构的网关附近。
人们逐步弃用模板引擎的原因无外乎两点，太慢了，以及浏览器功能全了。从这个角度看，再把模板引擎做重，重到可以渲染出整个首屏，说实话非常不划算。

[westoy]

ajax 刚流行的时候， 就有一把梭哈的 xajax 了， 配合 phplib 、smarty 食用更佳......

后来 php 流行期正赶上 web 重构+xhtml( 此处第 N 次 @laogui) + 前后端分离 + 前端分离的潮流.....

所以......就无了.......

[dcsuibian]

一个略会前端的后端路过。
没接触过 php ，但最开始用 jsp 、jQuery 开发过，也接触过 thymeleaf 、jinja 等模板引擎。

在我看来，所谓“前端工程化”就是用户对 UI 美观要求越来越高，前端工作量越来越大，所以要写前端像对待一个正经工程一样规范化。

为什么模板引擎不适合前端工程化呢?
我的看法：
1 。模板引擎太多了，而且和语言生态圈绑的比较死。
Java 、.net 、Python 生态圈里都有各种模板引擎。
这种时候。这时候，如果你基于一种模板引擎做了组件，那么在另一种模板引擎里就用不了。
这样的话，就算你能封装成组件，恐怕也只是这个项目或公司内部的复用，无法形成 ant design 那样的正经组件库。
2 、模板引擎不适合协作开发。
试想一下，如果使用模板引擎，那么前端开发人员也不可避免地对模板语法有一定的了解。而且还得有跟后端一样的开发环境。
当初我用 jsp 开发的时候，为了看到效果，重启服务器的过程真的是让我心力憔悴。而且更多的是串行开发，后端没做好前台也做不了。
而现在，只要定好相应的接口格式，前后端就可以并行开发。而且前端的代码更改跟后端也没有什么关系。可以专心地干自己的事。
3 、后台的服务端渲染也有问题。
首先，相比于静态内容来说，模板引擎这种东西会更加消耗服务器资源。（不过这个我没数据，所以无法证明影响多大）
这就是后台服务端数据不太完美的地方，对于流量很大的网站比如各种门户网站，后台也得提前把网页模板渲染成 html 缓存。
从响应速度上看不到差别，但网上确实有相应的实例。
4 、JSON 和 html
谁说后端提供的数据只能给前端页面使用呢？
比如 github 的开放 api ，如果返回 html ，那第三方程序怎么用呢？
而且，就算你真的只是拿来做页面。那么如果同时得支持移动端和桌面端页面呢？
。。。


其实还有好多我想说的，但我想直接反过来说，用了模板引擎，相比目前的前端开发模式，有什么好处吗？
可以说直接拉低了前端的上限。

[alexkkaa]

这类 spa 主要是不需要面对 seo 的 目前国外大量的传统应用

我是反对这种 spa 应用的 体验极差

[tabris17]

一切都要从 SPA 说起

[tabris17]

当然，SSR 本质上和 PHP 、JSP 模板没有区别

[gitignore]

你在讲开发网页 web page

前端在讲开发应用 web app

交互复杂度完全不一样，不是不能用的问题，讲究的是好不好用

[shuimugan]

缓存方案不够极致，界面相关的请求不能打到 PHP-FPM 进程，不然按住 F5 就能把 PHP 打死。

要想不被打死，界面相关资源就要尽可能远离计算层，所以生成好编译的静态资源特别是 html 和 js 部分是肯定的，既然都要生成，让后端语言玩就没意思了。

而且 PHP 之前语法连强类型都没有，写前端那不就是在写辣鸡吗，难道还要用 PHP 先实现一个 TypeScript 解析器？

更别说还要让前端跑一个 nginx 和 php 环境，再让它们能通讯，人家就想写个页面，还要经过你控制器层获取下缓存或者数据库，搞不好数据库也要搭，烦死了。写着写着 pull 下代码就报错了，一看是后端把字段调整了，还要跟着改数据库，我要是前端都想打人了，人力开发上都不解耦。

[GeruzoniAnsasu]

恭喜 lz 重新发明了用后端工程写前端

那 前端工程在哪？

[ipwx]

可是，稍微复杂一点的前端应用都不能用 web page 刷新那种交互形式啊。。。

举个例子，B 站你看视频，看到一半下面加个评论，难道还要中断播放嘛？

所以楼主的路线只能做一小部分功能。
----

现代前端框架是为了能和桌面应用的交互形式匹敌而设计的。

前端工程师既然有了这么强大的开发方式（而且开发也不慢），自然也能做你说的这些局限的应用。

那么既然这种开发方式吸引了更多前端工程师，那么传统的模板引擎路线，用的人就越来越少了。毕竟屠龙刀能干杀鸡的活，在无刷新模式下用户体验也比模板引擎的有刷新模式好，从用户体验到开发体验都完爆 SSR 模板引擎，高下立判。

既然用的人少了，那么新的项目自然优先用主流技术。

说白了这不是因为模板引擎不够，而是因为屠龙刀太强了已经吞噬了模板引擎的市场而已。

[ipwx]

当然模板引擎 SSR 的优势在于，搜索引擎友好。

但是中文互联网环境，大家恨不得搜索引擎找不到自己。都是想自己做平台的主。

模板引擎唯一比前端框架优秀的地方，在中文互联网环境是负作用的。

那就怨不得模板引擎衰落了。

[tabris17]

@ipwx DHTML 已经是上世纪提出的古董玩意儿了，现在的前端本质上也就是 DHTML 那套，甚至在 ajax 出现以前就有 invisible iframe 提交表单来进行无刷新服务器交互了

[ipwx]

@tabris17 不成体系的开发方式，和用 windows api 写 gui 有啥区别？

一个技术能够被广泛使用，解决开发的繁琐的心智负担是关键。

前端框架最重要的就是这一点。
----

背景：gui 方面，我当年高中时代就捣鼓过 windows api 、c# webform 、borland delphi (c++ builder)、c++ qt 。网页方面，我从 asp 、asp.net (c#)、python django 、python flask 。我都捣鼓过。

一直到现代的 vue.js ，所以我对这种开发难度的划时代的变化，我是非常感同身受的。

[ipwx]

更正：c# winform 。

不过 c# 确实推出过蹩脚的 webform ，作为网页的无刷新技术，hhh

[mxT52CRuqR6o5]

你只考虑了路由、html 渲染、api 这部分，但随着电脑性能和浏览器 js 引擎效率的提升，现在的网页都是需要执行非常复杂的 js 代码实现丰富的动态效果，当然你也是可以用 jsp 、asp 、php 等 js 以外的技术去管理 js 代码的，但相比用 js 去管理 js 都是需要引入额外的技术栈的

[Torpedo]

因为前后端分离了，要是一体考虑，用这一套就算工程化

另外现在服务端渲染的越来越少了，分离之后好多也用 node 做了

[kinge]

laravel 的前后端耦合非常高,对于大点的项目不利于维护和管理

[agagega]

现在也有 turbolinks 和 sjr 这种东西呀。这些和楼主说的没火起来的主要原因，是很多前端一点也不想碰后端，他们觉得在后端用其他语言做渲染是落后，但是用 JS 写服务又是先进