Programming principles for self taught front-end developers – a response
Was reading an article by Kilian Valkhof on Piccalilli called Programming principles for self taught front-end developers and had some of my own thoughts from my experience to add. There are so many angles to programming that it’s hard to come up with a hard list that applies in every context.
Libraries
In the article Kilian introduces the principle of the rule of three. While I generally agree with this, especially in the world of design systems where I don’t think a component should be added to the design system unless it’s going to be used in at least 3 places.
Where I disagree with this idea is when it comes to library API interfaces. Whenever you build code that other developers will use, changes can be hard. Where this manifests is the API interface that the developer uses to interact with the library.
Component Props
The easiest example in my world of building components that are deployed in a library has to do with what props you offer to the developer on a component.
This is a simple API interface to the button where we have a single prop that determines the styling of the button.
However there may be a moment where it is decided that this no longer serves us and we need to break this out into multiple props to better organize our code inside (a slightly contrived reason, but simple for this example). It might turn into something like:
This is a breaking change and a major pain for the developers who then have to refactor every place where that <Button> component is used.
The only real answer here is experience. Take some extra time to think through future use cases, look at how other libraries present developer facing API interfaces and then stick with it. It will mean you may be stuck with some things you don’t quite like anymore. It is always a balancing act of optimization vs developer pain.
I would then modify the rule of three to include the caveat, except when dealing with API interfaces - these need to be optimized early.
Front-end optimizations
The other area I see some nuance is in the front-end, specifically the presentation layer. I often have developers show me a page that “works” but is crazy list of selectors and styles that make a mockery of the cascading portion of CSS.
The problem with CSS and implementations that just work is that the final output is brittle and breaks with the next update. There is a great deal of subjectivity that goes into front-end work. Figma can never represent exactly how a site will translate on the web due to the web’s very nature. It may look fine with a viewport width of 1200px but what about on smaller devices at 360px? What about shorter screen heights? Or a height that changes depending if you’re scrolling up or down? What about set-top devices, accessibility, and the list goes on…
To say “it works” never means every possible scenario has been validated personally (an impossibility…). Instead it usually means, “it works with the limited set of variables, browser, OS, screen width, that I’ve been working with.”
Optimization in this case comes down to understanding how CSS works and building in a standards based way that you know will theoretically scale to most situations even if you can’t personally validate them all. I wrote about this in more detail in the post The Reductionist Approach to CSS - Why Less is Usually More.
I will probably be shouted down that CSS doesn’t qualify as a programming language, but that’s a whole other debate :)
Principles are not laws, there is always nuance
I think framing these as principles is great. However, I think sometimes people, especially junior developers, relate to principles as laws.
Principles are guides that apply to most situations. But there is always nuance. As much as we want to simplify things into basic rules, that’s just not the world we live in. Experience matters and will continue to matter even in the age of AI.
I’m definitely not arguing with the principles that Kilian is laying out, only adding some of the nuance from my experience.