原文地址：https://about.gitlab.com/2017/02/06/vue-big-plan/
GitLab的前端正在變的越來越好。如今我們做了兩件大事，我們想與大家分享它們以及我們未來的大計劃。
- 如果您使用了GDK(GitLab Development Kit)，請確保已經更新！如果您不知道所講的是什麼，跳過閱讀即可
- 請參考此文檔查看如何升級GDK
- 如果您在升級的過程中遇到了什麼問題，可以參考我們的故障排除指南
- 請隨時反饋您發現的其它問題
我們的大前端計劃
Vue很棒！不久前我曾寫過一篇文章來說明爲什麼GitLab喜歡Vue。現在這篇文章成爲了展示了我們通過Vue和webpack使得GitLab變的更快的這個長期計劃的一種方式。我們希望前端開發者能夠更加容易的開發GitLab。
生活中的經驗告訴我們“重要的事情不是使用什麼工具，而是如何使用它們”。也就是說我們選擇了Vue，但並不意味着成功。也就是說我們同樣可以使用Angular或React以及其它更好的工具。Vue是一種簡單的方式。
我們的計劃如何使用Vue在一段較長的時間中使得GitLab變的更好、更快以及更簡單（的開發）呢？
下面的計劃是一項正在進行的工作，非常雄心勃勃，但我相信，這將爲開發和性能創造一個更好的前端。 這份文檔也是對我們計劃在GitLab前端做的事情的參考。
一個更加健康的前端
當我們開始開發GitLab時，我們簡單的將jQuary集成在Rails中。它沒有想Vue那樣合理的改變大圖片。較小的圖片，我們添加了許多linters，更好的代碼覆蓋，和許多其他偉大的事情。
1.只重寫您需要的
我們並沒有完全重寫GitLab的前端。（完全重寫）將是一個非常糟糕的主意。當然這並不是對於所有人而言都是糟糕的，只是對於一個初創公司而言是一個糟糕的主意。因爲這將花費極大的時間和金錢。現在已有的jQuery（儘管有些人說這並不cool）已經通過測試並且工作的非常好。我們沒有必要去重寫那些效果很好的方法，除非修改後能帶來很大的收益。
我們也不會使用Vue實現所有的新功能，您也不需要這樣。但是，對於某些UI而言，即使是最簡單的Vue的部分也很難找到適用的地方。
下面是一些例子：
1.issue頁面（用於展示個人issue），裏面用了大量的jQuary。我們現在不會重寫它，因爲它很好用。我們將使用Vue重寫一小部分，用以增強某些功能的實時性。我們現在正在做實時的標題和描述。
2.Phil所寫的Issue Boards，是Vue完美的候選。這是一個全新的功能，有着很多無功部分。
3.現在的issue頁一次加載了全部的評論，並且增加了大量的事件監聽。由於性能的原因，這個頁面並不適合Vue。我們將評論變成Vue應用，並使評論的內容和表情選擇器等作爲組件。我們放大了UX，使您無需等待可以立即看到鏈接指向的評論。有很多更好的方法展示大量的評論，所以我們需要儘可能的重新考慮。
4.管道頁面被重寫以用於實時更新的到達。
5.環境是在Vue中編寫的。
6.也有很多其他的地方，我們準備使用或者已經使用Vue。由於數量太多就不一一列舉。
正如您所看到的，我們沒在所有的地方使用Vue。
2.增加webpack
Rails是一個很好的系統，用來抓取您的Ruby庫並且在您的應用中構建他們。通過“bundle install”可以安裝您在Gemfile中所包含的所有東西。所以爲什麼前端還要堅持把他們的庫放在vender目錄下？難道我們還不足以擁有我們自己的庫管理系統？自從資源管道第一次出現，JavaScript的生態系統就已經變得十分成熟。現在我們擁有“npm install”，也可以利用更高級的代碼構建工具。
通過引入webpack（已經合併並且準備應用），我們獲得了很多好處。
1.JavaScript庫將不會被直接捆綁在GitLab的源代碼或者包含在gem裏面。例如，jquery-ui和bootstrap-rails作爲一個ruby的gem被引入，我們在gem維護者的幫助下保持JavaScript庫的更新。
2.當代碼在文件中被共享時，我們可以確保不會重複加載lodash。列如，如果兩個文件都需要加載lodash，我們將只加載一次lodash的代碼。除了lodash不會被引用多次，在tree shaking的幫助下，只有我們所用到的lodash組件會被引用，而不是引用整個庫。
3.我們可以增加hot module replacement使得我們的Vue開發的更快。這是一個開發環境的特性，現在我們在開發的過程中花費了大量的時間用來刷新頁面。
將有兩個不同的構建方式：
- 獨立的構建：包含編譯器和運行環境
- 運行時構建：由於不包含編譯器，因此您需要預編譯模板或是手動編寫實現方法
3.移除Turbolinks
Turbolinks實現了什麼？
我們需要解決的問題
當您的JS被多個頁面同時加載時，時間成爲了一個很嚴重的問題。如果您想我們一樣使用了gem ‘jquery-turbolinks’，那麼$ready這個方法將會在每個頁面中加載，即使這些頁面沒有按照傳統的加載方式加載。不通過整個應用引入而在每個頁面中編寫特定的JavaScript是很痛苦的。我們做了而且做得很好，但是，爲什麼呢？對於大量需要引用在各個頁面中的JS確實沒有什麼辦法。
任何外部的鏈接都加載的非常快，因此我們需要注意性能。
如果您不注意，您的事件將被多次加載，因此多次啓動。 列如以下代碼：
$(function(){
$(document).on('click','.some-element', function(){
console.log('Click loaded');
}
});這個點擊事件將會被在每個頁面中加載，並且在每個‘.some-element’被點擊時執行多次。
解決方式
有很多方法可以解決這個問題，有的很好有的很壞。
1不要在$ready的回調中創建時間
2使用下面的方法
$(document)
.off('click', '.some-element')
.on('click'...我管他叫die live方法，在以前的jQuery中人們經常在各種地方寫die().live()。這是以前在學校中的jQuery的off().on()。
3.寫一個事件管理器作爲所有添加事件的委託。
4.移除Turbolinks並且確保在每個頁面中只加載您需要的代碼。
額外的
當我們移除了Turbolinks之後，我們可以做一些更酷的事情。我們可以讓每個頁面獨立存在。之後，某些頁面可以有自己的Vue應用。比如，我們可以使用文件瀏覽器的Vue應用程序。合併請求也也可以是它自己的應用程序。查看文件的代碼也不需要在其他頁面中加載，所有頁面都是這樣。這並不是什麼新鮮事，這是web開發的基礎。這也不是一個新的範例，我們不會是第一個。.
總結
現在仍在爭論是否將整個網站作爲一個單一頁面的應用程序，但我認爲這隻能帶來更加困難的維護，對於性能和用戶而言並沒有什麼好處。當然，現在是一個很好的機會能夠讓GitLab變成一個janky應用。例如，簡檔頁面可能非常輕，人們不能直接鏈接到簡檔頁面; 它應該在我們的項目中加載每一個單獨的JavaScript。
這只是GitLab的一小步，確是前端團隊的一大步。在未來您將會看到我們的團隊帶來更多更新更酷的事情。此舉便是向這一方向邁出的一步。