这是一个创建于 2329 天前的主题，其中的信息可能已经有所发展或是发生改变。
完全是 web 开发新人，问题太简单别笑话我哈
我知道现在前端用了 React, Angular 那后端只要提供数据也就是 Restful 就可以了，前端有各种各样的打包工具压缩 js 之类的。
那如果是传统的 server 端渲染呢? 就是所有 html, css, js 都是在服务端的，每一个请求过来就发一个 html 回去，向 grunt 这样的工具也能压缩这些文件？(主要是 css, js 我想）然后把压缩过的文件放在后端？
顺便问问，现在是不是基本都是前端渲染了，server 端渲染的还多吗？
谢谢
我知道现在前端用了 React, Angular 那后端只要提供数据也就是 Restful 就可以了，前端有各种各样的打包工具压缩 js 之类的。
那如果是传统的 server 端渲染呢? 就是所有 html, css, js 都是在服务端的，每一个请求过来就发一个 html 回去，向 grunt 这样的工具也能压缩这些文件？(主要是 css, js 我想）然后把压缩过的文件放在后端？
顺便问问，现在是不是基本都是前端渲染了，server 端渲染的还多吗？
谢谢
 |
1
cuzfinal 2018-07-17 15:22:37 +08:00
react 之类的也可以做 server 端渲染，非前后端分离的项目还是有一大堆。
|
 |
2
baxtergu 2018-07-17 15:26:25 +08:00
可以在发布前把所有服务端 js uglify 一下，用混淆后的版本传给前端
|
 |
3
OSF2E 2018-07-17 16:17:00 +08:00
第一个问题的答案就是你说的这样，只不过 grunt/gulp/webpack 等工具的应用场景远不止压缩静态资源这一点。
第二个问题，服务器端渲染（ SSR ）的 web 项目还非常非常多，桌面系统平台上的客户端渲染（ CSR ）的 web 项目屈指可数，移动端的稍微多一点。究其原因，大多数 web 项目不需要太过复杂的交互体验，更关键的原因则是用 SSR 技术栈可以实现大部分开发需求，同时将 SSR 开发思想转换为 CSR 有一定的门槛，很多开发者刻意逃避这个转换过程，导致 CSR 的普及就如同 python3.x 替代 python2.x 那样艰难。 |
 |
4
leafiy 2018-07-17 16:20:46 +08:00 via Android
如果只看压缩，服务端渲染打包工具不是很必要，gzip 就够了，但是打包工具主要解决的不是压缩问题而是工作流的问题吧。
|
 |
5
randyzhao 2018-07-17 16:28:48 +08:00
服务端渲染的话
能做的主要就是 1. js / css 文件压缩 2. js / css 文件合并 3. js / css 文件版本控制 4. js / css 文件 cdn |
Select Language