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

前端项目打包一般不在本地做，普遍专门的机器上做 build，或者直接在线上 build。

build 需要依赖 node，yarn 这些工具。

如果只是部署的话，让他直接填写好对应的 API 地址（因为源码一般都写死了然后 build 成一大堆 js 文件的）后直接发给你，你静态放服务器就好啦

服务器装不装 node 跟你后端用不用得上有关系，与前端无关，你无需负责他的打包之类的。

还有你贴的代码是 node 后端的。。 有点搞不懂了，233

楼主落后就要淘汰啊
你看看 Laravel 前端那一块的文档

让前端的 build 好给你或者研究下 CI/CD

他这个不行是因为在前面挂了一层 node 做代理之类的功能，所以才需要装 node 和 yarn。

他这个实际上跑了一个 node 服务器，不是单纯的静态文件。

前端 build 完全是搞笑的

我刚做一个项目，我只负责后端开发和后端服务器配置，前端的开发和前端服务器部署都由前端的同事完成，感谢前端同事

截图这是 nodejs，不是跑在浏览器上的。

build 肯定是要执行的，CI 是让它在服务器上自动执行，看把前端懒的。机智。

讲道理前端应该把编译打包好的的文件给你， 最好的方法当然是前后端分离，前端自己管理前端代码把代码上传到 cdn，就算只提供接口

后端只提供接口

公司都是半通水吗？

如果前端要挂个 node 来处理请求就走远了；开发环境 maybe，线上也怎么搞？

这压根就没分离彻底
分离彻底了你就负责写接口发布你的接口
前端代码部署是他的事儿，你俩应该除了接口撕逼和联调之外没有交集才是啊

他这是要在后端服务器 nodejs 上跑的，框架是 express

建议楼主赶紧补点前端部署知识了.

......前端不都是处理页面逻辑的吗？不是丢个 svn 或者 git 把文件提交 js 上来就行了，难道是全栈用 node.js 处理？

没分离加一

你还没试过给 node 项目打 docker 镜像

@mritd 我这边用 jenkins 和 docker 做 CI 用 docker 来做 npm build 和自动发布 美滋滋

工作中遇到前端打包的，有时候还好，前端都懂这些打包发布的流程，有时候就坑了，打包出现问题，找我这个后端……

@andy12530 我也没弄懂前端
@safedogcc 他是做前端，说是什么服务器渲染，我也懵逼

@GooMS 我只想安安静静的做一个 api 开发 >_<

@gdtv 现在是测试服务器，我晕，他要我装一个 node 在服务器上，我说我装了 nginx，他说不是一回事

@Perry 我不知道，我问另外一个前端同时他说 build，可以生成可以让浏览器直接运行的

@maichael 怎么解决直接让运行？而不是通过 node。
@feverzsj 不懂。。。求解释

@misaka19000 我已经把数据接口给他，然后想放服务器上测试一下，他就给我这些文件，我也疑惑，因为另外一个前端同事做另外一个项目时，给的是纯静态的。数据通过接口取。

@hlwjia 我不懂前端这块这么高级的，我环境搭建好了，后端和 api 都在运行

@banricho @MeteorCat @wellsc 他的数据的确都是通过我的接口取的

@8qwe24657913 我蒙蔽呀
@daydaydayup 短期是没这个打算，我只认为前端应该丢给我能直接运行的 build 好的能让浏览器直接运行的 html
@mritd 不敢不敢，我一个写 PHP 的，学多了消化不了，慢慢来

@jingniao 我对这些打包蒙蔽的很，电脑环境一个没装，让我装 node，yarn 什么的，我直接说，这些不是开发的时候用的吗？怎么还搞这些，他就说什么服务端渲染，我也不懂前端

你不专门做前端 不用羡慕这些 让他打好包把 bundle 给你就行

一看卵用 let 也不是啥“好前端”

奇怪，既然都用 nodejs 了，为什么不用 nodejs 写 api 接口。。。都不需要你们后端什么事儿了，一个前端搞定所有。。。美滋滋

