The Terrastruct Blog

Controversial web development tips

September 19, 2020
|
by Alexander

This is a collection of opinionated beliefs that I hold about web development that are not generally agreed upon.

  • Make every interaction feel snappier by catching events on mouse down instead of up/click.

  • Keep UI animations between 100-200ms. Less than that and it's subject to choppy fps. More than that and you're trading off snappiness for smoothness. Unless your website is more artistic than functional (e.g. a web design portfolio), that's not a good tradeoff.

  • For styling changes, develop on Safari, test on Chrome. In my experience, the rendering engines diverge much more than the Javascript engines (though I've run into my fair share). For most of my development, I only test on one browser (I alternate), but when it's a big layout change, I'll develop on Safari and test on all. What I've found is that things almost always look better on Chrome by default; I think because Chrome makes more/better assumptions for you. I used to develop on Chrome, but whenever I've had styling have an unintended look on Safari, the solution was usually to add CSS lines to be more specific about what I want. I now just develop on Safari, and I've never run into a case where it looks good on Safari and then bad on Chrome.

  • Fork libraries when they don't do what you want. Modern web dev is a lot of lego, and there will be times when you can't find the right piece. You can evaluate 5 different libraries for doing something, but if none of them are doing what you want, just take the one that's closest, fork it, and tweak it. It sounds scary, but it's usually really not that bad. Plus, what else are you going to do, file an issue, hit pause on development, and cross your fingers the maintainers get to it soon? Develop your own library from scratch? If the library is as small as Redux, that's an option, but then you probably shouldn't have used a library in the first place [0] (don't be the guy that includes your company's app in the next left pad apocalypse [1]).

  • Never use display: inline-block again. I was trained on this being the standard for horizontal layouts, but flex is superior in every way. I had lingering one-digit pixel vertical misalignments for years in production due to display: inline-block.

  • It took me half a decade to question the practice of putting cursor: pointer on the :hover pseudoselector. Maybe I read it in a tutorial or something when I was learning, but yeah, the cursor would never come into play when it's not hovered, you can just include it in the element's primary CSS lines.

  • Upgrades are dangerous and should be generally avoided. They can have hidden consequences that you can't find by testing via doing the upgrade and poking around. Once a month or so, read the release updates for libraries you depend on. If you've had a year of bug-free life with a particular library, that's built-up synergy of that library with your app that takes a big hit with an upgrade, especially a major version one. Personally, I only upgrade when the release notes list a significant performance increase, has something along the lines of "fixed a nasty bug that crashed everything", or has a feature I've been waiting for.

  • Your choice of library can have a substantial impact on the future of your project in terms of time saved or wasted, you should be picky as hell. If there's choices in which library to use, which there usually is, my first choice will be the one with most stars and has been updated recently, frequently, and doesn't have major outstanding issues that are just sitting there ignored. I'm willing to go with 2nd or 3rd most stars if the updates are much more recent and frequent, but I'll start looking more carefully into the outstanding issues and recent releases.

    Occasionally, I break the tie by who the creator/maintainers are. Some people have great track records of just banger libraries. I will use any library fatih (https://github.com/fatih) releases, even if it has 0 stars.

Notes

Want to learn more about software architecture?

We host a newsletter where we invite experts to do case studies on the architecture of popular open source software. We'll send you one email a month with high-quality diagrams that help you understand how the most used software around the world gets built, free.