HTML files + JQuery -> SPA -> Angular/React/Vue
-> 哎呀没有 SSR 来做好 delivery HTML files (e.g. for SEO)
-> 新造"前端框架"来解决传统 file delivery 问题
-> Next.js (真的能解决吗? 不该自己控制 HTML files 生成和发布到 CDN 吗...?)

作为后端, 你可以遇见, 这类"新的前端知识"会一直增长下去的...
如果不是"面向前端主流编程", 比如要找前端工作的,
建议保持在类 HTML files + JQuery 的设计上, 相对稳定. 可以用 alpinejs.dev + HTML files

从 k8s 开始宣传画的饼, k8s 自己的复杂度, k8s 的运行效率.
作为 dev, 对于其他 dev, 我想说: k8s 真的不行, 研究 k8s 没有性价比, 浪费时间. 省省精力研究点有用的.
多的不说了, 最后说一句: 不浪费智力, 去研究没有性价比的技术, 是 dev 需要的智慧.

@sampeng 一层层的 pull docker image 的 binary data 应该是最慢的部分, 回到我 19 楼说的基本问题上，这个在 k8s+docker 生态里是难以解决的. 另外, 你说的安全部分也可以搞得特别慢, 如果公司在这方面龟毛的话, 龟毛的安全要+k8s 那就是更加的慢.

@sampeng
刚刚问了负责的 DevOps, 说优化到 6 分钟了, 他们还在搞. 我作为 dev 不想搞 ops 事情, 只是用起来偶尔非常闹心...
按照你提前 3~5 分钟的说法, 所以最后能优化到 3 分钟上下. 但是我还是觉得好慢. 因为我们始终是在讨论分钟级别的延迟, 实际上, 广义上看, 如果底层实现够优化的话, 应该是秒级别的事情. 不知道底层在干啥, 需要达到分钟级别... @_@

@sampeng 我说的是 EC2 VM 起来之后, register 进入 EKS cluster 的时间. 不是 k8s replica scale 的时间(这个很快). 你决赛的瞬时流量不应该依赖这个, 因为启动 VM(甚至是启动物理机器)的是瓶颈. 你瞬时的 busty 流量要抗住的话，得实现至少把底下 VM(or 动物理机器)预先启动起来. 当然, VM register 进入一个 computing cluster 的时间确实应该很快. 不该是 5 分钟，或者 10 分钟这么慢. 所以我说 EKS k8s 慢.

@huangzongzhuan
Google 看着其它云厂商赚钱太眼红了, 就按照自家的 Borg, 做了个劣质简化的版本: Kubernetes
然后投入大量资源宣发 k8s. Amazon 一看, 开源的啊, 快加入我家 AWS 产品线: 结果 ECS, EKS 就出来了.
然后 AWS 用 k8s 继续挣钱，还省去了宣发费用. Google: ... ...

@kennylam777 你到底看懂我的回帖没...
什么叫我只考虑开发的日常, 我说的是 k8s EKS 的 scale 竟这么慢, 竟然影响到了实际业务 -- 竟然需要额外优化!? 我在硅谷这边工作, 不只一个 DevOps 组跟我说过这个问题, 也许是我认识的 DevOps 都很烂. 就你司 DevOps 厉害...

然后, 我说的根本问题 1 2, 你是不是一个没看懂.
"甚麼自己寫 Cluster manager 的出了 AWS 也是一團廢物" -- 做个最简单的 cluster manager 跟 AWS 实现屁关系没有, 只要能通过 VM image 构建 VM 就行. 用不用 AWS/Azure 都没关系. 只能用现成的"主流"工具的人, 是不是完全理解不了...
最简单 stateless computing cluster managing 是 k8s 最常用使用场景, 这个都做不好(竟然需要额外优化!?), 更复杂场景还需要看吗? 地基就是歪的. 你可以在上面加一堆更复杂更全面的功能，但是不能掩盖楼是歪的. 还"处理 BGP", 简单场景都这么费劲... k8s networking 部分几年前我看过一下, shit show 的复杂程度. 费老大劲糊上一堆 legacy 的 protocols... 我怀疑他们设计这块的人没有认真理解最近这些年 SDN(Software Defined Network)的主要成果. 至于你 EBS, NFS 我是看不懂你想说啥. 堆 GPU 搞 LLM 的话, 有些团队/组当然不是用 k8s 的!

