后端语言 PHP 这样的模板引擎 lavarel 等，为什么没有称为前端工程化？
liudaqi · 2021-11-13 08:24:28 +08:00 via Android · 3127 次点击这是一个创建于 1110 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如 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 服务端渲染回潮的情况看，这不是以前一直在干的嘛
只需改造 js 实现一下 pushState ，就可以在前端拦截路由，通过 ajax 加载所需的 template 或者 component 、section ，就可以实现单页应用 SPA 了。
这样还是原生 SS'R 服务端渲染，纯正的按需加载，初始化加载速度极快。其他的 for ，if 控制这些后端模板也一样用。
和 vue ，react 现代前端工程化相比，少了虚拟 dom ，该实现的工程化概念基本都在。关于 state 传递，哪种方式都少不了的，都要 js 做的活，没有很大区别。
并不是否定 vue ，react 这些的作用，而是觉得后端语言的模板引擎，工程化能力看起来也没差。从 SS'R 服务端渲染回潮的情况看，这不是以前一直在干的嘛
 |
1
512357301 2021-11-13 08:33:20 +08:00 via Android
技术不是决定因素。
前端就是从后端独立出来的，前端为了自己生存的更好，就得用自己擅长的技术造出适合自己技术栈的轮子的，哪怕是模仿后端呢。 说到底还是个话语权的问题，试问前端这些技术栈对于后端来说还能看得懂吗，还能拿来就用吗，不能了吧，这样前端的独立性就能保证了。 那 CTO 为什么就支持前端这么搞呢，因为花的是公司的钱，无所谓的，而且前后端各成一派，总团队人数还壮大了呢，何乐而不为呢。 技术不是决定因素，政治永远是决定因素，哪怕是办公室政治 |
 |
2
sheeta 2021-11-13 08:58:21 +08:00
这不就是 pjax 吗。。。
|
 |
3
shapl 2021-11-13 09:00:42 +08:00  4
感觉你对前端工程化有点误解。
|
 |
4
Cbdy 2021-11-13 09:00:52 +08:00 via Android
因为 php 不方便在浏览器执行
|
 |
5
cmdOptionKana 2021-11-13 09:01:33 +08:00
因为模板引擎还是要依赖后端，无法做到 severless ，自然就不是前端工程化了。
举个例子，比如静态博客，如果用模板引擎来做就必须要有后端，但纯前端可以挂在 github 里。 再比如网页版的 vscode （或各种类似的编辑器），你靠后端模板渲染，如何能实现一个浏览器里的编辑器？ |
 |
6
ChefIsAwesome 2021-11-13 09:20:14 +08:00
1.你讲的是如何通过 ajax 渲染，不是前端工程化。
2.mvc ，mvvm 等概念的本质是 view = render(state) 。渲染放在前端还是后端，是替换 html 字符串，修改 dom ，或是通过虚拟 dom 这层代理来修改 dom ，都是 render 的具体实现方式。各有利弊。 3.前端技术是以如何提供更好的用户体验为导向的。所有的界面变化都可以通过你讲的 ajax 到后端再返回 html 替换的方法实现，但用户能接受点个单选框都要先等上一秒钟，等后端返回请求才有响应吗？ |
 |
7
liudaqi OP @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 基本上是纯前端应用，后端可以没有。 |
 |
8
joesonw 2021-11-13 10:41:55 +08:00 via iPhone
你这个只能算是 BigPipe 流派。
|
 |
9
wdhwg001 2021-11-13 11:14:00 +08:00 via iPhone
实际上 Vue 的一个重要应用场景就是后端直接输出 json 为 js 在页面上，然后前端拿 Vue 去渲染，需要用到 json 以外的东西的时候再 ajax 。
从这个角度看，实际上也属于一种 SSR 了，而且这种方式不依赖模板引擎，还可以很好地搭建在微服务架构的网关附近。 人们逐步弃用模板引擎的原因无外乎两点，太慢了，以及浏览器功能全了。从这个角度看，再把模板引擎做重，重到可以渲染出整个首屏，说实话非常不划算。 |
 |
10
westoy 2021-11-13 11:47:26 +08:00
ajax 刚流行的时候， 就有一把梭哈的 xajax 了， 配合 phplib 、smarty 食用更佳......
后来 php 流行期正赶上 web 重构+xhtml( 此处第 N 次 @laogui) + 前后端分离 + 前端分离的潮流..... 所以......就无了....... |
 |
11
dcsuibian 2021-11-13 12:00:38 +08:00 3
一个略会前端的后端路过。
没接触过 php ，但最开始用 jsp 、jQuery 开发过，也接触过 thymeleaf 、jinja 等模板引擎。 在我看来，所谓“前端工程化”就是用户对 UI 美观要求越来越高，前端工作量越来越大，所以要写前端像对待一个正经工程一样规范化。 为什么模板引擎不适合前端工程化呢? 我的看法： 1 。模板引擎太多了，而且和语言生态圈绑的比较死。 Java 、.net 、Python 生态圈里都有各种模板引擎。 这种时候。这时候，如果你基于一种模板引擎做了组件，那么在另一种模板引擎里就用不了。 这样的话，就算你能封装成组件，恐怕也只是这个项目或公司内部的复用，无法形成 ant design 那样的正经组件库。 2 、模板引擎不适合协作开发。 试想一下，如果使用模板引擎，那么前端开发人员也不可避免地对模板语法有一定的了解。而且还得有跟后端一样的开发环境。 当初我用 jsp 开发的时候，为了看到效果，重启服务器的过程真的是让我心力憔悴。而且更多的是串行开发，后端没做好前台也做不了。 而现在，只要定好相应的接口格式，前后端就可以并行开发。而且前端的代码更改跟后端也没有什么关系。可以专心地干自己的事。 3 、后台的服务端渲染也有问题。 首先，相比于静态内容来说，模板引擎这种东西会更加消耗服务器资源。（不过这个我没数据，所以无法证明影响多大） 这就是后台服务端数据不太完美的地方，对于流量很大的网站比如各种门户网站，后台也得提前把网页模板渲染成 html 缓存。 从响应速度上看不到差别，但网上确实有相应的实例。 4 、JSON 和 html 谁说后端提供的数据只能给前端页面使用呢？ 比如 github 的开放 api ，如果返回 html ，那第三方程序怎么用呢？ 而且，就算你真的只是拿来做页面。那么如果同时得支持移动端和桌面端页面呢？ 。。。 其实还有好多我想说的，但我想直接反过来说，用了模板引擎，相比目前的前端开发模式，有什么好处吗？ 可以说直接拉低了前端的上限。 |
 |
