Is there a danger of creating a js file that just uses document.write () to combine js and css files?

Question

I am creating a front-end interface for developers in my company to use to create internal web applications. It consists of custom Bootstrap, jQuery, other open source libraries, internal modules, and style sheets. The user environment is completely IE9, and my server is .NET 3.5. I post shared files. The Dev teams in the firm will post links on their project pages and apply the structure on their pages.

I want to offer them the easiest way to implement this, which will be a single line of code for the insert, which creates a library for them. Cutting and pasting 30 lines of code becomes obsolete when the Ctrl + V button is pressed , it leaves me no control and is simply inelegant.

Failed experiments

I tried using Head.js and LazyLoad , which use best practices for inserting scripts. But each of them caused either the display of the contents before the style, or the conditions when the methods are called before the scripts are loaded. I refuse this approach. This is too unstable.

A simple solution to document.write ()

Last weekend, I thought, “Why don't I just create a js file called“ framework, js ”, add script files and link the files to the lines of the lines of document.write (). Tell the developers to put it into their heads and what it is. Maybe I could add the necessary meta tags for IE9 and mobile devices, it's so nasty and simple ... but it might work!

The user database is located on the internal network and has a limited size. Bandwidth is not a problem. I will check the performance before I select this. I can send development teams where to place the link.

Knowing this and actually providing it, is there a reason why I should not do this?

My only other opportunity to learn is server pooling. I hope not to resort to this, since I myself do not own the server, and I am not a .NET developer.

Answer 1

Your suggested approach is great for your situation. It has several advantages over more complex solutions, including complete simplicity, a completely predictable order of execution, and full compatibility with scripts that may not lend themselves to asynchronous loading. I used it many times in production applications, like many other developers.

Of course, other solutions have their advantages, but for what you are doing, there is nothing wrong with the good old document.write() .

It looks like you have several scripts and style sheets, and they are probably loaded from a shared directory (or shared root). To reduce the repetition in your framework.js file, you may need to define two functions: one for the <link> for CSS, and the other for writing the <script> for JavaScript. Thus, the framework.js skeleton file might look something like this:

 (function() { var scriptBase = 'js/'; var styleBase = 'css/'; function writeStyle( name ) { document.write( '<link rel="stylesheet" href="', styleBase, name, '">', '</link>' ); } function writeScript( name ) { document.write( '<script src="', scriptBase, name, '">', '</script>' ); } writeStyle( 'one.css' ); writeStyle( 'two.css' ); writeScript( 'one.js' ); writeScript( 'two.js' ); })(); 

Note that you do not need to perform special text escaping </script> , as you can see in the code that uses document.write() . This is only necessary when you put this code directly inside the <script> in an HTML file. The purpose of this escaping is to prevent the <script> tag from closing </script> inside the call to document.write() . Since your code is in an external .js file, this is not a problem: the presence of text </script> inside this file will not lead to the completion of the .js file.

Another point to consider is that all document.write() calls that you make inside the .js file are inserted into the document after the .js file that writes them. So don’t expect that you can do document.write() inside framework.js and then add other code inside framework.js , which depends on the .js file you just wrote. All these .js files (and .css ) are loaded after framework.js , and not alternated with it.

Another consideration, of course, is boot time. Your page can load faster if you combine and reduce your CSS and JS files. But if these are internal web applications, page loading time may be the least of your worries: reliability and maintainability may be more important. And in any case, you can always use the document.write() solution to start and run right now, and then optimize it only in the unlikely event that you need.