2022年了，uniapp发展的怎么样了?
2022年元旦补充:该问题始于2021年，在这一年里我见证了uniapp的成长，虽然仍有很大的进步空间，但我对uniapp是充满希望的。希望大家继续畅所欲言，该问题将见证uniapp的历史，也将随uniapp走向未来！2021年提问:有人说uniapp坑多，现在还是那样吗？开发简单的程序，部署到微信小程序、安卓、ios三端，性能、稳定性、方便性方面值得入手了吗？ uniapp证明了一件事，由于国内互联网的巨大生存压力，纯由国内公司推动发展，纯由国人维护积累的生态，最终产物一定是一坨屎。
在开发者工具里输出广告，罪大恶极。 做一个产品给用户用，其他产品是做出来第一版就是60分，每年给他完善个10分
uniapp属于出道的时候30分，每年努努力加个四五分，我觉得目前也就顶多50分
还是营销做得好，领导都知道uniapp。
uniapp会把一个正经前端原生开发中的问题，磨平成uniapp文档中的API，但是文档并不完善！比如我在使用uni.chooseImage H5是测试的时候我windows路径 安卓上路径会变成 /storage/emulated/0 ，开发者不一定意识得到，差异是磨平了，错误还藏在下面，等着开发者去找呢。
更别说出现变成无法解决的黑盒问题！
真实经历
项目要我写个App，要用到地图标点定位的功能。leader要求我必须用uniapp。前期技术调研的时候，我尝试获取设备经纬度，然后再定位到当前位置。结果发生了很匪夷所思的问题
console.log的时候经度打印出来是经度，纬度打印出来是纬度
但是赋值引用的时候，经度其实是纬度，纬度其实是经度！
what？写了两年前端第一次所见不是所得了
颠倒引用，才能正确设置定位
this.longitude = res.latitude
this.latitude = res.longitude意思就是说，你写的代码其实不是真正的运行代码。
uniapp会给代码进行转译，虽然打印的时候经纬度还是经纬度，引用的时候经纬度变成为 "纬经度"了，欸我就是玩儿。很难排查吧，还是android App的独有问题。
给我乐死了，3月份我第一次提的bug，8月份终于修了这个问题。
估计转译模块是实习生写的？两个单词 latitude 、longitude颠倒了
【报Bug】app端 uni.getLocation的返回值赋值给 map组件的 latitude 和 longitude 属性时， 经度更新在纬度上，纬度更新在经度上
APP map 经纬度多再次赋值 地图显示空白
对于有能力的人来说，我的评价是，不如Quasar Framework - Build high-performance VueJS user interfaces in record time 前段时间技术调研有测试使用过。结果是果断弃用，原因如下
1，杂而不精
咋说呢，妄想一口气吃下多个平台，结果就是搞出了个不伦不类的东西。要说有用吧！小项目确实有用，有封装好一些SDK，可以简化一些开发流程，但如果想要做高度定制，别想了。
难以理解的是，作为开发者工具的 HBuilderX 里边，居然有广告，居然有广告，居然有广告……
真是离了大谱，第一次在开发者工具里边看到招聘广告的。
2，不伦不类
再一个不能理解的是，uni app主要目标使用群体是前端，但似乎却在打造一个独有的跟前端割裂的生态，无论是官方的开发模式，还是一些插件加载等，很多跟前端开发流程不匹配。无论是 HbuilderX，还是自定义的插件商店而不是 npm 等
后来仔细一想，可能目的是为了简化项目结构，可这种简化个人觉得没这个必要。
3，文档混乱
由于为了宣传的支持多平台，文档中接口也为了做到统一，所以经常会看到这样的情况：
[*]找到一个api 接口
[*]拿来测试一遍
[*]怎么跑都跑不动
[*]文档往下翻，翻到最后，发现不支持这个平台
再然后，就是很多 uni app 自己都解决不了的问题，告诉你，这个我也没办法，给你几个建议你自己看着办吧之类的文档
4，对App 开发没什么大的作用
刚开始很好奇，uni app 是用了什么黑科技，即能支持 小程序，又能支持 app，抱着仰慕学习的态度做了这次技术调研，发现这东西不就是把多个平台拼凑了起来嘛！论好的一点，就是将各个平台的api做了统一，这一点是值得肯定的。但是为了做到这个目的，也让各个平台的环节比较薄弱。这一点就是 1 中所说的杂而不精。
相对来讲，对于小程序这种相对简单的平台来讲，uni 是可以胜任的，甚至是有一定优势的（多个平台），但在 App 方面，就毫无优势可言。
uni 提供了两种 App 渲染模式，一种是 基于 weex 的 .nvue, 一种是 基于webview 的 .vue。对于后者，实际上还有一个类似的平台：apicloud，这俩平台很类似，都是给 webview提供常用的接口，让 h5页面具备调用系统api能力。区别在于 uni 使用了vue而已。
所以，如果只是采用 vue 来开发，所开发的app实际上就相当于 h5 套壳，如果可以的话，完全可以把app做成一个h5网站，用定制webview 来像浏览器一样加载使用。所以，这一类的app注定性能是没法跟原生的比的
而如果 使用 .nvue，则使用的是 weex, 这个方案相对于 React Native 是没什么优势的，甚至已经停止维护了。如果采用 nvue 模式开发，意味着有很多无人来填的坑……。亲测 nvue 确实不太好用，很多组件使用起来，有莫名其妙的问题。
而如果 采用 nvue, vue 这两种模式混合开发，又有其它的问题。比如，一个公共组件，可能得写两个，一个用于 webview 模式引用，一个用于 weex 模式引用。在考虑到 android ios 兼容性问题，可能得写三个，徒增复杂度。
综上所述，个人觉得 uni 对于 App 开发绝对不是一个好的方案。只能用于较为简单的项目。做大一点的也可以，可成本要远远高于所预期的 A：我口算特别快
记者：请问 87364 乘以 246289 等于多少
A 脱口而出：等于 36
记者：好像不对。
A：就说我快不快吧。 这玩意儿就是拿着小无相功当少林七十二绝技的鸠摩智。
如果你是前端，想随便糊弄下假装自己是个app，可以试试。
只有crud的展示性应用，用它凑数还是可以的，真正复杂的项目它就抓瞎了。
真想做移动端的，趁早去学原生开发。
什么多端开发，提高效率，不敢苟同。
开发工具HbuilderX就是老牛拉破车，高效？搞笑！
官方文档更是一坨意面，查官方文档的感觉就好比你在读一段满是goto的源代码。
传销味道浓厚，到处是广告和自吹自擂，一个问题能啰嗦半天，解释的还语焉不详。就当你以为是你以为的那种情况时，一运行发现驴唇不对马嘴。
看上去是不用写多端的界面了，实际上你花在编译等待和踩坑排雷上的时间只会更多，最尴尬的是你收获的并不是有用的原理和语法知识，而是靠不断的枚举错误而获得的只能在uniapp当前版本当前范围内使用的经验。
所谓不用转换思维，其实就是培养固化思维的另一种说法。
那么这玩意儿到底能不能用？借用下《叶问》中洪师傅的那句话：
为了生活我可以忍，但侮辱程序员的技术池就不行。
想提高技术的，离它越远越好。
页:
[1]