There are two main problems with loading assets in the front-end world. I would also like that the following solutions maybe controversial and not necessary the best solution out there, but you will come to admit, that had browsers resolved the following problems (without JavaScript) natively, then we would have a better front-end world and asset management picture.

Problem 1 – Chaos

I would like to start with a list of assets and then describe in detail why choosing the following approach to solve this chaotic problem along with the benefits of choosing this solution and hopefully, one day it will become a standard in browsers (with fallback of course) to better manage assets.

  • CSS
  • JavaScript
  • Fonts
  • Images
  • JSON Data (restful APIs)
  • HTML Templates
  • Videos

Problem is that we have different ways to load different types of assets: by using a combination of the following tags: script, link, style, img/image, video etc. to load these files each must have their own way to declare the source of the resource (aka URL), using src and href attributes.

I propose the following existing tag.

The above code, will not load anything at all, it is a bit clearer and unified, no requests made to the server and no response. By placing on the head  tag, we can choose to load these assets, ASAP or at will, when they are actually needed.
We will use a JavaScript library to manage these assets and load them as soon as possible using the old fashioned way of the above underlined tags.

The first draft of this asset manager is found here, this is written in coffeescript and it’s really work in progress. (if file location changes and you can’t find it, please remind me on a comment below to change this link)

Unrelated notes:

  • I have come to realise that this could solve the problem of loading the proper images, when it comes to responsive designs, but I will talk about that on a separate blog post.
  • I’d really like to propose a one request solution (cut the number of requests drastically) but more on that of Problem 2 below and eventually separate blog post.

Problem 2 – Too many requests, too naggy

We tend to think of assets as static files, it’s easy to deal with and happy all day. I would argue that file separation is for humans to have a sense of organization so it’s easy to follow, we solved the problem for humans, forgot about the machine, so the problem now rests with the machine. We typically map each request to a file and that is it.

There are methods out there that can concatenated the files  and serve as one, but the problem has now shifted again to humans, specifically a developer, who will now manage this dependencies and make sure nothing goes wrong.

I think the solution is really simple, and Node.js community uses this really often, that is package.json , yes this is one of the most important files that declares a module’s dependency and other important and vital information about that module/application. All a developer needs to do is, require a library declare which one and what version and start using it.

My point is we don’t need browserify and other similar solutions to handle the dependencies. Allow me to clarify your picture with the following “Hello World”.

You  may be asking, how in the world would jQuery be loaded like that or other libraries and assets?

Now, you will be asking well that’s just a json file… my answer is yes, you are right but the contentType is not it is text/package , this does not conform to any standards it’s just a made up name but the important thing is that we are asking the server to respond back with a text/package file. So the server gets back to work and does the following task:

  • Scan package.json file
  • Assemble a list of dependencies required (this may be split into two if it is necessary to respond in chunks so to prioritise which to serve first)
    • Absolutely necessary (ASAP)
    • Needed but used after page load or user action
  • Then respond with the following format

The above is dedicated to future browsers (if this gains enough support and gets standardised ) to know how to handle the assets on the background.

Older browsers could use JavaScript Shims to convert each of those lines with base64 as a fallback, we could also add content-source: if it’s required on assets like fonts if there is a difficulty we can fallback on old method.

As usual, please leave your response and comments and thoughts below 🙂