What’s the point of <script> elements in an HTML doc?

Jonelle Noelani Yacapin
4 min readJul 13, 2021

--

In a previous blog, I explored scripting languages and shell/bash scripting.

This exploration was spurred by “scripting” being thrown around in job descriptions which made me ponder what little I knew of “scripts” and “scripting” in the programming universe. Here, I’m going to revisit <script> as an HTML tag since that’s the first form I’ve seen it as.

As a basic <script> tag it can allow access to another document (such as a JavaScript doc) or to other sources to be used for something like Bootstrap.

I also got a little exposure to jQuery and that just invoked more questions. Or, should I say, queries.

$ (document).ready(function( ){
$(“#div2”).find(“*”).css({“color”:”red”, “border”:“5px solid red”});
});

The above that I encountered is a form of scripting in jQuery, I believe. I’m not really familiar with it so I dug a little deeper…

jQuery example with <script> element

The above is a good example of what jQuery and <script> can do but I struggled to get past the fact that all it’s doing is changing all <span> in a <p> to be red. I didn’t understand why styling was in a <script> in the HTML doc when it “should” (as far as what’s been taught to me) be in dedicated CSS doc.

My imagination roamed and I wondered what was the point of this? Why avoid using a CSS doc? What else can <script> do?

The <script> Element

According to Mozilla, this “element is used to embed executable code or data; this is typically used to embed or refer to JavaScript code.” It can also be used with JSON (JavaScript Object Notation), which is basically a form of data.

Attributes:

*async — Which is short for ‘asynchronous’. This is kind of an abstract concept that took me awhile to understand. Imagine a bunch of processes and/or functions are happening at the same time; like when a page is loading or some other action triggers everything into motion. They can run ‘parallel’ to each other.

If the async attribute (which is a boolean) is ‘true’ then the script(s) and its’ dependencies will run whenever they’re ready. So, this might take some time as some finish before others. Some might be on pause as they wait for a response or data from another function/process.

Think of times when a page loads but not everything has quite loaded onto it, that’s asynchronous.

I suppose, if you wanted things to run in a very specific singular order, that would be synchronous so, set the boolean to ‘false’.

*crossorigin — I struggled a bit to understand this also in a past blog where I tried to resolve a Cross-Origin Resource Sharing (CORS) issue. CORS/crossorigin have to do with the secureness of passing or exchanging data with another source.

Mozilla suggests using this attribute “to allow error logging for sites which use a separate domain for static media.”

Read more on CORS settings attributes here.

*defer — This is also a boolean similar to the ‘async’ attribute, to tell a browser that this script should be executed AFTER the document has been parsed BUT before firing DOMContentLoaded.

DOMContentLoaded is an event that “fires when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading”.

*integrity — This is another security feature that “contains inline metadata that a user agent can use to verify that a fetched resource has been delivered free of unexpected manipulation.”

There are several other attributes for <script>: nomodule, nonce, referrerpolicy, src and type.

When To Use <script>

Scripts without the ‘async’ or ‘defer’ attributes will be fetched and executed immediately before the browser continues to do its thing.

Aha! Maybe that’s why we see and use this to make that JavaScript file available.

<script src=”javascript.js”></script>

Mozilla gives a simple example of an inline script inside the <script> element. Interesting, it makes a soft-of welcome pop-up message.

<script>
alert(“Hello World!”);
</script>

Lastly, you can embed data in the HTML so it renders on the server before passing everything to the browser (instead of just rendering it in the browser from the get go).

The benefit I can see from this is that it can save time since everything is already on the client/browser. You won’t have to wait additional time if some sort of process or function needs that data because it’s already been embedded. A request doesn’t need to be sent to the server and therefore, no need to wait for that data to be sent back to the browser. In my opinion, seems similar to “caching” but I’m sure there more to it.

Conclusion

Personally, this is still a lot to think about. I’m relieved Mozilla didn’t give me another example of <script> being used to change the CSS. That would’ve made me think that everything I’m trying to learn about coding is wrong. Ha ha! 😂 But still, I can’t help feeling that’s going to come up again.

Other Sources

--

--