@DavidNineRoc
1. 你贴的代码是 node 后端的代码，用了 express 框架。这部分确实需要服务器装 node 运行。
2. nginx 和 node 确实不是一回事，可以并存不冲突。
3. 他说用了服务端渲染，那么确实需要后端（ node ）代码支持。
4. 如果他用 node 只是用于服务端渲染，那么可以不使用服务端渲染，这样也可以不用 node。
5. 关于 build。一般 build 之后都可以在浏览器跑。如果在本地 build 再发布到服务器，那么不需要 node。如果在服务区 build，那么需要 node。
6. 你另一同事便是 5 的前者。

@Eoss 补充，确实按楼上，建议楼主补充点前端的知识。

@DavidNineRoc #21
原来是服务端渲染～
那么就好办了，直接给服务器权限，让他自己上去部署吧，然后把本地监听的端口给你就行，你配置 nginx （或者让他自己弄）设置好域名，直接转发本地 nodejs 监听的端口即可。

他那么懂，让他教你啊。都搞服务器渲染了，这方面肯定比你熟。服务器给他，让他自己折腾。

@murmur 我另外一个同时和我做项目的时候都是这样子的。

@SourceMan 我还处于用 var 的时代

@Tokin 我也不知道他为什么要用这个，直接安安静静的拿数据前端渲染不就行了

@Eoss thanks，前端这些框架的太繁琐，我安安静静的用 jq

@daydaydayup 前端部署问题前端自己不搞定来找后端，这前端是怎么干活的

@ChefIsAwesome
@safedogcc
下次，下次必须这样

@abcbuzhiming 我在折腾服务器搞些东西，我以为他就是给我一些纯静态的（以前的前端通过和我合作都是这样的）。哪里知道这么高级：：：

都是不安分惹的祸。
js 非要去搞后端。。。

这是弄的服务端渲染，你们前端用的 vue、react 或者 angular 之类的前端框架之类的话，是通过 js 渲染页面的，通俗讲就是浏览器加载 js 和 css，然后 js 负责生成 html 给用户看。


1.浏览器加载所有资源(html,css,js,img...)-->2.cdn-->3.返回资源-->4.前端请求 server 获取业务数据-->5.返回数据，js 渲染成 html 片段-->6.css 渲染片段成一个网页-->用户


但是这样带来的结果就是 4、5 步非常耗时，对数据比较复杂或者比较多的情况下，即使优化非常出色也需要 200 到 500ms 时间，而且在 js 完全加载之前用户看不到任何内容或者只能看到个加载中提示，体验很差。而且对前端生成 html 对非谷歌的搜索引擎 seo 不友好，它们可能不会解析 js 动态生成的内容。


加一层 node，就相当于在后台模拟一下浏览器，先把 html “快照”出来，直接递给前端，这样就解决上面的问题了。

build 不累吗？现在绝大多数浏览器都是支持 gzip 的

app 端好像怎么弄回复都 tm 不能换行，lz 将就看吧...

@DavidNineRoc 前端所谓的服务器渲染，不过是把后端早就玩烂的模板引擎换个名词罢了，还有，如果前端要玩这套东西，那麻烦前端自己搞定服务器部署问题，后端只提供 api 接口，也只负责 api 接口的数据正确性，数据正确了页面不对，前端自己想办法去，现在的不少前端完全就是在瞎搞，学了点名词就出来忽悠，硬要在数据接口和页面之间加一个 node 搞页面渲染层，你搞可以啊，自己部署搞定嘛，搞不定又来找后端

另外，什么扯淡的框架最后还是会变成 html+css 和 js，浏览器只认这些

服务端渲染 那不就跟后端写的东西 没区别了.....感觉他想代替你啊楼主 要小心了

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

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

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

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

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

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

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

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

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

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

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

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

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

@abcbuzhiming 不懂不要装懂

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

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

楼主呀，你可长点心吧。


他这是要抢你的饭碗呀。

rsync 了解一下

```
"scripts": {
"pub": "yarn build && rsync -avze ssh --delete-after build/ [email protected]:/var/www/html",
}
```

mark。以后注意下坑

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

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

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

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

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

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

@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

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

@DavidNineRoc 无非就是想把 API 那层包了。
假设你们后端服务是一个大集群、分布式。大前端其实就是想把面向客户的那层包了。以及汇总接口的那层前置 API 层（后端服务）包了。然后、后端服务，就可以抛弃 http 协议了。找个高效的 RPC 协议就可以了

