Unfortunately, your web browser is out of date. For the best buying experience, more security and better speed on the 56 Degrees website, please update your browser.

Follow us:

If you’re thinking about upscaling your e-commerce presence, there’s never been a better time. Download our free copy of “6 Questions to ask yourself when choosing an e-commerce platform”

Click here

Insights / Blog

Back-end vs Front-end

Are you shopping around for a new website or a redesign of your existing one? Then you’ve possibly come across the terms ‘back-end development’ and ‘front-end development’, terms which might have meant very little until now. However, it could be beneficial for you as a client to have a basic understanding of these terms. It will help to better determine the needs and scope of your project, which ultimately could end up saving you costs down the line.

In its simplest form, every website can be split into two parts. The front-end sometimes also known as client-side, and the back-end sometimes referred to as server-side. The clue to their purpose is in these names. Client-side is everything the user directly interacts with, while the server-side is what goes on behind the scenes. Due to the difference in purpose, the two are created using different types of code language. Front-end developers will normally be working with HTML, CSS and JavaScript, whereas back-end developers could be using Ruby, PHP, Python and several other languages.

Still sound complex?

Try this.

Think of web development in terms of a restaurant. A restaurant will have both waiting staff and kitchen staff, both allowed to work independently of each other to achieve a common goal. The waiting staff are responsible for creating a good customer experience and directly interacting with customers, whereas the kitchen staff are focused on efficiently creating meals in the back and never see the customers.

Let’s start with the front-end. As the customer enters the restaurant they are directed towards a table. This is where the experience will take place as far as the customer is concerned. Think of the table as the website itself, the user interface which the client will use to interact with the website.

Once the customer is seated, they are given menus which allow them to understand their options. This is your static website content giving the user a clear idea of what they can do on your site. This is mostly built using HTML and CSS code.

When the customer makes their choice off the menu, they need a way to communicate their order to the kitchen. This is where the waiting staff play a part- they relay the information received to the kitchen staff, but are also able to independently deal with certain requests without going to the kitchen. This is the user experience, where the front-end of the website takes the information received from the user and relays it to the backend. This is often done using JavaScript, which communicates information to the back end, but just like a waiter, it can solve some problems without talking to the back-end.

The back-end is the kitchen. The chefs in the kitchen utilise an entirely separate skillset to the waiters and never have to interact with the customers. Their job is to take the information given to them and, as efficiently as possible, translate that and send back the correct dish following the customer’s specifications. The kitchen is the server, a computer at a remote location, responsible for organising all the data and information and sending the right response at the right time. Just like the kitchen, the user never sees this part of the website. Popular choices for code language are Ruby, PHP, Ruby on rail, and more.

So, to round it up, the front-end or client-side is everything that the user can see and directly interact within the browser. This includes the themes and iconography of the website and all the way down to the fonts used in the web copy. The Back-end or server side is the framework, server and architecture that allows the website to function but is never directly interacted with by the user.


Do you need both for your website?

It is possible to build a website using only front-end code, you do not need a back-end for all types of websites. For example, if you are not doing any e-commerce and are using your website solely as a marketing tool and contact page then there is no need for a separate back-end as there is no complex information that needs to be calculated from user inputs.

The benefits of this? Front-end development is usually a much quicker and more design focused process, meaning it can be a lot cheaper than a site which needs a separate back-end. However, it could leave you limited in your options for expansion depending on your business development plans. Businesses looking to sell goods online will require, at the very least, some form of back-end in order to handle the large quantities of data such as payment apps, goods catalogues, customer information and more.


Pros of just having a front end

  • Simpler
    • Less coding languages required as the whole page can be developed using one or one set of languages. Additionally, back-end code language is often more complex.
  • Cheaper
    • Front-end development is usually less work intensive thus may at front face lower the cost, this may however lead to complications in the future.

Pros of having a back end

  • Scalability
    • Easy to scale-up the website and add more features as the business grows without compromising the integrity of the site.
  • Resource Optimization
    • The website will run more quickly and smoothly as there is a dedicated space for the calculations to take place. Any loading will take place invisibly in the back-end and not affect the front-end in thus not affect the user experience.
  • Easier to upgrade/extend
    • Safer to add additional pages and upgrade the architecture as it compartment
    • Much safer to add additional pages and upgrade the architecture. It compartmentalises risk meaning you can break a certain module without breaking the entire web page. Debugging becomes easier (Simpler to find a section in an indexed book than a continuous body of text)
  • Easier to change/switch framework
    • As technology is ever changing and fast moving you must be able to change and adapt your website efficiently. This means you can change certain aspects without having to rebuild the entire website.
  • Modularity
    • Means you can work on separate modules independently. No waiting for approvals from other teams or constant miscommunications between backend and front end. (Think too many cooks spoil the broth)

With this knowledge, it should now be easier for you to assess what your project needs upfront, eliminating surprise fees down the line. Deciding you need to add a storefront and payment system late in the project could incur you a hefty fee and stall your project as the amount of work required rises unexpectedly. Hopefully you can feel more confident discussing your project with your web developer and make sure you are on the same page.