Does Your Website Need JavaScript?

Do You Really Need JavaScript For Your Website?

The modern internet has seen a proliferation of complex web applications. Many of us in our daily lives are using apps in our browser like Google Docs, Spotify, and Facebook, just to name a few. These websites are powered by a programming language called JavaScript (sometimes abbreviated JS).

W3 Techs has determined that JavaScript is used by nearly 99% of all websites. This makes sense, as it is the de facto programming language of the web. If you want much functionality for your website beyond static documents, you'll need to reach for JS.

Today we'll examine this language, how its use has evolved, and whether or not you should integrate it into your own website.

What is JavaScript, exactly?

Web pages are composed of three coding languages.

Hyper Text Markup Language (HTML) defines what is on your web page. All of your content lives here, as well as the basic layout structure. As a markup language, it is limited to using functionality explicitly defined by the browser. In the past, this posed significant limitations for developers, and the web was mostly relegated to simple, static documents. HTML web pages are organized into a Document Object Model (DOM) which contains the hierarchy of all elements on the page.

Here is an example HTML document:

<!DOCTYPE html>
<html>
<head>
<title>My Web Page</title>
</head>
<body>
    <h1>Welcome To My Web Page</h1>
    <p>Thanks for visiting!</p>
    <p>
        <button id="my-button">Click Here</button>
    </p>
</body>
</html>

