为什么不把后端也交给 webpack？

[Cbdy]

根据 Atwood 定律，大部分后端场景迟早也是 js 的天下。众所周知，ts 写起来是很爽的，所以如果前后端都是用 ts 写（比如前端 react+tsx，后端 koa ），一个普通的 webapp，完全可以前后端都通过 webpack 编译运行，开发的时候也可以只用一个类似 webpack-serve 这样的工具，代替原先的前后端两套开发架子（比如前端 webpack-serve，后端 nodemon ）。

这样在同一个代码仓库开发，一个功能从前写到后，同一套数据结构从前用到后，岂不是效率很高？

[blanu]

关 webpack 鸟事？后端是可以用 webpack 打包运行，有必要？直接上 node lts 就有 es6 了，钓鱼贴吧。

[molvqingtai]

相信我大前端有朝一日会一统江湖！

[Cbdy]

@blanu 我是认真的，我打算下周搞个类似的东西尝试一下，看看效果

[lihongjie0209]

笑笑不说话

[mhycy]

打包意义在哪里？

[leafiy]

做过此事，实无必要

[blanu]

@Cbdy 我还用 webpack 和 redux 给嵌入式设备（ ruff ）写过代码呢，为的是压缩体积和适配 es5，但是后端我真想不清楚 webpack 有什么用。

如果追求前后端代码统一管理，你大可以放一个仓库，后端代码不走打包直接 node 运行

[blanu]

如无必要，勿增实体

[whypool]

deno 了解一下 直接可以运行 ts

和 webpack 有什么关系

[jimliang]

https://github.com/jaredpalmer/backpack

[Sanko]

求求你别搞新东西了，我学不动了

[ilgharkus]

那我们还是让 C++统一天下吧（滑稽）

[Torpedo]

webpack，就像它的名字。给 web 打包的。
然而后端一般 js 不用打包，直接引用各种 npm 包就可以了。也不用压缩合并

[rexer]

backpack 了解一下

[djyde]

不就是同构吗

[AllOfMe]

前端用 webpack 是方便模块化压缩合并，是考虑到浏览器默认不支持运行 import require 等情况，而且图片 less 一堆东西合在一起给页面展示。
你后端用 webpack 真正解决问题的是什么？模块化有个 node 就能跑起来了，而且我认为后端更加注重的应该是 SQL 性能和并发量控制，缓存，稳定性，设计模式这些东西，而不是一会 webpack 一会又这个那个打包工具，感觉意义并不是很大。
前后端我认为是很难简单用个 webpack 就统一架构的，服务的对象都不一样，这怎么统一？而且不要希望 JS 能打遍天下无敌手(我无意黑 JS)，多尝试多体会其他语言。

----------分割------------
楼上说“求求别搞新东西了，学不动了“，我深有体会，这并不是说楼上偷懒没有学习精神，可能他就是认为”学了这个东西，没什么深度，过两三个月又被推翻，没有传统后端知识那么稳固耐用有深度“。他说的可能是后端 node，而不是前端。面对后端，其实一些公司并没有那么多机会给你尝鲜什么新工具，也不太可能会给你各类框架工具链天天重构项目，毕竟时间成本还有失败几率也是放在那里的，目的就是把事情做好。
就 node 后端而言，我更希望能有一套比较普适的体系框架(如 Java 的 Spring 框架)，能基于这个框架逐渐深入更多的工具链，让开发者能更快更好更稳定的实现接口，让 HTTP 访问速度更快，有更多类似 lodash 的 kit 方便逻辑集合运算，有 async/await 这种优化编码质量的东西。让 node.js 回归后端的本质，就是提供 HTTP 服务，并且有一套成熟完整的生态(而不是某个框架火了几个月又改超焕袋，这样真的没意思)
吐槽完毕，当然你可以说我是嘴炮

[shijingshijing]

我等着什么时候 js 能取代 VHDL 整个 CPU 出来。

[Cbdy]

@blanu 后端其实也希望使用 js 的方言（ ts-loader ），静态类型写起来舒服，所以也需要编译，然后是后端也希望改完代码能够自动重启（ nodemon ），同时，后端定义的数据结构、公共函数希望前后端都能用，webpack 正好都有这些功能

[Socket]

整天折腾些有的没的，真实的商业项目复杂度非常高不是你玩玩具搞毕业设计

[ETiV]

后端需要的应该是加密…明文的代码不好部署给第三方