现在前端都已经这么高级了吗？

[DavidNineRoc]

我只是想问一个问题，如果有说的不对的地方，勿喷： 现在的项目前后台分离，我负责 api， 同时把他的前端给我，让我部署到服务器。（还要我装 node，yarn 什么之类的） 我惊呆了，前端为什么还要求服务器装这些？不是开发的时候用，部署时管你用什么 es6,不都打包成 html ？ 然后我就懵逼了，我的前端还停留在 jq 的时代； 我也不知道用的什么框架，截图一张。 难道现在不支持打包成浏览器直接运行的？ ps：我另一个同事用的 rn,说可以的，然后争不过另外一个。求大神解释一下

[Tokin]

@DavidNineRoc let 是 ES6 新的特性，ES6 出来之后我更倾向于用 let。
另外这个 nodejs 其实算是互相减轻各自的工作量了，大体是他直接用 node 读你的 api，然后把数据填到页面，我觉得还可以。。
那你之前拿到 html 是不是还要写成模板才能用？有点不明白。

[MeteorCat]

@DavidNineRoc 我感觉后端做好接口就行了，至于所谓服务器端的 js 构建你让他先部署在内网服务器，而且很多前端瞎 TM 搞的，不要让他瞎开端口，只能让他 nginx 反代理到他的服务，如果他都搞不定，就叫他不要碰什么服务器，以免到时候整个服务都被他搞乱；我见过以前有个前端自作聪明要搞服务器将所有端口全部到开放到外网，最后将 ssh 端口映射成服务，停了原来的 ssh 服务........

[abcbuzhiming]

@DavidNineRoc 不要被唬住了，一点都不高级，不过是把以前后端用烂了的模板引擎，又用 nodejs 实现一遍，在之前的
web 浏览器<——>后端 的中间，加了一个 node 层，变成了下面这样的结构

web 浏览器<——>NodeJs 服务器(模板引擎)<——>后端
nodejs 吐给 web 浏览器的，一样是 html，css，js，只是套模板的工作由以前的后端模板引擎，变成了 NodeJS 服务器来完成，后端不再套模板，只给数据（一般是 json ）。最早这种玩法是天猫搞起来的。这做法有好处，也有坏处，一般来说，小规模项目是不赞成这么做的。而且你们公司上这种架构之前，没讨论过吗？随便就允许他这么搞？

这事情最 tm 恶心的是，你要搞就自己搞定整个部署啊，NodeJS 服务器部署的测试在这个模型里可是归前端的工作，关后端屁事，后端只要保证 api 接口的数据没出错就行了

[coolcoffee]

现在就算是 SPA 应用，也一定存在这首屏资源加载好后还要向服务器请求一次接口再渲染，这个时间在用户那里要么白屏要么显示 loading， 服务器首屏渲染就是减缓用户第一次打开页面的等待时间，之后页面内切换就不需要再用服务器渲染了。

[mritd]

@raphaelsoul 不同项目的 node md 目录你做 cache 了么

[rbe]

服务端渲染和模板引擎并不是一个东西。

首先不用模板引擎改用前端单页应用原因，就是为了体验上的优化（不用频繁的页面跳转）。
在这个过程中，由于首次加载前端框架耗时较长以及 SEO 方面的原因，才会引入 Server Side Render 这个东西，一般来说也只是首屏直出，和传统的模板引擎并不一样。

另外引入这个 node 中间层还可以解决一些路由、数据定义上面的问题，并不是全无好处，只是在架构上会复杂一点。当然，也不是所有项目都需要这样搞，应该事先沟通确定

[finian]

@abcbuzhiming #43 你忽略了 Node.js 服务端渲染的一个优势，如果前端是用 React, Vue 这些框架，使用 Node.js 的服务端渲染，前后端可以共用一套代码（架构），用其他语言写模板，就要同时维护两份前端 UI 逻辑，明显是前者开发效率高，可维护性好

[linus3389]

如果给他两份钱的话。。。我想应该不需要后端了吧

楼主可以看看 gayhub 今年的项目语言类型统计，js 社区空前活跃，导致什么牛鬼蛇神的活都能干了

[isbase]

@abcbuzhiming 不懂不要装懂

@finian 说的对，这就是 Universal JavaScript，和字符串模板引擎是有本质的不同，开发效率和维护性有
天壤之别

[solgh]

上线项目 让后台搭环境的前端 都不靠谱....

[wekw]

楼主呀，你可长点心吧。


他这是要抢你的饭碗呀。

[FaiChou]

rsync 了解一下

```
"scripts": {
"pub": "yarn build && rsync -avze ssh --delete-after build/ root@111.222.333.444:/var/www/html",
}
```

[archknight]

mark。以后注意下坑

[bzw875]

感觉前端想刷经验，既然要做服务端渲染，那么就别做单页应用了，直接用后端的模版引擎渲染。这个平白给系统增加了复杂度，必经你们公司又不是淘宝那么大的系统，这样做不划算

[RubyJack]

前端要 SSR，那就让前端自己去管理自己的 node 应用啊，不关你事，果断甩锅

[otakustay]

1. 前端需要 Node 等做线上服务是合理的，原因很多
2. 前端都已经深入到需要这些东西了，自己不会部署和运维这说不过去

因此结论是：尊重前端，但请它自部署自运维，不要接锅

[notreami]

甩锅就行，管好自己的 api 和后台就行。

前端的工作，总感觉挺奇怪的。切图＋设计的活也不做了（这还要专门找个设计人员），兼容还闹革命，低几个版本就不兼容（直接放弃 1%以上的用户）。
最喜欢瞎折腾各种半年、一年就淘汰的玩意。天天叫的工程化，哪家工程化，几个月就要来一次小变动，半年来一个小重构，二年来一个大重构。

最恐怖的是，配置这么散，放个 1、2 年。估计连开发的人都不知道干啥的了。

[DavidNineRoc]

@DT27 下次不敢帮他推了

@vizards 这样是不是也有坏处？我发现只要我接触出错了，他直接报错页面渲染不了，而正常前后端分离，我接口出错，前端是可以提示服务器异常的

@eslizn 懵逼中

@abcbuzhiming 明白了一点

@chengxiao 应该不会，我们公司还是以 PHP 为主力

@Tokin 以前同事给我的 html 页面是 es6 写法 打包出来的，里面的用 js 获取接口数据渲染

@MeteorCat 我自己对服务器也不是很熟悉，只会搭建环境和简单的配置

@abcbuzhiming 前端自己决定的 ~_~

@rbe 用 node 在服务端渲染，不一样要请求接口，在服务端渲染返回，速度有加快吗？

@linus3389 现在 js 好 gay。
@solgh 测试环境玩玩而已

@wekw 前两周刚看见他拿着一本 go 的书看着，我是不是要做好拿一本 es6 的书看看 >_<

@bzw875 我也不懂前端的想法

@RubyJack 明白

@otakustay OK

[DavidNineRoc]

@notreami 我看了文件夹结构，要赶上后台了

[CoderGeek]

我一般都是直接给他们地址 接口 。
前端项目不是必要用 node 的时候还是让他们把 处理好的前端代码部署上去直接访问 api