Being a backend developer, it’s sometimes nice to be given the option to do something different. Right now I need to make changes to a Vue frontend project to support some work I’m doing in the backend. And while working on the HTML template of a new component, a funny feeling came to me: “wait, is this too much HTML? Should I be abstracting this out into another component?”

The want to build reusable components before you know you need them is a seductive one. You’re not just writing HTML, your “engineering” something: building the bricks that, when assembled, will be the application. It’s not just in frontend thing: Java development was much like this, with Spring containers wiring up individual classes that all have abstract APIs, so if you want to trace execution within the editor, you’re traversing through a bunch of frameworks you have no knowledge about just to reach the code you need.

Now this could be a little unfair. I have very little experience with Vue and the various other frontend tech this project it using. So this all could come from a place of ignorance and maybe there’s a really good reason for composing things like this. There’s a reason this form of development became popular after all. But I do wonder if some of the trade-offs are being discounted. This form of decomposition has a price, in the form of readability and simplicity, and I somethings wonder if the benefit of reusability you’re paying that price for is oversold. When changes come through, I usually see people just rewrite the components.

I don’t know. This is all probably because I’m paying that price myself now. But when you’re exploring a project you’re unfamiliar with, you tend to pick up patterns from the code that’s already there. And I found it interesting that I felt that my component had too much HTML.