Think twice before using your hammer to drive screws

You should go read Frank Taylor’s Rant on Front-End Development. I don’t agree with everything, but he makes good points where we differ and I’ll just have to sit with those for a bit and decide if Frank is right. It is a sweary rant, though. He says:

Ask your scrummaster if 8 points of profanity is too much to handle today.

As your scrum master, I have to say that only you know if it’s too much to handle. Consider the risks of being wrong, and if those are tolerable to you then press on ahead. Maybe it’s worth a conversation in the retro.

Like Frank, I find it really confusing when people use JavaScript — or worse, JavaScript frameworks — to solve problems the long way that have already been solved by other areas of the platform. For example, I have never found a situation where using Gatsby or NextJS was superior to using a server-side language like PHP, Ruby, or ASP to do the same thing. Generally speaking, React Server Side Rendering might have some use-cases, but I bet most of the places it’s used more out of (perceived) developer convenience than anything else.

“I already know React, and PHP sucks.”

I call this “domain shifting,” and it happens when you move a problem from one area you are unfamiliar with (CSS) to another you are more familiar with (JS) without regard for what gets lost along the way.

Now, I will never argue that CSS in JS is always wrong. Sometimes it is the right thing to do, either for a project architecture or because the CSS actually needs to be rendered more dynamically. CSS-in-JS solutions are best wielded by people who already know CSS pretty well; they can choose how and what to leave to vanilla CSS and what needs the JavaScript touch. But all too often — as Frank points out — it’s just a way for developers to domain-shift their way out of learning a new skill.

Another reason teams might choose to use an unsuitable tool is because there’s a misguided effort to keep the toolset small. For example, in my day job we have one application that absolutely needs a JavaScript framework because it’s a full-fledged web app. Another uses a JavaScript framework and clients-side rendering when something more along the lines of Eleventy would be more appropriate.I suspect the latter, newer project inherited the framework from the older out of a desire to keep the development stacks as similar as possible.

“But John,” I hear you saying, “Surely we can’t have people choosing tools willy-nilly.” Of course not, and also get out of my house. It makes perfect sense to say “We are a PHP shop” and avoid ASP; the tools are similar, they do similar things, and they fill a similar role. It’s tricker when it comes to frameworks. People say “when all you have is a hammer, everything looks like a nail.” But “we only use React” is like saying “let’s only use nails.” Using React for a small, static, content-heavy website is like using a nail-gun to hang pictures on your wall: the task calls for finesse, not raw power. Likewise, if you have a web application that requires a lot of interactivity and complex state management, you will really wish you had used a framework to manage that… or you will end up writing your own.

Rules are powerful and you should deploy them sparingly. You should also deploy them for better reasons than “I don’t want to learn something new.” For better or worse, the web platform is made up of many different languages. Effectively building on it requires us to be multi-lingual and multidisciplinary. You can’t domain-shift your way out of that. Not without serious consequences.