甲方通常不关心用什么技术，但这个选择会影响到后期的成本。技术选得不对，后面加功能麻烦，换人维护也麻烦。
不需要懂技术细节，但知道几条判断依据，能在选型时问对问题。
一、两者主要差别
原生开发直接用小程序本身提供的开发方式，稳定，能第一时间用上微信新出的能力，出问题时排查也直接。缺点是同一套业务要同时做小程序、公众号、应用的话，得分别写。
框架开发是用一套代码编译出多个平台的小程序或者应用。最常见的需求是同时出微信和支付宝两个版本，或者同时出小程序和应用。优点是开发量小，缺点是遇到平台特有的能力时可能要绕路，某些极端情况下的性能也不如原生。
还有一类是用网页技术包一层。开发快，但性能明显差，界面也不够原生。除非是迁移已有的网页项目，一般不建议新项目用。
二、怎么选
只做微信小程序，且对性能和体验要求高，选原生。这类项目最典型的是工具类和交易类，用户对流畅度敏感。
需要同时覆盖微信、支付宝、抖音多个小程序，或者同时要小程序和应用，选框架。一套代码多端输出，能省下大量重复开发。这在预算有限的时候是很有说服力的理由。
如果项目里有一部分功能要用到平台特有的能力，比如微信的支付、订阅消息、或者某个平台的开放接口，用框架也没问题，通过条件编译处理差异即可。只是这部分逻辑要单独写，不能指望一套代码完全通用。
三、选型要考虑后期
技术选型不只影响开发阶段，更影响后面几年。要问清楚几个问题。
这个技术现在用的人多不多，招人好不好招。用的人少的框架，一旦原来的开发方不合作了，你就很难找到接手的人。这一条比技术本身的优劣更重要。
这个框架还在维护吗，多久更新一次。已经停止维护的框架，以后遇到微信端的调整可能没人适配，小程序就运行不了了。
迁移成本高不高。如果将来要从框架迁回原生，或者在框架之间切换，工作量有多大。技术上没有永远的正确答案，能方便地换才是安全的。
四、甲方该问什么
不用问用了什么技术，问这几句更实在。这个方案后面加功能方不方便，大概加一个中等复杂度的功能要多少工时。如果以后要换开发方，别人接手难不难。这套技术现在市面上好找人吗。
如果开发方的回答是这套只有我们会，或者这套我们有自己的封装，其他家不好接，那就是个警告信号。技术上的封闭对甲方没有任何好处。
还有一个可以要求的点，让开发方在方案里写明技术栈和版本。这不只是好奇，是给后续接手的人留一份准确的说明。很多项目后期维护困难，就是因为没人知道当初用的是什么版本。