uniapp真的很垃圾吗？

这东西烂不烂取决于你做什么。

SQLite垃圾吗，挺好用，但是你拿他顶个高并发，顶个百万数据试试？

人家就不是干那个的。

很多人在技术层面上天天瞧不起这个瞧不起那个，说起来好像也头头是到，Python写不了企业级应用，php性能不好，Golang轮子太少，Java太过臃肿，vue不优雅，react滥用魔法，泛型太过死板，any又对项目可读性有损害，Mysql顶不住单表两千万数据。这些发言我常在一些技术讨论下的评论区看见。

我倒是觉得技术本身不能当饭吃，技术只是手段，钞票才应该是目的，只有在你的目的充分的达到了之后才应该去考虑一些精神层面，或者说追求层面的问题。

uni很大程度上挡住了一些烦人的甲方，这东西到底能节省多少成本我相信用过的人是很清楚的，给大伙看一个上个月遇上的甲方。

从甲方这个需求中我们能抽象出几个端呢？安卓，IOS，H5，微信公众号，后台管理(Web)

如果原生开发，就算每个端只需要一个人，这个破项目光前端，即便吧公众号和H5合并也要四个人，我都还没算鸿蒙，得亏人家没要求必须是 .hap 的包，不然安卓还要再加一个端。

而这个项目才十几万，我要是去找两个做原生的同行，再找个H5同行来帮我，十几万收入至少减一半。

这就是Uni存在的价值和意义，它是很多地方不好用，它是性能不够，但是你原生性能再好能写一遍代码打包运行四个环境？

老拿性能说事对Uni其实不是一个好的攻击点，因为作为一个有经验的开发，判断一个项目对性能的要求有没有超过一个套壳Web所能提供的能力，我认为是很容易判断的。

如果甲方要做一个直播，要PK要打赏要连麦，还要各种礼物特效和实时的视频特效，这种需求你为了节省成本用Uni做，且不论你有没有职业道德，做完怪Uni性能不够我觉得是很没有道理的一件事，他就不是干这个的。

Uni的烂，更多体现在文档和API，编译的时候烂，还有偶然需要调用一些系统底层的内容，而又恰好没这个插件的时候，这种时候会一下吧之前节省的时间补回来。以及那个HbuildX编译器更是让Uni屎上加霜。

还有人提taro，taro跟Uni属于是一个巧克力味的屎和一个屎味的巧克力。都烂，但是有时候不得不吃。

硬要比的话taro开源，不必担心闭源打包会给你塞没办法审查的代码。

这玩意我对它的定位就是用来做轻量级(乐色)的APP，顺便送一套小程序，不建议对它抱有过高的期待。