琢磨一下 Monorepo
Monorepo 不是一个新话题了，这个概念最早被 Google 提出，指的是将所有项目代码(无论是前端、后端、库、工具等)集中存放到同一个仓库中，打个比喻就是把我们现在的 Java 应用、前端 JS 和组件库都放在同一个仓库中，再通过工程自动化在发布过程做分离。
发展到如今已经有非常多的公司采用这种方式进行该种方式管理代码，随后也发展出来非常多针对 Monorepo 场景下的工具链，如：Nx、Lerna、Turborepo
使用现状
Monorepo 在我们团队内部其实已经有许多项目已经在应用，为此我们还专门做过一期当前 Monorepo 解决方案的对比分享（😑 很遗憾没有做视频录制，
谈谈国内前端的三大怪啖
因为工作的原因，我和一些国外的工程师们有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。
今天聊三个事情：
* 小程序
* 微前端
* 模块加载
小程序
每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。
“ 我们为什么需要小程序？”
第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着 🤦。
于是，当我们在有一次交流中，他问出了我这个问题：我们为什么需要小程序？
说实话，我试图解释了 19
今天这个 Antd 是非换不可吗？
最近在思考一个可有可无的问题：
“我们是不是要换一个组件库？”
为什么会有这个问题？
简单同步一下背景，我效力于 Lazada 商家前端团队。从接手系统以来(近 2 年) 就一直使用着 Alibaba Fusion 这套组件库。据我所知淘系都是在使用这套组件库进行业务开发，已经有 7 ~ 10 年了吧。我们团队花了 2 年时间从 @alife/next(内部版本已经不更新) 升级到了 @alifd/next，并在此之上建立了一套前端组件库体系。将 Lazada Seller Center 改了模样，在 Fusion 的基础上建立了一套支持整个 Lazada B 端业务的设计规范和业务组件库
为什么需要前端工程师？
之前我在《如何看待技术匠心》 的文章中提到，今后的一段时间，互联网行业都将会处于一个价值回归的状态。每个在互联网行业中的职业，都比以往更加需要知道 职业和个人的核心竞争力。
* 企业为什么需要前端工程师？
* 当前国内环境下，前端工程师的核心竞争力是什么？
* 如何创造更多前端岗位？
这几个问题我思考了很久，其背后所代表的目的是一样的。前端开发者，如何能够在这个洪流涌动的时代中更有竞争力。
当然，本文所提到的观点不一定正确，纯粹个人见解。
从何而来？
搞清楚这个问题之前，不如来看看早些时候，这个职业是从何而来？
其实早些年是没有前端工程师这个职业的，和这个职业最相关的应该是网页
Formily 2.0 深度实践
Formily 作为阿里巴巴旗下开源的一套非常火热的表单解决方案，目前已有 7.8k Star，针对表单这一领域场景，以非常完整、高效、先进的方式解决了开发表单过程中能遇到的几乎全部问题。
面向企业级表单的专业解决方案，专业！
Formily 2.0 正式发布至今已有 7 个月，作为 Contributor 之一，我将以一个企业级复杂度的表单——商品发布，作为应用场景做一个实践总结。
响应模型
初学者都说 Formily 的学习成本高、理解不了，如果说理解 Formily 最难理解的部分我想应该是 表单数据模型 和 响应机制 的两大问题，而这也恰好是 Formily 的精髓所在。
历史
引入Vite = 多一个月
Vite 在21 ~ 22年在前端界可谓风生水起，颠覆传统也不为过。
20年4月，尤雨溪发推说：“我感觉我再也回不到Webpack了”，Webpack作者用中文直呼：大哥… 在22年的今天，我们再看这个Twitter是不是感觉这声 “大哥” 喊得歇斯底里 😂。
到底Vite有什么魔力，可以让全世界的前端开发者们争先恐后的投入怀抱呢？
如果只说一个特点，那就是 “快”，不是传统概念的那种快个百分之多少，是tm的几十倍几百倍的快！
什么概念呢，Vite 可以让你的项目甭管多大，1秒内启动；热更新更是快的离谱，几乎是保存的一瞬间就看到效果。说实话，第一次尝试的时候，我惊呆了，我从来没见过这
端上的插件设计
在设计一套客户端软件，尤其是基础模块时，我们通常会考虑到扩展性。而插件机制是一套非常好的解决思路，可以让其他开发者按照我们预期的路径进行功能扩展。
那么在软件初期，我们要如何设计一套较为完善的插件模式呢？本篇将会从我个人对插件的懵懂认知开始，逐步介绍如何形成一个较为完善的解决思路。
怎么理解插件？
Plugin（Plug-in, addin, add-in, addon 或 add-on）是一种计算机应用程序，它和主应用程序（host application）互相交互，以提供特定的功能。
首先，我们经常会在各种软件里面看到 "Plugins" 等关键字，那怎么理解这个词呢？
在我刚接触
Vmo助你在Hooks盛行的前端年代里，找到面向对象的方式
@vmojs/decorator 一个帮助你更好，更快地创建前端数据模型的工具库，可以让你对数据处理过程更加简单，更加灵活。
关于前端使用数据模型这个话题我已经写过很多次相关的介绍，并且也确实在我们的业务项目里面实践过非常多的成功案例。经过一开始的 @vmojs/core 的继承数据模型到现在的 @vmojs/decorator 纯粹装饰器模式使用，期间有过很多次思考和打磨，接下来我想再次聊聊前端的数据模型应用和前端面向对象编程这个话题。
首先，面向对象的设计模式在一切复杂系统设计中都是被无数次验证过的成功经验，而在当代 Hooks 盛行的前端年代里，是否就代表着我们不再需要面向对象的设计
Vite + React 组件开发实践
去年，在 “阿里技术” 上发表的《这一年我的对组件的思考》 介绍了借助 TypeScript AST语法树解析，对 React 组件Props类型定义及注释提取，自动生成组件对应 截图、用法、参数说明、README、Demo 等。在社区中取得了比较好的反响，同时应用在团队中也取得了较为不错的结果，现在内部组件系统中已经累计使用该方案沉淀 1000+ 的 React组件。
之前我们是借助了 webpack + TypeScript 做了一套用于开发React组件 的 脚手架套件，当开发者要组件开发时，即可直接使用脚手架初始化对应项目结构进行开发。
虽然主路径上确实解决了组件开发中所遇到的
数据模型在电商前端领域的应用
前言
Vmo 是我在 18 年发布的一个工具库，用于快速创建数据模型，当时我写了一篇文章：Vmo 前端数据模型设计
在社区得到过一段时间的关注，当时我还在 xx 兔，从事三维装修相关的项目。在图形学的背景基础及海量复杂的数据的情况下，自然而然在前端则会衍生出一种数据处理、解析、消费的技术方案，也种下了我对数据模型概念的种子。
简单举个例子：
需要解析一个三维装修的房子的数据会有哪些呢？房子（Hourse）,楼层（Layer）,房间（Room）,墙体（Wall）,墙面（WallSpace）,墙角（Corner）,吊顶（Ceiling），踢脚线（Skirting），地（Floor，带厚度），
