Variety, but of something different
I tested spinning up an Eleventy site to see if it would help me scratch some itch about keeping things simple in how I’m maintaining this blog. After scanning the docs, I just realized that the API it’s introducing is yet another way for me to self-induce web development fatigue.
I know that Eleventy compiles fast and is lean, but sometimes I wonder if blazing fast build times are still a good enough reason these days to create a framework that is slightly different. This is not to say that I’m not concerned about performance, but performance without a significant return on investment just doesn’t do it for me. I eventually changed my mind and chose to stick with my legacy Next.js app because it works, and it is easier for me to do things with it because of my familiarity with it.
I also realized that it is easy to learn the API of a new framework or library. What’s difficult is:
- implementing robust code
- scaling
- solving somebody’s major pain point
- minimal yet effective software architecture
- software architecture that stands the test of time
In my observation of the JavaScript ecosystem, many hyped software products are simply repackaged versions of existing working software. There’s a new library or framework claiming to be the fastest and the best for software development every two weeks. At this point, it’s simply a mess.
There are times that I envy C++ developers because, despite C++ being regarded as old technology that should be replaced with Rust, I feel like they are the ones engaged in actual software engineering and in maintaining software that truly matters. If you want to deal with a lot of legacy code, be a JavaScript developer - you will find that by next week, many of your dependencies will start giving you warnings, telling you to upgrade them. What a pain. As if upgrading is always for free.
It’s true that technology and change go hand in hand, and we cannot stop technology from evolving. But a lot of times, what’s called “new” in the JavaScript ecosystem is simply a rehashed way of doing something from a different library or framework. “Oh, your React app renders just fine? Let’s make it 1000x faster because faster is better.” “Are you struggling to scale your persistence layer? Maybe you should migrate to this new and shiny ORM that promises instant productivity for your whole team. Just try it; you’ll never regret jumping ship.” Everything is just a rat race at this point.
What I’m doing about it
To cure my JavaScript fatigue, I decided to unfollow newsletters about JavaScript and related topics like Node.js and React. JavaScript is still my daily driver at work, but now I’m choosing to leave it there and learn something else in my free time that I believe will make me a better engineer, such as system design and functional programming in Elixir. Learning the API of yet another JavaScript library for the nth time will certainly make me lose my crap.