There is an Order to Everything

When you are developing web applications, one thing to keep in mind is the order in which things occur.

An HTML document is loaded top down in a hierarchical fashion. If you do not keep this in mind, you could run into errors with your coding. What typically happens is the application does not run as expected and you get an undefined error. You may have some code in the head of the HTML document, in an external js file and in the bottom of the HTML document (I do not recommend putting js in the midst of an HTML doc as a standard practice).

So how does this work? Imagine I have a function that I am calling in the head, but the function is declared and put into memory in a third party js file that is loaded after my function call. The function will not be called because the HTML file has not come across that function yet and therefore has no memory of it. Another scenario is calling a function that is not declared until later on within the same file.

Let’s look at a couple of examples…

Imagine we have an HTML file with a script at the bottom that contains a function and the call to that function is in the head…

[code lang=”html”]
<!DOCTYPE html>
<html lang="">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Order Counts</title>
<script>
// Call myFunc function
myFunc();
</script>
</head>
<body>
<script>
function myFunc(){
alert("I work!");
}
</script>
</body>
</html>
[/code]

The above code will result in the following error being written to the console…

Uncaught ReferenceError: myFunc is not defined

If we place the function declaration prior to the function call, then it will work because the function is in memory.

[code lang=”html”]
<!DOCTYPE html>
<html lang="">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Order Counts</title>
<script>
function myFunc(){
alert("I work!");
}
// Call myFunc function
myFunc();
</script>
</head>
<body>
</body>
</html>
[/code]

Now, I have demonstrated this issue with a single file, but the same thing applies if we are using external js files, which is a standard practice. If you make a call to a function prior to loading the external js file into memory, you will receive the same error.

Now there are ways to alleviate this other than placing things in the correct order. You can make calls to functions using the onload event. Even though the function call might appear ahead of the declaration in the code, it will not get called until the page loads.

Frameworks also typically have ways to address this. For example, jQuery uses $document.ready to wrap jQuery code to tell the app to not call the wrapped code until the document is ready.


On a related note, many times in our code, we are manipulating the DOM (document.getElementById() for example). Order matters here as well. If you create a function and call it at the top of your document, and that function manipulates a DOM element, you might run into an undefined error. What is happening is your code is attempting to “tap” into the DOM element before it is created. So make sure your element exists in memory prior to your calls.

 

Happy Coding!

Clay Hess

 

More To Explore

Code

A Quick Tour of the Web Encoding API

Modern web apps live at the boundary between JavaScript strings and raw bytes. The Web Encoding API exists to make that boundary explicit and safe: it lets you encode a string into UTF‑8 bytes and decode bytes back into text. Importantly, these operations aren’t symmetrical—encoding targets UTF‑8, while decoding can interpret UTF‑8 and many legacy encodings. Alongside the synchronous TextEncoder and TextDecoder, the platform also provides stream-based variants for processing text incrementally as data arrives.

Script Proofread And Sentence Grammar Spell Check
Code

EditContext API: A New Foundation for Custom Web Editors

The experimental EditContext API gives developers a new foundation for building custom rich text editors by separating text input and selection from rendering. Instead of relying on contenteditable, you attach an EditContext to a focusable element and manage your own text model, selection state, and UI updates—while still receiving browser-grade events for typing, caret movement, and IME composition. This demo highlights the core event flow and why character bounds matter for accurate input UI, especially in custom-rendered editors.

Share This Post

small_c_popup.png

Need help?

Let's have a chat...


Login

Jump Back In!

Here at Webolution Designs, we love to learn. This includes sharing things we have learned with you. 

Register

Begin Your Learning Journey Today!

Come back inside to continue your learning journey.