最近考虑3D模型浏览器/编辑器采用的架构：打包器构建或者原生H5。这两种方式区别很大，需要好好考虑一下。
背景：
3D模型浏览器/编辑器只是系统的一小部分，所以不会因为一个小项目而大改整个系统
以下所说的打包器一律代表Vue、React等SPA前端工程化框架（脚手架），区别于无打包过程直接就能跑的项目。
公司不用Docker，目前是宝塔 + PHP，卖源码，经常需要给客户部署
区别
讲一下我理解的二者区别
原生H5
可以用Vue，但管理组件麻烦
JavaScript脚本文件引入后所有代码都在全局环境，容易冲突
部署方便，直接上传服务器就能跑
部署成本低，无需前端介入
打包器
组件拆分容易，代码结构易维护
无需考虑样式冲突，js重复声明等问题
支持各种预处理器，无需考虑兼容性问题
部署成本高，需要安装node环境
打包后的源码不支持二次开发
闲扯
为了省事，用纯H5写。
系统有离线导出的功能，或许需要完整导出源码（没了解过）
写过原生都知道，对于原生编码起来遇到的问题基本上是全局性的，代码散落在各处，不像是组件化开发，只需要找对应文件就可以了。新学到的词，叫关注点分离
原生开发，css预处理器这些都得靠IDE插件了，JavaScript新语法特性也得悠着点写，因为得手动配置polyfill
当然打包器也有缺点，那就是上手门槛过高，环境配置复杂。原生写直接一套PHP就装上了，而打包器比如打包的Vue，需要到客户服务器上装好nodejs，运行npm build，然后将文件挪到public目录，再配置文件代理（路由history模式）。
你或许想说Docker打包个镜像一键pull run？
单个前端没必要docker，无非打包出来构建了个dist文件，最终还得配置代理。
之前系统没有用docker，大概率不会因为一个小项目去改整个系统。（系统比较复杂，可能出现一些问题）
所以我就在想，
打包器在公司里的应用到底是什么角色？
光是打包过程复杂就足够难住我们，是否我们的系统将永远用原生H5？
有没有无需打包器实现组件拆分的方法？
打包器研究出来究竟是为了什么？
如何让构建过程更简单？或者说无构建过程，直接原生编写组件化的代码？
找到了两种方案