是时候和DOM说再见了——《React Native：用JavaScript开发移动应用》读后感
程序员文章站
2024-01-23 09:54:04
...
看到十一月的试读活动的时候，一下子就被React Native的介绍给吸引住了：真的可以通过纯前端的解决方案来进行移动端APP的开发吗？
在看到ReactJS的解决方案之前，也有思考和实践过这个问题。之前的解决方案是通过PhoneGap，也就是现在的Cordova，通过APP的外壳包装了一个WebView的容器。具体过程是先完成一个纯HTML+CSS+Javascript在移动设备分辨率上的实现，然后将整个目录结构放到PhoneGap的目录中，最后通过调用PhoneGap的命令，将整个目录编译成不同平台上的应用文件，比如IOS的APP，android上的APK。这个解决方案在某种程度上使得即便没有从事过移动端开发的经验，也可以通过纯前端的技术，只是利用app本身作为Web容器，从而实现移动开发，同时一份代码，解决了多个移动平台。同时也可以利用相对比较成熟的JS效果库实现丰富的动态视觉功能。
听上去解决方案非常完美，但是在真正实现了之后，发现原生的JS在移动端不仅运行缓慢，有明显的卡顿感，而且用户很明显可以感受到是浏览器的体验，而不是真正的APP。这两点原因直接使得通过前端方案实现移动端开发的方案搁浅。除此之外，PhoneGap调试的繁琐步骤也是一个巨大的槽点。即便之前提到的两点问题不存在，但是PhoneGAP在移动设备上调试JS必须通过载入一个特殊的JS，然后连接到台式机端口上，通过chrome的开发者工具进行调试。
因此看到这次试读活动的主题之后，我对于reactJS是如何克服PhoneGAP的缺陷有了非常大的兴趣。首先关注的就是性能问题，如何使得HTML在移动端的渲染和JS的运行效率能够将效果媲美原生API编写的APP。其次就是调试性如何，是否能给开发带来革命性的便利。
通过了解reactJS的相关知识，React不再使用text/javaScript标记JS代码段，而是通过text/babel，因为reactJS的JSX语法和传统的JS不兼容。reactJS必须的三个的三个库中有一个叫browser.js的库，就是用于将JSX语法转换成JS的语法。但是在真正上线的时候，不再会由浏览器即时转换，而是通过服务器端提前完成。而JSX语法在使用的过程中，相当于可以将JS变成了动态组织HTML的逻辑语言。浏览器的DOM可以动态的拼装生成。
在编写了一些reactJS的实例之后，发现这门技术更多的像是在用后台语言的方式在前端处理HTML。目前主流的技术果然都是在某些点上是相通的。比如nodejs就是在用JS的语法编写后台代码，而angularJS则是以开发动态语言页面模板的方式编写HTML模板。reactJS则是另辟蹊径，脱离了原来网页上DOM结构的限制，由自己封装的Virtual DOM接管浏览器上DOM元素的生成和渲染。而ReactJS重新定义的DOM，正是解决当下的性能杀手——复杂频繁的DOM操作的有效方案。ReactJS通过自己维护虚拟的DOM树，每次动态变化只需要DIFF不同的部分，大大提高了显示上的性能。
reactJS是基于组件化的开发，所以另一点优化就是把组件当作了状态机，用户只需要关注组件状态的变化，通过事件驱动机制，自动渲染UI的变化。
在调试上，reactJS通过相关浏览器插件可以直接在浏览器上进行调试。我的疑问是是否reactJS能够保证在不同设备上执行的一致性？使得只要在PC上调通在手机端也能保证正常运行？但是浏览器插件可以直接查看组件的状态确实非常方便。
试读样章中将笔墨集中在了flux，但是由于关于flux的具体描述并没有收入在样章之中，只能通过文中的描述推测是用于传递组件的状态，控制和处理状态之间的转化。如果有幸得到赠阅的机会，可以解答我心中的这个疑惑。
在看到ReactJS的解决方案之前，也有思考和实践过这个问题。之前的解决方案是通过PhoneGap，也就是现在的Cordova，通过APP的外壳包装了一个WebView的容器。具体过程是先完成一个纯HTML+CSS+Javascript在移动设备分辨率上的实现，然后将整个目录结构放到PhoneGap的目录中，最后通过调用PhoneGap的命令，将整个目录编译成不同平台上的应用文件，比如IOS的APP，android上的APK。这个解决方案在某种程度上使得即便没有从事过移动端开发的经验，也可以通过纯前端的技术，只是利用app本身作为Web容器，从而实现移动开发，同时一份代码，解决了多个移动平台。同时也可以利用相对比较成熟的JS效果库实现丰富的动态视觉功能。
听上去解决方案非常完美，但是在真正实现了之后，发现原生的JS在移动端不仅运行缓慢，有明显的卡顿感，而且用户很明显可以感受到是浏览器的体验，而不是真正的APP。这两点原因直接使得通过前端方案实现移动端开发的方案搁浅。除此之外，PhoneGap调试的繁琐步骤也是一个巨大的槽点。即便之前提到的两点问题不存在，但是PhoneGAP在移动设备上调试JS必须通过载入一个特殊的JS，然后连接到台式机端口上，通过chrome的开发者工具进行调试。
因此看到这次试读活动的主题之后，我对于reactJS是如何克服PhoneGAP的缺陷有了非常大的兴趣。首先关注的就是性能问题，如何使得HTML在移动端的渲染和JS的运行效率能够将效果媲美原生API编写的APP。其次就是调试性如何，是否能给开发带来革命性的便利。
通过了解reactJS的相关知识，React不再使用text/javaScript标记JS代码段，而是通过text/babel，因为reactJS的JSX语法和传统的JS不兼容。reactJS必须的三个的三个库中有一个叫browser.js的库，就是用于将JSX语法转换成JS的语法。但是在真正上线的时候，不再会由浏览器即时转换，而是通过服务器端提前完成。而JSX语法在使用的过程中，相当于可以将JS变成了动态组织HTML的逻辑语言。浏览器的DOM可以动态的拼装生成。
在编写了一些reactJS的实例之后，发现这门技术更多的像是在用后台语言的方式在前端处理HTML。目前主流的技术果然都是在某些点上是相通的。比如nodejs就是在用JS的语法编写后台代码，而angularJS则是以开发动态语言页面模板的方式编写HTML模板。reactJS则是另辟蹊径，脱离了原来网页上DOM结构的限制，由自己封装的Virtual DOM接管浏览器上DOM元素的生成和渲染。而ReactJS重新定义的DOM，正是解决当下的性能杀手——复杂频繁的DOM操作的有效方案。ReactJS通过自己维护虚拟的DOM树，每次动态变化只需要DIFF不同的部分，大大提高了显示上的性能。
reactJS是基于组件化的开发，所以另一点优化就是把组件当作了状态机，用户只需要关注组件状态的变化，通过事件驱动机制，自动渲染UI的变化。
在调试上，reactJS通过相关浏览器插件可以直接在浏览器上进行调试。我的疑问是是否reactJS能够保证在不同设备上执行的一致性？使得只要在PC上调通在手机端也能保证正常运行？但是浏览器插件可以直接查看组件的状态确实非常方便。
试读样章中将笔墨集中在了flux，但是由于关于flux的具体描述并没有收入在样章之中，只能通过文中的描述推测是用于传递组件的状态，控制和处理状态之间的转化。如果有幸得到赠阅的机会，可以解答我心中的这个疑惑。