Shipping vs. Fiddling
I’ve recently switched to a new computer and did a clean setup. A few days ago I needed to do a tiny update to my home page which is built with Jekyll. Jekyll is a static site generator built with Ruby, so had to install all required dependencies before I could change anything. Things didn’t go smoothly and I failed to get it to work on my machine. And since I’m not doing Ruby at my work, I decided it’s a good time to switch to something more familiar to me. So I tweeted about:
Some people replied that I’d better fix my Ruby installation and even provided me with guidance (which I’m thankful for). Some replies, though, were less helpful saying “Jekyll is better” without getting any context:
And since Twitter isn’t the good place for discussions, I thought I’ll write a longer post.
Curiosity vs. Getting Things Done™
When I was younger, I was very curious about how things work. I could spend hours disassembling an old radio or fixing a bicycle. Curiosity is the reason I become a software engineer in the first place. As time passed, I was less and less interested in how things work and more in getting things done. Probably, I’m just getting older :)
The truth is, modern software is so complex there is no chance you can understand how things work without spending a decent about of time digging in. And when it happens to be that you’re an expert in something because you spent the last couple of years digging it full time, this piece of technology becomes your favorite choice when something needs to be done quickly.
So when people suggest that the technology they are familiar with is better than the technology I am familiar with I think they are missing a fact that all I want to do is to update my website, not to learn or fix my tools first.
It works… until it doesn’t
— You’re just not qualified enough to set it up!
— If you’d just do XXX, it would all work!
— This guy is stupid!
Probably this is your reaction right now, but believe me, before switching to a more familiar JavaScript environment, I had a couple of projects built with Ruby.
Get Andrey Okonetchnikov’s stories in your inbox
Join Medium for free to get updates from this writer.
A good example is the ColorSnapper landing page — a product I and my friend built a while ago. It was also built using Jekyll since it was the simplest way of building and hosting a static website back then. And it worked flawlessly… until it stopped.
One day I had to do a small content update on the website and I run into major problems with my Ruby or Sass installation. I kept fighting it for hours trying everything I could find on StackOverflow and even reached to my Ruby friends to only get 🤷♂️ as an answer.
JavaScript to rescue
So I switched to Webpack and libsass to generate my assets. Not only it worked perfectly well, but it was faster and I got some benefits like Hot Reloading of CSS (without external tools like BrowserSync) and Autoprefixer integration so I could finally skip writing prefixes manually.
At that moment, I already had to give up on “magic” website generation by GitHub since I had to use some Jekyll plugins that weren’t supported by GitHub (for security reasons) and commit the generated sources all along (which I never felt good about, to be honest).
So when Netlify launched, I ditched Jekyll and Ruby in favor of Metalsmith — another static site generator built in JS without hesitation.
It took me some minimal amount of time to write a Metalsmith Webpack Dev Server plugin to improve the experience of local development even further and I was all set. Since then I had zero problems with this stack and even could extend it to generate our “What’s new” page automatically using a simple plugin I open sourced for everyone every time another developer creates a release in a separate repository.
Choose a tool you know best
JavaScript might be not the right answer to every problem but it happens to be the tool I know the best. When it comes to choice, you should choose a tool that makes you productive and happy to work with, even if it feels wrong to someone else.
Garett Dimon wrote a great post about choosing the tools that speed you up. James Long mentioned a similar experience he recently had when launching his own product:
Remember, it’s not them who need to do the job and your users don’t care what you’re using either. So, don’t listen to anyone (myself included!) and pick tools you are most comfortable with at the moment.
Happy shipping! 🚢
