Boring technology and the five-year rule

I’m a firm believer in choosing boring technologies when building products. I find that each time I use newer technologies, it is usually because I’m more enamored with the technology than the actual product idea itself. In this sense, I’ve grown to dislike newer technologies - or talking about them - as I find that it distracts me from my aim of making useful things.

Of course, the difficulty lies in determining what is boring and what is not. I have come up with a simple rule of thumb, that seems to work:

Choose something that would solve your problem five years ago.

I think it is important to also add a qualifying clause as well.

And would do so in about the same manner then, as today.

This allows us to easily filter out technologies that have the same name, but had significant breaking changes to the point that they could and should be considered different.

Boring technologies

Let me demonstrate some technologies that pass this rule of thumb.

PostgreSQL

Obviously, Postgres passes the test!

I’m fairly certain that our use of Postgres would be completely the same today as it would be five years ago. Ours is a pretty standard CRUD app, after all.

Phoenix, Elixir, Ecto

Despite their relative obscurity when compared with Rails or Django our main backend stack of Phoenix, Elixir, and Ecto all pass this rule!

Ecto 3.0 came out just about five years ago, so passes the test just fine.

The differences between Phoenix 1.4 of five years ago and Phoenix 1.7 today are pretty minor when we exclude LiveView. We don’t use LiveView, so Phoenix passes the test.

There were many quality of life improvements between Elixir 1.7 of 2018 and the Elixir 1.15 of today, but for most of our application coding these would make little to no difference.

The only aspect of this stack that does not pass this test is the migration from EEX to HEEX templates over the past five years within Phoenix, but EEX is still supported for Phoenix applications, so I don’t count that as breaking the rule.

Mithril.js

Mithril.js 2.0 came out in 2019, so on the surface it seems like it would not pass the test. However, the changes between 1.0 and 2.0 are minor enough that our mild use of the library would likely be unaffected, so it passes the test for us. The breaking change was mainly cleaning up unused APIs, if I recall correctly.

Not-boring technologies

Vue

Vue has been around for a long time, but unfortunately has had so many breaking changes that I don’t consider it a boring technology.

There are many examples of libraries, like Buefy that worked fine in the Vue2 of five years ago but are now effectively on life support and won’t be migrated to Vue3.

So using Vue now and using Vue five years ago to solve our problems would be fundamentally different, so it does not pass the test.

However, Vue was recently chosen as the official Javascript framework for MediaWiki. Perhaps three years from now VueJS 3 will still be mostly the same, at which point it will pass our test.

HTMX

The first commit for HTMX came out in 2020, so it does not pass the test. Out of the main Javascript libraries we use, this is the youngest one. Since it does not pass the test, it comes as no surprise that most of our rough edges we encounter on the frontend come from it, but we have always found workarounds.

We like it well enough, but perhaps should have chosen something more boring. Unfortunately, the most important thing it provides to us - navigation-over-AJAX - does not seem to have any stable equivalent that would have passed our test. The closest is Turbolinks which has not been maintained for the past two years and was redeveloped to turn into Turbo. Our usage of it is light enough that we could rip it out if we needed to, at least.

SQLite via Ecto

SQLite is certainly boring technology, but I consider using SQLite3 within a Phoenix application to be too cutting edge. This is because the Ecto adapter and the SQLite database driver that one would use five years ago and the ones used now are completely different with different behaviors. I know this because I helped build both the modern Ecto 3.0 adapter and the exqlite driver!

When I started building HanziHero, I wanted to use SQLite3, but decided that the lack of others building SQLite-powered web applications in Phoenix to be an indication that it was not the Boring path. Given that our application is actually quite write-heavy, this was a good choice.

Conclusion

Our choice to use boring technology allows us to focus on helping our users learn Chinese characters. That singular purpose continues to be our north star in terms of the features we develop and the technologies we use.

If you are looking to temper your enthusiasm for technology and focus on the product itself, I recommend trying out this rule of thumb.

Choose something that would solve your problem five years ago, and would do so in about the same manner then as today.

It has worked well for us!