根据 Atwood 定律，大部分后端场景迟早也是 js 的天下。众所周知，ts 写起来是很爽的，所以如果前后端都是用 ts 写（比如前端 react+tsx，后端 koa ），一个普通的 webapp，完全可以前后端都通过 webpack 编译运行，开发的时候也可以只用一个类似 webpack-serve 这样的工具，代替原先的前后端两套开发架子（比如前端 webpack-serve，后端 nodemon ）。
这样在同一个代码仓库开发，一个功能从前写到后，同一套数据结构从前用到后，岂不是效率很高？
 |
blanuAug 4, 2018 via iPhone
1
关 webpack 鸟事？后端是可以用 webpack 打包运行，有必要？直接上 node lts 就有 es6 了，钓鱼贴吧。
|
 |
molvqingtaiAug 4, 2018
2
相信我大前端有朝一日会一统江湖！
|
 |
lihongjie0209Aug 4, 2018
4
笑笑不说话
|
 |
mhycyAug 4, 2018
5
打包意义在哪里？
|
 |
schemesAlotAug 4, 2018 via Android
6
做过此事，实无必要
|
|
blanuAug 4, 2018 via iPhone
7
@Cbdy 我还用 webpack 和 redux 给嵌入式设备（ ruff ）写过代码呢，为的是压缩体积和适配 es5，但是后端我真想不清楚 webpack 有什么用。
如果追求前后端代码统一管理，你大可以放一个仓库，后端代码不走打包直接 node 运行 |
|
blanuAug 4, 2018 via iPhone
8
如无必要，勿增实体
|
 |
whypoolAug 4, 2018
9
deno 了解一下 直接可以运行 ts
和 webpack 有什么关系 |
 |
10
|
 |
11
求求你别搞新东西了，我学不动了
|
 |
12
那我们还是让 C++统一天下吧（滑稽）
|
 |
TorpedoAug 4, 2018 via Android
13
webpack，就像它的名字。给 web 打包的。
然而后端一般 js 不用打包，直接引用各种 npm 包就可以了。也不用压缩合并 |
 |
14
backpack 了解一下
|
 |
djydeAug 5, 2018
15
不就是同构吗
|
 |
16
前端用 webpack 是方便模块化压缩合并，是考虑到浏览器默认不支持运行 import require 等情况，而且图片 less 一堆东西合在一起给页面展示。
你后端用 webpack 真正解决问题的是什么？模块化有个 node 就能跑起来了，而且我认为后端更加注重的应该是 SQL 性能和并发量控制，缓存，稳定性，设计模式这些东西，而不是一会 webpack 一会又这个那个打包工具，感觉意义并不是很大。 前后端我认为是很难简单用个 webpack 就统一架构的，服务的对象都不一样，这怎么统一？而且不要希望 JS 能打遍天下无敌手(我无意黑 JS)，多尝试多体会其他语言。 ----------分割------------ 楼上说“求求别搞新东西了，学不动了“，我深有体会，这并不是说楼上偷懒没有学习精神，可能他就是认为”学了这个东西，没什么深度，过两三个月又被推翻，没有传统后端知识那么稳固耐用有深度“。他说的可能是后端 node，而不是前端。面对后端，其实一些公司并没有那么多机会给你尝鲜什么新工具，也不太可能会给你各类框架工具链天天重构项目，毕竟时间成本还有失败几率也是放在那里的，目的就是把事情做好。 就 node 后端而言，我更希望能有一套比较普适的体系框架(如 Java 的 Spring 框架)，能基于这个框架逐渐深入更多的工具链，让开发者能更快更好更稳定的实现接口，让 HTTP 访问速度更快，有更多类似 lodash 的 kit 方便逻辑集合运算，有 async/await 这种优化编码质量的东西。让 node.js 回归后端的本质，就是提供 HTTP 服务，并且有一套成熟完整的生态(而不是某个框架火了几个月又改超焕袋，这样真的没意思) 吐槽完毕，当然你可以说我是嘴炮 |
 |
