Feb 10, 2021
In a world of page builders, WYSIWYG editors, pre-made themes, and software that writes code for you - some people are surprised to hear that I still Handcode my websites - out of choice. Not only do I choose to Handcode my websites, but I also emphatically believe that this is the best way to go about it.
In this blog, I want to discuss some of the reasons why I believe this, and why given the choice, I will always opt to hand-code something versus using an editor.
It should be stated that despite this preference, I still frequently am required to use various editors. My preference to hand-code my sites is not at all based on an inability to use the other options. I am very well-versed in almost all of the other options out there - and because of that experience with these other options, I can say with even more confidence that hand-coding is the way to go.
For skimming purposes, I’ll summarize the five main reasons that I choose to hand-code my websites here:
One of the biggest frustrations that I encounter with using editors is that they are often unpredictable. For example - let’s say I drag an element onto the “canvas”, click on the settings, and add some padding to the element. When I inspect that element using the browser inspector tool, I usually find that the padding has not been applied to the element that I “think” it was applied to. Almost 100% of the time, a lot of additional, unnecessary markup gets added, and the padding gets applied somewhere in that.
The result of this of course is unpredictability. It’s more difficult for me to make a site responsive, or to look a certain way on a certain device, when I am not sure where any of the settings that I specify are going to be applied.
This is a non-issue when I write my own code. With a hand-coded site, I have complete control over exactly what markup is produced, and what styles get applied to that markup.
As I mentioned in the previous point, my biggest pet peeve with editors and page builders is the amount of unnecessary markup they spit out. Say what you will - but there is no universe where the 5 lines of markup that I write will not outperform the 75 lines of markup that an editor vomits out for the very same outcome.
In fairness, I acknowledge that we’re really only talking about milliseconds of processing power - but, with search engines using page speed as a ranking factor, even milliseconds can make a difference.
The data around page speed and performance is clear. According to this article (https://www.marketingdive.com/news/google-53-of-mobile-users-abandon-sites-that-take-over-3-seconds-to-load/426070/), a whopping 53% of users will leave a siite if it doesn’t load within 3 seconds.
So - if 3 seconds is our performance bar, your darn right those milliseconds matter.
There is also a reason why almost all of the sites that I develop have a score of 90% or higher on Google Pagespeed Insights.
Bigger, national brands, such as Nike and Apple can of course get away with having slower loading sites, because competition is not usually quite as steep.
However, for small businesses, any competitive edge that exists is one worth taking. So - if I can help my clients websites load more quickly than their competitors - I am absolutely going to do that.
Tell me, what code do you think is easier to read?
<a title=“3 Keto-Friendly Recipes” href=“/3-keto-friendly-recipes”>3 Keto Friendly Recipes
OR:
Even if you don’t understand HTML, it should be plainly obvious which of these examples is easier to understand. Now, imagine if you were visually impaired, and relied on a screen reader to interpret the intention of the HTML markup. Which one do you think the screen reader would have an easier time processing?
Once again - having full-control of the markup of a page puts the websites that I build at a significant advantage when it comes to accessibility and readability.
While it is true that computers are generally going to be better at reading code than humans, they are NOT good at inferring meaning from poorly written code.
And unfortunately, unclear meaning & intent is not good enough when providing a positive experience to ALL users, regardless of what disabilities they may be facing.
Forcing a screen reader to interpret overly complex, and convoluted code would be a little bit like having an audiobook repeated back to you by a robot, compared to a professional narrator. Clean code, semantic markup, and well-structured content all matter in accessibility, just like tone, inference, and emphasis all matter in speech.
I can only speak for myself here — but I am a fast typer. I average between 80 - 100wpm. I am not at all saying this to brag. (Well - maybe I am a little bit.) But mostly, I am simply stating that between my fast typing, my understanding of code, and my years of experience... it is almost always faster for me to write the markup and styling that I need, compared to clicking on buttons in an editor, and having the editor write it for me.
When I am required to use an editor, by the time I have the elements on the canvas, and have gone through the myriad of options for each element (90% of which I don’t need), there’s simply no comparison. It is faster for me to write things by hand.
Again - this is not me bragging - but I hand write code simply because I can. Many web developers don’t have that luxury. They are dependent on what they can accomplish with a web-builder. This is perfectly okay! I’m not knocking them. If they are able to run a profitable business in this way - I applaud them for finding something that works for them. But, being that I DO have that luxury, it is always to my benefit when I can code something that would otherwise not be possible through an editor alone.
Really - this list is the tip of the iceberg. I am sure I could come up with dozens of other reasons why handwritten code is preferable to relying on a page builder.