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.
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.
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.
in Asp.net / C# / Episerver / Episerver / Episerver cms / Site extraction / Web development on Episerver, Episerver cms, C#, Asp.net
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?
in Asp.net / Octopack / Octopusdeploy / Teamcity / Web development
Traditionally, front-end code is compiled locally, the generated files are included in the project and then pushed out to source control. This is a redundant step and one we should get rid of, especially if we’re using build servers like TeamCity, and Octopus Deploy for deployments.