如何看待技术匠心？
先说结论：在中国，对技术匠心的投入是一个存在明显 滞后性 的 长期投资，想要享受它所带来的 无限宏利，就必须承受它所带来的一段很长时间的发育期。
20世纪初期，中国互联网发展初期，这个时期有无数通过 技术 → 业务变现 的财富神话，这是宏观发展策略中的必经之路。在那个流量为王的时代里，国内的技术匠心是一条难走的道路，在一个高速发展、业务先行的互联网现状里，技术通过实现业务产品，实现公司发展，通过市值变现是工程师们追求向往、屡试不爽、奉之为神的职业道路。
在过去的20年里，工程师跟随业务发展，有流量则有资本青睐，有资本则促使更多人才涌入。于是，大量追求业务变现的 “业务专家工程师” 造就了中
✍🏼写份信 给十年前的我
本期主题是我的成长之路，虽然感觉自己还是一个小伙子，未来的路还很长，突然写起这个话题，也不知该从何讲起。
或许我应该列出一个思维图谱，推荐一些前端领域学习目录？或许应该讲讲学习前端的经历？
左思右想之后，决定回答一个问题：如果给 10 年的我写一份信，我会说些什么？
Dear Yee：
想想你现在应该还在高中，或许你还不知道你以后会叫 Yee，因为这个名字是你 3 年后才起的，记得是为了注册一个什么账号，后来工作了也容易记住，所以就这么叫了。
这份信来自 2022 年，作者就是你。
”或许你会对未来有些迷茫“，你一定以为我会这么写。但我知道，你其实一点都不迷茫，你连未来是什么都没想过
见微知著 - 一个商品选择组件
在围绕电商的开发中，都免不了围绕商品来做各类数据的打标，集成，联动。
商品选择，自然也是电商B端系统中一个最为 常见 且 通用 的交互流程之一。而在我们的系统中，商品选择这一交互动作之前大多由业务自行开发比如(营销域)，这类交互说简单也简单，但要说起体验、说起细节，复杂起来让人头皮发麻 😖
首先，说到体验，我认为我们团队不缺从零到一的人，整个阿里都不缺；我们缺的是真正投入进去做细节、打磨产品的人。
做一个组件，做一个平台，这个事情很快，但这样的成品如果给到另外一个同样水平的同学，别人会进来用吗？打磨了200个小时的组件和总耗时2小时的组件，体验是不一样的，被其他开发者的采纳率也是不一样
Vmo助你在Hooks盛行的前端年代里，找到面向对象的方式
@vmojs/decorator 一个帮助你更好，更快地创建前端数据模型的工具库，可以让你对数据处理过程更加简单，更加灵活。
关于前端使用数据模型这个话题我已经写过很多次相关的介绍，并且也确实在我们的业务项目里面实践过非常多的成功案例。经过一开始的 @vmojs/core 的继承数据模型到现在的 @vmojs/decorator 纯粹装饰器模式使用，期间有过很多次思考和打磨，接下来我想再次聊聊前端的数据模型应用和前端面向对象编程这个话题。
首先，面向对象的设计模式在一切复杂系统设计中都是被无数次验证过的成功经验，而在当代 Hooks 盛行的前端年代里，是否就代表着我们不再需要面向对象的设计
Vite + React 组件开发实践
去年，在 “阿里技术” 上发表的《这一年我的对组件的思考》 介绍了借助 TypeScript AST语法树解析，对 React 组件Props类型定义及注释提取，自动生成组件对应 截图、用法、参数说明、README、Demo 等。在社区中取得了比较好的反响，同时应用在团队中也取得了较为不错的结果，现在内部组件系统中已经累计使用该方案沉淀 1000+ 的 React组件。
之前我们是借助了 webpack + TypeScript 做了一套用于开发React组件 的 脚手架套件，当开发者要组件开发时，即可直接使用脚手架初始化对应项目结构进行开发。
虽然主路径上确实解决了组件开发中所遇到的