对于那种只能用 k8s 的团队/组，我是会用 k8s 的跟他们干活的，但是破玩意儿真的不用浪费时间研究.
对于不用 k8s 的团队/组, 我也很乐意使用/改进他们自己的 infra.
在工作中, 上面两种情况都常见. 不要以为全世界都只会用 k8s @_@

注册 5 分钟也够慢的了... 启动个 EC2 VM 都只需要 1~2 分钟. 这个只能是 k8s 的设计问题, 没得救了.
为啥注册个 VM 还需要额外再加个"ECI 虚拟节点"来加速...

docker+k8s 我上班天天用，自己做项目是绝对不会用的.
我只简单说下这套东西为啥是复杂的工业垃圾:

1. 各个新老语言的 package/dependency/build 工具进步了, 可以在 dependency hash 层面实现 reproducible build. 根
本不需要用 docker 做那种非常重非常笨非常慢的 binary 级别的 reproducible build.

2. docker 本来应该被淘汰的, k8s 基于 docker 所以会继承 docker 的低效, 但是没想到会这么低效. 如果只是实现 stateless computing cluster 这么简单的东西, 你自己写个 cluster manager 就实现了. 那么对于一个 running cluster, new VM registering 就应该是秒级的速度 -- 我 10 年前就写过这样的东西, 在 AWS 上管理几十个 EC2 VMs. 不要轻易说 "那就相当于你实现了一个 k8s", k8s 的情况属于: 拥有大量宣发资源的人, 忽悠出的"主流"技术栈, 最终点错了科技树的情况.

docker + k8s 这帮人, 设计这么一大坨复杂玩意, 面相 yaml 编程, 折腾半天, 只能做个 stateless computing cluster. scale 的速度居然还奇慢... 上周公司开会，讨论说往 AWS EKS cluster 加个 EC2 node 要 10 分钟以上, 我都听懵逼了, 我说 EC2 instance 启动瓶颈不是 2 分钟上下吗? DevOps 说是的, 但是 EC2 node 起来后, 往 EKS cluster 里注册非常慢. 我上网搜了下, 确实要加个 EC2 node 要 10 分钟上下... 好烂, 我真的惊了...
所以工作需要的话, 会用常用命令行就行. "研究" 这坨"主流"并"流行"的垃圾, 属于浪费时间.

你们抱怨归抱怨, 但是用微服务的组, 本地项目跑不起来的情况很多...

确实尴尬... 现在有 ChatGPT/LLM 了, 编写/优化 SQL 的这类知识更不值钱了, 写点 Prompt 就能生成.
你这个在 SQL 上再做个 DSL, 是要再去精调 LLM 来生成你的 DLS 吗? 多搞一层, 不如直接让 LLM 生成 SQL...

SQL 都够蹩脚了 ... 能这么流行 (滥用), 本来就是个历史遗留问题
这个是在 SQL 上做个新的 DSL, 然后编译成一坨(复杂并可能低效的)SQL, 再送到 DB engine 执行么...

回归不过时的 JQuery + HTML 风格
https://alpinejs.dev/
https://htmx.org/

确实只需要一种语言, 但是没有哪个救世主造出来
所以现在只能按应用领域来选择语言

从 卖家秀 成 买家秀

不写论文的话, 真是不想折腾这垃圾东西

编程用的话, 买个低配 Mac mini, 16G 内存, 直接买就是 $800 上下, 等个折扣还能更便宜.
在家办公，就改省下钱来买个好的大显示器, 超宽屏之类.
程序员重视 M3 CPU 干啥? 在本地机器上跑啥需要 M3 CPU 的...

有没有一种可能, 其实是做得太多, 想得太少...
我不是针对 xx.js, 我是说前端框架的设计都是... ??

又来了... 你们娱乐圈活儿就是多