以下说一下我的感触。
服务端渲染 -> 客户端渲染 -> 服务端渲染
框架与生态
框架与构建工具强绑定
为何有这些感触?
* 首先本人从事 web 开发也有六七年了,近一年在学习使用 django ,折腾下来发现 django 是一个对于 web 标准理解非常深刻的一个框架。但在用 django 写模板的时候又发现,现在主流的一些 ui 库,没办法直接使用,能够直接使用的库例如 bootstrap ,还是传统的模式,远不及主流 ui 库好用。
如果本人理解不够,还望轻喷。
1
cxe2v 274 天前 5
你要关注服务端渲染 -> 客户端渲染 -> 服务端渲染这个过程发生的原因,不要只关注表象
|
2
echo0x000001 OP |
3
echo0x000001 OP @cxe2v 我的理解,本质上是为了提升工程化和开发效率,但是现在工程化的生态已经建立,可以向传统开发模式去靠拢,建立原生开发的生态。
|
4
Torpedo 274 天前 3
django 那个时代的 ssr 的问题是做复杂网站不友好。优势是做展示类网站很好,利好 seo 。
react ng vue 这一类是因为前端应用复杂,同时很多 spa 网站不在乎 seo ,自然前后端分离就行 至于又出现的 ssr ,那是希望能结合上面两种开发方式 至于 ui 库有啥浪费的,你算算后端有多少种语言,每种又有多少框架 |
5
echo0x000001 OP @cxe2v 其实第一点我到不在意,在意的是 2 和 3 。
|
6
echo0x000001 OP @Torpedo 我在想能不能在框架发展生态的时候给原生开发一点机会,目前除了 vue 脱离构建工具还算能用,其他的框架基本都用不了。
|
7
wanguorui123 274 天前
Web 前端已经进化到 PHP YES
|
8
echo0x000001 OP @wanguorui123 php 有个叫 拉乌瑞尔(具体咋拼忘了) 的框架倒是能够使用 react vue 等生态,好像还不错。
|
9
zhonghao01 274 天前
以前( 8 年前?)的 web 页面基本上都是服务端渲染,然后陆续出现了 angular 、vue 、react 这些框架,使服务端渲染的开发模式转变为客户端渲染的开发模式,到如今又开始推崇服务端渲染的模式
---- 这难道不是根据需求而决定的?有些网站就是不需要 ssr 啊,spa 就行了,有些网站需要 ssr ,并且不想回归传统的方式就出现了 nuxt next 啊 |
10
echo0x000001 OP @wanguorui123 找到了,是这个 laravel
|
11
Lockeysama 274 天前
主要是还是太卷了,不搞点新东西,没噱头,KPI 完成不了~~
前后端的负载重心也一直随技术变化,以前一台服务器搞定所有的时候,刚开始上网的人也少,服务器压力不大,随便搞,后面人多了,要减轻服务端压力,开始分离前后,再后面服务端集群化门槛低了,要优化用户体验,又把负载放回服务端……等以后又需要平衡的时候,可能又换回去了…… |
12
zzzlight 274 天前
巧了 这也是我觉得的 有一种回去了的感觉
|
13
stinkytofu 274 天前 1
现在前端开发太复杂了, 项目配置起来比写后端还麻烦。
|
14
echo0x000001 OP @Lockeysama 我只希望卷的时候,不要太自由发挥,脱离标准,照顾一下原生的生态。
|
15
zzzlight 274 天前
2,3 我觉得其实技术问题之外 很多程度上是社区或者人的问题 排挤其他框架最后大家都用自己的 那么为啥要做兼容别人的生态呢,这个是技术社区之间的人的问题。
|
16
clue 274 天前
1. 前后端分离是为了工程化解耦合, 最后回到服务端渲染是为了提升性能, 但现在大部分还是分离的, 并且与以前有个不同就是全面 JS 化
2. 多框架不正代表有活力吗? 人多了自然就有更多的细分市场, 这些框架差异挺大的, 但也在互相借鉴学习 3. 本质上还是前端复杂度在这里, 另外 JS 原本设计出来也没想到会应用这么广泛, 都渗透到服务端了; 很多为了提升开发效率加的特性你要向前兼容, 那就离不开各种工具了; 如果你把视角转到纯服务端, 比如 nodejs, 你会发现框架变化挺少的, 到现在不还是在用 express / koa 嘛 |
17
Lockeysama 274 天前
|
18
jymsy 274 天前
你是后端开发吧,现在的服务端渲染和之前的可不一样,虽然名字一样。现在的 ssr 主要是为了解决首屏渲染的问题。
|
19
ixixi 274 天前
多一种选择不好吗 ? 自己想用啥就用啥
|
20
ChefIsAwesome 274 天前
首先,这些框架是做 spa 的,所以确实没必要上 spa 的页面就不该用这些东西,徒增复杂度。
但是,现在新出来的后端就没学过,也不会干套模板。所以这活还是前端干。前端又整了套 js 在服务端渲染的东西。 现在这个局面是各种因素导致的,没办法。 |
21
yKXSkKoR8I1RcxaS 274 天前
前端越来越复杂
|
22
jguo 274 天前 1
先搞清楚轮回和螺旋上升的区别
|
23
hongweijie8 274 天前 1
我用 django 写模版的时候都是引入静态资源中的 vue.js 和 element.js/css ,不用 bootstrap ,感觉不是很好用
|
24
wu67 274 天前 1
讲真 ssr 只是为了官网, 更多的企业应用例如 oa 管理后台 crm 之类的, 其实完全不需要 seo, 这些场景都是 spa 的天下
生态乱战这个我没话说, 前端就是这样乱 至于工具, 也是乱战, 你看 vue 的迁移, webpack vue-cli vite, 每一次都是大难题, 不是说工具本身有什么问题, 是业务代码要各种改、还有私有 API 之类的调整, 本质上你选了一个技术栈, 那基本就是只能在这个坑里打滚了, 楼下别杠什么升级, 问问老板给不给你时间再说... |
25
ychost 274 天前
以前的服务端渲染和现在不太一样,以前基本就是个字符串模板引擎替换,现在像 Blazor 之类的是可以在服务端响应前端 click 事件,直接操作 DB 的,省去了 Controller 、Service 等裹脚布
|
26
Torpedo 274 天前
@echo0x000001 #6 可以啊,react 也能不用构建工具开发的。所谓编译不过是个工程化问题。而且有构建工具很正常,不然怎么打包压缩?
|
27
nomagick 274 天前
现在的前端是有结构性问题的,整个行业的发展前景都又问题
究其原因,是领头羊不行,领头羊的上限太低,下限更低,全部都不是软件行业深耕过的人,而是应届生或者别的不相干的行业转过来,没有工程思维,缺少背景知识和积累 每次出一个新的框架,不是把人往高处带,反而是不断突破底线,不断颠覆之前的标准和工程最佳实践 领头羊把路带偏,后面跟着的只能是越走越偏,和软件行业的主支差着十万八千里,都不知道以后怎么办 |
28
x2ve 274 天前 via iPhone
现在也有类似的 fastui 这种
|
29
iidear2015 274 天前
> 在用 django 写模板的时候又发现,现在主流的一些 ui 库,没办法直接使用。
--- 你先整一个集成方案,然后开源,就可以直接使用了 |
30
alphardex 274 天前
确实,不过我的视角跟 OP 不同,我觉得前端还有一个重要的方面是负责用户所看到的视觉效果(不限于 CSS 、Canvas 、WebGL ),但现在研究这方面的感觉越来越少了,都是在研究三大框架和 SSR ,很没意思
(嘛,不过对于看见 CSS 就头疼的后端来说这些不讲也行) |
32
lozzow 274 天前
后端学会一门语言后,基本上可以再不同的框架之间快速切换
反而前端感觉上时换一个框架就等于学习了一门新的语言 |
33
zzzyyysss 274 天前
@echo0x000001 laravel + inertiajs 一个字爽!
|
35
duanxianze 274 天前 1
诚如楼上诸位所说,这个演进的背后是前端越来越复杂了,前端能做的越来越多了,另外你说的那些都 2 ,3 不成立,angularjs react vue 完全可以混用,框架与构建工具也没有强绑定
|
36
SorcererXW 273 天前
感觉是大规模的边缘计算/CDN 基础设施完善,jamstack 开始流行,现在的 server component 是在这个基础上,让网站在不损失服务端渲染的好处,同时获得更强的动态能力,属于 spa 和 ssr 的融合
|
37
lstz 273 天前 via Android
服务器渲染和客户端组件并不冲突,可以参考 laftools.dev ,该静态的直出,该动态就动态加载
|
38
lynan 273 天前
我也想说现在的服务端渲染和以前的服务端渲染其实几乎并不是一回事,php/jsp 时代的服务端渲染,客户端没有多少互动的能力,但是现在的服务端渲染是满足前端可以是一个 Web App 的形式上,通过服务端提前拼接一些首屏内容提升加载速度
|
39
BeiChuanAlex 273 天前
对前端不是很了解,但是根据 vercel 的文档来看,现在的服务端渲染和以前的 django 所描述的服务端渲染不是一个东西,或者说不太一样,vercel 可以在编译的时候把该静态的全部进行静态化,动态的地方就动态渲染,基本上是尽力做到静态化。
|