**关于技术储备** [Vue,React,React-Native,](#vue) [Nodejs](#node) [ES6,TS](#es6) [Eletron](#Eletron) [Casvas](#canvas) [数据可视化](#data) **问题与意见** [意见](#idea) **总结** [总结](#res) <h2 id="es6">ES6与typeScript</h2> 先说一下ES6与typeScirpt吧 ES6与我们书写的 js 之间的关系就像HTML4+与HTML5,HTML5对比HTML4加入了诸多通过了W3C标准的新特性，如简写的docType、新增标签，移除部分非语义化标签等，ES6也一样，在JS基础上添加了《ECMAScript 2015 标准》的内容，如变量的声明方式，炒鸡简洁的箭头函数，更直观的Class类替代ES6以前的原型链操作，Set,Map方法等。个人认为语言标准的制定更多的是解决了开发者在实际开发中遇到的问题，比如常用的操作需要臃肿的代码去操作，通过新特性可以使用更优美且方便的方式解决这些问题。故私以为语言的新标准是值得去学习且拥抱的！ >ES6目前存在的问题： 就像HTML5一样，虽然主流浏览器均已支持，但是仍有部分非主流浏览器以及老旧版本浏览器占有市场份额且不支持ES6语法，是使用时需要考虑的问题，解决办法：babel转译为ES2015前语法规范,webpack&gulp均可实现。 意义：首先语言标准需遵循，其次项目中开发效率的提升是显著可见的 语法示例： ``` javascript var arr= [1,2,3,4,5,6] // 条件筛选 //ES6之前 var newarr = [] for (var i = 0; i < arr.length; i++) { if(arr[i]<4)newarr.push(arr[i]) } // ES6语法 let newarr = arr.filter(x=> x<4) // [1,2,3] // 优势显而易见 filter 方法字面意思即为过滤 使用了箭头函数， 省略了之前的花括号， return 关键字（箭头函数中有且仅有一个表达式的时候是可以省略花括号以及 return关键字的）， for 循环 ``` 关于TS:TypeScript的目标就是让开发人员能够更好的管理类型和参数。简单来说就是通过编写静态语言的方式编写本是动态语言的 js 编码。通过这种方式降低复杂项目的维护难度与重构成本。 >存在的问题： 1.Vue对TS的支持目前还处在仅可用的状态，React与Angular相对较好，不过19年即将发布的Vue3.0版本将全面支持TS且其本身也会用TS重构, 2.浏览器不支持，同样需要 babel进行编译。 意义：降低项目后期维护成本，且对项目质量有一定提升 <h2 id="node">Node.js</h2> Nodejs方面就个人理解，用途主要存在三个方面： 1.前端自动化项目构建 2.中间层 3.I/O密集型项目服务端 > 首先关于前端**自动化**： 前端近几年的发展速度是众所周知的，可以讲是今非昔比的，早就已经不是以前只能写写页面 样式，交给后台套数据，前后端分离以后，前后端除了数据交互部分基本是相对独立的系统，从而衍生出前端自己的构建系统，而这个构建系统就是nodejs的一部分功能，他的作用就是整合项目资源，如我们项目打包是运行的 npm run build 以及前面提到的 babel，npm 是 nodejs内置的一个 package 管理工具，通过nodejs读取资源文件对文件内 js 编码转译。在工程化项目中nodejs的使用的无法剥离的，没有 nodejs的处理，任何工程化的项目不过是一堆无用的编码罢了，重要性不言而喻 > **中间层**： 通过最近在工作之余的对 nodejs 的调研有了一些关于中间层的思考，在前后端分离的项目开发中，前端负责页面数据展示与交互，后端负责书写逻辑与数据接口，中间层存在的意义是什么呢，其实在对接数据的时候会发现前端拿到的数据为了便于渲染通常会指定一些数据格式让后端处理，而后端在业务逻辑中加入大量处理格式的代码显然是不好的，中间件的作用就在这里，个人认为中间件可以简单理解为一个过滤器，把一堆杂乱的数据，处理成前台需要的格式，这样后端注重逻辑，中间件进行数据过滤，前端注重交互以及前端逻辑，对项目质量的提升还是极大的，且可以减少后端同学的压力，不必纠结于数据处理部分。（中间件可以使用任何语言，只是在 web 端前端语言为 js，nodejs 对于前端学习而言更友好），当然 node 作为中间件也并不是完美的，实际使用仍是以项目需求为根本，进行技术选型。[关于中间件的更多解释](https://juejin.im/post/5b3a0c066fb9a00e9b3a195d) 以nodejs作为中间件存在的问题： 1.前端工作量增大，需要同时进行服务端以及client端的编码工作。 2.nodejs是单线程语言，一旦一处代码出现问题，极有可能引发整个项目的崩溃从而终止服务响应。 3.增加维护成本，需求更改时从原本的前后端更改多加一部中间层 自己的想法： 既然是技术储备，储备是关键，中间层有存在的意义，也有存在的问题，假设公司有一个整合平台的项目，目前平台大大小小十几二十个，需要整合一部分，着实有点心疼后端同学，通过中间层也确实可以使后端同学减压不少可以专心去实现逻辑部分 >**服务端**： 关于服务端我了解到的框架有 Express 以及 Koajs，都是较为稳定的服务端框架是同一团队开发的，Nodejs打出的旗号便是 I/O密集型高并发，虽然其是单线程，但特色是异步I/O， 这里必然有其优点存在，由于了解深度这里不做深究，仅结合公司需求来讲， 项目开发中是否需要 nodejs做为服务端，我的论点是：即可使用，也可不用。项目开发做技术选型时，多存在一种选择总归是好的，技术多元化发展对团队还是对个人永远利大于弊 <h2 id="vue">Vue,Weex,React,React-native</h2> 这里把Vue,React放一起 | | Vue | React | | --- | --- | --- | | 单项数据流 | 是 | 是 | | 生命周期 | 有 | 有 | | 语法 | 模板指令 | JSX | | router | Vue-router | React-router | | 状态管理 | Vuex | Redux | | TypeScript支持 | 5分(仅目前) | 完美支持 | | 背景 | 尤大 | FaceBook团队 | >通过表格内容的基础对比，各有各的优势存在，目前React仅在对TS的支持上占有优势，从开发者背景来讲，Vue为个人开发者，React有Facebook的大厂背景也算是相对优势 结论：从公司目前前端业务而言Vue 足以应对前端工程的需求，从技术的发展角度讲还是多元化发展 | | Weex | React-native | | -------- | ---- | ------- | | 语法 | 基于Vue | 基于React | | 热更新 | 可以 | 可以 | | 语法 | 模板指令 | JSX | | 跨平台 | 一套代码 | IOS/Android两套代码 | | 社区完善程度 | 3分(仅目前) | 7分 | > Weex 与 React-native 跨平台开发的原理均是以 map 方式转译 js 编码为 OC/Java 从而获取APP端原生能力，实现效果与APP原生开发无异，也存在部分APP的原生能力无法完美桥接的情况，基于表格对比的情况 React-native是目前而言跨平台技术相对最好的解决方案。Weex由于发布较晚，社区上较为不成熟，不建议使用。 **使用React-native跨平台开发较为著名的是 Airbnb,现已放弃React-native，下面是关于Airbnb对于React-native作为技术选型的一部分建议** >我们将 ReactNative 整合到现有的大型 App 项目中去，还保持着很快的迭代速度。在这过程中遇到的很多问题其实是由于我们采用的这种混合的开发模式导致的。并且由于我们的公司规模，可以让我们去解决一些对小公司来说没有时间解决的相关技术难题。这种混合开发的模式下，让 ReactNative 与原生无缝协作与融合在一起是绝对可行的，但也是一项很有挑战的事情。每个使用 ReactNative 的公司都有他们自己的使用体验，这取决于他们的团队组成，现有 App 架构，产品需求，以及使用的 ReactNative 的版本成熟度等因素。 [关于 Airbnb放弃使用React-native](http://awhisper.github.io/2018/06/24/Sunsetting-React-Native-translate/#more]) **总结：结合项目需求而言，跨平台方案的选择最根本的问题在于技术稳定性与成本之间的考量，React-native是相对成熟的跨平台方案，但需要以 React 为基础的技术栈，技术储备上而言如有跨平台需求是需要对其深入学习的必要的** <h2 id="Eletron">Eletron</h2> Eletron可以通过前端技术跨平台构建桌面应用的一个框架，关于该技术结合公司需求，我能想到的就是解决语音标注平台长语音崩溃问题，具体能否实现还有待调研，Eletron 构建的桌面应用是运行在最新的 chrome 版本与 node环境中，因为其运行环境固定，对于问题排查方面以及迭代想必有一些益处。该技术实现的桌面应用 【Github】 存在的问题：由于编译需要导致打包文件体积巨大。 <h2 id="canvas">Canvas</h2> **这里加该技术的主要原因在于，目前公司前端核心技术不在工程化，不在平台交互界面如何高大上，其本质定义为工具。即【简洁的达到用户目的为最优】。而平台工具核心就在于Canvas， 目前语音标注、图像标注、未来可能的视频标注以及3d 标注均在此技术范围之内，个人认为前端同学需尤为重视** 这里不再做技术赘述。 **** <h2 id="data">数据可视化</h2> 这里仅是个人理解部分：公司主要业务是做数据的。关于数据可视化这里一直没有业务需求，未来有没有我也不知道，凭感觉来讲在数据可视化方向的需求不会没有，此处也有较深的技术深度（非饼图折线图基础可视化图形），前端有一个独立的岗位叫做 数据可视化工程师 虽然基于 canvas 但是与标注平台的工具类交互型 canvas技术相关性不大。比较好的案例是双十一活动淘宝的数据巨幕，展示全国各地在双十一的交易量以及热力图等。 一个字真**炫! 此处仅了解，暂未进行深入探究。关于入门，有比较成熟的可视化框架如百度的Echarts， Highcharts等。 <h2 id="idea">个人建议</h2> 公司体量逐渐变大的同时，团队也在扩张。关于技术团队，个人认为需要一个良好的技术氛围才能越来越好的发展 1.CodeReview，多数大厂都在运行的技术交流方式 [CodeReview详细了解一下](https://blog.csdn.net/shgh_2004/article/details/78559762) 2.技术分享已经两年了始终没有形成氛围 <h2 id="res">总结</h2> 技能储备： Canvas&ES6 > Vue > Nodejs > TS & React > React-native & Weex > 可视化 > Eletron ----- the end by clouds :) 18.12.4