左手Ionic，右手年华

第一次亲密接触

第一次接触Ionic，是在2015年，并在年中的时候第一次在正式项目中使用，那时它才是Ionic1的Alpha版，每次版本更新仍有不少坑，但在可接受范围，而且Ionic team一般会很快地修复Bug或者给出解决建议，就算他们没有回复，个人花点时间仍能找到折中处理方案。

其实，在使用Ionic前，移动端JS框架，我尝试使用过Jquery Mobile（JM）、Sencha Touch（ST），JM坑很多，而ST相对好一些，但是性能有很大问题，如文件体积过大、内存占用过大等，而且UI实现对IDE不友好，或许后面都有所优化了，但是我没等这一天。

因为有Angular1（Angularjs）的基础，所以上手Ionic1很快，它全家桶的功能，省却了配套技术选型的烦恼，同时，它比较齐全的cli命令，使得项目的创建到发布都比较简便。

那时的Ionic1还没有懒加载。在我认为Ionic打包为App后，它的基础文件在本地加载，不依赖网络开销，所以没必要做懒加载处理时，架构师同伴却执着地进行懒加载改造，没有官方解决方案，我们啃国外的文档，最后使用了ocLazyLoad处理（我们改造完几个月后，才在国内看到一些相关文档，早期吃螃蟹的人都不容易）。后来的事实证明做懒加载还是有一定必要性的，在此基础上，我们又陆续做了热更新、动态渲染等功能，那时Ionic1的表现还不错。

虽然Ionic1基本摸透了，但是它还是有一定学习成本，为了团队建设考量，等Ionic2出来后，我们犹豫了一下是否沿用Ionic1，也比较了一下其它移动端js框架，最后还是敲定了升级使用Ionic2。然后v2、v3、v4一路走来，见证了Ionic的成熟，也见证了其它混合式开发框架的诞生和崛起。

新欢与旧爱

随着Ionic4的推出，自己也较早时间去踩坑，从去年中创建第一个Ionic4项目开始到现在，指导开发了几个Ionic4项目，可以确切地说，Ionic4已经稳定了（仅限于Angular版、Vue和React版的还有较长一段路要走），而且相对Ionic3来说，性能更加优化、机制更合理，同时两者间差异不算变化很大，可以很好的过渡（仅限于技术过渡，而不是旧项目过渡），对于新项目的选型，可以考虑Ionic4替代Ionic3来开发。

Ionic4最大的感观是在转型，转型向一个纯粹的UI框架，借助Stencil，基于Web Components技术实现跨框架使用。其实如果Ionic3时，是采用Ionic4的技术线条，而Ionic4是下一个新的技术，那一定比现在更成功。而现在，在其它竞争对手面前，Ionic4并不算有很亮眼的表现，一定程度上归结于Angular在国内的受欢迎程度。

其实，在我先前的文章中提到过Capacitor，最开始它的官方文档介绍有【Native UI View】这个内容，一度让我以为Ionic版的RN要来了（与NativeScript不一样的实现），后来发现相关内容被删掉了，再后来看到相关团队成员的文章里面提到过这个事情，提到这是他们的一个梦想，只是这个工作量太大了，所以把其它工作优先处理，这个先排除掉，但不知道什么时候再提上日程。

乱花渐欲迷人眼

在我看来，Ionic4已经不再神秘，它和其它基于Angular的UI框架相比，其实没什么两样，可以从很多Angular资料中找到参考，所以也便很少写关于它的文章。一些从Ionic3过渡到Ionic4的人仍旧以Ionic3的思维去做开发，抱怨这个Ionic3可以，怎么到Ionic4不行？Ionic3是Angular的基础上封装了一层，是Ionic3独有使用，Ionic4把它开放还给了Angular，就该用Angular的思维去做。

就像我前面提到过的，Ionic有其它竞争对手，当你有较深的Angular经验，或者团队的技术栈主要是Angular时，Ionic仍是不错的选择，它还有很长的生命周期，当然针对不同的需求，也可以选型其它技术，不用说绑死在一棵树上，或者悲观地说我要放弃某种技术，在我看来，很多时候，技术是殊途同归的，懂了这个，了解其它也能很快上手，换了其它技术也代表你又学到了一样东西，技术有了升华。像我所在的公司，我可以决定选型的技术，就算我认为Angular比Vue更适合于中大型项目的开发管理，虽然我可以固执地要求使用Angular，但考虑到招人的成本、框架的特点和国内的趋势，一些项目我会考虑使用Vue。

就算我在使用其它技术，我仍感谢Ionic的一路陪伴，它曾经帮我实现了我想要的效果，它就像一瓶美酒静静躺在那里，哪天我想小酌一杯，它仍会给我醇香……