Don't Roll Your Own ... - Susam Pal
Don't Roll Your Own ...
By Susam Pal on 23 May 2026
This is going to be a rant about modern web design practices. But<br>before I get to that, let me begin with a familiar principle from<br>the world of cryptography. Among software developers, and<br>especially among those who work on security-sensitive systems, there<br>is a well-known maxim: Don't roll your own crypto. This<br>does not mean that nobody is allowed to write cryptographic code.<br>Someone has to. It means that, for ordinary production software<br>that protects sensitive data of users, we should not rely on a<br>private, unreviewed implementation that has not been vetted by the<br>wider software development community. We should use established,<br>vetted software packages or tools wherever possible.
Fortunately, it is now standard industry practice to avoid rolling<br>your own crypto and instead use cryptographic algorithms and<br>packages that have been peer reviewed and stood the test of time.<br>It wasn't so some twenty years ago. I have seen several flawed<br>home-grown RC4 implementations early in my career, with issues like<br>improper initialisation vectors, predictable keystreams and partial<br>leakage of plaintext into ciphertext, putting sensitive data of<br>users at risk. But today, major e-commerce websites or banks<br>typically do not use home-grown cryptography for its web services.<br>In fact, in regulated domains such as payments, healthcare and<br>personal data processing, doing so could violate requirements for<br>strong cryptography, possibly leading to hefty financial penalties.
Website design is obviously not cryptography. A broken scroll bar<br>is not the same kind of failure as a broken encryption scheme. But<br>I wish there were a similar maxim for website design as well. There<br>are many aspects of websites where, I think, developers should not<br>be rolling their own X, especially when X is something browsers<br>already do well and something users depend on every day. Here I<br>present a list of such X.
Don't roll your own page scrolling.
Don't roll your own link navigation.
Don't roll your own text selection.
Don't roll your own context menu.
Don't roll your own copy and paste.
Don't roll your own password field.
Don't roll your own date picker.
Of course, there are valid scenarios where you may need to roll your<br>own X. But here I want to focus on the cases where you should not<br>roll your own X, and how doing so can lead to a worse user<br>experience, at least in my experience. I am not saying that nobody<br>should ever build anything themselves. As someone who does a lot of<br>creative computing myself and develops fun tools from time to time,<br>I am a big proponent of developing your own stuff. But when it<br>comes to developing user interface features for serious websites<br>that people need to use to get their work done, I wish the software<br>development community were more conservative in deciding what fancy<br>feature goes into a website and what is left out. Do keep in mind<br>that I am no expert in user experience. Far from it. So none of<br>what I am saying here should be taken as a recommendation. But I am<br>a user of the Web, and as a user, I have found some modern<br>web design patterns to be frustrating. This post is a lament from<br>one user of the Web, not a design guide.
Of all the things I mentioned above, the one that bothers me the<br>most is custom scroll behaviour on websites. I am used to how page<br>scrolling responds to my mouse, touchpad or keyboard input. When<br>you override the default scrolling behaviour of the web browser with<br>your own implementation, it 'breaks' the page for me. The page now<br>moves too slowly or too quickly when I scroll. Keyboard scrolling<br>may or may not work. You take something I am so familiar with that<br>I don't even think about it, and turn it into something unfamiliar<br>that I now have to think about.
Custom link navigation is another pet peeve of mine. Web browsers<br>can already handle links very well. You could say that this is the<br>whole reason web browsers even exist. Following links is their<br>bread and butter. You shouldn't have to mess with that behaviour at<br>all. If you think you need to, reconsider what you are trying to<br>achieve and whether it is really so important as to disrupt normal<br>link navigation. The worst offender I have found here is GitHub.<br>When you click on a link on GitHub, say, a file link or an issue<br>link, it triggers a massive piece of functionality implemented in<br>JavaScript that handles the link click for you. If you don't<br>believe me, visit your favourite project on GitHub using Firefox or<br>Chrome, type F12 to open the browser's developer tools,<br>then go to the 'Debugger' or 'Sources' tab, find 'Event Listener<br>Breakpoints' on the right sidebar, expand 'Mouse' and select<br>'click'. Then click on a link on GitHub and see what happens.
I'm sure I am not the only one who has noticed that, on GitHub, a<br>clicked link sometimes takes too long to load. Ironically, it is<br>often faster to open the link in a new tab than to wait for...