写一些这个插件的原理，v1版本存在的缺陷，以及未来展望。

[sonofmagic]

插件原理

利用 babel postcss 以及 regex 对生成后小程序的 wxml，wxss, 以及 js 进行更改和替换，从而达到兼容 tailwindcss Just in Time 的效果。

插件原理掘金link

[sonofmagic]

v1版本存在的缺陷

taro react / uni-app vue3 这种动态绑定class变量的情况，由于它把 class 的运算和结果都放入了 js 里面，而这个插件，主要正对wxml 模板和 wxss ast 进行替换， 导致这种在 js 中运算的，无法被默认替换。需要用户自己使用 replaceJs 手动替换，这点不好，会对原先的代码，造成一定的入侵。

另外，不得不提到 uni-app 和 taro 这种框架的巨大差异。

uni-app 传统模板
而 taro 动态，即递归的 wxml fragment 渲染

// Todo
占位

[sonofmagic]

未来展望

其实不得不承认的是，unocss 在这块比 tailwindcss 更适合小程序的场景

为什么？ tailwindcss 大部分作为一个 postcss 插件来用，同时在加载的时候，它会根据配置里 content 里的 glob 去抓取所有满足的文件内容，获取后，使用正则对字符串进行提取，然后再在 css生成对应的工具类。

简单来说，它只有读的能力，读取并提取了大量的字符串片段，满足 Just in time 引擎规则的，就生成 css 工具类，不满足就忽略。

而 unocss 是同时具有读和写的能力的，因为它主要是作为打包插件来使用的(当然 core 还是根据字符串提取，生成 class)，这样就更容易自定义各种属性，并替换掉所有满足条件的值。

这种使用上的不同，导致 unocss 是无法作为 postcss 插件来使用( 2023-02-26 , 更新了 @unocss/postcss 插件，当前还处于 Experimental，以后说不定可以作为postcss插件使用)，它依赖打包工具给它提供中间产物对象 Source 然后它对里面的字符串进行分析，来生成。

而 tailwindcss 自己写了一套基于正则的提取器，大部分情况下，直接从你的源码中，进行提取生成。

这点差异，也造成了很多 webpack 等等应用，使用 unocss 的速度要远远高于 tailwindcss 处理生成的速度。

毕竟人家在 webpack 构建打包的时候，就顺便生成了，搭了一个顺风车，而 tailwindcss 还在傻乎乎的提取生成，无法复用 webpack 的结果，这点导致了巨大的性能差距。

// 当然 tailwindcss 也有很多优势:
// TODO

(我应该提供一个 unocss 插件)

[nei1ee]

如果有兴趣可以一起来维护 unocss-applet

[sonofmagic]

如果有兴趣可以一起来维护 unocss-applet

很不错的插件，厉害啊