谈谈国内前端的三大怪啖
因为工作的原因，我和一些国外的工程师们有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。
今天聊三个事情：
* 小程序
* 微前端
* 模块加载
小程序
每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。
“ 我们为什么需要小程序？”
第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着 🤦。
于是，当我们在有一次交流中，他问出了我这个问题：我们为什么需要小程序？
说实话，我试图解释了 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 是我在 18 年发布的一个工具库，用于快速创建数据模型，当时我写了一篇文章：Vmo 前端数据模型设计
在社区得到过一段时间的关注，当时我还在 xx 兔，从事三维装修相关的项目。在图形学的背景基础及海量复杂的数据的情况下，自然而然在前端则会衍生出一种数据处理、解析、消费的技术方案，也种下了我对数据模型概念的种子。
简单举个例子：
需要解析一个三维装修的房子的数据会有哪些呢？房子（Hourse）,楼层（Layer）,房间（Room）,墙体（Wall）,墙面（WallSpace）,墙角（Corner）,吊顶（Ceiling），踢脚线（Skirting），地（Floor，带厚度），
如何接"地气"的接入微前端
前言
微前端，这个概念已经在国内不止一次的登上各大热门话题，它所解决的问题也很明显，这几个微前端所提到的痛点在我们团队所维护的项目中也是非常凸显。
但我始终认为，一个新的技术、浪潮，每每被讨论最热门的一定是他背后所代表的杰出思考。
“微前端就是…xx 框架，xx 技术”
这种话就有点把这种杰出的思路说的局限了，我只能认为他是外行人，来蹭这个词的热度。
在我所负责的项目和团队中，已经有非常大的存量技术栈和页面已经在线上运行，任何迭代升级都必须要保证小心翼翼，万无一失。
可以说，从一定程度来讲，微前端所带来的这些好处是从用户体验和技术维护方面的，对业务的价值并不能量化体现，落地这项技术秉
为你的JavaScript库赋予插件能力
前言
最近在做一个中台框架的设计开发，在做了主框架的基础能力后，思考在框架落实真实业务需求过程中，需要对主框架功能有非常多的定制化内容存在。如果在主体框架中做了哪怕一点业务改动，都可能会对后面的拓展性及灵活性有所限制。
所以为了让主体框架做的更加灵活、扩展性更搞，在主框架有了基础能力后，就不再对主框架做任何非主框架能力的业务功能开发。
要为主框架不断的”开槽”
其实在很多前端库中都有类似的设计，才能够让更多的开发者参与进来，完成各种各样的社区驱动开发。比如：Webpack，Babel，Hexo，VuePress等。
那么如何为自己的项目开槽，做插件呢？
调研
在了解了很多插件的项目源
JavaScript 常见设计模式
前言
设计模式，这一话题一直都是程序员谈论的”高端”话题之一。许多程序员从设计模式中学到了设计软件的灵感和解决方案。
有人认为设计模式只在 C++或者 Java 中有用武之地，JavaScript 这种动态语言根本就没有设计模式一说。
那么，什么是设计模式？
设计模式：在面向对象软件设计过程中，针对特定问题的简洁而优雅的解决方案。
通俗一点讲，设计模式就是在某种场合下对某个问题的一种解决方案。如果再通俗一点说，设计模式就是给面向对象软件开发中的一些好的方法，抽象、总结、整理后取了个漂亮，专业的名字
其实很多设计模式在我们日常的开发过程中已经有使用到，只是差一步来真正意识、明确到：”哦
JavaScript面向对象和模块化
JS 是否有必要使用面向对象、设计模式
在一次面试过程中，一位已经有 5 年工作经验的前端，在回答面试问题时这样说到。
问：你能说说 JS 的面向对象和设计模式吗？
回答说：这些内容主要是后端的 Java，C#这种高级语言才会用到的，前端一般我们没有用到。
对于这样的回答，不禁让我有点无话可说，JS 中是否有必要使用面向对象以及设计模式呢？我列举了以下几个场景：
数据接口请求
一般的，在请求接口方面，我们一般会使用一些第三方库，比如axios。然后在逻辑代码部分，比如在组件中直接使用axios进行请求，例如：
let methods = {
/**
* 获得分类信息
*