Cascading Style Sheets (CSS) gives style to your web page. All of your design touches like colors, fonts & font sizes, even layout designs should be handled here. Over the last number of years, its functionality has expanded to include more complex features like animations, pseudoelements, robust conditional selectors, and more. (If you're not sure what that means — don't worry! Just understand, it's cool & very useful.)

Here is an example CSS document, to compliment the above HTML example:

body {
    background-color: black;
    color: white;
}

h1 {
    font-size: 2rem;
}

And finally, JavaScript is an imperative programming language for the web. Meaning, you can give custom instructions to the user's browser & create new functionality. As you might have guessed, JavaScript is extremely powerful. It has allowed developers to take web pages from static & informational, to full-blown applications in their own right.

Here is an example of JavaScript to modify the behavior of a button:

const button = document.getElementById('my-button');
button.addEventListener('click', event => {
    event.preventDefault();

    alert('You clicked the button!');
});

How Has JavaScript Evolved Over The Years?

Back in the early days of the web, JavaScript was used sparingly, perhaps to validate user input before submitting a form, or something similarly trivial for convenience. While it had a lot of potential for custom functionality, developers wishing to make complex in-browser experiences typically used Flash or Java applets instead (remember those?)

The Advent of Ajax

Perhaps the first, most significant step towards JavaScript web applications was when Google used a newer technology, Asynchronous Javascript & XML (Ajax), in its Gmail and Maps applications. This allowed for loading new content without navigating the user to a new page. Ajax had technically existed since the late 90s, but wasn't yet standardized & had hardly been used much. In fact, the World Wide Web Consortium (W3C) didn't write the official standard for it until April 2006.

It would be a while still before the modern web as we know it came about. The other most significant development in this period was jQuery, a JavaScript library that implemented lots of shortcuts & useful features like finding HTML elements via CSS selectors (rather than needing to find them by ID), animating elements (before CSS had the ability to do so), sending Ajax requests, and more. The most important feature? It just worked across all browsers, in an era where browser cross-compatibility was a massive headache.

Here is an example of using jQuery to update a counter whenever you click a button:

<p>Counter: <span class="my-counter">0</span></p>
<p><button class="my-button">Increase Counter</button></p>

<script>
let counter = 0;

$('.my-button').click(() => {
    counter++;

    $('.my-counter').text(counter);
});
</script>

We use jQuery to find our button & add a click event to it which increases our counter, and also updates the counter value on screen.

Nowadays, most of jQuery's useful features have been baked into standard JavaScript, causing many to consider it obsolete. Here is an example of how to implement the above example in modern, vanilla JS:

<p>Counter: <span class="my-counter">0</span></p>
<p><button class="my-button">Increase Counter</button></p>

<script>
let counter = 0;

document.querySelector('.my-button').addEventListener('click', () => {
    counter++;

    document.querySelector('.my-counter').innerText = counter;
});
</script>

jQuery may be considered outdated, but that doesn't stop it from topping the list of most-used JavaScript libraries, at a staggering 89%! As of this writing, jQuery is still included in the latest version of WordPress.

The Rise of Frameworks

In 2010, Google released a JavaScript framework called AngularJS. The big idea was that manipulating the DOM with JavaScript should be declarative, not imperative. Meaning, you define what you want the DOM to do & it does it for you. So when you change any data on the screen (say, updating a live view counter, a status message, or anything else), the AngularJS framework will automatically update all of the places that data is used when you change it.

Here is an example of how to use AngularJS to create a counter that goes up every time you press a button:

<div ng-app="app" ng-controller="controller">
    <p>Counter: {{ counter }}</p>
    <p><button ng-click="increment()">Increase Counter</button></p>
</div>

<script>
var app = angular.module('app', []);
app.controller('controller', ($scope) => {
    $scope.counter = 0;

    $scope.increment = () => $scope.counter++;
});
</script>

Notice that we're no longer writing additional JavaScript to track down our button or our counter display, nor are we imperatively updating the counter value on screen. We used AngularJS attributes on our HTML elements to identify them with our data (in this case, the counter value) and with our event (in this case, the incrementing function). AngularJS takes care of the rest — it updates automatically!

Using JavaScript to manipulate the DOM is called client-side rendering (CSR). The classic method of delivering a complete DOM to the user's browser is called server-side rendering (SSR).

JavaScript in the Modern Era

Today, there are many popular frameworks & libraries that not only allow for declarative DOM management, but contain a myriad of other features as well. The most popular frameworks include Angular (no longer called AngularJS since version 2.0), React, Vue, Svelte, and more.

Building complex web applications with these softwares can help by speeding up development significantly, providing time-tested solutions to hard problems like DOM state management, and much more, depending on which one you choose. React is considered a library instead of a framework because it provides a set of tools useful for frontend development without being opinionated about how your application should be designed. Angular, on the other hand, provides much more structure & has many more features out-of-the-box.

Overall, they are a major component of modern web development & they make many of our favorite applications possible.

So, Should My Website Use JavaScript?

This can be a complicated question. Even twenty years ago, you would have a hard time creating a website without using any JavaScript at all. But many web designers & developers are seeing that reaching for JavaScript to solve more mundane problems can end up causing more issues in the long run.

Author & developer Theo Soti makes a compelling case in his book You Don't Need JavaScript that, for many websites, most JavaScript is just not necessary.

To put it in his own words:

It’s easy and tempting to reach for JavaScript. Popular frameworks such as React, Vue, and Angular have made rapid prototyping and rich interactivity extremely convenient. While this convenience has significant advantages, it also often leads to bloated bundles, slower load times, and unnecessary complexity.

Web standards have advanced a lot, especially in the last decade, and many things that we're accustomed to using JavaScript for have been solved for us by simpler technologies.

How Does JavaScript Affect Performance?

JavaScript can have a real effect on your website's performance. As it is an imperative language, it can perform noticeably better or worse depending on how optimized or complex your code is.

Consider a small business brochure website, designed in a modern web framework. The home page would probably have a hero section, three listed services, and a contact form.

This is a typical process your customers' browser would follow for rendering your home page, every time:

Load initial HTML document. This sends an HTTP request & waits for your server to respond with the requested document.
Send requests for your JavaScript assets. Secondary requests are sent to load the various JavaScript files that might be necessary to build your application. While there could be only one, often times there are multiple.
Your app renders. At this stage, your app's code will be parsed & run, buiding out the page dynamically. Depending on how you built your app, this may requre loading all of your app's page structures all at once, and only rendering the one your user is currently viewing.
Your media assets load. Any images you have on your page probably won't be requested by the browser until this stage. After these assets are finished loading, your page is finally complete.

Going through all of these steps increases load times & bandwidth usage for the end-user, while greatly increasing complexity for the developer. The benefit for a small business brochure website is virtually nonexistent.

Conversely, if you just serve a pre-rendered HTML document to your users, the steps look more like this:

Load initial HTML document. This initial HTTP requests loads all of your DOM content at once.
Your media & stylesheet assets load. CSS, images, and more are all loaded at this stage. Once this first & final round of assets is finished loading, the web page is complete.

Avoiding frontend frameworks for simpler sites can give you shorter load times & fewer loading stages. Google found that 53% of mobile users will abandon your site if it doesn't load within 3 seconds.

Can SEO Be Affected By JavaScript Usage?

There has been much discussion on this subject. For many years, Google could only analyze the HTML returned by your server; any content rendered by JavaScript was not visible. Many still believe that client-side rendering has an adverse effect on search engine optimization, particularly the speed at which your pages are indexes.

How Does Google Learn About Your Web Pages?

Google' process occurs in a few stages:

Discovery, in which the crawler becomes aware of a URL on your site. This can be because it followed a backlink to the page, or because you submitted your page or sitemap to Google Search Console.
Crawling, which is when Google actually visits your page & views the content delivered from your server. At this point, it just analyzes the HTML without rendering it. The page is queued to be rendered later.
Rendering, when Google finally renders your page (JavaScript & all) for analysis.

We see that Google definitely can see JavaScript-rendered content. But the question remains: are CSR-pages indexed significantly slower because of this rendering queue? Some people speculate that it can delay indexing by long periods of time, even weeks.

But is there any truth to those rumors?

What Does Google Say About JavaScript & SEO?

Google's advice on JavaScript & SEO can be a bit confusing. For instance, they say:

Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.

So, server-side rendering can be faster for crawlers?

But they go on to say that your page may stay on this queue for a few seconds, but it can take longer than that. This is rather vague – how much longer?

Luckily, we have a clear answer right from a Google employee. In an interview with Faber Company Inc., Martin Splitt of Google clarified that the majority of pages are rendered in about 5 seconds. In some rare cases pages may take longer, but that is not the expectation.

Further putting this myth to bed, Vercel partnered with MERJ to research the effects of CSR on SEO. In the article, How Google handles JavaScript throughout the indexing process, they determined that client-side rendering does not have a significant effect on your website's SEO. While they did observe a rendering queue, the rumors about its lengthy delays did not seem to bear out.

While a rendering queue exists, its impact is less significant than previously thought. Most pages are rendered within minutes, not days or weeks.

So while there may be implications for complexity & performance, it seems that SEO concerns for client-side rendering may not be significant.

Conclusion

So, do you need JavaScript for your website? The answer, as for most things, is that it depends.

If you're building a brochure website for your small business, a bit of JavaScript may be recommended or even necessary, but you should probably reconsider building it with the latest frontend framework.

However, if you need a full web application with lots of complex functionality, a CSR framework is probably just what you need to get the job done.

If you're looking for a new website, whether a simple brochure site or a complex web application, Acworth Web Designs can create it for you. Contact us today for a free consultation!

« Does Page Speed Matter? Why Are Static Sites Different? »