shijingshijingAug 5, 2018
17
我等着什么时候 js 能取代 VHDL 整个 CPU 出来。
|
 |
18
@blanu 后端其实也希望使用 js 的方言（ ts-loader ），静态类型写起来舒服，所以也需要编译，然后是后端也希望改完代码能够自动重启（ nodemon ），同时，后端定义的数据结构、公共函数希望前后端都能用，webpack 正好都有这些功能
|
 |
SocketAug 5, 2018
19
整天折腾些有的没的，真实的商业项目复杂度非常高不是你玩玩具搞毕业设计
|
 |
ETiVAug 5, 2018
20
后端需要的应该是加密…明文的代码不好部署给第三方
|
|
21
@AllOfMe 其实我的本职工作是 Java 后端，不过也用过 node 写过一些东西，Java 生态确实好，node 的生态乱糟糟的，不过 node 有他得天独厚的优势：JavaScript。我感觉 node 的技术债已经蛮严重了，起码 gyp 实在太难用。不过真的很好玩
|
 |
24
根据 Atwood 定律，大部分后端场景迟早也是 js 的天下。
233333 |
 |
SparetireAug 5, 2018 via Android
25
这勃式提问的风格真的不是来黑的？
|
 |
RqPS6rhmP3Nyn3TmAug 5, 2018 via iPhone
27
前端用什么 js，迟早都是 C(WebAssembly)的天下
（狗头 |
 |
laxenadeAug 5, 2018 via Android
28
那不就是 meteor 了吗
|
 |
windfarerAug 5, 2018 via Android
30
你说的对
|
 |
31
就凭 js 的残废语言还想做企业级业务逻辑啊？ undefined：）
|
 |
temp178Aug 5, 2018 via Android
32
得了吧，可行，有用，但想一统江湖，妄想。后端不是运行在统一得浏览器环境，不同应用对各方各面都有不同要求。那么多语言那么多框架百花争妍多年都没出来个大统一，JS 显然基本不可能
|
 |
janxinAug 5, 2018
33
是是是，JS 秒天秒地秒空气好了吧
问过 Java 程序员同意了吗？ XD |
 |
vindurrielAug 5, 2018 via iPhone
34
前后端统一这个野心并不算大 看看 GraphQL 人家要干掉后端
|
 |
owenliangAug 5, 2018 via Android
35
写前端的天天惦记写后端，这样很不专一啊
|
 |
yangxin0Aug 5, 2018 via iPhone
36
你拿 js 写个数据库试一试？
|
 |
37
前端轮子一个接一个，没见有多少能上生产环境的😂
|
 |
38
真给前端脸了？在自己的领域内你咋造轮子都没人理，作为后端开发来说，你们那些破玩意儿自己留着玩就行，别出来霍霍了好么 :xd
   |
 |
xiaojunjorAug 5, 2018
39
大部分后端场景迟早也是 js 的天下
？？？ |
 |
40
拿了锤子，满世界都是钉子
|
 |
jrtzxh020Aug 5, 2018 via iPhone
41
ssr 了解一下。。
|
 |
deepkolosAug 5, 2018
42
目测前后端对接接口会十分方便
|
 |
43
这帖子画风跟那个前端算程序员吗的贴子完全不一样嘛
暴躁后端只在这里出现吗 |
 |
44
前面有人在提 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 语言的设计, 在开发环境和在生成环境, 由于开发环境代码包含标准库, 还有一些高阶的抽象, 实际上性能是有折扣的, 所以就需要建构过程同时做一些优化. 不过由于我的项目太小, 实际上也看不明显区别. |
 |
zhzerAug 5, 2018
45
要打包就打包啊，后端又不要你编译啥，要一起打包不就一行代码的事？
|
 |
sagaxuAug 5, 2018 via Android
46
因为后端不需要 js
|
 |
