为什么使用axue？
一、名称由来
最早有想法设计一个基于svg技术的轻量级、可嵌入的原型框架，取名比老牌的axure少一个字母，取义轻量级，但缺乏一个顺带的时机，于是止于“就是想想而已”，但音译傲雪这个名字感觉还不错，加之组件库确实也够轻量，就用到了这个组件框架上。
这是本人第一个开源项目，一个十年产品经理、却持有技术主义信仰的人，进入中年后的首次推窗尝试，如果不好，勿怪。
二、跨框架
axue基于lit，而lit基于原生组件技术栈：Custom Element、Shadow DOM、模板字符串......
原生方向
轻量和原生始终是我所关注的一个技术趋势。
Web Components标准是在2018年才完整落地，属于非常前沿的趋势，由于浏览器原生，在性能和尺寸、跨技术栈方面有天然优势，只是生态初起，底层优势并没有充分得到重视。
最主要是跨框架，无论你使用什么技术栈，都可以与之混搭。但可惜的是，lit生态缺乏比较满意的组件库，尤其是面向PC的，好不容易选中一个quarkd，结果发现是面向移动的，尺寸差距巨大。
lit体验
Web标准组件代表的是一个底层范式，但不是全部。原生标准也有缺陷：
- 草案成型较早，并非响应式的，属于能力缺陷
- 传参基于字符串，序列化开发体验并不简洁，属于设计缺陷
- 节点检索、插槽带来的层级误导，属于范式缺陷
Google在Web标准能力的基础上，对标以Vue、React为代表的前端框架，进行了响应式能力和开发体验方面的封装，推出了lit框架，补齐了生态的基础拼图（解决了前两个问题）。我个人，以新手角色的纯净视角，对各种框架的使用初体验横向比较，确实感受到了足够的轻量级、足够少的概念、足够小的学习曲线。
但反过来，lit这部分体验增强封装的语法糖，毕竟不是web标准，因此实际的技术栈混搭，没有纯使用lit简洁（但依然比vue、react简洁）。
纯lit开发 > 技术栈混搭 > vue或者react唯一有瑕疵的，是第三个问题。这不是lit所能解决的问题，而是源于组件作用域的封装性隔离这一底层范式设计，让自定义组件-slot-自定义组件链路的节点定位检索非常不便捷，正所谓有得必有失，这是为了样式隔离优势的对等代价。
（注：因为对各种框架我都是浅尝辄止，可能优缺判断有失偏颇。）
三、足够小的尺寸
除了50kb的lit，几无依赖。
| 框架 | dist尺寸 | 依赖库数量 |
|---|---|---|
| Ant Design 5.5.0 (react系生态) | 45.2M | 48 |
| Element UI 2.15.14 (vue系生态) | 9.25M | 6 |
| Naive UI 2.35.0 （vue系生态） | 24.3M | 18 |
| Chakra UI 2.8.2 （react系生态） | 16.3M | 53 |
| Quark Design 1.5.1 (web Components系) | 1.08M | 8 |
| ...... | ||
| axue 0.4.33 （web Components系） | 0.2M | 2 |
整体代码量很少，剪除了一切非必要的封装，只为了实现一个体验：在入口模块处一次初始化，然后在页面的任何其他地方当<div>一样使用。
四、API能力
拥有非组件形态的API能力，是axue框架的另一个特点，与纯粹的组件库有一定定位区别。从长远看，围绕web Components【原生范式】-->lit【响应式范式】-->axue【开发范式】的定位，更多的基础工具扩展，是框架的另一个可能方向。
弹框能力
axue在内部最早是用于electron。
electron的原生menu导致的原生-web通讯链路无谓膨胀，弹框也极其难看.....早期，为了主进程弹窗还是渲染进程弹框都成了一个纠结思考点。除此之外，顶部tip、跟随鼠标弹出、子页面等等，其实都有点类似基础设施，是存在一定需求的。
- tip，会自动关闭的小提示
- toast，可扩展的人机交互对话框
- property，右侧进出的属性栏
- slot，跟随鼠标位置智能计算位置、完全自定义的插槽框
- page，居中呈现的子页面
- module，子业务模块
- ......
节点工具
凡封装，必生新边界。
原生方法、lit方法，以及其他框架，在渲染节点上是有一些区别的，比如lit，在某些边界下，会将节点追加变成替换式渲染，这是lit对体验进行封装的代价，这类边界问题对跨框架混用代码带来了巨大的挑战，从职责上看，不应该由业务开发层来承担。
五、自定义能力
允许在业务开发层，对框架层的默认内置的全局设定进行自定义，是axue的一个特色，我称之为loadtime范式。
1、自定义标签名
正常的自定义标签是长这样的<axue-logo-close>、<axue-list-data-manager>，带axue-前缀，除了版权标识，还有两个必要性原因：
- 防止命名污染
- 自定义组件标签名必须是带-的，为了与div等基础标签区分，否则会报错
而版权标识是框架作者的需求，非业务开发者的需求，而上述两点必要性在开发者侧是可控的，如果开发者希望长这样<xxloveyy-logo-close> 、<logo-close>，并且很清楚不会带来冲突，那也是应该支持。
2、自定义图标
主流组件库的设计是基于单个组件的，想象是不是存在这样的场景： A、B、C......组件都提供了可定义的图标，最典型的是logo图标，基于单个组件提供属性设置，则意味着每一个组件、在每一个实例模块使用时，都需要传入同一个图标参数？
axue框架则很懒，会在loadtime优先处理配置，你可以直接在config里指定覆盖默认图标，所有涉及该图标的组件、组件实例，都会自动切换成新的组件，甚至支持在运行阶段动态修改图标。
3、自定义样式
axue的样式基本建立在同一个共享样式文件之上，而样式文件又尽可能的使用了标准的样式变量。因此，开发者可以在自己的html里，或者js逻辑里进行变量覆盖，来实现样式自定义。这种机制，能确保无论是axue默认样式，还是自定义之后，风格都具有跨组件一致性。
自定义API
允许对API进行全局配置，而不是在每一次调用时进行频繁配置