在选择技术栈时，我一直有点像"唱反调"的人。2000年代末使用Ruby进行Web开发时，我没选择Rails，而是使用了Sinatra搭配DataMapper。使用JavaScript框架时，我没选Prototype，而是用了MooTools。2010年代初用Python做Web开发时，我没用Django，而是选择了Werkzeug搭配SQLAlchemy。现在，我没用React和Next.js，而是选择了Solid和SolidStart。我把这种不用主流技术，偏偏选择另类替代方案的做法称为唱反调技术栈。与之相对的可能就是正统技术栈。

唱反调技术栈最大的特点是使用的人相对较少。因此，你会遇到更多问题，在排查故障时也常常无法使用别人已经找到的解决方案，而必须自己解决。但这恰恰成为了深入理解该技术，甚至整个领域的机会。例如，由于Werkzeug的抽象级别不高，我实际上必须在其基础上构建一个内部Web框架。当然，有人可能认为这是"徒劳"，但这种"徒劳"确实促进了我的成长。当Stack Overflow上找不到答案时，我不得不直接阅读源代码，在这个过程中，我甚至理解了HTTP协议的细节。而且如果这项技术是开源的，你也有更多机会为其做出贡献。当你提交的拉取请求被合并时的那种喜悦，在正统技术栈中很难体验到。

唱反调技术栈的另一个特点是它们通常是后来者。也就是说，它们往往是由那些无法忍受正统技术栈缺点的人创建的。因此，它们通常采用替代性设计。就像Solid为了避免React的虚拟DOM开销而实现了精细粒度的响应式（fine-grained reactivity）。虽然并非总是如此，但这些替代设计往往比正统技术栈的设计更好，因为它们是在学习了正统技术栈的错误选择后，有意避开这些问题而创建的。因此，选择唱反调技术栈的人往往比选择正统技术栈的人有更多机会获得对该领域更好、更系统的理解。

另一方面，正统技术栈通常采用"一站式"的形式。想想Rails的"约定优于配置"（convention over configuration）、Django的"内置电池"（batteries included）以及Next.js的全栈解决方案，虽然内部集成了多种技术，但从用户角度看，这些技术的边界几乎无法感知，集成得非常好。相比之下，唱反调技术栈通常需要用户自己选择各种组件然后自行组装，这个过程虽然耗时，但有两个好处：一是可以为每个组件选择最佳选项，二是在组装过程中可以更深入地理解每项技术。

这个组装过程有时会很艰难。当组合Sinatra + DataMapper + Haml + Sass时，需要调整各自的配置，连接中间件，调试错误。但在这个过程中，我更深入地理解了Web框架实际如何工作，各层如何连接。而这种理解，无论以后使用什么技术栈，都成为了宝贵的财富。

然而，有一点需要记住：今天的正统技术栈在过去可能也是从唱反调技术栈开始的，而今天的唱反调技术栈在未来也可能成为正统技术栈。Ruby on Rails最初不也是作为Java Web开发的替代方案崛起的吗？React不也是作为Backbone.js等过去MVC前端框架的替代方案而受到关注的吗？也就是说，重要的不是具体使用哪种技术，而是始终对新的替代方案保持好奇心，在做技术决策时不要仅仅将选择依据委托给大众，而是要自己主动做出判断。

由于LLM（大型语言模型）学习和推理分离的局限性，未来正统技术栈可能会变得更加"正统"，而唱反调技术栈的劣势可能会增大。Claude Code可以流畅地编写Next.js代码，但在处理SolidStart代码时却会犯难。尽管如此，我认为唱反调技术栈所能提供的学习机会仍然存在。

即使在LLM时代，我也将继续走唱反调的道路。因为唱反调技术栈提供的学习机会超越了简单的知识获取，它培养了对技术更深层次的理解。所以，我建议读到这篇文章的各位，偶尔也尝试走一条在Stack Overflow上找不到答案的路。在那条路的尽头，你获得的领悟将完全属于你自己。