Getting Started With Web Development

April 19, 2023

  1. Frontend development
  2. Backend development
  3. DevOps
  4. Summary

First Steps

Getting started with web development is an exciting time. Whatever your motivation, learning the fundamentals of web development, which will later turn into software engineering, is an incredible feeling. When I started learning HTML and CSS, the ability to turn 'code' into actual elements on a simple web page felt like I had just learned how to build for the first time. The idea of creating something from nothing is like nothing else I've experienced and soon I became addicted. But, where should you actually start when taking that very first step?

If, like me, you didn't study computer science at university, you probably won't have much knowledge about the world of software until you start learning. It's worth mentioning already that web development is, of course, not the only type of software development around. There are many other fields of expertise that might interest you, but they won't be covered here. These include Desktop Application Development, Systems Administration, Database Administration, Mobile Development, Data Science, Embedded Systems Development, and many others.

Simply put, web development is the creation of websites. This typically involves coding or programming in one or more languages, and will typically involve working with:

  1. Frontend development - the visual parts of the website that the user sees and interacts with.
  2. Backend development - the underlying data and logic that the website contains.
  3. Hosting - making the website accessible at a public address.

Frontend Development

This is usually the easiest place to start along a web development learning path. Creating elements with HTML, styling them with CSS, giving some interactivity with JavaScript. These 3 languages are the building blocks of all modern day websites, although some argue that JavaScript is optional. In my experience, JavaScript plays a fundamental role in web development and while the expectations of users in the early 2000's might have been satisfied by a simple HTML and CSS site, nowadays it's rare to find any serious website without JavaScript to add interactivity. The JavaScript ecosystem goes deep, so we'll just be scratching the surface here.

A first project

Your first project, if you're looking to get into web development, should be simple. You're learning the tools and learning how programming works. Sticking to a simple HTML site, styled with CSS is usually sufficient. You will learn the fundamentals of HTML, the syntax, the various tags that are available and what they mean, as well as learning your first CSS selectors. At this point, it's not necessary to know absolutely everything about either of these languages, but you should get familiar with how CSS can be used to position elements, how the structure of HTML elements can affect your options in terms of styling, and how to combine these to your advantage. You can also take this chance to learn about the flex and grid positioning of CSS and how this can help you to quickly build out page structures.

Adding JavaScript to the mix

As mentioned before, modern sites usually rely on JavaScript to add some interactivity. While it's possible to use CSS transitions for some form of interactivity, JavaScript will take this to the next level. Dynamically showing and hiding elements, changing the contents of parts of the page, moving elements around, and many more - these are all achieved by adding JavaScript. When learning JavaScript, I try to break it down into two parts. First, JavaScript the programming language. Learning about data types, variables, data structures, functions, classes, modules, is the first part. Learning about the browser API is the second part. The browser API is the set of functions and operations that allow you, as a developer, to manipulate and store information from the webpage using JavaScript. For example, I can interact with the user's browser to find what they have typed into an input field and use that data for any purpose.

This raises an interesting question though - "do forms need JavaScript to be submitted?". The answer is no. Form submission is a functionality that is implemented by the browser, and this should be an area of research when learning the basics of web development. After all, forms make up most of the interesting parts of interactive website, in some form or another (yes, pun intended, I know it was bad.) Logging in to Facebook. That's a form that you submit. Updating your status, that's a form that you submit. Even uploading a photo, that's a form that you submit. Forms and their submission are kind of the backbone of web applications and you should learn to use them properly.

A quick note on the distinction between a website and a web application. A website, like the one you're on right now, is just a static bunch of pages that display data. They might have some interactivity, but the content is more or less the same for everyone. It changes only when the owner of the website changes it. A web application, on the other hand, is like Facebook, or Google, or Netflix, or any other that has dynamic content. This doesn't mean interactive, it means that it changes according to who is using it and what they are doing or have done. Imagine you update your status on Facebook. Well, that status is when visible to everyone you're friends with. It dynamically updates according to your actions (and the actions of others). This definition isn't perfect and leaves room for interpretation in some cases, it's good enough for the time being.

The first time you add JavaScript to a webpage will probably be inline. This means you write the JavaScript code within a <script> tag within your HTML. Later, you'll learn about how to load the JavaScript file from another file in your system. This will be the beginning of more serious web development.

The next step in this process will be when you want to use Open Source (OS) libraries or packages. This is software that other developers have created and published for use by anyone. There are too many to name here, as new packages are being created every day, but some common use cases are dealing with dates in a uniform way with moment.js, formatting and working with numbers with numeral, using a pre-defined framework with components and functionality with Bootstrap and many more.

