前端技術選型的遺憾和經驗教訓

我是Max，Spectrum的技術聯合創始人。Spectrum 是一個面向大型在線社區的開源聊天應用程序，最近被GitHub收購。我們是一個三人團隊，主要擁有前端和設計背景，我們在這個項目上工作了近兩年時間。

事後看來，以下是我做出的令自己感到遺憾的技術選型以及從中學到的經驗教訓。

遺憾1：沒有使用react-native-web

Spectrum的很大一部分吸引力在於內容是公開的和可搜索的，所以我們在開發原生應用之前先開發了網站。

我們的搜索索引做得很成功，但用戶一直在要求有更好的移動體驗。我們現在正在開發原生應用程序，但因爲是從頭開始，所以很耗時。如果我們當初使用react-native-web來構建網站，就可以重用一些基礎組件，加快原生應用程序的開發速度！

最重要的是，我們應該已經對網站的移動版本進行了優化。如果移動體驗做得足夠好，即使是在桌面上也是可接受的，只需要做一些調整即可。然而，桌面體驗在移動設備上的表現就有點令人生厭了。事實證明，不管我們做得多麼好，都難以在各種尺寸的設備上有良好的表現。

學到的第1課：構建一個好產品就是要不斷進行實驗，加快開發速度，爲了迭代速度和靈活性而優化。

出於SEO的目的，我們需要使用服務器端渲染。但我們已經使用create-react-app構建了應用程序的第一個版本。我們考慮過切換到Next.js，但我認爲重新設計路由和數據獲取比我們自己構建服務器端渲染的工作量更大。

但事實證明，自己構建生產就緒的服務器端渲染非常困難。它需要很大的工作量，並且很難爲開發人員和用戶提供良好的體驗。

Next.js提供了驚人的開發體驗和性能，更不用說活躍的社區和優秀的文檔。如果我們現在重新開始，我會懷着激動的心情使用它。

學到的第2課：儘可能使用現有的解決方案來解決技術問題，特別是那些你不瞭解的問題。

我之所以選擇RethinkDB作爲我們的主要數據存儲，主要是因爲它的changefeed功能。這個功能允許你監聽幾乎任何一個查詢的實時更新。我認爲它可以降低系統的複雜性，因爲我們不需要爲了實時功能單獨使用另一個發佈和訂閱系統。

但不幸的是，我們在RethinkDB上遇到了很多麻煩。由於它沒有被廣泛使用，幾乎沒有關於如何操作數據庫的文檔和資料。我們經歷了好多次數據庫中斷，調試問題感覺像是在蒙着眼睛走路。

事實證明，changefeed的可擴展性並不如我們預期的那樣好。雖然我們設法解決它，但我們原本沒有必要這麼做。

現在，我會選擇一個更成熟的數據庫（或許Postgres？），並基於它構建一個發佈和訂閱系統。

學到的第3課：謹慎選擇以後難以更改的核心技術。

學到的第4課：在選擇技術時，優先考慮社區規模和維護活躍度，尤其是在不熟悉的領域。

文本輸入是Spectrum用戶的主要活動之一，我們希望爲用戶帶來很棒的輸入體驗。我決定使用基於Draft.js（最近由Facebook發佈）的自定義WYSIWYG編輯器替換純文本Markdown輸入。

可惜的是它效果並不好。即使經過數月的努力，我們的用戶仍然在不斷抱怨，說編輯器真的很難用。最重要的是，編輯器的庫佔了我們JavaScript包大小的大部分，而且缺乏跨瀏覽器支持意味着我們必須將普通文本輸入作爲後備選項。

另一個框架可能效果更好，但我們應該專注於更緊迫的功能。我認爲我們需要WYSIWYG編輯，但並沒有與用戶就此事展開交流。否則，我們很快就會意識到根本就沒有必要所以這個編輯器。

學到的第5課：在考慮新技術時要謹慎，偏向保守的選擇。

學到的第6課：開放路線圖，瞭解用戶的優先事項。

即使改變了這些決定，也不會讓Spectrum自己成爲更好的產品。但這樣會節省我們的時間，讓我們花更多的時間進行實驗。

總而言之，以下是我總結的六個經驗教訓。