I've always had a habit of choosing contrarian technologies when deciding on a tech stack. In the late 2000s, when developing web applications with Ruby, I used Sinatra with DataMapper instead of Rails. When using JavaScript frameworks, I opted for MooTools instead of Prototype. In the early 2010s, when developing web applications with Python, I avoided Django and instead used Werkzeug with SQLAlchemy. These days, I use Solid and SolidStart instead of React and Next.js. I've come to call this tendency to deliberately avoid mainstream technologies in favor of alternative ones the Contrarian Stack. The opposite would probably be something like the Conventional Stack.

The most notable characteristic of the Contrarian Stack is that relatively fewer people use it. This means you're likely to encounter more problems, and when troubleshooting, you often can't rely on solutions others have already found—you have to solve issues yourself. However, this becomes an opportunity to develop a deeper understanding of the technology and the field beyond it. For instance, Werkzeug's low level of abstraction meant I essentially had to build an in-house web framework on top of it. Some might consider this "reinventing the wheel," but such "wheel reinvention" has undeniably helped me grow. When Stack Overflow didn't have answers, I had to read the source code directly, and in the process, I gained a detailed understanding of the HTTP protocol. And if the technology is open source, you get many more opportunities to contribute to it. The thrill of having your pull request merged is something you rarely experience with a Conventional Stack.

Another characteristic of the Contrarian Stack is that it often consists of late entrants to the field. These are frequently created by people who couldn't tolerate the frustrations of the Conventional Stack. As a result, they tend to implement alternative designs. Take Solid, for example, which implements fine-grained reactivity to avoid React's virtual DOM overhead. And while it's not always the case, these alternative designs are often superior to those of the Conventional Stack because they learn from and avoid the mistakes of their predecessors. This gives users of the Contrarian Stack more opportunities to develop a better, more refined understanding of the field compared to those using the Conventional Stack.

Meanwhile, the Conventional Stack often takes the form of an all-in-one package. Think of Rails' "convention over configuration," Django's "batteries included," or Next.js's full-stack solution—they're all well-integrated to the point where users don't feel the boundaries between the various technologies they encompass. In contrast, the Contrarian Stack often requires users to select and assemble various components themselves. While this process is time-consuming, it offers the advantage of being able to choose the best components, and the assembly process provides an opportunity to gain a deeper understanding of each technology.

This assembly process can sometimes be arduous. The time spent configuring and connecting Sinatra + DataMapper + Haml + Sass, setting up middleware, and debugging errors. But through this process, I gained a deeper understanding of how web frameworks actually work and how each layer connects. And that understanding has become a valuable asset regardless of which stack I use later.

However, it's important to remember that today's Conventional Stack might have started as yesterday's Contrarian Stack, and today's Contrarian Stack might become tomorrow's Conventional Stack. Didn't Ruby on Rails initially emerge as an alternative to Java web development, and wasn't React once noticed as an alternative to older MVC frontend frameworks like Backbone.js? In other words, I believe what's important isn't the specific technology itself, but rather maintaining curiosity that always looks toward new alternatives and making technical decisions based on your own judgment rather than simply delegating your choices to popular opinion.

Due to the limitations of LLMs, where learning and reasoning are separated, the Conventional Stack will likely become even more conventional, and the disadvantages of the Contrarian Stack will grow. Claude Code can effortlessly write Next.js code but struggles with SolidStart. Nevertheless, I believe the learning opportunities that only the Contrarian Stack can provide will remain valuable.

Even in the age of LLMs, I will continue walking the contrarian path. This is because the learning opportunities provided by the Contrarian Stack go beyond simple knowledge acquisition—they foster a deeper understanding of technology. So I encourage you, the reader, to occasionally walk a path where Stack Overflow doesn't have the answers. The insights you gain at the end of that journey will be entirely your own.