这种 前端->node(渲染层)->php(接口数据层)
理念是挺好的,而且大公司也崇尚用这种方案

但是 node 这一层的部署,如果管服务器的人没有对这个东西有一定把握的话, node 太容易挂掉或搞爆内存了
不是一开始定好的方案, 这么突然扔一套东西上来, 也难怪楼主会懵逼

既然他要这么玩, 应该他自己部署, 自己管好高可用这些, 至少保证 node 不 crash,另外日志这些也让他维护好.
所以楼主还是和他沟通一下, 并且把他的东西退回去,
要搞就好好搞,别把练手的东西这么扔过来

本地打包和服务器打包都可以，最终生成的代码也不过是 HTML/CSS/JS，对系统没有要求
后端如果负责部署的话，帮忙部署前端内容也没毛病（你敢让前端登上服务器操作一下么）

@learnshare 这里说的不是 build
是 node 起 server 渲染页面

我这儿就是这样：web 浏览器<>NodeJs 服务器(模板引擎)<>后端，服务器跑 node，nginx 做负载均衡，有些小项目直接用 node 全做了，操作数据库也挺方便。

@isbase 谁不懂装懂，喂，你们不要自以为发明了全新的玩意好不好，你以为我没玩过 node 没去看过这东西的实现机制是吗？和字符串模板引擎有本质不同？加了点新功能就“本质不同”了？
还有，前端的可维护性不是用这个东西体现的，用了 nodejs 做渲染但是代码仍然写的换一个程序员就没法改的我见多了

多研究点技术，少忽悠点概念，看技术要看到本质。

@alexsunxl 那就适用于第二行
不过如果是 server-side-render，那前端应该也掌握了部署的技能

@CoderGeek 给接口地址前端开发了

@notreami 我感觉我们没到那一个地步

@alexsunxl 服务器上还要挂着 `node index.js` ?这个和 php 的`php -S localhost:8000`应该不一样的吧，php 一般都是调试用

@learnshare 打包不了，前端说必须要用 node 跑

@billyu 唉，你们不要这样子呀，我 php 的感觉要收拾东西回家了

首先老大在哪？谁管事的，问一下服务端渲染是要还是不要的

@DavidNineRoc 不要纠结，这种模式下 node 就是个服务器，通过执行 js 代码完成服务器逻辑，同时它作为客户端，向你的 api 接口发出请求获得数据，然后和它持有的模板文件组合，最后变成 html+css+js 吐给前端（浏览器）

直接告诉他，你搞不定不就好了

楼主用的 laravel 吧

前段不是程序员系列.

@abcbuzhiming 模板引擎缺少了逻辑封装，还真不是一个玩意。

我觉得主要是你们前后端沟通有问题。

说明你有点 out 了，该了解的还是要了解一些的。

暴躁后端例行集会

楼主把锅甩给管事的就好，小公司这样搞有点坑，特别是在写 nodejs 的之前没写过后端的情况下

譬如可以测一下参数过滤、跨站攻击、错误告警之类，没写过后端的可能都不会在意这些

是需要前端部署，但是这事是前端或者运维负责的啊，不归服务端的管。

@DavidNineRoc 你 PHP 的？那你真有点危险，说句不好听的，大部分 PHP 现在的工作真的就是在当模板引擎而已。这个工作，是真的可以被 nodejs 取代的，nodejs 目前可以出现在基本所有 PHP Web 能出现的场合里，而且最致命的是，比 IO 的话 PHP Web 是比不过 NodeJS 的

@hlwjia 小公司，老大不懂技术

@abcbuzhiming 明白~~~

@goodryb 已经搞定了~~~ 只是询问一下，为什么要这样。
@lostinyou 必须的！！！
@TestSmirk 最厉害的程序猿就是前端的了。

@vigoss 我是后端的，那么如果你是前端，你了解 composer 吗？了解 spring 吗？了解有个屁用啊，不会用，我也知道 node 呀，可是不会，前端三大框架一个不会。 那么你前端会管理后台的包吗？
@YenvY 必须的，后端天下第一 *+*
@yplam 明白人 >_<。
@neilwong 小公司

@abcbuzhiming 说真的，我毫不担心。公司的 api，后台都是用 laravel 开发的，侧重于 PHP， 前端只是恰好这次用这个而已。

