Back to front (the rise of Javascript frameworks)

12th November 2020

Javascript has long been a staple of web development, but in recent years the popularity of Javascript has exploded. One of the reasons (among many) for this increase in popularity is the advancements made in front end javascript frameworks allowing developers to build “web apps” as well as “web sites”. In this article we will have a little look at what a front end javascript framework is, and why they are so great!

Before we can understand the benefits of a front end JS framework, it’s important to understand the building blocks of a typical web page and the process of how they end up on our screen.

A web page is a document, written in HTML (hypertext markup language). This is a relatively straightforward language that simply denotes different elements on a page such as a heading or a paragraph.

HTML on its own is pretty boring, and simply lists everything one element after another. In order to position elements on the page, add colour and shape etc we need to add a stylesheet. This is written in another language called CSS (cascading style sheets).

So now our page has content and looks great, but there’s no interactivity. That’s where Javascript (JS) comes in. Javascript allows us to add interactivity to a page by writing functions that we can call when a certain event happens. A typical example would be to show the main menu when the user clicks on the menu button.

So now we have the 3 components that make up a web page, but still how does the page end up on our screen and how does it know what page to load?

In order to explain how a traditional website works, we will compare the process to going to a restaurant.

1) Typically the first thing you are going to do is request the home page by visiting

You arrive at the restaurant and request a table for one.

2) The web server will process your request and return the home page along with any additional stylesheets, images etc.

The waiter sets your table, with cutlery, glasses, a napkin and a menu.

3) You browse the home page and decide you’d like to read a particular article. You click on the article and your browser reloads the entire page and now displays the article.

You browse the menu and order a starter. The waiter then moves you to a new table, resets the table with cutlery, glasses, a napkin, a menu and the starter you ordered.

4) After reading the article you decide to click on a related article, you click on the article and the browser reloads the entire page, and now you see the next article.

You finish your starter and order your main, again the waiter takes you to a new table, sets the table with cutlery, glasses, a napkin, a menu and the main you ordered.

This process continues, every time you request a new page from the server you get a whole new page, even if only one thing on the page is different from the last. The equivalent of the waiter taking you to a new table every time you order something, even a refill on your drink.

Now in reality, the website reloading each time is nowhere near as annoying as a waiter reseating you everytime you order something but that’s just because computers are really really fast.

So how does a front end JS framework solve this problem?

Using a front end framework, the page template is built and instead of adding in the dynamic parts of the page (the article specific sections) we just put placeholders (variables). Then when a user requests an article, a request is sent to the server in the background, only requesting the data required (for example, it will just request the title, content, and images). When the server responds, it seamlessly replaces the placeholders in the page with the actual data. This is the equivalent of the waiter simply removing your starter plate and replacing it with you main course, everything else on the table, stays where it is.

Why should I care?

Firstly, from the users perspective, the page seamlessly updates to the new article without reloading the page, and because we only had to load the data, it was much faster and less data downloaded.

Secondly, the server now only needs to process requests for data, it no longer needs to be concerned about what happens with the data, meaning our server is processing requests much faster, and we can manage higher traffic without increasing the size of our server.

Consider a site Oi recently built for Liberty Bus using this method.

If you visit the first timetable here and then select another timetable from the list, you will see the timetable data update seamlessly without the need to reload the page. It happens so fast that if it wasn’t for the timetable number changing you would be forgiven for thinking it hadn’t changed at all.

Furthermore, because the whole site is built in Javascript, we can do some really cool stuff that traditionally was quite a mission. For example, if you view the planner here you can start typing a location name (e.g. St Helier) and it will suggest places to you to save you typing out the full name (this is really useful in Jersey since a lot of place names are in french and can be a bit tricky to get right).

In the background the site will take what you have typed and ask google maps for place names matching your text and then list them out for you to select. The result is a really smooth user experience. This is thanks to the virtual DOM (but thats for another article).

In addition to what we have covered on the front end, we should also consider that now our back end application is only responding with data, as well as having performance improvements, this also means that the data can be used in more that just a website. Your back end application is now functioning as an API (application programming interface).

This means that if you later on decided you wanted to build a mobile app, or perhaps allow other websites or apps to read data from your site, they can since it’s just the data and there is no restriction on how it needs to be displayed or on what platform it can be displayed.

This is just the tip of the iceberg on what front end JS frameworks can do, but hopefully this gives you a little taste of what the future of Javascript holds!