Many methods, many implementations.

Just like in coding there’s many methods, there’s also many implementations.

From NuGet to NPM, to CDN’s.

A mammoth system using all three can get confusing very quickly.

Let’s start by the most famous framework out there Bootstrap!

Imagine there are different variations of it.

The original, the Sass, the older version (just because it was release with a version name), the third party types (usually plugins that provide additional functionality with their version of compatibility to Bootstrap).

And let’s associate this is within NuGet.

Then bring in NPM an alternative, where front end tech stacks can be searched online and installed through command lines using webpack or something similar to bundle and serve.

Of course you may find Bootstrap in NPM and many variations of it, so be careful.

Then add the CDN, often used to serve code from different servers across the globe for performance boost.

It soon becames apparent there are multiples of frameworks or packages being used.

Then you’ll find them also added in different places, let’s say in different pages.

It really doesn’t get any easier and wondering how it became like this is probably best to ignore and forgive as there could be multiple factors involved.

So the aim is to consolidate the variation to one and keep any plugins used by checking their compatibility.

Where there’s multiple implementation, replace it with one direct access checking it’s version in the process or upgrade it to its latest.

In an ideal world, keeping on top of version control is an advantage.

Developers can stop hacking and develop features faster and for users to gain access earlier.

It was time to address this mess, for our development purpose mostly, but also our users.

Allow me to explain.

In development, developers often find using a framework and looking at new online documentation just because it’s available.

Usually with the less experienced developers you may find them hacking their current version to look or behave the same as to the online documentation.

That’s a no no right there, don’t even go there situation.

Developers should check their current version and find the relavent document version and work from there.

Then there’s the fact of customised features built on top of the framework.

This is the bit that can get complex, if not done the Bootstrap method using it’s classes.

On the other hand for the users, it would be a big performance boost.

Again, allow me to explain.

Refresh rates feeling like a flicker rather than a loading spinner.

But that also depends on the scenarios.

If a user is just loading a page that’s great.

If a user is querying the database it could take some time, depending how complex the search is and how much data is there.

So expect loading spinners there.

If it’s a simple search with very little data to filter from, expect a performance boost.

Apply the users to busy environments and you may find an increment of performance a cross the floor.