@abcbuzhiming 还有，你的观念有点老了，都已经 2018 了，你的 PHP 还停留在模板时代

大家都很逗

@DavidNineRoc 笑笑，朋友，laravel 并不能救你，如果你真的对 PHP 特别热爱的话，去研究研究 swoole 吧。几乎所有的 PHP MVC 框架，就是在套模板而已，我言尽于此吧，做技术，眼光要广泛，不要只盯着眼前一小块；同时，也不要被新概念忽悠，要能找到共性

@DavidNineRoc 现在看起来是搞定了，恭喜一下。不过劝一句，职责还是分清楚好；特别是你对前端也不是特别熟的情况下；以后出问题，前端甩锅给你怎么办。

前端的坑很多的，要到 production ready 还是要有真正懂 node 来 （都是门槛太低惹的祸）

吃瓜群众飘过~

我们之前有服务器渲染的，就是楼上提了的 Universal Javascript ；但是后来发现一是（主要原因）业务没这样的需求；二是后端还是单纯一点跑后端服务好，没必要把服务端搞复杂了。

所以后面把服务器渲染去了，纯打包上传。

需要服务器渲染的，比如为了帮助 SEO 的，像一些静态页面需要给爬虫的，就都开发机上打包好再传上去

@lizhenda 你是来增加顽皮的吗？
@abcbuzhiming 如果你真的研究过了，就不会这么说了。PHP 不也是套了模板的 C ？ swoole 用不到为什么研究呢？有更多的方向，而且已经有大神把 swoole 继承到 lv 里，来增加并发。
@hlwjia 下次不敢动了

这事情谁做都可以
帮忙做一下也没坏处
可以和前端一起研究下 docker ci cd
然后让前端出 dockerfile 就好了
你搞个自动部署。。

神一样的 let

前端有前端的服务器，后端有后端的服务器，自己上线自己的。

可以看打包后的 dist 里有没有 html，没有的话可能用了服务端渲染，那样的话是需要 node。。。因为服务端渲染方式它的 html 是通过 node 整合而成的，不跑起来是没有的。。。

不用服务端渲染的话我们一般把打包后的目录路径给后端 path/to/dist 这种，也有前端开发完 build 一下再发的。我还是倾向前一种，毕竟如果是到了测试或者迭代阶段，每改动一点都要 build 一下，赶脚怪多余的还容易忘

用不用服务端渲染取决于项目类型，SEO 啊兼容啊之类的，赶脚一般小项目都用不着把。。。前端 build 还是后端 build 也可以商量的，要是能自动部署就更爽了

如果是管理平台这种系统的话，不需要服务器端渲染。如果是网站展示，需要 SEO 的话，还是需要服务器端渲染的。
服务器端渲染，一是可以保证客户端和服务器端的 js 共用，二是加载页面的体验更好，获取数据在服务器端进行，而且不会出现 webpack 代码分割后的赖加载白屏的情况。
无论是否需要服务器端渲染，现在也不是 html 拖到浏览器里就能运行了年代了。你的前端还停留在 jq 的时代，确实过时了。
至于为啥把代码都给你，因为前端没有服务器部署权限。
要我说，一个 react、vue、Angularjs 项目的服务器就不应该用什么 nginx、Apache 之类的。node 不到 100 行代码就能跑起来，他好我也好，大家都好。

我感觉是，前端这家伙自己不懂瞎搞，把楼主搞糊涂了。我个人如果你们要前后端分离，那前端应该自己负责部署，至少也要负责好 build。

看大家的回复
学到了不少
谢谢

@markx 明明是楼主不懂被搞糊涂了吧，如果楼主知道服务端渲染是怎么回事就不会来发帖了，直接弄好或者推掉就是了。

1.前端都这么“高级”好几年了，其实没有很高级，不就是用了 nodejs 吗。
2.根据贴出来的代码，前端用了 nodejs 下应用最广泛的 web 框架 Express，nodejs 虽然本质上是后端语言，但常用于 api 层之前的页面渲染。
3.造成困扰的原因可能是前端没有服务器资源，或者公司没有前端部署服务器的先例。
4.准确地讲公司没有完全实现前后端分离。
5.这种情况，解决问题的正确方式应该是前端维护自己的服务器。
6.楼主的疑问无可厚非。
7.评论感觉满满的戾气。