**關于技術儲備** [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