这个有道理的，看起来目前的前端团队好像分成了两波：

一波人做多端打通，一组前端能够同时产出多个平台的客户端，比如桌面用 electron，移动用 React Native。

一波人做前后打通，前端同时负责 BFF 层和前端，也就是所谓的大前端，这种组里的后端就彻底下沉到基础组件去了。

国内组件库还是盛行于中后台网站啦，比如最火的 antd、element ui，而更具 2c 产品气质的 Material UI 反而国内没什么人用。

我以为可能是国内好多中后台开发的产品经理对于组件有着毫不节制的复杂需求 不用组件库就做不完了

人家上来都是历史分析 + 用户群体分析 + 原因，你上来就“不是给前端用的，前端觉得难是因为觉得后端难”你这不武断、不拉踩吗？前端现在很多都要写 BFF 层的好吧。

你这话说的 。。。毫无道理、武断、不客观，充满了主观臆断，无理无据。还顺带踩了一脚前端同学，透露出一股莫须有的“全栈优越”。

JetBrains 那个 ssh beta 版本远程是真的挺不好用的

用原生 DOM 手写也能前后端分离呀，分离也不依靠框架。框架提供的只是声明式视图能力而已。

其实就是现在的新时代的前端，没怎么深入了解过 DOM 和 HTML 之类的，All in JavaScript 解决问题。但 Hotwire 这一套感觉和这些知识结合的很紧，所以都不太适应，如果是在 DOM 时代的前端可能觉得没啥。

Nextjs 如果只是使用的话，基本无感吧，最大的区别就是不能随便直接在文件里面访问浏览器的 API 了，必须在页面渲染了之后才能调用，比如在 useEffect(() => {}, []) 里面，很多事情 Next 都帮我们做了

我觉得是国内的一些网站，特别是中后台，对复杂的前端组件无节制的依赖，导致最后你如果不用 React / Vue 这种声明式的库，就会特别难做，一个组件能开发你小半个月，还一堆 bug

可能是 turbo 和 stimulus 有太多和 DOM 还有 HTML 相关的东西，但现在的前端框架其实完全不 Care DOM、几乎不会 care HTML。就不太熟悉这俩。

不觉得老古董，我看的是 Spring 官方的文档，https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#spring-core。因为觉得 Springboot 太重了，所以看了眼最基本的 Spring，放眼望去一堆 xml

像 C 和 Go 也不存在注解这种东西，似乎也没有发展出 xml 生态

依我看到的：是的。

也许新的不是，但以前的是的，特别是 Springboot 还没出来的时候。

我就想了解下为什么，因为别的语言生态好像没有这么玩的。结果你就在这装逼的甩一句：“先问是不是，再问为什么”，就离谱。。。

那以前是为啥呢

离谱啊

贵司不是刚签了自愿降薪协议啥的吗。。。

国内的共享电动车好像基本全都歇菜了

Go 现在的定位本身就是基础设施层，这个排名也算正常

这个我最近正好研究了一下，这个和内存逃逸有关系。

首先明确一点：在函数内创建的变量在栈上。

1. 如果函数返回一个结构体，那么就会拷贝一份该结构体，然后把函数内的结构体销毁掉。
2. 如果返回的是指针或者 interface{} 类型，那么指针指向的地址所存放的变量就不可以再储存在栈上了，Go 就会帮助他逃逸到堆上。

两种方法比较之下，可以得到结论：

1. 如果你的对象很大，拷贝对象需要花费太多资源，那么就可以选择返回指针。
2. 如果对象不大，那么返回结构体是一个比较好的选择，因为一旦内存逃逸到堆上，就会增大 GC 的压力。

最近两年有个叫 Rust 游戏特别火

再来张过去五年全球的

你这 Rust 都没有选 Program Language，你选了就会发现查了五六倍好吧

流行度国外不知道，但是国内 Go 肯定是碾压的。。。看看招聘的岗位就知道了

原来 module include 的时候可以声明 private，我还以为不可以

我比较好奇，为什么 POST 请求更安全

没用过 XPS，Windows 旗舰只用过 Surface Pro 和 Surface Book，Pro 感觉一般，Book 感觉不错

16 寸 MBP 应该是目前外放素质最好的笔记本之一了

或者说影响不大

像 Nodejs 的 lock 文件就不会出现这种问题

项目工程文件呢，存在 Windows 还是 wsl