左手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的一路陪伴,它曾经帮我实现了我想要的效果,它就像一瓶美酒静静躺在那里,哪天我想小酌一杯,它仍会给我醇香……

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券