revolAug 5, 2018
47
其实后端（些其他语言的）根本看不起 JS 和 JS 的工具链好吧。。。连自举都做不到，别的就不谈了
|
|
jiyinyiyongAug 5, 2018
48
@kevinhwang 帽子扣大了. 残废在哪倒是说说看
|
|
jiyinyiyongAug 5, 2018
49
@revol 单纯说自举, JavaScript 明明是能做到的 https://github.com/jterrace/js.js
|
 |
fulvazAug 5, 2018
51
除了 ts->js 外, 其实没啥必要呀, 如果只是为了这个, github 上全是 boilerplate
webpack 本质是对模块进行处理的工具, 但是 node 自带模块化. 你说 ESModule 的话, 我理解可能比较肤浅, 我的理解是 ESM 最大的作用是结合 TreeShake 去除没使用的依赖, 对后端来说不存在包大小的问题. ---- 语言根本就不是个问题, 框架也是, 语言和框架脱离场景都是耍流氓, 咋搞得十字军东征一样乌烟瘴气. |
 |
guolaopiAug 5, 2018
52
日常撕。。。
PHP：别说了 JS 是世界上最好的语言 |
 |
gluesAug 5, 2018
53
前端造了这么多轮子，对于 99% 的项目来说，并没有比当年 jQuery 提高多少开发效率
|
 |
KuroNekoFanAug 5, 2018 via iPhone
54
看来国内做“纯后端”的开发者真的很看不起 js ……话说很好奇国外 nodejs 应用场景多不多呢，看到文章讲还是很广泛的
|
 |
hlAug 5, 2018
55
你还想干啥 😂😂😂
|
 |
pony279Aug 5, 2018
56
如果你真以为后端开发面临的主要困难是编程语言门槛的话
可以马上开始自己造轮子啊，当下可是千载难逢的好机会 |
 |
CasualYoursAug 5, 2018
57
给我们留口饭吃吧。
|
 |
PharielAug 5, 2018 via iPhone
58
大部分后端场景迟早也是 js 的天下
高级黑？ |
 |
murmurAug 5, 2018
59
楼主是认为后端 webpack 能解决你产品的加密问题么
|
 |
zhangyu911013Aug 5, 2018 via Android
60
wepack 主要是打包工具，后端不用打包，而且现在 node 用 weback 有很多坑，踩过一些
|
|
zhzerAug 5, 2018
61
大家应该这样想，都用 ts 写前后端，是不是意味着前后端合并？那不是开了历史的倒车吗？
真相就是，其实楼主是高端黑，恶政隐（告辞 |
 |
simonguoAug 5, 2018
63
在开发过程中，为什么要前后端分离？
|
 |
tt67wqAug 6, 2018
65
前端都这么跳了现在？
|
 |
sdrzlyzAug 6, 2018 via Android
66
不需要 pack 啊。。。而且，为啥要 js/ts 搞后段？仅仅因为前端也用？告辞告辞
|
 |
tushankakaAug 6, 2018 via Android
67
后端可以用 node，js，但 webpack 就没必要了。没必要黑 js 的。
|
 |
allgyAug 6, 2018
68
兄弟你怕是对 webpack 有误解
|
 |
xuecatAug 6, 2018
69
同样，求求你们别更新了，劳资学不动了。
滑稽。。。 |
 |
beny2morAug 6, 2018
70
对于一些 1m 大小差距就会影响性能，并且支持 js 的环境.... 可能有这种东西吧
|
 |
jerry4718Aug 8, 2018
71
整个后端，build 成一行 js 代码，顺便 uglify 一下，多捞啊
|
 |
chai2010Aug 20, 2018
72
Atwood 定律已经完成任务了。以后是 Ending 定律："Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually."
Ending 定律也称为终结者定律，它是 Ending 在 2016 年 Emscripten 技术交流会上给出的断言：所有可以用 WebAssembly 实现的终将会用 WebAssembly 实现。 |
2
Select Language