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

作者 | Max

譯者 | 無明

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

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

1

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

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

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

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

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

2

遺憾 2：沒有使用 Next.js

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

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

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

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

3

遺憾 3：使用了 RethinkDB

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

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

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

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

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

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

4

遺憾 4：使用了 DraftJS 和 WYSIWYG 編輯器

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

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

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

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

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

5

小貼士

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

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

構建一個好產品就是要不斷進行實驗，加快開發速度，為了迭代速度和靈活性而優化。

儘可能使用現有的解決方案來解決技術問題，特別是那些你不了解的問題。

謹慎選擇以後難以更改的核心技術。

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

在考慮新技術時要謹慎，偏向保守的選擇。

開放路線圖，了解用戶的優先事項。

英文原文

https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum

點個好看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！