Reginald Mullin

I first became a front-end web developer in the year of our Lord, 1998.  Back then, the HTML specification had just reached version 4.0; Internet Explorer 7 was the dominant browser; and, the mantra of separation-of-concerns  was still being preached to web developers.  (Back then merely uttering the phrase CSS-in-JS  would've gotten you killed, professionally speaking.)  What's more, back then, HTML tables were still de rigueur; in fact, many websites used them for layout purposes ( DIV-itis hadn't caught on with the masses as yet; that would happen several years later.) Yes, it was the stone ages of the web -- in comparison to today.  Today, there's a wealth of newer technologies for developers to choose from when building websites, i.e. HTML5 , CSS4 , ES9 , etc.  Long gone is the mantra of separation-of-concerns and in its place sits CSS-in-JS, mockingly.  And, long gone are table-based layouts too; they gave way to the aforementioned DI...

I've worked at several major companies thus far in my career; and, at each of those companies, I've had to use an in-house Content Management System (CMS)  to create and modify digital content.  For a long time, I couldn't understand why those companies would choose to allocate time, resources, and ultimately money to create a customized CMS in spite of having functionally equivalent, open source solutions readily available in the marketplace.  What was their rationale for doing so, I often wondered?  Was their businesses so unique that an off-the-shelf CMS simply wouldn't cut it; were the security risks associated with an open source CMS too great of a burden to bear; or, was it because the software engineer(s) in charge at the time simply wanted to showcase their PHP, Java, Python, etc. programming skills by building yet another CMS from scratch.  Well, in the years since I first pondered that question, I've come to realize that the answer is often ...

I'm the proud father of two wonderful children, Kyle and Alexis. Kyle's an energetic six (6) year old boy and Alexis is his equally lively three (3) year old sister; they're both very cute and smart and headstrong.  From time to time, my children will say things - sometimes directly to me or to their mother or others - that gives me pause as a parent.  It's usually something clever or witty but on occasion, it's bad too.  In such moments, I often find myself awestruck by the seemingly guiltless words coming out of their mouths.  Naturally, I've decided to chronicle all of their "wise for their age" utterances in this blog post. Date: 12/13/18 (approximately) Scene: We're in the bathroom; Kyle sits down on the toilet to pee. Me: Why are you sitting down to pee? Kyle: So I don't spill pee everywhere. Lesson: More males should've been taught to sit down to pee; myself included. I must admit though, as a 41-year-old man, that statement...

Okay, you're here; welcome.  Let's get started right away.  First, you should always minify and compress your website's static resources using Gzip , Brotli , Lossless , etc.  (To be clear, by static resources, I mean HTML, CSS, JS, images, videos, fonts, etc.)  Next, you should use a Content Delivery Network to host said static resources, i.e. Cloudflare , Cloudinary , Fastly , etc. You shouldn't , however, bundle your static resources together; in particular, your CSS and JS files.  There was once a time, long ago, when it was considered a good strategy to bundle and shard your static resources, but that time's long since past.  Nowadays, with the ubiquity of HTTP/2 , you're actually doing your users a huge disservice by bundling.  In case you're unfamiliar with it, HTTP/2 reduces "latency by enabling full request and response multiplexing, minimizes protocol overhead via efficient compression of HTTP header fields, and adds support for request...

Google Tag Manager  (GTM) is one of Google's best products - second only to its ubiquitous and feature-rich Google Analytics product.  GTM, as its name implies, is a tag manager that's used to embed JavaScript, HTML, and/or CSS code into websites.  Such code can include, but is not limited to, analytics scripts like Google Analytics, tracking beacons from online advertisers, and proprietary content from websites themselves.  There's no denying that GTM is a powerful tool; one that represents a major shift forward from the bad old days of self-hosted, spaghetti-code.  But like most technology, if it's not used correctly, GTM could end up causing more problems for a website than it solves.  Problems having to do with slow performance, mostly; but also tag misfires, data corruption, and quota limitations.  In this article, we'll be discussing solutions to such problems by exploring the five (5) common mistakes that websites make when setting up GTM. M...

If you were given a dollar by every website that transferred unnecessary metadata to you, you'd be richer than Bill Gates!  Well, not really; but you'd at least be well off.  You see, very few people realize that the websites they visit on a daily basis are transferring useless metadata to them -- including seasoned website developers, designers, and marketers.  And, even when people do realize it, they often assume that it's a best practice.  It's not!  In fact, it's one of the reasons why the web has become such a bloated medium.  Well, that and images, stylesheets, javascript, fonts, etc. -- all of which are even bigger culprits than metadata.  Still, that's no reason to ignore metadata -- it's been ignored for far too long!  Thus, in this article, I'll shed some light on the problem of transferring unnecessary metadata on the web as well as discuss several solutions for dealing with it. What is metadata? According to Wikipedia , metadata r...

You've seen them before... those exceedingly long URLs of static resources on websites.  No?  Well, just view-source on your favorite website or copy & paste the address of a static resource from Google to see the problem for yourself.  Done?  You've probably noticed that the most ubiquitous examples by far are those of images -- many of which have cryptic URLs like " /images/G/01/gno/sprites/nav-sprite-global_bluebeacon-V3-1x_optimized._CB516556901_.png " and " /v/c/assets/navigation/image/drawer-sunwear/21/edee9f4c82.jpg " or even " assets/images/homepage/top/navigation/cart-icon.jpg ".  But the problem isn't limited to just images; there are other media types with exceedingly long URLs too, i.e. video, audio, CSS, JS, etc. When did this trend start? Over the past few years, it seems, the web has Gone Wild with exceedingly long URLs; or, perhaps it's website developers and designers who've gotten lax about their craft.  But wh...