In order to use these packages, you need some way to manage them. That is, to download them into your project and incorporate them into your code. Node Package Manager (NPM) is a common way to do this. Using NPM you will create a file in your project called package.json which will keep track of all the packages, called dependencies, that you use. If you share your code, it will also make it fast and easy for other developers to quickly download the packages that are required to run your code. Learning NPM (or one of the tools that has since replaced it, like yarn or pnpm) will be a crucial step in taking your projects from basic web pages/websites to fully-fledged web applications.

Adding a framework

After becoming comfortable with JavaScript, it's time to move on to a framework. It's likely that you've heard of React, Angular, Vue, or one of the other frontend frameworks that have become popular over the last few years. Previously, my recommendation would have been to use jQuery but it has since decreased in popularity in favour of the more modern tools.

My recommendation here is to use React. While the others are also popular and are used in teams across the world, React is the undeniable winner in terms of popularity. Why does popularity matter? Two simple reasons:

  1. There are more jobs
  2. There are more resources

It also means there are more developers who use that tool, which can be a disadvantage, but at this stage it makes sense to go with the most popular technologies.

Learning React will completely change your way of thinking about web development. With JavaScript, you favour an imperative approach. When I click this button, change this other thing. When the page is scrolled, do that thing over there. With React, it's a more declarative approach. You describe the state of things based on what is changing. When the state is this, then this component should have this property. When the state is another thing, then this other component has this content.

Getting started with React requires the tooling we talked about above. A package.json file, some dependencies and now also some code compilation using tools like Webpack. Webpack takes the code you write and turns it into code that the browser can understand because browsers can't understand React code exactly as it's written, so we need to help them out before it gets there by compiling it into something that makes sense.

A full React project will contain navigation, where instead of your browser taking control of where your user is and what they see, React takes control of that and shows what you defined for certain screens. This concept is know as a Single Page Application (SPA). You can have 1 page, or 1,000 pages, but the browser will only recognise it as one page, and you will only have 1 HTML file to control it all. JavaScript (via React) will be doing all the heavy-lifting in terms of which 'page' or screen the user sees and what content is contains.

Applying for those frontend jobs

You're still far from fully understanding the world of frontend development, and it can sometimes be frustrating to realise how little you actually know, but here is where you can and should be looking for jobs and applying for them. With the skills described above, you should be able to land yourself a junior frontend position where you will be able to learn more.

Adding a meta-framework

After React, you can go further by learning a meta-framework like Next.js. Next is a bit more rigid and opinionated in how it does things. You need to give the files the right names, you need to export the correct functions or data from those files, but once you get to grips, Next gives you superpowers. It can take care of all your routing for you, it can handle images, it can look after authentication and it also has great static and server-side rending functionalities that can give your web apps a real performance boost! There are other frameworks that can give you similar and other features, so feel free to look around and find the right option for what you're trying to build. The idea behind these frameworks is that they make your development speed much faster and easier, so choose the one that does that for you.

Backend Development

Backend development is creating the backend part of a web application. The backend provides the data that the frontend needs and is where the business logic. Websites don't use or need backends, since their data is static and belongs on the frontend. Backend concerns itself mostly with the data and logic that is present in the application. Taking Facebook as an example, the backend is responsible for deciding whether the username and password you submit are correct and which user in the system they correspond to. For this, backends require some form of database, a specially designed system that contains all the data for the application. A database is structured in a way that it is optimised for inserting data into it and querying data from it. When checking a username and password, for example, the database will first look up the user by the username that is given. This will return some information about the user, including the password (in some form). The rest of the backend system can then check the password that is stored against the one that has been submitted to make sure they are the same and that you are authorised to access the user's data. If everything is fine, the backend system will respond to the login request with some sort of success message. If there is something wrong, either because no user with the given username exists or because the password is wrong or something else, the backend system will send a rejection message to the frontend. The login page will show an error to make it clear that the login failed.

Let's look at a simple example to see the separation between frontend and backend: a chat application.

You create a chat application that users can sign up to and send messages directly to each other. A simple user behaviour would be to send a message to another user. In the frontend, you design a chat screen with a message input field, and some elements to show the previous messages that have been sent by you and the other participant.

The backend of the application would be responsible for:

  1. making sure you are who you say you are with authentication (a login form).
  2. retrieving the data about you and the other person, like their name, maybe also their online/offline status, etc.
  3. retrieving the messages that have been sent in that chat between you and the other person.
  4. sending all that information for the frontend to display
  5. saving new messages that are being sent

