Copy to clipboardShould you read this?
If you need to understand at more than a superficial level what makes websites and applications work behind the scenes, this article is aimed at you. I'll break down the technology stack using a house metaphor—from the visible parts users interact with (frontend) to the utilities that power everything (backend) to the world all of this exists within (the infrastructure). I'll also talk a bit about the tools I use in each of these areas as a useful starting point to continue your own research and discovery.
For those of you interested I'll lay my cards out early: if you want to learn web development learn Javascript.
Copy to clipboardThe House Metaphor
Put very simply a technology stack is the combination of tools, frameworks, and technologies that work together to build, deploy, and maintain applications or websites. Each tool in the stack is responsible for a job that bridges the gap between what humans can understand (text, buttons, forms) to what computers understand ( "1"s and "0"s).
Copy to clipboardThe Front End
To use a more tangible metaphor to explain the stack, we can imagine a software application as a house. Starting from the top of the stack, aka the Front End, these are the visible elements that the user interacts with. These are the floors, doors, walls, light switches, furniture, water taps, dishwashers etc in a house. In a web application these are the buttons, forms, menus and content.
The visible bits of house are themselves built with building materials like bricks, wood and glass and decorated with paint and wallpaper and contains switches, wires and pipes that turn lights on and provide water and operate equipment for the tenants. We can think of the building materials as HTML, the decoration as CSS and the wires and pipes and appliances in the house as the Javascript. Every single house in the world (web application in a browser) is made up of HTML, CSS and Javascript. Things are slightly different for native mobile applications, but the metaphor still generally holds.
Fundamentally every house will consist of these three elements, however the tools we use to built the house can vary. Different building companies will use different equipment and methods to put the brick, wood and glass in place, apply decoration and install electrical wires and plumbing pipes. If you're building a one-off mansion you're likely to use different methodologies to building an entire neighbourhood of very similar houses. In terms of the technology stack these different building methodologies are known as front-end frameworks. Some of these frameworks (building methodologies) include React.js (Next.js), Angular and Vue.js.
Copy to clipboardThe Backend
So a house wouldn't be very fun to live in if it didn't have electricity, water and other utilities. These utilities bring the house to life and make it habitable. In terms of web applications we can think of these utilties as the data which makes the application useful for the user. In an e-commerce application these could be the product listings, order history and search results.
Unless the house is "off grid" it is unlikely that the power station and water reservoir isn't located anywhere near the house itself. There will need to be a connection that goes from the house and to the sources of power and water. These connections are called application programming interfaces (APIs) and are how the application talks to sources of data (aka the database or the content management platform).
An API is a fancy way of saying: software talking to other software. It is a mutually understood set of rules between two applications. When somebody in the house (the front end) turns the water tap (requests data from the backend) there is a specific set of rules on how it makes this request and what is expected back this is governed by the API.
We can think of the sources of data as the power station and reservoir. These APIs bring the data (utilities) to the house and then the internal wiring and plumbing within the house will move the data to where it is needed.
The wrinkle to the house metaphor is that we need to imagine that some of the water/electricity are private to that house. Imagine the database that contains user passwords and information - this database must only be accessible to the specific application that it is intended for.
Copy to clipboardThe Infrastructure
So the house, the underground water pipes and electricity cables and the reservoir and power station all physically exist somewhere. Software can sometimes feel esoteric, but just as with a house, all software code and data need to physically live somewhere as 1s and 0s. We can imagine the "land" where all of these things exist as the infrastructure layer of the stack. The databases which store the information, the servers which perform functions and the APIs connections all exist within this infrastructure. Some big names that you might have heard that provide this infrastructure are Amazon Web Services, Google Cloud or Microsoft Azure. In reality this infrastructure is essentially a series of large data centres which run computers which run software that run our databases and servers (this is the very fundamental bottom layer of our tech stack) - the substrate rock that underpins the land where our house sits.
Copy to clipboardA useful but gross over-simplification
So the above house metaphor feels quite neat and self contained. All web applications send information from a data store which lives somewhere, present it to a user, who might be allowed to read, edit or delete this information and then this data is then sent back to be stored again.
In reality the stack involved for a production-grade web application can be extremely complicated. Engineers have to consider things like cyber-security, load management, scalability, error-handling, analytics, cost management, risk management and the system involved in deploying changes to the application. Consider the diagram below which shows Netflix's tech stack, taken from Hina Arora's Medium blog.
Gif showing Netflix's technology stack:
Courtesy of Hina Arora
In addition to the front-end and backend stuff we've already discussed you can see that Netflix's infrastructure component is actually made up of three separate items. Streaming is all about the sub-stack which is dedicated to making sure that Netflix video content is delivered quickly and with minimal buffering to all users around the world. Big Data is Netflix's analytics sub-stack which helps them figure out what their users are browsing for, watching (or not watching) and what they think of the content. CI/CD is short for continuous integration, continuous delivery and relates to the sub-stack involved in allowing Netflix engineers to make changes to the rest of the stack.
Copy to clipboardMy Current Tech Stack
As I said at the beginning there are many many different tech stacks that can be used to create any web-application. I use the technologies below because they happen to be the ones I've been taught at bootcamp, taught myself or found good documentation online. I would recommend to anybody choosing a technology to apply in their software, always go for something more established, with a proven track record of usage, a strong community of users and indeed nowadays good characterisation by the AI models.
Anyway here's what I am currently most comfortable with.
Copy to clipboardFrontend
Copy to clipboardUser Interfaces
Unsurprisingly I exclusively use React to do all my front-end development. This is a Javascript framework and I daresay the most common front-end framework around according to Stack Overflow's 2024 Developer Survey. Since React is so widely used there's a huge community out there and a huge ecosystem of extensions available. Unless I find myself trying to build something very unusual I almost always find that whatever problem I'm facing with React has been faced and solved by somebody else. So with a little Google-ing and LLM prompting I can quickly get to a solution.
Being a Javascript framework (there are others in addition to React) has the added benefit of not needing to context switch when working with the backend technologies that operate within Node.js. More on Node.js later, but I can do pretty much all my web development work without ever leaving Javascript land. Developers who use different front-end and backend frameworks might have to switch between PHP in the front end and Python for the backend. Lots more learning and work required with this approach.
Copy to clipboardFramework
If React.js wasn't itself a huge boon to building front end applications, Next.js came along to smoothly solve many of the common problems faced by developers using React. Prior to Next.js React developers would have to fiddle around with common problems such as page routing, loading speeds, server-side rendering, SEO and image optimisation. With these common problems in mind the Next team have built a framework which includes out-of-the-box solutions for all these common issues.
Once you've learnt the mental model for React's component driven architecture, applying this thinking within the Next.js framework is pretty simple. Next has been so good at solving some of the shortcomings in React that the React team (at Meta) actually recommend using React within the Next.js framework for any projects that use React. More on this later, but Next.js is made by Vercel who in addition to building the framework have built an infrastructure pipeline which makes deploying Next apps really easy. They give Next away for free and make their money on the infrastructure.
Copy to clipboardStyling (aka CSS)
To get straight to the point here, if you want to know how to style web applications there is no getting round learning CSS. I've written an entire article on my approach to CSS. The TLDR of this piece is that I initially "cheated" by copying templated Tailwind CSS components, this allowed me to quickly build interfaces, but severely hampered my learning of CSS and therefore my ability to properly customise the look and feel of my interfaces for my needs.
My approach now is to use CSS Modules, but the biggest bit of advice I can give you is to learn CSS properly from one of the many sources I mention in the article. There are so many powerful tools in modern CSS which really have taken much of the complexity out of making great looking interfaces. CSS Grid, Flexbox and CSS variables all deserving notable mention.
Laying my cards out again: If you want to learn web development make sure you properly understand semantic HTML and CSS. There are no shortcuts here.
Copy to clipboardOther frontend stuff
For animations to make things on websites feel a bit more human and organic I use vanilla CSS and for more complicated stuff I use GSAP.
For fetching data on the front end I am indifferent really between the native Javascript Fetch library and another tool like Axios. Axios does remove a bit of the complexity and configuration requirements of Fetch. They are both really well documented online.
For developing some mobile app concepts I have played with Expo, which leverages my React knowledge to let me build native mobile applications (iOS and Android) without having the native languages for building on those platforms.
A word on Typescript
If you are using a front end framework like React and Node.js on the backend you'll find yourself writing a lot of Javascript. Do yourself a favour at some point and learn the fundamentals of TypeScript. It's essentially a system of guardrails and a suggestion engine to help you write "safer" Javascript. TypeScript will royally p**s you off when you first start with it, but once you become proficient, it becomes a joy, like a friend on your shoulder constantly making helpful suggestions and catching your potential mistakes.
Copy to clipboardBackend
So without going into too much detail, the backend is the bulk of the iceberg that your users never seen under the water. It is far less tangible than the frontend and it feels a lot more like the programming you would see in 90s movies - a lot of staring at the terminal and scratching your head over various errors.
As I mentioned before I've learnt Javascript and when you use Javascript in any world that isn't the browser you are using Node.js. Node isn't a different language to Javascript, it is just a different context (runtime) for Javascript which allows it to run on servers. If you want a full explanation of the comparison here have a look at the Node.js website.
Copy to clipboardDatabase
I am forever looking for shortcuts and one of those shortcuts has been to avoid learning the specific languages required to "speak" to databases. Traditionally this language has been SQL (Structured Query Language) and it is how you handle structured data in a relational database.
I understand the mechanics of relational databases, but I have avoided learning a lot of SQL by using tools called Prisma. Put simply Prisma allows you to talk to your database in Javascript (in Node) and it translates this to SQL which the database understands. Prisma is an Object-Relational Mapper (ORM) which allows you to use all of Javascript power over objects and the safety mechanisms of TypeScript when performing database operations (Create, Read, Update Delete).
Copy to clipboardAPIs and Middleware
There are lots of ways to create APIs within applications, but the classic and battle-tested approach is by using Express.js. Express is unopinionated, meaning it doesn't demand that you build you APIs in a certain way. Just like with CSS on the frontend being unopinionated makes life difficult in the initial learning phase since there are no guardrails or specific ways of doing things. Once you get familiar with Express and you understand the mental models of APIs, controllers, endpoints etc you begin to appreciate the benefits of its simplicity and flexibility. Express is also very well documented online and as such as good understanding with the LLMs.
Copy to clipboardContent Management Systems
For common use cases, like writing this blog, it makes sense for me to use existing solutions versus building one from scratch. Instead of configuring a database schema and building an API I have just used Payload CMS. Payload is a content management system that provides a ready-made database (hosted by them), admin interface where I create the content and API for accessing content on my front-end.
Each CMS will have their own quirks since they are highly opinionated, i.e. if you want to use them you have to play by their specific rules, but for what you lose in flexibility you make up for in simplifying your life. I can just get down to writing my articles instead of worrying about all the other elements of the stack I'd have to build if I didn't use Payload. Essentially you can think of using a CMS and importing a whole ready-made chunk of your into your existing stack.
Copy to clipboardAPI Testing
One of the tricker things with backend development is that (unlike the front end) there isn't a lot of interactivity to play with. Going back to our house metaphor, the pipes and wires are all hidden in the walls and floor boards. It would suck if you could only test whether the wiring and plumbing is working once you install lightbulbs and bathtubs and have decorated the entire house. If you found an issue you would have to start ripping up floorboards and making holes in the wall.
Thankfully we have some tools which allow use to test the wires and pipes without even having to have the frontend parts of the house built at all. We can test the water flow without even having to think about what the bathroom will look like.
Postman is one of these tools. It essentially "pretends" to be a front-end and allows you to make requests to your APIs (and APIs built by others). You can test all aspects of your API before ever using it in anger.
Tools like Postman are really powerful in allowing for a separation of responsibilities. In a bigger organisation there will be some engineers who solely focus on frontend development and others who handle the backend. A backend engineer can fully build the API to an agreed specification and test it using something like Postman. They can then share this API specification with the frontend engineer who can get on with building the interfaces.
Copy to clipboardInfrastructure
Infrastructure is a whole beast unto itself and is probably the engineering function that is the most esoteric and abstracted from the actual users of a web application. Infrastructure engineering concerns itself with all things relating to the hardware that runs the operating systems that execute the code that power your application. There are various processes involved in managing this hardware: provisioning (setting up), code deployment, maintenance and scaling (making sure there is the right capacity at all times).
As with the other elements in the stack you have many options available when deciding on infrastructure. You are most likely to use a cloud-provider to host your software, the days of building a website on your own computer and self-hosting are pretty much over.
Copy to clipboardCloud Providers: Infrastructure as a Service (IaaS)
In terms of cloud computing you have lots of options. You can go direct to the big boys who own the datacenters that house the hardware: Amazon (AWS), Google (GCP) and Microsoft (Azure). However for a novice within infrastructure engineering (which I am), this can sort of feel like buying crude oil from an oil company to fuel your car. It need a lot of refinement before it can be used as petrol. These big guys will give you a menu of blank slates in terms of configurations. You will have to do a lot of the hardware and deployment (getting your software on the hardware) work yourself, this can be complex and confusing.
Copy to clipboardContainers
Some of the deployment to infrastructure can be simplified through what's known as containerisation - an example of a containerisation tool is Docker. To use our previous metaphor containerisation is just what it sounds like, you pack up the entire house, pipes, electricity wires, power station and reservoir into a single "container". You then "ship" this container to a cloud provider and they unpack and assemble everything for you. The beauty of this approach is that containers have been standardised (like in real-world logistics) and the way that these container are "unpacked" into applications and infrastructure are determined by a special code "manifest". Containerising your software allows you to take a standard package and take it to any cloud provider and know that it can be unpacked and will work as expected on their services.
The challenge here is that you need to build you application with containerisation in mind and create the code that determines how your whole application architecture is packaged up and how it should be unpacked.
Copy to clipboardPlatform as a Service (PaaS)
Your lower effort option is to go to companies that abstract away away a lot of the nitty gritty configuration, scaling and code deployment stuff for you. They still use the infrastructure from the big cloud providers under the hood, but you pay them an additional fee to deal with all of this for you. Essentially these companies containerise your application for you and ship it out to whatever core infrastructure supplier they have an agreement with. They can give you ready to go servers, databases, code deployment pipelines, object storage and so on. There are loads of these companies out there but some of the ones I use have been Heroku, Supabase and Netlify.
My go to infrastructure has been Vercel. Primarily because Vercel developed Next.js (a React framework discussed earlier) and applications built using Next are very easy to deploy and scale on Vercel architecture. Most of my current projects will automatically deploy to the latest version when I push a commit to my main branch. This deployment setup is super simple in comparison to achieving the same thing directly on AWS. Vercel offers servers to run your Next application, database hosting, object storage, monitoring and AI solutions. You obviously pay for the privilege of this convenience and if you were building an application scaling to many hundreds of thousands of customers I'd suggest that you take a more cost aware approach and take the time to build your own architecture directly with the Amazon Web Services of the world.
Copy to clipboardExternal Layers of the Stack
No discussion on technology stacks would be complete without mentioning the parts of the stack you don't actually build yourself but you make use of. Some of the applications I've built make use of Large Language Models. I am obviously not able to build ChatGPT for myself or even begin to understand how to do so. So to make use of ChatGPT I need to use the OpenAI libraries, in my case specifically the Javascript (Node) library. Within my own backend I can send data to OpenAI, request they do something with it and then send me back a response which I can make use of in my application.
There are endless external services out there that you can programatically (using an API) make use of. Before you think about building some functionality it's worth seeing if an API exists for your specific problem. These can include Google Maps, email sending services like SendGrid, analytics (Segment, Amplitude), monitoring (DataDog).
Copy to clipboardSumming up
This article contains a lot of information since I've tried to (briefly) go over all the key area of the stack that powers web applications. Much like a house in the real world there are layers of technology that allow the house to perform its function as a habitation. It is much the same deal in the software world. If you're starting out in web development the number of layers to the stack is overwhelming. I remember thinking to myself: I need to learn all of these layers just to get something online!
The short answer is yes you do need to understand how all these layers work. That said you can "get away" with knowing just the basics of some areas of the stack. For example, I really don't know how Vercel manages my infrastructure for my applications, it just does and it seems to work really well. So all I need to worry about is creating high-quality front ends and robust back ends and then running them on platforms where I pay to not have to worry about the nitty gritty.
If you are reading this article because you want to get into web development my advice would be to very robustly learn HTML, CSS and Javascript. Learn a front-end framework (my advice: React), learn some Node and pick a backend stack that makes sense to you: my advice Express and Prisma. With all of this in hand you are pretty much a fullstack developer, since the final part of the stack, the infrastructure you can, arguably, get away with paying for simplicity and convenience, at least for smaller scale projects.
As a frontend engineer learning CSS properly will save you time and your sanity in the long run irrespective of which styling approach you use.