Dzulqarnain Nasir

Smart Bundle Management Using JavaScript Modules

I recently read an article on SmashingMagazine on managing bundles for modern and legacy browsers, in which the author had discovered that bundles built for legacy browsers are, on average, 25% larger than those created for modern browsers.

This is mainly due to the fact that native support for ES6 has resulted in the possibility to achieve the same results with less code. Unfortunately, legacy browsers such as Internet Explorer lack support for most, if not all, of ES6, forcing developers to include workarounds and polyfills just to get things working, resulting in larger bundle files.

In the article, the author suggested creating separate bundles for each platform, and employing server-side browser sniffing to serve the appropriate bundle to users.

While this method works, there are numerous reasons why browser sniffing is bad.

Webpack, Moment.js and CDNs

In one of my projects, I needed to implement MomentJS with localisation. I thought, “Alright, this should be simple enough.”

Here’s the funny thing about “simple” tasks. There’s always a catch. It just so happens the catch with this one is that I had to make the site load MomentJS from a CDN server, and fallback to a local copy in the event CDN is down.

Still, it’s not really a big deal - or so I thought.

Once I’ve set everything up, I ran Webpack. I immediately noticed that the file size had increased by over 500 kB.

Five hundred kilobytes! What on earth..

Turns out the moment I imported a MomentJS locale file into one of my files, for some bizzare reason webpack decided to include the entire MomentJS library, AND ALL THE LOCALE FILES.

Solving the annoying package-lock.json integrity discrepancy

One of the most annoying feature, in my opinion, added to the Node Package Manager (NPM) is the automatically generated package-lock.json file, which is used to “describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates”.

As described in the documentation, one of the benefits of using package-lock.json is that it “describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.”

Ironically enough, the package-lock.json has created more annoyance within the team than anything else.

You should be using HTML picture - with workarounds

One of the biggest culprit to website data traffic, if not the biggest, is images. Due to the increase in the number of devices with high resolution display, content creators have started using high resolution images to improve the look and feel of their websites. This results in large amounts of data needing to be downloaded by everyone, including those not using hi-res displays.

HTML picture is an extension for the image element that allows us to add multiple image sources based on predetermined rules.

My experience moving an EPiServer site to a new project

Every now and again we get sites that have grown so huge that it becomes necessary to extract certain parts of the site and convert them into separate sites. What was once a simple landing page had turned into a huge member-based system that involves stuff like integration with external service providers. True story.

Typically the simplest way to solve this little scenario is to simply move the section to the Root node of the EPiServer site, and assign it its own URL in the website configuration tool. But what if you wanted to extract that section out of the project altogether and recreate it as an entirely new project?