Structure with Javascript code? CSS, Divs and then Scripts?

Question

I have noticed that the place of scripts is not irrelevant, if script refers to some div below, it may not work, not sure about rules perhaps my messy code assign some other value later. So I am asking general guide-lines to design the structure in Javascript code. What is the order for example to the parts such as CSS, Divs and Scripts?

My personal bias is that good code should be easy to read from the bottom to the top. So, for example, a browser could have browse() script at the bottom to start browsing and the rest junkies that it uses to to top in logical order, so after browse() its above script should be something that the browse() uses. Field values should be defined at the top, I think things like CSS and divs -- rude analogy I know. But if user's browser is slow, the script may not execute at all and the code seems to be non-working. Dilemma between practicability and readability.

Please, define terms, such as top-to-bottom coding and bottom-to-top coding, and show the structure.

Answer 1

K-I-S-S is my dogma. When my code does not work, it starts usually to work when I kill non-intrinsic code. Some good things are covered in replies such as mwilcox and prodigitalson. No unnecessary pictures and no excessive script blocks. Actually, some people seems to have working-JS-code of over 500 000 lines, example with Gmail. I have no idea how they do it but it hints to be critical about the replies here! Further replies could cover how to design massive JS code like of the size 100 000 lines, for the time being.

Exceptions

libraries and analytics scripts are an exeption and go to the beginning (if needed at all). Due to this kind of messy things, you may see why the term structure become confusing. But to craft some sort of structure, it would look something like:

1. CSS
2. Divs
3. scripts at the end

Answer 2

The style sheets go first and scripts go later. The reason for this is scripts are "blocking", meaning that while the browser is downloading JavaScript, it will not download anything else - not style sheets, nor images.

Browsers will only download so many resources at one time, and will block all other loads until this number of resources free up. IE8 actually will download quite a few at a time, as many as 18 or more. Firefox and Safari will download 6 at a time, but IE6&7 will only download one script or two non-scripts at one time. The thing to keep in mind is these resources are not free, and scripts are different.

A good rule of thumb is to put your style sheets in the head and your JavaScript at the very bottom of the body. Of course JS libraries give you some sort of "on DOM ready" to attach to. You can use this, and most devs do, but there are side effects:

IE occasionally barfs on the DOM-loaded hack. Rare, but it's happened to me. Your page will be frozen until your scripts load if they are in the head. If you have too many scripts, that can make your page look slow and non-responsive.

If your JavaScript is all at the end of the page, you'll never need to worry if stuff is loaded or a DOM node is available. And the page will be rendered and styled while your JavaScript is loading and calculating.

Finally, keep your resources to an absolute minimum. If you have more than two scripts and two style sheets, your page is not as fast as it could be. Images too - make full use of image sprites. There should only be a handful of images unless you are dealing with thumbnails or something like that.

Answer 3

RequireJS - Outsourcing Script Loading

I have found RequireJS particularly useful for JavaScript application development. In my case I'm dealing with tens of JavaScript files (modules) but I'm sure it will come in handy in other cases as well.

The library handles a lot of boring stuff for you. All you need to do is to set up some files (main.js, build options), state module dependencies and you are good to go. It includes a build system so you can easily get a debug or production build (minified) done.

On Application Structure

I like to code "top-down". The idea is that higher levels of an application should be really loosely defined. You shouldn't see actual algorithms used for solving some specific problems there. The highest level should be just about wiring parts of an app together. The lower levels solve more specific problems till you get to concrete implementations.

This is a fairly standard, layered approach to application development. You probably won't need something like this for casual scripting. It's still a good idea to apply in practice as it helps you to compose your scripts better. You can use the idea on closure level even to make the code easier to read.

On Functions

It might help to read "function" as "to" (Logo concept :) ). I think a well-written function reads like a recipe (to "drawLine" you must do this and that using these parameters...).

I know this might not be exactly pertinent to the question but I thought it might be a fun idea to mention. Perhaps it will help you to see functions differently and help you to structure your JavaScript code that way.

On Elements Not Ready

Considering elements not ready and script loading... you might be better off defining your code at a "document ready" handler. This is fairly standard thing to do.

If you use RequireJS or a similar library you probably don't have to worry about this. They handle this particular issue for you.

Answer 4

I try not to have excessive script block ins my code at all. I call all external scripts in the head or just before body close in the case of some api inclusion (addthis for example). All inline scripting goes in a single block at the just before the close of the body tag as well.

Answer 5

You can consider the entirety of the page, JavaScript, CSS, and HTML, as a combination "top to bottom" generic program, where later code can reference earlier code. Because when the page loads, it simply starts "executing" or interpreting "code" as it sees it. Most of the time, that "code" is simply definitions (like JS vars or functions), and placement of elements (like DIVs).

However, if you have JS that actually runs during load, that is code, that is outside of a function definition, then it's going to only "see" things that exist before the code is executed. So, in that sense, the whole thing is simply one long program, with the HTML as a meta-language building a DOM as the HTML is interpreted by the browser.

Obviously there are techniques to run code at certain points, like page load, etc., and that's where the libraries like JQuery come in to to expose those event points and make them easy to use.

But fundamentally, it's a top down script, like pretty much anything else.

Answer 6

Usually I try and place scripts that manipulate DOM on the bottom of the page, it solves the problem of not finding the DOM elements before a page is fully loaded.

However, libraries (such as jQuery) should go in <head>.

Answer 7

In head, put CSS, then scripts in order of usage and in body Divs.

Example if you use jQuery and have a .js file that uses jQuery code, it's adviced to import the jQuery files before your .js

Personally I try to avoid putting scripts in the body and rarely face such issues as scripts not finding divs below.