前端技术选型的遗憾和经验教训
我是 Max，Spectrum 的技术联合创始人。Spectrum 是一个面向大型在线社区的开源聊天应用程序，最近被 GitHub 收购。我们是一个三人团队，主要拥有前端和设计背景，我们在这个项目上工作了近两年时间。
事后看来，以下是我做出的令自己感到遗憾的技术选型以及从中学到的经验教训。
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 自己成为更好的产品。但这样会节省我们的时间，让我们花更多的时间进行实验。
总而言之，以下是我总结的六个经验教训。
构建一个好产品就是要不断进行实验，加快开发速度，为了迭代速度和灵活性而优化。
尽可能使用现有的解决方案来解决技术问题，特别是那些你不了解的问题。
谨慎选择以后难以更改的核心技术。
在选择技术时，优先考虑社区规模和维护活跃度，尤其是在不熟悉的领域。
在考虑新技术时要谨慎，偏向保守的选择。
开放路线图，了解用户的优先事项。
https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum
点个好看少个 bug 👇