The frontend of the application would be responsible for:

  1. showing the screen layout with all the elements.
  2. calling the backend endpoints to retrieve the information as above.
  3. filling in the details of the other person to show who you're chatting with.
  4. populating the screen with the previously sent messages.
  5. showing the input field and responding to the form submission by telling the backend the contents of the message and who sent it

A first project

Getting started with backend development is more complex than frontend. The backend usually serves some sort of frontend, so if you know nothing of frontend development or how the data is used, you're going to have a hard time. This is the main reason why I recommend starting the frontend development regardless of where you want to end up.

Ruby on Rails is a simple full-stack framework that allows developers to quickly start up a project, whether it's a side project or a production application. There are many similar frameworks out there that use other languages, like Django for Python, Phoenix for Elixir - these are all examples of MVC frameworks.

The idea is that you need one single application to create the frontend and the backend. This is why they are also known as full-stack applications - both stacks live in one single code base, one repository, one application. They run all together and the separation between frontend and backend is blurred a little.

Following the Ruby on Rails documentation and creating a first application can be done very quickly for a first project. Here you will learn how to build up basic controllers and actions, learn the basics of CRUD and you will be forced to learn what a database is, like Postgres or MySQL, how it stores data and how to interact with it.

The first application won't contain any authentication (login, logout, sign up), it can just be something simple like creating, reading, deleting and editing blog posts. That sounds like a terrible application, and it is, but it's a good first step to get all the parts of the application playing well together.

Getting more advanced

A good second project would be to add authentication and to make the project more complex. It could be an extension of the first project by adding authors and comments to the blog, maybe even grouping them with categories. This will force you to learn about associations, how records in your database are connected to each other. For example, your blog posts will have an author. Each comment will be related to one particular post and there could be a many-to-many relationship between categories and posts. A post can have many categories and a category can have many posts. This will lead all the way down to the database level where those records will be associated - in the place where they are stored.

Adding authentication can be as simple or complex as you like. Rails has a great library called Devise which is often used to add simple authentication to an application. It works well in full-stack Rails applications and uses session cookies to track whether a user is logged in and who that user is.

This application is still quite simple in real-world terms, but it's the foundation for creating serious web applications that could be deployed for users to actually interact with.

Production-ready applications

When an application is high enough quality and has sufficient security to be deployed to be used commercially, it's called production-ready. Production is the name of the environment that is used for such applications. When in development, the environment is unsurprisingly the development environment and for testing purposes, it's common to create staging or sandbox environments that are only accessible to certain people, usually people within the company that owns and develops it.

The application also needs to be deployed, or hosted somewhere online. Tools like Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure provide a whole host of services for developers and DevOps professionals to deploy applications and other software products. However, for a beginner, these are too advanced and using a platform like Heroku is more developer-friendly and easier to get started with.


Developer Operations - or DevOps - is taking hosting and deployment to the next level. DevOps is an area of expertise in itself and developers with these skills are in high demand. DevOps Engineers take care of setting up and maintaining the deployment of the application(s) that developers produce. They also deal with smoothing out the deployment of the application to make changes, upgrades and rollbacks much easier to make for the developers in their team. A DevOps might be specialised in AWS, GCP or Azure, among others, and will have skills in setting up a Continuous Integration pipeline that will automatically run tests and checks on the application before deploying it to production.

DevOps is outside of the realm of the work of a usual Software Engineer, although many developers have skills in this area.

For a beginner in web development, getting familiar with a tool like Heroku, or comparable platforms, is sufficient. DevOps shouldn't worry you at this point, but it's an interesting area in case you find yourself moving towards it in the future.


In conclusion, the path to becoming a web developer, either frontend or backend, is not too complex, although it can be long. The skills required to become a professional and make a living are wide-ranging and can take quite some time to pick.

For frontend development:

  • JavaScript
  • JavaScript framework (React, Angular, Vue, etc)

For backend development:

  • Programming language (Ruby, Python, Elixir, Java, PHP)
  • Framework (Rails, Django, Phoenix, Spring, Laravel)
  • Database (Postgres, MySQL, MongoDB)

There are also skills, like Git, which span both of these and are necessary in order to become a professional in web development.

Are you looking to take the next step as a developer? Whether you're a new developer looking to break into the tech industry, or just looking to move up in terms of seniority, book a coaching session with me and I will help you achieve your goals or check out my available courses.