從很久以前開始，每當選擇技術棧時，我總是喜歡選擇那些逆向思維的技術。2000年代末使用Ruby進行網頁開發時，我沒有選擇Rails，而是使用了Sinatra搭配DataMapper。使用JavaScript框架時，我也沒選Prototype，而是用了MooTools。2010年代初期用Python做網頁開發時，我沒用Django，而是選擇了Werkzeug搭配SQLAlchemy。現在，我不用React和Next.js，而是使用Solid和SolidStart。我現在把這種不用主流技術，偏偏選擇另類替代技術的做法稱為逆向思維技術棧。與之相對的可能就是正統技術棧。

逆向思維技術棧最大的特點就是使用的人相對較少。因此，你會遇到更多問題，在排除故障時也常常無法使用別人已經找到的解決方案，而必須自己解決。但這也成為了深入理解該技術，甚至是整個領域的機會。例如，由於Werkzeug的抽象層級不高，我實際上必須在其上建立一個內部網頁框架來使用。當然，有人可能會認為這是在「挖坑」，但這樣的「挖坑」確實讓我成長了。當Stack Overflow上找不到答案時，我必須直接閱讀源代碼，在這個過程中，我甚至理解了HTTP協議的細節。而且如果這個技術是開源的，你也有更多機會為其做出貢獻。當你提交的拉取請求被合併時的那種喜悅，是在正統技術棧中難以體驗到的。

逆向思維技術棧的另一個特點是它們通常是後來者。也就是說，它們往往是由那些無法忍受正統技術棧中不滿意部分的人所創建的。因此，它們會採用替代性的設計。就像Solid為了避免React的虛擬DOM開銷而實現了精細化反應性（fine-grained reactivity）一樣。雖然並非總是如此，但這些替代性設計往往比正統技術棧的設計更好。這是因為它們通常是在學習了正統技術棧的錯誤選擇後，有意識地避開這些問題而設計的。因此，選擇逆向思維技術棧的人比選擇正統技術棧的人有更多機會獲得對該領域更好、更有條理的理解。

另一方面，正統技術棧在許多情況下都採用了綜合禮包的形式。想想Rails的「慣例優於配置」（convention over configuration）、Django的「內含電池」（batteries included）以及Next.js的全棧解決方案，雖然內部可能包含多種技術，但從用戶角度來看，它們的整合程度高到讓人感覺不到各部分之間的界限。相比之下，逆向思維技術棧通常需要用戶自己選擇各個組件然後自行組裝，這個過程雖然耗時，但好處是可以為每個部分選擇最佳選項，同時在組裝過程中也能更深入地理解每種技術。

這個組裝過程有時候很繁瑣。當組合Sinatra + DataMapper + Haml + Sass時，需要調整各自的設定、連接中間件、除錯錯誤，這些都需要時間。但在這個過程中，我更深入地理解了網頁框架實際如何運作，以及各層如何連接。而這種理解，無論日後使用什麼技術棧，都成為了寶貴的資產。

然而，有一點需要記住的是，今天的正統技術棧在過去可能也是以逆向思維技術棧開始的，而今天的逆向思維技術棧在未來也可能成為正統技術棧。Ruby on Rails最初不也是作為Java網頁開發的替代方案而崛起的嗎？React不也是作為Backbone.js等過去MVC前端框架的替代方案而受到關注的嗎？也就是說，我認為重要的不是特定技術本身，而是始終對新替代方案保持好奇心，以及在做技術決策時不僅僅依賴大眾的選擇，而是能夠自主判斷的能力。

由於LLM（大型語言模型）學習和推理分離的限制，未來正統技術棧可能會變得更加正統，而逆向思維技術棧的劣勢可能會增加。Claude Code可以輕鬆編寫Next.js代碼，但在處理SolidStart代碼時卻會遇到困難。儘管如此，我仍然認為逆向思維技術棧能提供的學習機會依然存在。

即使在LLM時代，我也會繼續走逆向思維的道路。因為逆向思維技術棧提供的學習機會超越了簡單的知識獲取，它培養了對技術更深層次的理解。所以，我建議讀到這篇文章的各位，偶爾也嘗試走一走在Stack Overflow上找不到答案的路。在那條路的盡頭，你所獲得的領悟將完全屬於你自己。