12
alexkkaa 2021-11-13 12:02:33 +08:00 via Android
这类 spa 主要是不需要面对 seo 的 目前国外大量的传统应用
我是反对这种 spa 应用的 体验极差 |
 |
13
tabris17 2021-11-13 12:04:59 +08:00
一切都要从 SPA 说起
|
|
14
tabris17 2021-11-13 12:05:27 +08:00
当然，SSR 本质上和 PHP 、JSP 模板没有区别
|
 |
15
gitignore 2021-11-13 12:09:26 +08:00
你在讲开发网页 web page
前端在讲开发应用 web app 交互复杂度完全不一样，不是不能用的问题，讲究的是好不好用 |
 |
16
shuimugan 2021-11-13 12:59:26 +08:00 via Android
缓存方案不够极致，界面相关的请求不能打到 PHP-FPM 进程，不然按住 F5 就能把 PHP 打死。
要想不被打死，界面相关资源就要尽可能远离计算层，所以生成好编译的静态资源特别是 html 和 js 部分是肯定的，既然都要生成，让后端语言玩就没意思了。 而且 PHP 之前语法连强类型都没有，写前端那不就是在写辣鸡吗，难道还要用 PHP 先实现一个 TypeScript 解析器？ 更别说还要让前端跑一个 nginx 和 php 环境，再让它们能通讯，人家就想写个页面，还要经过你控制器层获取下缓存或者数据库，搞不好数据库也要搭，烦死了。写着写着 pull 下代码就报错了，一看是后端把字段调整了，还要跟着改数据库，我要是前端都想打人了，人力开发上都不解耦。 |
 |
17
GeruzoniAnsasu 2021-11-13 14:00:34 +08:00
恭喜 lz 重新发明了用后端工程写前端
那 前端工程在哪？ |
 |
18
ipwx 2021-11-13 15:01:00 +08:00
可是，稍微复杂一点的前端应用都不能用 web page 刷新那种交互形式啊。。。
举个例子，B 站你看视频，看到一半下面加个评论，难道还要中断播放嘛？ 所以楼主的路线只能做一小部分功能。 ---- 现代前端框架是为了能和桌面应用的交互形式匹敌而设计的。 前端工程师既然有了这么强大的开发方式（而且开发也不慢），自然也能做你说的这些局限的应用。 那么既然这种开发方式吸引了更多前端工程师，那么传统的模板引擎路线，用的人就越来越少了。毕竟屠龙刀能干杀鸡的活，在无刷新模式下用户体验也比模板引擎的有刷新模式好，从用户体验到开发体验都完爆 SSR 模板引擎，高下立判。 既然用的人少了，那么新的项目自然优先用主流技术。 说白了这不是因为模板引擎不够，而是因为屠龙刀太强了已经吞噬了模板引擎的市场而已。 |
|
19
ipwx 2021-11-13 15:02:51 +08:00
当然模板引擎 SSR 的优势在于，搜索引擎友好。
但是中文互联网环境，大家恨不得搜索引擎找不到自己。都是想自己做平台的主。 模板引擎唯一比前端框架优秀的地方，在中文互联网环境是负作用的。 那就怨不得模板引擎衰落了。 |
|
20
tabris17 2021-11-13 15:08:58 +08:00
@ipwx DHTML 已经是上世纪提出的古董玩意儿了，现在的前端本质上也就是 DHTML 那套，甚至在 ajax 出现以前就有 invisible iframe 提交表单来进行无刷新服务器交互了
|
|
21
ipwx 2021-11-13 15:12:39 +08:00
|
|
22
ipwx 2021-11-13 15:16:03 +08:00
更正：c# winform 。
不过 c# 确实推出过蹩脚的 webform ，作为网页的无刷新技术，hhh |
 |
23
mxT52CRuqR6o5 2021-11-13 15:19:03 +08:00 via Android
你只考虑了路由、html 渲染、api 这部分，但随着电脑性能和浏览器 js 引擎效率的提升，现在的网页都是需要执行非常复杂的 js 代码实现丰富的动态效果，当然你也是可以用 jsp 、asp 、php 等 js 以外的技术去管理 js 代码的，但相比用 js 去管理 js 都是需要引入额外的技术栈的
|
 |
24
Torpedo 2021-11-13 17:28:42 +08:00
因为前后端分离了，要是一体考虑，用这一套就算工程化
另外现在服务端渲染的越来越少了，分离之后好多也用 node 做了 |
 |
25
kinge 2021-11-13 18:18:50 +08:00
laravel 的前后端耦合非常高,对于大点的项目不利于维护和管理
|
 |
26
agagega 2021-11-14 17:38:36 +08:00 via iPhone
现在也有 turbolinks 和 sjr 这种东西呀。这些和楼主说的没火起来的主要原因，是很多前端一点也不想碰后端，他们觉得在后端用其他语言做渲染是落后，但是用 JS 写服务又是先进
|
Select Language