为什么不把后端也交给 webpack？ Nodejs 角度的思考
为什么不把后端也交给 webpack？ Nodejs 角度的思考
根据 Atwood 定律，大部分后端场景迟早也是 js 的天下。众所周知，ts 写起来是很爽的，所以如果前后端都是用 ts 写（比如前端 react+tsx，后端 koa ），一个普通的 webapp，完全可以前后端都通过 webpack 编译运行，开发的时候也可以只用一个类似 webpack-serve 这样的工具，代替原先的前后端两套开发架子（比如前端 webpack-serve，后端 nodemon ）。
这样在同一个代码仓库开发，一个功能从前写到后，同一套数据结构从前用到后，岂不是效率很高？
我还用 webpack 和 redux 给嵌入式设备（ ruff ）写过代码呢，为的是压缩体积和适配 es5，但是后端我真想不清楚 webpack 有什么用。
如果追求前后端代码统一管理，你大可以放一个仓库，后端代码不走打包直接 node 运行
前端用 webpack 是方便模块化压缩合并，是考虑到浏览器默认不支持运行 import require 等情况，而且图片 less 一堆东西合在一起给页面展示。
你后端用 webpack 真正解决问题的是什么？模块化有个 node 就能跑起来了，而且我认为后端更加注重的应该是 SQL 性能和并发量控制，缓存，稳定性，设计模式这些东西，而不是一会 webpack 一会又这个那个打包工具，感觉意义并不是很大。
前后端我认为是很难简单用个 webpack 就统一架构的，服务的对象都不一样，这怎么统一？而且不要希望 JS 能打遍天下无敌手(我无意黑 JS)，多尝试多体会其他语言。
----------分割------------
楼上说“求求别搞新东西了，学不动了“，我深有体会，这并不是说楼上偷懒没有学习精神，可能他就是认为”学了这个东西，没什么深度，过两三个月又被推翻，没有传统后端知识那么稳固耐用有深度“。他说的可能是后端 node，而不是前端。面对后端，其实一些公司并没有那么多机会给你尝鲜什么新工具，也不太可能会给你各类框架工具链天天重构项目，毕竟时间成本还有失败几率也是放在那里的，目的就是把事情做好。
就 node 后端而言，我更希望能有一套比较普适的体系框架(如 Java 的 Spring 框架)，能基于这个框架逐渐深入更多的工具链，让开发者能更快更好更稳定的实现接口，让 HTTP 访问速度更快，有更多类似 lodash 的 kit 方便逻辑集合运算，有 async/await 这种优化编码质量的东西。让 node.js 回归后端的本质，就是提供 HTTP 服务，并且有一套成熟完整的生态(而不是某个框架火了几个月又改超焕袋，这样真的没意思)
吐槽完毕，当然你可以说我是嘴炮
后端其实也希望使用 js 的方言（ ts-loader ），静态类型写起来舒服，所以也需要编译，然后是后端也希望改完代码能够自动重启（ nodemon ），同时，后端定义的数据结构、公共函数希望前后端都能用，webpack 正好都有这些功能
其实我的本职工作是 Java 后端，不过也用过 node 写过一些东西，Java 生态确实好，node 的生态乱糟糟的，不过 node 有他得天独厚的优势：JavaScript。我感觉 node 的技术债已经蛮严重了，起码 gyp 实在太难用。不过真的很好玩
得了吧，可行，有用，但想一统江湖，妄想。后端不是运行在统一得浏览器环境，不同应用对各方各面都有不同要求。那么多语言那么多框架百花争妍多年都没出来个大统一，JS 显然基本不可能
前面有人在提 WebAssembly, 我想了下大概还真的可能以后基于 Node API 开发后端要用 Webpack.
现在我们用 Node.js 开发直接发布源码, 原因在于 JavaScript 是动态语言, 而且我们不像一些苛刻的场景那样要求在服务端运行时候快速启动. 如果说这些条件改变了呢, 后端代码借助 WebAssembly 做多语言的混合开发了, 代码部署的时候为了安全或者为了快速启动不建议分发源码, 而是基于二进制的 WASM 文件?
按这样想, 以后用 Webpack 建构后端代码很正常的事情, 就像 Java 程序编译上线不是很正常嘛. 当然这种事情不是一天两天的.
至于说复用代码, 编译发布到服务器. 我现在用 ClojureScript 开发就是这样, 一套代码全都是 ClojureScript 前端浏览器, 后端 Node.js , 其中的 ClojureScript 部分完全可以复用的. 完成之后通过 shadow-cljs 分别给前端后端代码打包, 上传到 CDN 和服务器上更新服务. 阅读代码 https://github.com/Cumulo/cumulo-workflow .
至于标题的为什么现在不搞? 目前基于 JavaScript 开发的话没有切实的需求啊, 大家都不想把事情搞复杂, 直接上传整个项目, 直接整个重启, 不觉得有问题, 当然是怎么维护简单怎么来的.
你可以把我的 ClojureScript 项目跑起来看看, 因为 ClojureScript 语言的设计, 在开发环境和在生成环境, 由于开发环境代码包含标准库, 还有一些高阶的抽象, 实际上性能是有折扣的, 所以就需要建构过程同时做一些优化. 不过由于我的项目太小, 实际上也看不明显区别.
除了 ts->js 外, 其实没啥必要呀, 如果只是为了这个, github 上全是 boilerplate
webpack 本质是对模块进行处理的工具, 但是 node 自带模块化.
你说 ESModule 的话, 我理解可能比较肤浅, 我的理解是 ESM 最大的作用是结合 TreeShake 去除没使用的依赖, 对后端来说不存在包大小的问题.
----
语言根本就不是个问题, 框架也是, 语言和框架脱离场景都是耍流氓, 咋搞得十字军东征一样乌烟瘴气.
Atwood 定律已经完成任务了。以后是 Ending 定律："Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually."
Ending 定律也称为终结者定律，它是 Ending 在 2016 年 Emscripten 技术交流会上给出的断言：所有可以用 WebAssembly 实现的终将会用 WebAssembly 实现。
在探讨为什么不将后端也交给Webpack处理时，我们需要从Node.js的角度进行深入思考。
首先，Webpack是一个前端模块打包工具，它擅长处理静态资源，如JavaScript、CSS和图片等，通过加载器和插件机制，可以高效地打包和优化这些资源，以提升前端性能。
然而，后端开发通常涉及更多复杂的逻辑，如数据库操作、网络通信、文件I/O等，这些任务的处理方式与前端资源打包存在显著差异。Node.js作为一个强大的后端运行时环境，提供了丰富的API来处理这些后端任务，如fs模块用于文件系统操作，http模块用于网络通信等。
此外，后端代码通常需要与数据库和其他服务进行交互，这要求后端框架能够提供强大的异步处理能力、错误处理机制以及高并发支持。而Webpack并不具备这些后端开发所需的关键特性。
以下是一个简单的Node.js后端示例，展示了如何使用Express框架处理HTTP请求：
const express = require('express');
const app = express();
app.get('/', (req, res) => {
res.send('Hello, World!');
});
app.listen(3000, () => {
console.log('Server is running on port 3000');
});
综上所述，由于Webpack和Node.js在后端开发中的定位和功能差异，我们不能简单地将后端也交给Webpack处理。Node.js更适合作为后端运行时环境，而Webpack则专注于前端资源的打包和优化。
