為什麼要選擇一個前端框架？

沒用過個react vue啥的出去都不好意思說自己是做前端的。

但，我們在選擇框架的時候，是否基於業務充分考慮到為什麼我們選擇了一個框架？

半年前，差不多是2016年中的樣子，我跳槽到了一家電商公司做前端。

當時新東家的技術團隊經歷了大換血，老大提出了要做前後台分離的需求。

之前我只是一個菜雞頁面仔，所做過的工作僅為http://asp.net里畫好樣式，用jQuery做邏輯操作，也不知道自己做的是服務端渲染。

要扛起前後端分離的工作明顯是有困難的。

之間的一段時間裡，我嘗試了網紅的react與vue，且向做前端同學@ywthoho取經（在這之前根本都沒聽說過react什麼的，唉～-_-!），腦子裡有了展開這項工作的大致構思。

第一，我需要一個框架，原因為：

1、將以往基於java spring的後端渲染移植為前端渲染；

2、以往基於jQuery的頁面邏輯維護起來相當吃力，對團隊開發協作很不友好，且隨著項目邏輯的複雜化存在著性能方面的問題；

3、公司的一部分業務場景適用作SPA。

第二，選擇哪一款框架。

當時的場景為react已打下半壁江山，vue因vue-router的發布大放光彩。

最終的選擇是react，原因為：

1、vue透露出vue2.0正在進行中，彼時採用vue將來必定會面對遷徙的問題；

2、當時react社區非常成熟，而vue的社區生態相形見絀，團隊中也沒有其他同事在之前進行過相關框架的使用，考慮到開發過程中問題的發現與排查react還是更為妥當；

3、相對於vue略高於react的性能優勢（當時vue還沒有virtual dom），react在做好性能優化的時候是足以滿足我們的需求的。

以上，在當時的需求下我為什麼選擇了一個前端框架。

時過半年，業務已經非常穩定，但反觀現在的架構還是存在很多問題的。

首先，框架的採用還是要基於業務需求的，忌不能一概而論。很多場景下，譬如僅僅需要返回一個狀態頁面，一些需要seo的業務，顯然後段渲染是更好的解決方式。

本想著引入react可以在很多業務場景中採用spa，但真正到了做的時候才發現適用於spa的業務場景屈指可數，且不說spa還將帶來bundle size過大的問題（可以使用code splitting）。

其次，後端做路由前端渲染，怎麼感覺也是繞了一圈。。（node的BFF也剛提上日程。。）

並且，在使用react後前端邏輯完全對後端透明，介面的協定就變的至關重要，每一次業務迭代時伴隨的介面文檔是必須的。

。。

在目前的業務中，我們也是在選擇性的使用框架（譬如搶購之類的頁面還是後端渲染來完成）。

最好的技術選型，還是要由業務需求來決定。