Topics
-
- How long until I will be ready to apply for jobs?
- How do I know when I am ready to apply to jobs?
- Where do I find jobs?
- What programming language should I learn?
- Why are there so many different programming languages?
- What if I fail?
- What if I get overwhelmed?
- What are the most important factors in getting hired?
- How do I get a job when all companies want existing work experience?
- What can I expect from an interview?
- Do I need to get a degree?
- Do I need to go to college?
- Which factors most influence potential income?
- What other factors should I consider when applying to a company?
- How do I know if my expectations are too high?
- What if I find a job, but it's not what I was expecting?
Welcome learners!
This post is targeted at anyone and everyone out there who has decided, for any reason at all -- that they would like to become a web developer.
No matter your age, or experience level. No matter whether you are a student, recent graduate, or someone who has had a lengthy career in a completely unrelated field. This guide is for you.
Although there is plenty of information that even experienced developers may find helpful, the primary audience I am aiming to target with this post are complete beginners.
I know it can seem extremely overwhelming at first, and it's important to know that this is totally normal. The purpose is to give readers an introduction to a massive range of topics. It is not meant to be a fully comprehensive deep dive into any one of those topics in particular.
Instead, at the end of each section where I discuss a concept, I will include a curated list of links and resources which you can visit to continue your learning on that topic.
With a couple exceptions, all of these resources are entirely free.
At any point a topic is spoken of or introduced, I will make an attempt to answer these three questions:
- What is it?
- Why is it important?
- How do you use it?
These questions are critical to beginners in particular as I know it can often be extremely difficult to bridge the gap between discussion of a concept and seeing how it's actually used in practical application. For example: I know websites use a programming language called Javascript but where do I actually write that code and how do I make it run?
If you encounter anything in this tutorial that you feel is skipped over too quickly, please let me know in a comment and I will make a best effort to update it to be more clear.
My goal here is to provide you with not only the technical details you need to know, but also answers to a lot of more generalized common questions that come up like:
- "How long do I need to practice before I can apply for jobs?"
- "Do I need to go to college? (or back to college again?)"
- "How do I know which things I even need to learn?"
In fact, maybe you're still so early in your journey that you don't even know what being a "web developer" means! And that's perfectly okay.
Perhaps you're still in college and worried about what it's going to be like to apply for jobs when you graduate. Or maybe you hate your current job and you heard on the internet that being a web developer is a real sweet gig.
Well, you're right it is. And it's a bit unique compared to some other professional fields like medicine, law or civil engineering where you really can learn and acquire all the skills necessary to succeed from the comfort of your own home entirely for free.
That may not necessarily be the most efficient route, or the one that is right for you, but it does afford potential avenues of opportunity to a lot of people who might otherwise not have the same options.
With that said it's important to state unequivocally that being accessible does not make it easy. Learning web development is difficult. Really difficult. It's a massive field.
That's the bad news.
The good news, is that it's a good kind of difficult. And you don't need to know everything. Not even close. I certainly don't.
If your goal is to get employed, you just need to learn enough.
Enough to get started and make small contributions to the big projects at the companies where you work. Enough to keep asking questions and learning as you go.
This guide is designed to introduce you to the basics of the many concepts you'll encounter in the web development world, but keep you focused on that goal.
(I'll add one last reminder that if at any time you feel overwhelmed or that anything in this guide is too technical for you, even as a complete beginner, to please comment and leave feedback. I will always be happy to try and improve things to help.)
Aspiring to becoming a web developer (which itself is just a specific area of focus for the more generalized role of software developer) means signing up for a lifetime of learning.
If that alone isn't enough to scare you aware right now, then that's a good sign you're on the right track.
The very first lesson, and the first thing you need to learn, is to become comfortable with not knowing how to do something. It's going to happen to you constantly. Even when you've got years of experience. There's a good chance that you'll encounter something you don't know how to do at first glance as frequently as every day.
If you see yourself as someone who can be in that situation, and see it as a challenge to overcome rather than an impasse, then you are fortunate enough to possess what is probably the most important prerequisite for becoming a developer.
The entire software industry exists because of people with that attitude, and it is entirely dependent on them to continue to function.
If you're still reading I'm going to assume you've agreed that you are that kind of person. Great! Let's take this opportunity to test that.
Is there a roadmap or summary of everything I should learn?
I'm going to hit you with a link that you might come across while you're beginning your journey. Maybe you've already come across it.
Before you click, acknowledge that part of being a developer is recognizing that it's perfectly okay not to know something. It's perfectly okay not to know lots of stuff!
Take a moment to skim through the link below. If you feel completely overwhelmed, remember that's totally normal.
The step-by-step roadmap to becoming a front-end developer
What do you think? That's a heck of a lot you're going to have to learn isn't it? Maybe this wasn't such a good idea?
The reality is you're going to come across a lot of similar links like this while you are learning. They are often going to make you feel like maybe it's too much, that the journey will not be possible.
I've been a developer for many years (including enough to be teaching and training others) and there's topics and tools on that list that not only have I never used -- but there's some I've never even heard of!
I'm here to tell you definitively that if your goal is simply to "become employed as a web developer" then you can safely devote 100% of your attention to just the first five things on that list:
- Internet (the browser and simple web servers)
- HTML (the structure of websites and web apps)
- CSS (the style/appearance of websites and web apps)
- Javascript (the interactivity and data for websites and web apps)
- Version control systems (the ability to work with other team members and back up your project)
That's it. Almost everything else on that list is simply a tool someone has created that boils down to one of the above (or makes it easier/faster to work with them).
If you have a solid understanding of the fundamentals of those five things, then you will have the necessary knowledge to learn everything else.
I'll pick a few random ones off the list to demonstrate:
- Electron: Electron is a tool that uses chromium (basically the Chrome browser) to let you write web apps that you actually install on your computer. It's popular because since it's Chrome based, you can write those apps and run them on almost any platform (Windows, Mac, Linux, etc). You write those apps in HTML, CSS and Javascript. So if you know those three, then you can easily learn Electron. Popular Electron apps include Slack, Discord and VS Code.
- Sass: Sass is an enhanced version of CSS. It lets you write a bunch of extra syntax that you can't write in normal CSS in addition to regular CSS. Once it's written you use a little tool called a preprocessor to convert that file into a regular CSS file. If you understand the fundamentals of CSS, you can easily learn SASS.
- React: React is a tool written in Javascript to make organizing and interacting with parts of the browser easier. Its syntax is basically a mix of HTML and Javascript together. Rather than having to manually write all the instructions for interacting with browser elements in Javascript, you can write re-usable React components to share behavior across different parts of your website or web app. Similar to SASS, a processor is then run over the React code to convert it into Javascript. If you understand the fundamentals of HTML and Javascript, then you can easily learn React.
Those are just three examples, but as I said the majority of topics on that roadmap could have similar descriptions. Most everything in the front-end ecosystem comes back around to HTML, CSS, and Javascript.
HTML, CSS and Javascript are the building blocks of the web, have been for decades, and despite what anyone says, there is no indication that is going to change anytime soon. Nothing is truly future proof, but those three are about as close as you get in the web development industry.
So that basic introduction out of the way, let's talk about what being a web developer really means.
What is a web developer?
A web developer is someone who contributes work to any part of a web page or application. It is a subset of the field of software development describing someone who specifically works on projects that are accessed by users over the internet.
It doesn't even necessarily mean writing code. For example you might build pages in Wix or Squarespace or Wordpress using drag-and-drop tools to place the elements where you want them.
Anyone who works on building websites is a web developer (at least as far as I'm concerned). They're just using different tools.
Nevertheless, the most common definition of a web developer is someone who uses HTML, CSS and Javascript to build websites and web apps.
The majority of jobs out there hiring for a "developer" position are looking for those skills at absolute minimum. The majority of this tutorial will be focused on those three technologies.
What is the different between a Front-End, Back-End and Full-Stack developer?
Front End Developer
A front-end developer is someone whose focus is on the part of we pages and apps that the user sees. Their core tools are HTML, CSS and some Javascript.
There is a very interesting article called The Great Divide that discusses the divide in the front-end development world.
At absolute minimum I would expect someone applying as a front-end developer to be able to work comfortably in HTML and CSS, with a basic knowledge of Javascript.
Back End Developer
A back-end developer is someone who works on the part of the sites and apps that relates to the data itself and how the user interacts with it.
A back-end dev needs to understand network configuration, hosting, HTTP, REST, user authentication, be familiar with web servers like Apache and Nginx, and know how to work with databases like MySQL or MongoDB.
Common programming languages you'll use to do back-end development are PHP, Python, Javascript, Java and C#.
Full Stack Developer
Full-stack developers are simply devs who have experience working on both front-end and back-end. Often they will not have as much experience as a dedicated dev in either domain, but they are considered extremely valuable to companies for being a jack of all trades.
Full-stack devs are more common now as many modern tools are built around the assumption of blurring lines between front and back end. It's more common than ever for companies to want to hire devs who can work with both.
My recommendation to anyone would be to have a preference for either front or back, but at least be willing to learn the basics of the other. It will greatly benefit your career opportunities if you do.
This guide will focus on tools and strategies needed to become a front-end developer, but we'll cover basic explanations of the fundamentals of back-end as well so you're at least aware of how they work if that's a path you decide you want to take.
Basic Tools and Concepts
What does a typical work day look like for a web developer?
Let's consider an example workday for a front-end developer. We'll focus on a junior developer position since that is likely what you are going to be working toward.
We'll use this opportunity to discuss topics and tools that are commonly used in real workplaces, that you should be aware of, but might not necessarily encounter when working alone including meetings, project management tools, design systems, and communication tools.
Communication Tools
Your day will likely start with opening your email, then opening up a communication tool like Slack or Microsoft Teams.
These tools are what you use to chat with your team in real time, particularly if you are working remote, but even within the office most communication is done through a tool like this.
For video discussion you'll likely be using something like Zoom, Google Meet or Skype. Most people these days are familiar with at least one of these tools, they are pretty interchangeable for the most part.
Companies typically use these for basic communication for work to be done, or asking questions and clarifying assumptions. Bear in mind that when it comes to actually documenting work that needs to be done, tools like these are usually discouraged as they are not designed to manage tasks. We'll cover that when we get to project management tools.
Once you've logged in and checked your emails, it's often time for the daily standup or similar meeting.
Meetings
You begin your day often with a meeting called a "stand up". This is where other developers on your team and your team lead discuss the projects they are working on, what they have done, what they are planning to do, and whether there is anything "blocking" their work.
An example of a "blocker" would be for example waiting for a client to send you a description of the new page they want built, which you need before you can begin working on it.
Meetings are very common in the developer's workplace (often a source of jokes and memes), but humour aside there is a reason they are popular. Often it is beneficial to a project to discuss in real-time work that needs to be done, and the different approaches about how you plan to accomplish it.
The most important thing to do to have successful meetings in the workplace is to document them and produce a list of actionable tasks. Everyone should walk away from a meeting having a better idea of the work that needs to be done.
At this point it's likely time to review the work that does need to be done that you are responsible for. This is usually done through issue ticketing systems. People within your organization will create tickets that represent issues with your project or work that needs to be done in one of the many project management tools that exist out there.
Project Management
What is Agile?
It's a good idea to familiarize yourself with at least one of these tools before you start looking for employment. One of the simplest ones to play around with is called Trello.
It has a free plan and it would be a good idea for you to use it to keep track of work that needs to be done even if you are only working on personal projects for yourself, just to get familiar with the workflow of creating issues and marking them complete.
Other more complex professional tools in that space you might use in your real job include JIRA, Github issues and Gitlab. You don't need to know how they work, just being aware they exist is fine.
In addition to the tools themselves, there are many different ways that you can choose to use them. This is where you may have heard terms like agile, waterfall, kanban,and scrum master.
These are different project management methodologies that sound fancy, but ultimately are just different approaches to tracking work and making sure expected projects are delivered on time. Feel free to Google the above terms to learn more if you desire.
As a developer you honestly really don't need to worry too much about these, you simply follow whatever methodology your company uses (oftentimes will be no specific methodology at all).
So at this point you have found a ticket assigned to you. We're ready to do actual development work.
The ticket looks something like this:
This is an extremely simple example I whipped together on Trello, but it includes most of the fundamentals. You'll have a basic title that describes the issue, and a description that explains the work that needs to be done.
Oftentimes you'll see additional things like a due date, priority list, tags for organizing and grouping related tickets etc. As a developer, particularly a junior developer, your only real concern will be the description of the ticket itself and marking it as "complete" when the work is finished.
You'll notice here the description says to use the design in Figma to complete the task. What is Figma?
Before we can answer that question, first let's talk briefly about Design Systems because the two are very closely connected.
Design Systems
As someone who does not pretend to be a designer nor a design expert, I have nevertheless come to appreciate the importance of good design and a good design system.
A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.
-- Nielsen Norman Group:
The further I go in my career the more I realize that proper design of a piece of software before development occurs can make or break the success and scalability of a product.
Pay particular attention to the terms "shared language" and "consistency". Imagine you are building a massive product with hundreds of other developers. Here's just a couple examples among countless that might occur without a proper design:
If you don't all agree on the term used for a concept in your app, you may end up with a dozen different names for the same thing like "customer" vs "user" vs "employee" across the app and two developers may think they're working with totally different data when they're actually talking about the same thing.
The designer may offer a specific hex code for "yellow" that is intended to use across the app, but if the relationship between that "yellow" is not defined between actual behavior, one developer may make it the default colour for "success" in one part of the app while another defines it as "warning" leading to a confusing UX experience when a user of your product can't easily tell if their action was correct or not.
Examples of famous design systems include Google's Material Design, Apple's Human Interface and IBM's Carbon Design System.
These systems are not necessarily exclusive to those companies, they are made publicly available specifically so they can be used by any designer and developer. Many open source tools like Material UI for example (a React component library) are built on top of these basic principles and available to use by anyone.
Depending on the company you work for, they might build on top of an existing design system while trying to modify it to their company's needs (for example just change the colours to match their brand colours). This has the benefit of being fast and inexpensive since you are working on top of existing verified designs already established.
Alternatively many larger companies will opt to build their own design systems from scratch. This has the benefit of being more unique, while also being more expensive both from the design side and the development side.
(And then of course you may be unfortunate enough to land at a company that does neither and expects the developer themselves to handle both design and development and just "make it look good". If you find yourself in that situation.... good luck!)
Once you have established what kind of design system and design language you will be using, the next step is to pick the right design tool to foster the best collaboration between designer and developer you can.
Design Tools
What is Figma?
Figma is a design tool, and pretty much the de-facto current standard in the web development industry. Other similar tools exist like Adobe XD and Zeplin but we're going to focus on Figma since it's most likely the one you will encounter.
Again, like many other tools it's more about the basic concepts. Which specific one you use doesn't make a big difference as long as you understand the fundamentals.
The general process at most companies (particularly large ones) when creating a new website or web app will be to built the wireframes about how they want it to work and function before development work actually begins.
Remember your job as a web developer isn't to make decisions about how they work or how they look (that's the job of the product manager and UI/UX designer respectively).
Your job is to implement those decisions and designs as code.
Here's a small example of what you might see when you follow the link in the ticket to the Figma design they want you to implement:
Each element built by the designer can be clicked on and you can see all the details about it, often even the CSS code you can use to build your actual implementation off of.
These designs will serve as the example of what the expectations are for how the site should look and function. When your code gets reviewed after it has been completed, the person doing the review will be comparing the work you did and checking to make sure it matches the intended design.
Remember that a website or app includes both design and function. As a front-end developer you are not just responsible for making sure images are laid out properly and that buttons are red, but also that the correct data is being displayed and correct logic is being used to display it. That's where the more complex programming aspects come into play.
It's not necessarily easy to tell from this image, but your task might include fetching data from an API which includes a real time list of all the plants the company has in stock, and exactly what their inventory levels are. This data will be changing from minute to minute, which is why you can't just write those descriptions in by hand.
All that and more is part of your responsibility as a front-end developer to create a working "New Arrivals" page. You will do this work almost entirely in the scope of HTML, CSS and Javascript.
We briefly mentioned reviews, and that is the last topic we will touch on as part of your daily experience in your front-end developer role.
Code Reviews
One last critical part of a developers job is also one of the most difficult to replicate and get experience with when you are learning: code reviews. Because you will be doing most of your work on your own, you won't get to benefit from having your work reviewed by others (unless you are lucky enough to find friends or peers online willing to do so, in which case I would highly recommend you take advantage of it).
Code reviews are a critical part of the development process for most (unfortunately not all) companies. The reason they exist is to try and ensure only that all code written and implemented as part of the larger codebase meets a certain standard of quality.
Code reviews are usually done through your version control system when your changes are committed. We'll speak more on these topics when we get to git, but the basic idea is that your code can be viewed live in a browser on a website like Github for other team members to see.
They have the ability to leave comments and either "approve" or "deny" and send back with a request to fix errors, or make general improvements.
It's important to look at code reviews as a positive opportunity for improvement. They are probably going to be one of the most important sources for your growth, and the best developers I know are those who seek out and ask for reviews from others so they can learn.
Those doing the reviews are encouraged to focus on finding and fixing potential errors, as well as issues that may result in code that is difficult to maintain in the long run. They should be done from a perspective of positive encouragement and keeping in mind that it's not something to take personally. Done properly code reviews are one of the best tools a company has to create long term maintainable systems.
Here's a great blog post about how to do a code review effectively. Well worth reading if you are going to be joining a team working with other developers.
What skills are critical for a successful junior developer?
That brings us to about the end of the day, you've successfully finished your first day as a junior developer!
There are two final closing thoughts I have that I feel are critical to be successful in a developer role that you may not necessarily get to practice much while learning on your own, so I think this is a good place to mention them:
Reading Code
Learn to Read code -- not just write it.
For many developers, particularly new ones, you will actually spend more time reading code than writing code in the real world.
The reason for that is that as someone with less experience, you will not be tasked with building new systems, but rather making small improvements to existing ones.
A lot of developers really underestimate how difficult it is to read code. Reading other people's code is hard. Harder than writing code, because when you write code you know what your intention is, but when you read it you have to try and figure out other people's intentions through the code they have written.
And unfortunately, the reality is that a lot of those code is going to be a mess. If you have any rose coloured glasses on regarding expectations of clean codebases and well documented requirements you're going to be in for a bit of a rough ride.
Oftentimes that is the exception rather than the rule, so you need to be ready to dive into something that isn't necessarily straightforward and figure out what's going on in order to make the changes that need to be made.
If this is something you would like to practice, once you have learned the basics of writing code, I would suggest looking into contributing to open source projects. It can be very intimidating at first, but also very rewarding.
Asking for Help
My rule of thumb for someone new is to try figuring out something on your own for about 10-15 mins, and if you still haven't made progress, then ask for help. That time frame will gradually increase as you get more experience.
Any good company that hires a new developer will understand that the goal is to get your trained and up to speed and will properly dedicate assets (other developers) to be available to mentor you and answer questions.
If you ever find yourself in a position where you are new and other developers are "too busy" or "don't have time to help" then please know that is a failure of the company, not a failure of yours.
Getting Started
How do I get started?
Now that we have established the mindset you want to be in, and what bring a "web developer" really means, let's talk about getting all the tools you need and setting you up for success.
There are five fundamental things that you should have before you get started
- Computer Hardware
- A Working Environment
- A Way to Test Your Work
- A Goal to Work Toward
- A Resource to Learn From
Computer Hardware
To have the most user friendly and effective setup, you are going to want to have a standard computer or laptop with either Windows, Mac OS or Linux installed.
It is certainly possible to learn programming on a Chromebook or even a tablet / phone, however you will encounter a lot more challenges in trying to do so than if you can get your hands on a computer with a traditional operating system.
Whether you choose Windows, Mac or Linux makes absolutely no difference as a beginner. Even as a professional all three of them are perfectly good viable options. Don't ever let anyone tell you that you need a Mac to be a developer. Or that you have to use Linux.
You'll be perfectly fine to get through your learning experience on whatever you have available to you, and if your job ever requires a specific one, then the company will provide that one for you.
If budget is an issue, I would recommend looking for a used laptop. Something with an least 4GB of RAM (that's about the minimum for most modern coding environments).
A Working Environment
Although it is possible to learn web development entirely with tools in the browser, it will limit you significantly compared to setting up your own computer to do your development work on.
You can technically do your development in any text editor (even something as simple as Notepad).
The reason we use specialized code editors in the software field is because they can provide tons of added features to both speed up development and check for errors in your code automatically as you type it.
You will see the shorthand IDE which stands for integrated development environment often. The most popular IDE by far is Microsoft's Visual Studio Code referred to as VS Code for short.
It's totally free and you can use it to help you write code in almost any programming language in existence.
Later in this guide we will go into full detail on how to set up a simple web server on your computer that you can use to test and run your code.
A Way to Test Your Work
Once your code is written, how do you actually run it to see if it works?
If you are learning web development, then you need something that sends your HTML, CSS and Javascript code to your browser to run. That "something" is called a web server.
When you type an address into your browser's URL bar, that URL gets converted into an IP address which identifies a particular machine somewhere on the web. If that machine is running a web server, then your browser will request data from it (usually HTML, CSS and Javascript) which it then parses and displays it on your screen for you..
Later in this guide we will go into full detail on how to set up a simple web server on your computer that you can use to test and run your code.
A Goal to Work Toward
This one is relatively simple, but it's important to define it. Most people who begin their web development journey will have the goal of getting employed in a web developer job, which is a great goal!
However some might simply wish to learn more about how websites or made, or have a hobby project in mind that they would like to learn how to build. Those are great goals as well.
Regardless what your goals are it's critical that you establish a plan for how you will reach that goals.
Early on in the process you will not even be aware of everything you need to learn, so setting specific timelines might not necessarily be realistic at the beginning.
Instead try to focus on routine, decide how much time you can devote each day and each week to your learning and make sure you've done everything you need to do to ensure that time is available for you.
Regular practice is far more important than singular long sessions. For example you will learn more from practicing for one hour every day than you will doing 5 hours on Saturdays and Sundays.
The reason being that the long the gap between practice the less likely you are to retain things you have learned. Learning web development (and anything really) is all about repetition and consistent practice.
And don't forget the importance of proper sleep for solidifying what you have learned at the end of each day.
In terms of timelines, my experience from those I have worked with and talked to in the community, is that someone who dedicates themselves to learning web development full time (like a 9-5 job) will probably require at least 6 months to become proficient enough to begin applying for jobs.
Those who are only learning just a few hours a week in their spare time will require more, likely at least a full year or more.
These are by no means set in stone, everyone is different, everyone learns at different rates, so you should not hold yourself to any unrealistic deadlines that might put you at risk of burning out or giving up.
It's a marathon, not a sprint.
Once you have that plan in place then it's finally time to decide how you will go about learning.
A Resource to Learn From
One of the most difficult parts of learning web development people often find is deciding which course they should take, or which tutorial they should follow, or which project they should build.
In this guide I will provide a lot of recommendations, the vast majority of them free to use.
The most important thing to keep in mind is again, that learning to be a developer is a constant never-ending learning journey. Each tutorial you follow and project you build will teach you a little more.
Most people find that the most effective way to learn is through a combination of tutorials and self-directed projects. Start by following an online course that will guide you and hold your hand most of the way.
After completion, try to build your own project using some of the things you learned. Select that project based around something that interests you. That's a very important step to help stay motivated to see it through.
Keep the scope (size of the project) small. It's much better to start and finish a small project then to undertake a large project and quit when you realize you've taken on too much.
The more projects you build the better you will get at properly estimating the scope of the workload.
Your very first resource will be this guide. We will introduce you to the basics of HTML, CSS, and Javascript. We'll also touch on version control (git) and web servers.
Finally we'll talk in brief detail about a number of other concepts you'll want to be aware of, even if you don't understand how they work.
Web Development Basics
How does a website get created?
So how does a website get created? We'll begin by going and taking a look at one of the most poplar websites in the world: Amazon
Start by loading the home page.
Now try right clicking on any of the section titles. I've chosen "Shop by Category" but if yours appears different thats fine.
When you right click choose "Inspect" from the menu that comes up.
A menu will appear at the bottom of your screen.
This is your browser's "Developer Console". The code-looking text you are seeing is called HTML. It is a special kind of text designed to structure content.
It is one of the three primary web languages you will need to need to learn to become a web developer (along with CSS and Javascript).
What you are looking at is the complete HTML structure of the Amazon home page. This code is not designed to be hidden from you, in fact all code that runs in your browser on every site you visit is totally public and visible by using the "inspect" tool.
You will find that the browser's inspector is one of many important tools you will become familiar with while learning.
How can I build a website or web app?
The absolute easiest way for someone with no experience at all to start building their own website or web app is to use a tool called Codepen.
There are many tools like this (code editors in your browser), I have simply chosen Codepen because it's one of the simplest and easiest to get started with.
Create an account for yourself (using an account will allow you to save your work) and then click the Pen button on the left menu. You'll be taken to a screen that looks like this:
Remember we were looking at some HTMl code on the Amazon website, so let's copy it over and see it if works here! I've doing to copy and paste this from the developer console:
<h2 class="a-color-base headline truncate-1line">Shop by Category</h2>
Notice that a couple of seconds after your paste it into the HTML block, some text appears in the white section of the bottom of your screen. That is Codepen render the result of your HTML!
It looks just like it did on Amazon, even the font size is similar. The reason for that is that <h2> represents a "header" and all browsers have built-in ways of deciding how they should look. You can customize them of course, but the browser handles the defaults.
You now have an environment where you can learn and play with HTML. We'll go into more detail on HTML in a later section. For now I'd also like to introduce the other two important languages you will need to learn: CSS and Javascript.
We'll begin with Cascading Style Sheets. CSS is a special syntax used to change the way HTML looks. So as we mentioned, your browser has its own default options of how an <h2> tag should look, but with CSS we can override those default styles and make it look however we like.
In the second box on your Codepen marked as CSS let's add the following code:
h2 {
font-size: 36px;
color: green;
}
Notice how it changed the font size and colour of your text? That's what CSS does. The label outside the curly brackets says h2 which is called the selector. That specifically says which HTML elements we want to apply these styles to.
We'll get into CSS in much more detail in a coming section, but let's at least introduce the 3rd language you'll be learning: Javascript.
Javascript is by far the most complex of the three, it's a full fledged programming language, but believe it or not you can actually build fully complete websites with just HTML and CSS alone.
Javascript is only need to make your sites and apps interactive, and although that is an important part of the vast majority of the web these days, there are still many types of sites that need little to no Javascript.
For example a business page for a local restaurant which simply lists the menu, store hours and a contact phone number. Or a blog which is just written content and images and links between pages. Neither of those examples would require Javascript to work.
As soon as you start to want user interactivity, you are going to need it though. Let's show one of the simplest examples of Javascript at work: a button.
Add the following to your Codepen in the Javascript section:
function buyItem() {
alert("You bought an item!");
}
What we've created there is a "function" which is basically something that performs a set of tasks. In our case the task is to show an alert banner on the screen that says "You bought an item!"
In order to actually trigger our function though, we will have to connect it to HTML. We'll need a button we can click that will "invoke" this function. Add the following code to your HTML block on codepen after the <h2> that is already there:
... <button onClick="buyItem()">Buy Item</button>
A button that says "Buy Item" will appear in your little app. try clicking on it and you should get a little pop up window that says "You bought an item!"
Honestly, that's web development in a nutshell right now. Obviously it just grows and gets bigger and more complex from here, but you now have experience using every core tool you need to build applications for the web.
All the fancy tools you hear about like React, Angular, etc ultimately just transform your code into HTML/CSS/JS before it gets sent to your browser, so if you can learn the fundamentals and learn them well then you will be in an extremely strong position to pick up the specialized tools which simply make developing apps easier and more efficient.
Easier said than done of course, but we're going to walk through everything you need to know step by step.
How can I build websites on my own computer?
There's absolutely nothing wrong with continuing to use Codepen or similar services like Codesandbox, Replit or Glitch while learning, but at some point you are probably going to want to know how to built websites using tools on your own computer.
There are many benefits to doing it this way, you'll be able to store and manage your own files, as well as share them with others. You can customize your own tools to behave how you like, and you don't need to worry about always having access to an internet connected browser to build.
Of course when you work for a real company the expectation is that you will be working on your own machine (or a company machine) so it will be expected that you know the basics of how to set up an editor.
Absolutely any text editor can be used to write HTML, CSS and JS. Even basic Notepad. The main reason we choose something like VS Code (which this tutorial will teach you to use) is that we get major benefits designed to help people who write code.
Some of the benefits include:
- Project organization (see all the files for our project in one place)
- Syntax highlighting (colouring text differently depending on what it does)
- Intellisense (autocomplete and tooltips that tell you what your code actually does)
- Error checking while you write
There are many more benefits of course, but these are just some examples of the most useful ones!
The next section will help you get VS Code installed on your machine and prepare you to setup your first web project.
In the event you don't have a computer you can install a text editor on, you can continue to use Codepen for the time being. Simply skip over the below section on setting up VS Code. You would also want to skip the section on configuring a web sever, but it's still worth reading as there are many concepts explained that are important to understand.
How do I set up a development environment on my computer?
Start by installing VS Code. You can download it here from the official site.
The benefits you will get from automatic syntax highlighting, formatting, intellisense and other programming-specific features will not only improve the quality of your code, but also your experience in writing it.
You will definitely want to download or bookmark the keyboard reference for your relevant OS:
- VS Code Keyboard Shortcuts (Windows)
- VS Code Keyboard Shortcuts (Linux)
- VS Code Keyboard Shortcuts (Mac)
The majority of the keyboard shortcuts in this tutorial work for both Windows and Linux, and Mac users can usually substitute the Ctrl key for the Option key.
Next we are going to create a folder called my-project. You can create this folder anywhere on your computer that you like. Once you have created it return to VS Code and select File -> Open Folder then navigate to the my-project folder you created.
Now open up the Explorer bar on the left side of VS Code. There are a few ways to do this, either press Ctrl + Shift + E or use the little papers icon:
You are now ready to create files and write code.
Before we continue any further, let's really start to dive deeper into what HTML is and teach you how to set up the shell for a standard website.
HTML
What is HTML?
HTML stands for Hypertext Markup Language and it is the building block of all content on the web, and even many web applications. It is a way to represent different types of content, for example headers, paragraphs, links, images, lists etc so that another tool (for example a browser) can display them in a way that is easy for a user to consume.
HTML is primarily concerned with the content its and not its visual style; however there is some overlap and browsers all have their own set of default styles they use when they render HTML content.
If we were to compare it to a house, HTML would be the foundation, the walls, the roof. Things like paint, trim, and even arrangement of the furniture would be someone else's job (for example the interior designer). Our job as HTML is to simply provide those building blocks to the designer.
HTML is a series of elements. An element is composed of three things:
The opening tag - Contains the element name. For example a paragraph tag is
<p>. That opening tag can also have attributes inside of it which we will get to in a moment.The content - Contains anything that goes inside the element. Can be just text, or another element, or multiple elements.
The closing tag - Tells whatever is rendering your markup that this element is finished. Looks similar to the opening tag with a slash character, so a paragraph closing tag looks like
</p>. All elements have a closing tag (with a few exceptions called void elements).
So taking what we know now, a paragraph element would look like <p>Hello everyone!</p> and would render on your wep page as simply text. Here's how it looks by default in Firefox:
When we discussed the opening tag we mentioned the other important thing that an HTML elements can contain are attributes. An attribute provides additional information or identifying characteristics about that element.
A link for example which is defined by an anchor element uses the <a> tag. Of course a link is useless without specifying where you want it to go. The destination of a link is specified with the href attribute.
Attributes are always placed within the opening tag of an element, and follow the rule name="value" with the value in double quotes. So to set the href attribute on our anchor it would look like:
<a href="https://www.google.com/">Link to Google</a>
The content of the element will be the text of the link. When we place this below our paragraph tag, our page now looks like:
Click on that link will take our browser directly to Google.
Lastly let's take a look at the complete HTML content used to render these examples. The below code shows everything that is required to render out the most basic web page:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My First Project</title>
</head>
<body>
<p>Hello everyone!</p>
<a href="https://www.google.com/">Link to Google</a>
</body>
</html>
(Note that technically some of this could be removed and still rendered by the browser, when we say "minimum" we are referring to best practices of good HTML form, not the absolute minimum to get some content to appear)
You are already familiar with the <a> and <p> tags so let's look at the rest of the structure:
<!DOCTYPE html>- Simply informs the browser that you are writing valid HTML. This element used to provide more functionality than it does in modern times. Simply including it is sufficient.<html>- This is the root element that wraps your entire page, simply specifying "this is where my HTML content can be found". Thelangattribute specifies that the content we are writing is in English, this helps translation tools like Google translate know what language to start with when doing the translation.-
<head>- This element wraps all the elements that provide information about your web page that don't actually contain any content that renders on the page itself.-
<meta>- This is a general tag that provides meta information about your HTML, for example above we are telling the browser that our HTML is written using the UTF-8 charset so you can expect any valid character in that set to appear. There are many other meta elements you can use as well. -
<title>- Provides the title of your web page, you can see this most commonly as the label of your browser tab. This is very important for SEO which we will get to later.
-
<body>- Contains the actual visible content of your site. Differentiate from the<html>element which contains both the visible body, but also the metadata in the<head>.
There is lots more to learn, but this covers the absolute fundamentals. Check out the where can I learn more section to dive deeper.
How do I use HTML?
Here we will look at how you can take your knowledge of basic HTML structure and use it to build something.
Presuming you followed the introduction about setting up VS Code, you are now ready to create your first HTML file.
Note that VS Code is not required for any of this, it's simply a text editor. If for any reason you prefer other code editors like Atom or Sublime they work just as well, and you can follow along exactly the same (just be aware the keyboard shortcuts and example images will not necessarily match up).
Begin by opening the sidebar (Ctrl + Shift + E) right clicking in it and selecting "New File". You can also press Ctrl + N to create a new file.
Our file will be called index.html. The html extension identifies that the file contains HTML, and the name index is also special too. index is the default filename a web server will look for when a browser makes a request. It's not required to name your file index.html, but if you don't then you would specifically need to tell your browser which file to get.
We'll cover this and more in the section on web servers ahead.
Once your file has been created you can copy & paste the code from the first section into it:
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My First Project</title>
</head>
<body>
<p>Hello everyone!</p>
<a href="https://www.google.com/">Link to Google</a>
</body>
</html>
We were told this is valid HTML, but is there a way we can be sure? There is!
If you would like to validate your HTML to ensure it meets modern standards you can use W3's HTML validation tool.
Let's paste our code into it to be sure:
Fantastic, we've verified everything is good to go.
Before we look at getting our code running in the browser, let's wrap up our discussion on HTML. Below are some great free resources for taking your HTML learning further, and I've also mentioned a few key topics you will want to learn more about as you build your skills.
What else do I need to know about HTML?
Semantic HTML is all about using tags that properly describe your content. For example using an <h1> for a header rather than putting your text in a <div> tag. This allows things like web screen readers to better understand that the text is meaning to tell the user. More information below:
Accessibility and Semantic HTML
SEO stands for Search Engine Optimization and it is the field of creating your site in such a way that search engines (mostly Google) can scan them automatically and increase their ranking when users search for relevant terms. Things like semantic tags, page speed, colour contrast, text content and much more are considered when deciding your SEO score. More information below:
What are the best free resources for learning HTML?
There are tons of great resources on learning HTML out there, and they're free!
MDN for a complete resource that covers everything you need to know about HTML
The Odin Project HTML foundations portion of the full stack curriculum
Codeacademy for a more academic "course style" approach to learning HTML
HTML Validator - The HTML markup validation service
HTML Can do that? - A great blog post on dev.to showing some amazing browser native features that can be accomplished in pure HTML without CSS or Javascript
Web Servers
Now we are ready to get back to the HTML code we wrote in the previous section. We would like to view the contents of that HTML file in the browser.
But how do we do that? Where exactly does the browser get the HTML code from to display it? We need a way to test and view the HTML we have written.
This section will teach you everything you need to know about how that code gets up and running in your browser. This is not specific to getting it running on our machine, the concepts you are going to learn are exactly the same concepts real web servers use that let us access real websites and web apps from the internet every day!
What is a Web Server?
(Note that although I would consider this sub-section to be extremely important for every aspiring web developer to understand, it's not required understanding to complete this tutorial. If you would prefer to skip understanding how a web page gets to to your browser, you can jump ahead to How do I run a web server?
That said I would highly recommend you at least briefly read through it if only to become familiar with the basic terminology.)
A web server is a fancy name for software on a computer that is connected to a network and has the ability to send content over a protocol called HTTP. Most commonly this is an HTML page, but a web server can serve up any type of data you like.
It can be something running on a farm of supercomputers across the ocean, handling millions of requests per second, or it can be something running on your own machine to practice writing HTML.
Our tutorial, to no one's surprise, will focus on the latter.
Before we get into how to run a web server, let's start with why we need one. A web server exists to provide data to your browser, so that you (the user) can request different web pages and data. The HTML file we created in the previous section is not really any different from a web page you would request on the internet. So how does a web server know which file to send to the browser?
What is a web request?
Domain
When you enter a URL into your browser and press enter, it makes what's called a GET request to a server. Let's pretend that address is https://www.google.com/. Presumably we are trying to get the Google homepage.
How does it know which server, of all the servers in the world, to get the Google homepage from?
A server is identified the same as any other computer, with an IP address. Notice we don't see any IP address in http://www.google.com/.
When a domain name is used, the IP address is acquired through a system called DNS which transforms the domain name into an IP address. There are DNS servers all over the world with giant address books of all the domain names and the IP addresses they are registered to.
Port
So now that we have identified the Google server, your browser makes an HTTP GET request to that server. In addition to the IP address, a request also always includes a port number which helps to identify which process (think which piece of software) that request should go to.
Imagine you are mailing a letter. Think of the IP address as the house your letter is addressed to, and the port as the name of the person inside the house that the letter is for.
HTTP requests by default use port 80, so you don't have to specify it manually. You can still specify the port manually with a colon and the port number. So a request to http://www.google.com/ is equivalent to a request to http://www.google.com:80/. Try it yourself! Anything other than port 80 should give you a timeout error because no process on the Google server is listening on that port (or if they are, they aren't listening for your type of request).
Path
The final part of the URL that is relevant to our example is the path of the data we are requesting. A similar term you might also hear in this context is the route. That's the part that tells the server what data or page specifically we are looking for.
In our example it is the / on the end of the URL which is often referred to as the root directory. Think of it similar to filers and folders on your computer. It represents a path on a file system where you cannot go "up" any further.
In the context of web servers, it typically represents the directory the server is running in. This way it provides a layer of security. If you run a web server in c:\Users\my-server then requests made it it will only be able to access files within that my-server directory (and directories inside of it). Users would not have access to anything in the c:\users directory or above.
Let's give an example. I create a directory (folder) called my-server on my computer, and run my web server software inside that directory. Let's say the IP address of my computer is 127.0.0.1 (this is a actually a special IP that always refers to your own machine, so this is a valid way to make requests to your own machine).
If I enter http://127.0.0.1/ into my browser, the web server will go looking in the root directory, which means the directory the server software was started in. In our example that is the my-server directory. By default most web servers will look first for a file called index.html and send it back to whoever is requesting (our browser in this example). If it finds that file, the browser will render it, if not, you'll likely get an error.
What if we make a request next to http://127.0.0.1/something-else ?
Our web server will now look for a directory called something-else inside of the root directory and follow the same behavior: look for an index.html file. This is how we can create routes on our website. Let's say we put relevant info about our business into an index.html file in our root directory. Then we create another index.html file with our business hours and phone # and put it in a folder named contact-us.
We can now access the main page at http://127.0.0.1/ and our contact info at http://127.0.0.1/contact-us
How do I run a web server?
(This section will cover the basics of how to run a web server on your own computer so that you may test your website/app while working on it. If you are looking for how to actually put your website/app somewhere so it can be accessed publicly by anyone, check out How do I put my website on the internet)
(Furthermore, if you are looking for more information about how to a production web server for a real world website or application that needs to handle both large amounts of traffic and guarantees about service & uptime, then you will want to reach more about a professional web server like Nginx rather than the more hobby-level approaches described below)
We've covered the basics you need to understand about what a web server is an what it does. At this point you should be able to comfortably run one yourself and explain in simple terms what it is doing.
Let's now look at how to run a web server yourself and get the HTML you wrote in the previous section to render in your browser on your machine.
In this section we are going to learn how to add some extensions to the tools you are already using (VS Code or Chrome) to serve up your web content and view it in the browser.
If you would like to learn how to run your own web server on your own machine (which is surprisingly easy) I have written a separate tutorial for this: (Note that this tutorial presumes you have a basic familiarity with the terminal on your machine, at least enough to be able to copy and paste commands)
If that sounds a bit beyond your understanding, then no problem at all! For this tutorial we are going to focus on the absolutely simplest way to simply get your content running in your browser. We will provide three options, choose the one that fits your situation best:
Option 1: Choose this option if you have installed VS Code on your machine
Option 2: Choose this option if you have installed Node.js on your machine, you understand how to install an NPM package and you want more control over your server than the VS Code extension provides.
Option 3: Choose this option if you are using the web version of VS Code, or any editor other than VS Code, or are on an OS besides Windows/Linux/Mac (a Chromebook for example)
Option 4: Choose this option if you are on a public computer like a school or library where you do not have permission to install software
Option 1: VS Code Extension
We are going to install the VS Code Live Server extension. Start by clicking the Extensions icon or pressing Ctrl + Shift + X.
Next search for Live Server or the unique id of the extension: ritwickdey.liveserver and click it, then click install:
(This is a reminder if you are using the web version of VS Code that this extension does not work, please use Option 2)
Once installed, a Go Live icon will appear on the blue bar at the lower right corner of VS Code:
(Another alternative option is to simply right click on index.html and select "Open With Live Server" which is a new option that will appear when the extension is installed)
Regardless of which method you choose, you will be able to view your web page at whatever port the server decides, the default URL being http://localhost:5500.
If you have any difficulty you can refer to the full documentation here.
Option 2: HTTP Server
If you have Node.js installed on your machine and are familiar with the basics of the command line, you can get a simple web server up and running in a few seconds.
Navigate to the folder that has the web files you want to host (usually that means the directory with your index.html file) and run this command:
npx http-server . -p 8080
(Note there is a period character before the -p which indicates "this directory")
That will start the server running in the directory you are in and serve the files. The -p indicates the port which I've set as 8080 which is the default, but you can run your server on any port you choose.
You will be able to view your website's index.html file by visiting this URL:
Obviously change the 8080 if you decide to use a different port. And remember that localhost is simply a special shorthand name for the IP address 127.0.0.1 also known as the home address.
When you are done with your server simply press ctrl+c to close it.
Option 3: Chrome Extension
(Reminder that you only need to choose one option, if you already have your HTML running in the browser then skip ahead)
If you are using the web version of VS Code or another editor and just want to get your code up in the browser, another easy option is the Chrome browser extension. This option requires you to use the Chrome browser.
(If you cannot use the Chrome browser, or would prefer to run your own on your own machine via the command line then jump ahead to option 3)
Start by installing the extension called Web Server for Chrome in your Chrome browser
Next navigate to chrome://apps/ in your Chrome browser. There you should see and be able to click on your new Chrome app.
In the menu that appears select "CHOOSE FOLDER" and navigate to your project, the /my-project directory that contains your index.html file inside of it that you created in the first section.
Finally go to the URL that the extension shows in the menu, by default it is . If all goes well you will see your page!
Option 4: No server at all
(Reminder that you only need to choose one option, if you already have your HTML running in the browser then skip ahead)
If you are unable for any reason to install software on your machine (or even extensions in your browser) then we still have an option for being able to write code and test it in the browser.
The title of "no server at all" is a bit of a misnomer as there is still a server; it's just being run by someone else and you are simply providing the code to be served.
This option would technically work even for a device like a phone or tablet. Though I would not recommend trying to code on a small touch device; I will say that maybe a tablet with a big enough screen and a bluetooth keyboard you might be able to get yourself a viable environment for practicing (if you have no other alternatives).
In the first section of this tutorial we use Codepen to demonstrate how to quickly write some HTML, CSS and Javascript. Unfortunately Codepen does not provide an easy free way to mimic the file structure of a real project.
For this example we are going to use Replit. It's an absolutely fantastic tool that supports browser-based coding environments in all kinds of programming languages. It does require you to sign up however, but doing so will give you the big benefit of being able to save your projects, share them with others, and come back to them later.
Start by navigating to https://replit.com/ and creating an account. Once you are logged in you will see a Create option with a + button:
Click that button and you will have a number of templates you can choose from the dropdown. Select HTML, CSS, JS:
At this point you will have your own web editor that looks quite similar to VS Code. On the left are all your files generated and setup for you, with default templates provided. GO ahead and replace the content of index.html with our example and press the Run button. You will see the same output that we have on our local server:
You now have an environment you can continue to follow along and write code in directly in your browser.
In future tutorials (and as you learn more and your projects get more complex) you will likely begin to run into limitations of what you can do with this tool, but if your goal is to learn the fundamentals of HTML, CSS and JS then this tool can easily take you the majority of the way if you need it to.
What else do I need to know about web servers?
Some topics related to web servers that are worth learning about as you build your skills:
What are the best free resources for learning web servers?
There are tons of great resources on learning HTML out there, and they're free!
MDN again is your best friend for learning the fundamentals.
When you are ready to learn how to configure your own real web server then I would suggest a Digital Ocean Droplet. That page might look overwhelming, but it's just a fancy name for remote access to one of their computers you can put your web content on, and let other people access. They have a great tutorial on setting up one of the most popular web servers called Nginx (pronounced engine-X).
CSS
At this stage of the tutorial we are operating under the assumption that you were able to successfully get one of the three options for running a local server up and running, and you have the ability to view your HTML in the browser.
In this section of the tutorial we will begin to learn about how we can style our content with CSS.
What is CSS?
CSS stands for Cascading Style Sheets and it represents a syntax for describing for HTML content should look. Someone who is well versed in CSS can take the same HTML content and make two completely different looking pages out of it, such that you might hardly recognize it comes from the same HTML source.
A great resource to demonstrate this idea is CSS Zen Garden. On the right side of the page are links you can click on to apply different CSS stylesheets to the site. The HTML content doesn't change, but with the power of CSS each design feels like an entirely different site!
Before we discuss the concepts, you should be familiar with the most basic syntax. Let's begin with a simple example of some CSS, and explain what it is and how it works:
p {
font-size: 18px;
color: green;
}
Take a look at what happens when this CSS is applied to the HTML from the example in our previous section:
(Note you don't need to create any files or do any coding along with this section, we are just using this as an example to learn the syntax, you will learn how to create your own .css files and add them to our project in the next section)
It should be fairly straightforward what has happened based on the example above. Our "Hello everyone!" text has been formatted with the styles we described in the CSS.
These style descriptions like color: green are calledCSS properties.
Properties
CSS properties are combination of a name (e.g. color) and value (e.g. green) separated by a colon that describe what styles to apply to the elements you have selected.
There are more properties out there than any one person is likely going to learn in an entire career. Fortunately you do not need to learn them all. Many of them are either not supported anymore, or their use is strongly discouraged.
Focus on trying to learn the core properties well rather than trying to learn a lot of different properties. Like many things in life you'll find than a small number of them end up comprising the vast majority of usage.
Here is a hand picked list of the most common properties you will encounter, and the most important ones to learn (the rest can be picked up as you encounter them):
- display
- position
- box-sizing
- width (including min-width and max-width)
- height (including min-height and max-height)
- margin
- padding
- border
- color
- background-color
- background-image
- font-family
- font-style
- font-weight
- z-index
MDN also has a slightly larger opinionated list that you can use as a quick reference to learn about these and more.
Selectors, Combinators and Specificity
In our CSS example above, why did the styles apply to the <p> element and not the <a> element? The reason is CSS selectors.
In our example we are using a tag selector for the p tag. You can see that before the opening of the first curly brace p {. This will apply all styles in that block (between the curly braces) to all <p> elements on the page.
Selectors are one of the most basic features of CSS, they describe which specific elements that your styles should be applied to; but what happens if multiple selectors try and apply the same CSS property to an element?
The default is that the styles that come later would overwrite. So in the example:
p {
color: green;
}
p {
color: red;
}
All <p> elements on the page with this CSS would render as red. This is where the concept of the cascade in Cascading Style Sheets comes from.
However this only applies if the selectors are exactly the same level of specificity. They are in this example because they are identical (each one is a tag selector for <p> tags.) There are many different kinds of selectors though, and ones that are considered more specific would take precedence even if they came earlier on the sheet.
Specificity is what determines which property gets applied to an element in a scenario where a property is set from more than one selector.
Let's take a look at each possible level of selector in order of specificity. This means that each one of the examples below is more specific than the last, so it would override those styles even if they appeared first on the style sheet:
Global Selector
* {
color: green;
}
The asterisk is called the global selector and it targets every single element in your HTML. There are not many cases when you want to apply a style to every element in your page, so it doesn't get used too often.
It can be handy for debugging, for example to place a border around every element on your page to help quickly get a visual indication of the size of eah element.
Tag Selector
p {
color: green;
}
div {
width: 100px;
}
The above example shows two tag selectors. It will apply a green color to all <p> elements on the page and a height of 100px to all <div> elements.
If you used the * selector to set the color of all elements, this would overwrite that color value for p and div tags.
Class selector
p {
color: red;
}
.example-class {
color: green;
}
<p class="example-class">I will be green</p>
The class selector uses a period . before the term of your selector and will target all HTML elements with that term on the class attribute. In our example the term is example-class but that term can be anything you like.
The class selector is more specific than the tag selector, so green is applied.
ID Selector
.example-class {
color: red;
}
#example-id {
color: green;
}
<p class="example-class" id="example-id">I will be green</p>
The ID selector uses a pound symbol # before the term of your selector and will target all HTML elements with that term on the ID attribute. In our example the term is example-id but that term can be anything you like.
The ID selector is more specific than the class selector, so green is applied.
Inline styles
#example-id {
color: red;
}
<p id="example-id" style="color: green;">I will be green</p>
This is not a selector per-se, since it gets set directly on your HTML element as an attribute rather than within your CSS.
HTML elements all have an attribute called style that allows you to set CSS properties directly. These properties are so specific they will override even ID selectors.
It can be convenient to quickly set styles directly on the element, however you should be cautious as it is often considered a bad practice. The reason being that they are difficult to override elsewhere, and that they exist outside of your stylesheets. Having styles in more than one location can make it difficult to reason about how styles are being applied.
!important
#example-id {
color: red !important;
}
<p id="example-id" style="color: green;">I will be red</p>
Often called the nuclear option when all else fails and you can't figure out why your styles are being overwritten, CSS supports a very powerful option called !important that essentially says this style cannot be overwritten.
Notice in our example it even takes precedence over inline styles.
!important is nearly always considered very bad practice for reasons that should be obvious. The entire concept behind cascading style sheets is that styles are designed to be overwritten at different levels of specificity. !important breaks that model entirely.
To give an example: consider a scenario where your downloaded a library of "cool buttons" that looked fantastic and fit the needs exactly for your clients product. Your client says "they're perfect, we just need them to be blue instead of green". You find out to your dismay the button library author used background-color: green !important; when styling them. There are ways around this, but your job has just become significantly harder than it needed to be.
In summary, avoid !important entirely unless you are absolutely sure you know what you're doing.
Multiple Selectors
You can combine styles together and apply them to more than one selector with a comma. For example:
h1,
h2 {
font-weight: bold;
}
Will apply the bold style to all h1 and h2 elements on your page.
Combinators
The last aspect of CSS we need to address before going into our example is combinators.
Combinators work in tandem with selectors. They allow you to chain multiple selectors together to get more specific. They are applied most often when dealing with nested elements. For example:
div {
background-color: black;
}
p {
color: black;
}
div p {
color: white;
}
div > p {
font-size: 20px;
}
<p>I am black text</p>
<div>
<p>I am white text and 20px size</p>
<section>
<p>I am white text but regular size</p>
</section>
</div>
There are two combinators in this example:
div pdiv > p
The first one uses the space combinator, a space between selectors means all children of elements targeted by the first selector. So styles in div p would apply to every <p> element that is a child of a <div> element.
In our example this is necessary. Since we gave our <div> a black background, the text in the <p> elements would be invisible if we did not set it to white.
The second one uses the angle bracket >, it means direct child of this element, so any <p> element that is a direct child of a <div> element will be targeted with the styles we write here.
Notice the word direct in this example only applies to <p> elements that have a <div> as a direct parent. Our first <p> has no parent and our third <p> element has a <section> as a parent, so only the second one has the font-size: 20px style applied.
You can find a great quick reference for selectors and combinators here.
Now that we have covered all of the basics, let's take a look at a real world example that we can continue to iterate on for the remainder of this tutorial!
How do I use CSS?
There are three primary ways to apply CSS to your HTML:
- Using the
<style>tag - Using the
styleHTML attribute - Using a
.cssfile
Option #3 is by far the most common and nearly always the best practice, however since we are here to learn we'll quickly begin by showing an example of options #1 and #2:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>Example</title>
<style>
p {
color: green;
}
</style>
</head>
<body>
<p>I am green</p>
<p style="color: red;">I am red</p>
</body>
</html>
The above example demonstrates the use of the <style> tag in the header applying a green colour to all <p> elements.
Within the HTML itself the second <p> element has a style attribute which is setting the color property to red. This has more specificity than the tag selector, so the second paragraph element will render as red.
To demonstrate the third and most common option (a .css file) we are going to construct a more complex example and take the time to break each selector and property down to get some experience working with something that looks more like a stylesheet you might encounter in a real world site.
Begin by creating an index.html file in the root directory of a project (you can use the one you already created it you are following along) and paste the following code into it:
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My Animal Blog</title>
<link rel="stylesheet" href="style.css" />
</head>
<body>
<header>
<h1>My Favourite Animals</h1>
<h2>Enjoy these furry friends</h2>
</header>
<main>
<article class="card">
<img
src="https://res.cloudinary.com/dqse2txyi/image/upload/v1657421273/blogs/intro-to-web-development/cat_k4fcww.png"
alt="Cat Playing Chess"
/>
<div class="card__container">
<h3>Chess Cat</h3>
<p>He's planning his next move.</p>
</div>
</article>
</main>
<footer>
<p>© 2022</p>
</footer>
</body>
</html>
The key line to look at in the above example is this one:
<link rel="stylesheet" href="style.css" />
This element tells your browser that you want to link an external stylesheet, and the filename is style.css. It looks in the root directory by default. As of right now, you do not have a style.css file in the root directory of your project.
Without any CSS at all, this page looks like:
Not too bad, but we can make it look a lot better. Create a new file in the root directory next to index.html and call it style.css.
Leave it empty to start. We're going to add some CSS little by little to clean it up a bit and give you an idea how to craft an extremely simple, but still modern and responsive page design. We'll also explain each piece in detail as we go.
So feel free to add each of these pieces to your style.css file as you read them, one after the other (it's not necessary though if you would prefer to just read, we'll post the full file contents at the end).
So let's begin styling our animal blog:
body {
color: #333333;
font-family: Helvetica, sans-serif;
margin: auto;
max-width: 800px;
}
The body in HTML defines where all the content is. The body is inside the <html> element, which by default will span the entire width of the page.
Let's look at each property in the body tag selector, to see what they do and why we chose them.
max-width: 800px;
Typically in many modern web pages you'll find it common for the actual content not to span the entire width of a user's screen. People often use very wide monitors these days and it can be challenging to read content, particularly text that spans from one edge to the other.
For an easy example of this go to Google and search. You'll see that the search results only span a small portion of the screen before the text wraps (on my 1920px monitor the results are 600px wide).
We are doing something similar for our blog. Body content can only be a maximum of 800px wide, and will shrink down automatically on smaller screens.
margin-auto;
With only max-width our content will still be left justified on the page. We would like it to be centred. That's what having an auto margin does in this context.
On the top and bottom it will do nothing since the default height of <html> is only the height of our content; however the width is the width of thr full screen. The difference between that screen width and the 800px content will automatically become margin on the left and right.
This has the result of placing the content in the centre.
color: #333333;
Pure black text on a pure white background creates a fairly stark contrast. It's not terrible, but it's fairly common to use a not-quite-black color instead of black for text on a white background.
Here we have chosen a hex colour that is close to black, but not quite.
font-family: Helvetica, sans-serif;
After setting the color we are also setting the default font of our site. We've chosen Helvetica because it is one of the safe web fonts that are available on the majority of web browsers and operating systems.
The font-family property allows as many font names as you like separated by commas. It will chose the first one it finds from left to right that exists on a user's system. The final option sans-serif simply says worst case give me any sans-serif font you have.
Here's a look at what we have so far with our body styles:
main {
margin-bottom: 40px;
}
header,
footer {
text-align: center;
}
h1 {
font-family: Arial, sans-serif;
}
h2 {
font-style: italic;
font-weight: lighter;
}
margin-bottom: 40px;
We added this to give a bit of space at the bottom of all the main content before the footer, so the copyright symbol doesn't press up directly against the text.
text-align: center;
As described, this centre aligns the text in the header and footer. Since the header includes both an <h1> and <h2> element each one will automatically inherit that property.
font-family, font-style, font-weight
Each property sets the font properties as described.
Similar to the previous, but now our fonts are updated and our texts are centred:
.card {
width: 350px;
margin: auto;
box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
border-radius: 10px;
overflow: hidden;
}
width: 350px;
We are going to set our card elements to be 350px wide. This is simply a value I have chosen based on common screen sizes. Very few modern smartphones have a width smaller than 375px, so setting our cards to 350px means they will fit nicely (without having to be shrink) on nearly every device.
margin: auto;
Used again for centring, this time to centre the card inside the <body>. Since the card is 350px and the body is 800px this will set margins on either side to fill the difference and centre the element.
box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
Easily the most complex of all our properties, but a good example to break down because it will not be uncommon to encounter this type of property in your CSS journey.
First the property itself, box-shadow creates a shadow like effect around the edge of an element. The thickness of it depends on some numeric values. In this case it is the four numeric values you see 0 4px 8px 0
Whenever you see a CSS property with four consecutive numeric values it typically refers to the sides of a box in clockwise order from the top. This image from MDN illustrates:
So in our example, there is no shadow on the top, 4px on the right, 8px on the bottom and no shadow on the left. In CSS when using the number 0 it is standard to leave off the unit.
The final fifth value on box shadow indicates the colour. For an rgba colour 0, 0, 0 is black and the final value is the alpha; think of as the opacity. That's what makes the shadow look more natural and diffuse rather than a solid black at 0.2.
If you managed to follow this one, well done! If not, don't feel bad about skipping over it. This type of syntax will grow on you naturally as you encounter it more often.
border-radius: 10px;
A border radius will give us rounded corners. The larger the value the more rounded. It's common to use this property to create circles by giving a radius of 50%. For our case 10px give a nice rounded edge to the card.
overflow: hidden;
This is necessary to keep the image from going over our rounded corners. Since the image has rectangular images and sits above the card <article> it would hide the rounded corners of the card.
Hiding the card's overflow keeps the image inside the card and the edges visibly round.
.card > img {
width: 100%;
height: auto;
}
Setting the width of our image (using the direct child combinator) to 100% will stretch it to the edge of its part, the 350px card. Setting the height to auto ensures that the aspect ratio remains correct.
.card__container {
padding: 16px;
}
For our class selector here we have used a common practice to help with CSS scoping. Imagine we had just called this class container. It's a pretty common term, what if we have a container somewhere else on the site? The styles of that container class would overlap and mix unintentionally with these ones.
I've chosen to prefix the class name with the name of the parent card with two underscores between. This is a common practice based on a methodology called BEM or block-element-modifier.
Essentially it's just a way of naming things to avoid unintentional collisions between unrelated elements. There are many different ways of doing this, you should choose whatever feels right to you as you gain more experience.
The property itself padding: 16px will create a buffer of space inside the border of the element. This keeps the text from pressing up against the edge of the box border, and makes things look a lot cleaner.
Now finally with all properties applied, or styling for this example is done. Take a look:
What else do I need to know about CSS?
The "cascade" is how CSS decides which styles actually get applied to an element when multiple different rules are applying values to the same property.
The box model describes the way every element in CSS is rendered on the page and all the factors (padding, margin, border) etc that go into deciding its size and how it flows with the rest of the content.
Flexbox is one of the most popular ways of laying out content on a web page. Modern browsers will support Grid which is even more powerful for full 2D layouts, but any modern CSS developer must understand Flexbox when contributing to web projects professionally:
Media queries are used to change which CSS styles are applied depending on what media the user is using to view it. Most commonly used to change styles for mobile devices.
There are many different units in CSS (px, em, rem, etc) and it's important to understand the difference between them.
- CSS Units DEBUGGING CSS
What are the best free resources for learning CSS?
The Odin Project - The Odin Project CSS foundations curriculum
CSS Diner - A fun and effective way of learning CSS selectors
Flexbox Froggy - A fun and effective way of learning Flexbox
Flexbox Zombies - Another fun way to learn Flexbox
Knights of the Flexbox Table - Another fun way to learn Flexbox
Grid Garden - A fun way to learn CSS Grid
Javascript
What is Javascript?
Javascript is a programming language, originally developer to run code in web browsers to make pages more interactive. Since then its potential usages have expanded significantly, however for the purposes of this tutorial, web page manipulation is the use we are going to focus on.
How do I use Javascript?
There are a lot of ways to use Javascript. If you just want to write your very first code you can do so in a matter of seconds. THe quickest and easiest place to write and run Javascript code is directly in your web browser.
Hit the F12 button to open up the browser's development console (alternatively you can look for a "Dev Tools" option in your browser's settings menu).
It will open be an attached bar, on either the bottom or the right side of the browser window (depending on the browser). You will see a number of tabs across the top, these values will vary between browsers, but all the major ones (Edge / Firefox / Chrome) will have a tab called console as highlighted in the below screenshot.
Within the browser's console you can type and run any code you like. We'll begin by running the simplest possible Javascript code, the traditional "hello world!" program. Type the following into your browser's console and hit enter:
console.log("hello world!");
Your output should match what you see in the screenshot above. Below the code the text "hello world!" is printed out. Your code asked for the browser's console to use its log method and print out the "hello world!" string (a string is a sequence of text characters).
Strings are a primitive value in Javascript. A type of data that is built-in and supported by the language. Another example is the number data type. You can read more about primitive data types here if you like.
Now as you can probably imagine, very few people write their Javascript directly in the browser console. For many reasons, but the simplest of which is that the code is gone as soon as you close your browser. We'd like to be able to write some Javascript that sticks around! To do that we need the HTML <script> tag.
Before we return to our code from the previous section, let's use the simplest example we can. Create an index.html file that looks like the following:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My First Javascript Project</title>
<script>
console.log("hello world!");
</script>
</head>
<body>
<p>My Javascript Test Page</p>
</body>
</html>
Notice that we have included some Javascript code in the <script> tag? Try opening up your page on your local web server and checking your result. You should see the "My Javascript Test Page" text from the body as expected, but if you open your browser console again you will see your message.
Just as before, using the console.log function we have instructed out browser to print the "hello world!" string in the console.
Great, but there's still one final step. Similar to CSS, although originally the standard was to write Javascript code directly in your HTML, at some point everyone realized that it made more sense to separate it into its own file. Let's look at how to load a Javascript file into our site.
Begin by creating a script.js file (again the filename doesn't matter, you can call it anything you like as long as it ends with a .js extension):
script.js
console.log("hello world!");
And then update your HTML file:
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My First Javascript Project</title>
<script src="script.js"></script>
</head>
<body>
<p>My Javascript Test Page</p>
</body>
</html>
Notice how our <script> tag changed:
<script src="script.js"></script>
The src attribute is the filename and path of the file that you want to load.
Save both files and refresh your index.html page. You'll see once again that "hello world!" appears in the console, but this time the code is being loaded in from the .js file.
At this point you now have the knowledge of how to set up a working Javascript environment and run any code you like. Of course this is only the tip of the iceberg, the ocean of JS is very deep, but the wonderful thing is that you can even as a beginner you can accomplish a lot with just a little.
Teaching the Javascript language itself is beyond the scope of this tutorial (I would highly recommend MDN's tutorial as usual for that) but we will take the time to explore just a little bit deeper into some of the most common use cases.
One of the main usages of Javascript is for manipulating the DOM. The DOM is a term you will come across frequently in web development and it can be a little confusing at first, but we'll make sure to describe exactly what it is in the next section, and how you can use that knowledge to make your web pages more interactive.
The DOM
What is the DOM?
The DOM stands for Document Object Model and most simply put it just means the actual structure of the page built by your browser when following the instructions described by your HTML.
Think of your HTML file as the blueprints of a house, and the DOM as the house itself.
You can use a single set of blueprints (HTML) to build as many houses (pages in the browser) as you want. Maybe in one of those houses you might choose to change the colour of the exterior paint from white to blue. This change of paint colour would be analogous to what Javascript does.
When you change the paint colour of your house you change it on the house itself, you don't necessarily update the blueprints to say "all houses must be blue." Similarly, when you use Javascript to change the background colour of your page, you are changing it on the DOM and it's updating the background colour of the page in your browser. It's not changing the HTML file itself.
The DOM is represented in the browser as a tree structure. Don't worry if that looks confusing, you've already used the structure before when writing your HTML. Your elements have a hierarchy and elements can be nested inside of other elements. This represents the tree structure. All elements (except for the <html> element) have a parent element.
How do I view the DOM?
Browsers make it very easy to take a look at the DOM directly. Open up your web page again and right click on the "My Javascript Test Page" text. You will se an option to Inspect. This option is available on all browsers.
Inspecting the element will open up the dev tools console, but this time it will default to the DOM tab (it may be called "Elements" or "Inspector" depending on your browser.) Here you can see the DOM structure that has been built by your browser based on the instructions provided by the HTML.
With a simple page it is likely that the DOM structure will look identical to your HTML file. This isn't absolutely necessary though. We could have some Javascript that changed the DOM structure after it has built so that it no longer looks the same. Let's try that now.
Click on the Console tab of your browser's dev tools like we did before so that we can write some Javascript. This time, instead of using the console.log function we are going to call a different function.
All browsers provide Javascript with an interface for interacting with the DOM through code. You can change, add, remove, clone, and generally just do almost anything you can think of with the elements on the page.
First type the following code into the browser console and press enter:
document.querySelector("p");
When you hit enter you will see the result of your code directly below, it looks like a little <p> element.
Let's break this line down and see exactly what it's doing:
document - This is a Javascript variable provided by the browser. It represents a reference to the page you are currently looking at (for example in your current tab). You can use it to find out all kinds of information, for example the width of the user's page, the current URL, and many more. In this example we are using it so we know which specific page to search for the element we want to change.
querySelector - Is a function that exists on the document. It's an incredibly powerful function that allows you to use CSS Selectors that we have already learned about to target particular elements on our page with Javascript. It's great because it lets you leverage skills you already learned in CSS and apply them to Javascript.
"p" - in this context "p" is a Javascript string that represents our CSS selector. As you may remember, just
pon its own is atag selector. Our goal is to select the<p>element on our page. Although this is a very simple one, you can use any kind of CSS Selector you like. For exampledocument.querySelector("#example")is a valid function that would get a reference to any element withid="example"that exists in the DOM.
So when you combine the three of these together you get a Javascript function that searches the DOM for a <p> element and returns it to you (if there is more than one <p> element on the page it will return the first one it finds, starting from the top and moving down the tree).
Once you have that reference you have the ability to modify it. As we mentioned before we just want to change the content that is inside of the tag, the text that says "My Javascript Test Page".
When you ran the querySelector function in your console you got that little <p> element returned on the next line. If you haven't done so already click on it. You might be overwhelmed at first by try not to be. There are far more options and bits of information on a DOM node than the average developer will ever need. Just let them wash over you like background noise.
Look for one called innerText that should have a string version of the text that we put inside of our <p> element. This is the one we are going to update to change our page.
(In case you are wondering why we chose innerText instead of innerHTML, which looks exactly the same at a glance, the answer is that if you are just working with text (like we are) rather than adding new HTML, then innerText is safer (though both would technically work). More information here if you are curious)
So now that we know the element that we want to change, how do we change it? When we run our querySelector we get that <p> element back, but we don't know how to change it yet.
There are a number of options available, but this would be a good opportunity to introduce the concept of variables. You can use variables to store information in your program that you will need at a later time.
Let's demonstrate how to save a reference to our <p> DOM node in a variable:
var myParagraph = document.querySelector("p");
This is the same code as before, except this time we have declared a variable that we've named myParagraph and set it equal to the paragraph node in the DOM. This gives us an easy way to reference and make changes to that node.
To bring it all together, the code to update our paragraph node on our page looks like this.
var myParagraph = document.querySelector("p");
myParagraph.innerText = "My Updated Javascript Test Page";
(If you're wondering about the name of the myParagraph variable, Javascript uses a naming convention called camelCase. This is not mandatory, but is considered a best practice.)
You can run it in the console yourself to see:
Now that we've seen how we can interact with the DOM, let's move this code over to our script.js file so that it runs every time we load the page. With this in place you will essentially never see the "My Javascript Test Page" text, since the script will run immediately on page load and replace it with the "My Updated Javascript Test Page" text.
There are two necessary steps. First, update your script.js file:
script.js
var myParagraph = document.querySelector("p");
myParagraph.innerText = "My Updated Javascript Test Page";
And a reminder that your index.html should look like:
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My First Javascript Project</title>
<script src="script.js"></script>
</head>
<body>
<p>My Javascript Test Page</p>
</body>
</html>
If you load the page now, even though this is the same code we used in the console, you'll notice that it doesn't work! Why not?
The reason it doesn't work in this case is because of the oder we are running it in. In the console we were running our document.querySelector function in the console after the page had finished loading.
If you look at our index.html file above, imagine you are the browser parsing the file from the beginning and working your way down. You will get to the <script> element and run that .js file before you've even reached and created the <p> element. So the querySelector runs, finds nothing, and then its done its job. Nothing is telling it to run again after the page has loaded.
There is a very easy fix for this, all we need to do is instruct out <script> element to hold off and wait to run that code until the page has finished loading. We use the defer attribute for this. Update your <script> element to:
<script defer src="script.js"></script>
And try refreshing the page again., you should see "My Updated Javascript Page" as expected as soon as the page is loaded.
At this point you now have a very basic familiarity with Javascript, including how to run your code and some of the ways it can be used to manipulate DOM nodes on your page (remember that _DOM nodes is just the term used to describe HTML elements that have been built into a page in the browser)_
The last section in our Javascript introduction will go through an example of using Javascript to solve a real-world problem you might encounter.
We'll continue where we left off at the end of the CSS section with our "Animal Blog" and the cool little card that we created.
How do I add Javascript to a website?
Let's say we've been tasked with adding some new functionality to our animal blog. We want people to be able to "like" the images of cats that we are adding to our blog. A user need to be able to interact and make a change to our element, so we recognize immediately that it's a perfect use case for Javascript.
First we will pull up our previous example. In case you don't have it handy, we need three files:
- index.html
- style.css
- script.js
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My Animal Blog</title>
<link rel="stylesheet" href="style.css" />
<script defer src="script.js"></script>
</head>
<body>
<header>
<h1>My Favourite Animals</h1>
<h2>Enjoy these furry friends</h2>
</header>
<main>
<article class="card">
<img
src="https://res.cloudinary.com/dqse2txyi/image/upload/v1657421273/blogs/intro-to-web-development/cat_k4fcww.png"
alt="Cat Playing Chess"
/>
<div class="card__container">
<h3>Chess Cat</h3>
<p>He's planning his next move.</p>
<button onCLick="likeButton()">Like</button>
</div>
</article>
</main>
<footer>
<p>© 2022</p>
</footer>
</body>
</html>
style.css
body {
color: #333333;
font-family: Helvetica, sans-serif;
margin: auto;
max-width: 800px;
}
main {
margin-bottom: 40px;
}
header,
footer {
text-align: center;
}
h1 {
font-family: Arial, sans-serif;
}
h2 {
font-style: italic;
font-weight: lighter;
}
.card {
width: 350px;
margin: auto;
box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
border-radius: 10px;
overflow: hidden;
}
.card > img {
width: 100%;
height: auto;
}
.card__container {
padding: 16px;
}
At the moment we don't have any content in our script.js file, leave it empty for now.
There is a single difference between this file and the final versions of the examples at the end of our CSS section, in index.html we have added a Like button inside the card:
<button>Like</button>
When you serve the page in your browser you'll see it rendered:
Of course at this point clicking it does nothing. In order to connect some Javascript to our button, first we have to write a Javascript function, give it a name, and finally attach it to our button.
A function is essentially a block of JS code that you don't want to run right away. Another common use for functions is to create blocks of code that you might want to run more than once. Both are great reasons to create a function.
There are a number of ways to create functions as the JS language has evolved over many years. Here for simplicity we will teach the traditional method that works in all browsers. Later as you get more comfortable you can learn about the various shorthand forms.
script.js
function likeButton() {
alert("Like button has been pressed");
}
When you load your script.js file, the code inside of this function block (the code between the curly braces) is not run right away. You have to first call the function (sometimes called invoke) which basically means "run the code inside the function when i tell you to". The syntax in Javascript to call a function is the function name followed by open and closed parentheses.
So calling our likeButton function would look like:
likeButton();
The alert function is another built-in browser function like console.log, but this time instead of printing a string to the console, it pops it up in your face with one of those annoying pop up messages. Great for testing, but never ever use them for a real site.
So now that we have this function declared, we can update the <button> element in index.html to call the function whenever the button is click. We learned the syntax for calling the function, so the final thing we need to learn is how to connect them. We do that with the HTML onclick attribute.
The onclick attribute is available and most any elements in HTML, but for accessibility reasons you want to aim to use it primarily on elements that are designed to be click (like buttons or links).
We can tell our <button> in our index.html file to run the function when it is clicked by updating it like so:
<button onclick="likeButton()">Like</button>
As you can see, inside of the onclick attribute we can technically write any Javascript code that we want. Even as much as you want (separated by semicolons) although that gets very messy very fast, and is considered bad practice. If you want a button to perform multiple tasks, put them all into a function and simply call that function.
When we load our page and click the like button we are greeted with:
Excellent! Our page is interactive now. If your button does not work try some common troubleshooting tips:
- Verify your
script.jsis being loaded inindex.htmllike<script defer src="script.js"></script> - Verify that you've saved all your files after editing them
- Check your spelling and case. Javascript is case sensitive so
onclickandlikeButtonare very particular. - Make sure you are calling the function: it's
onclick="likeButton()"and notonclick="likeButton"
At this point we've verified that we can create a function, and call it by clicking a button. That's fantastic progress. The next step is to update the button to show it has been "liked".
Here is the code for your script.js file. Remove the old function and replace it with the following.
script.js
var likes = 0;
// Adds 1 to the number of likes, and updates the text of the button
function likeButton() {
likes = likes + 1;
var myButton = document.querySelector("button");
myButton.innerText = "👍 " + likes;
}
Let's break down each piece above to see what it does:
var likes = 0;
We create a new variable named likes that stores a number. This number keeps track of how many likes our animal picture has received so far. By default we will start at zero.
// Adds 1 to the number of likes, and updates the text of the button
This is something we haven't used yet, it's an extremely common part of programming called a comment. They are used to provide information to other team members (or yourself in the future) looking at your code to help explain what the code does.
You do not need to add comments for every line, the vast majority of code (if you use descriptive variable names like likes = 0 rather than x = 0) will be self-descriptive. Comments would only serve to add bloat. Reserve your comments for code that is less easy to understand fro ma quick glance, or to describe the entirely of what a function does as we have above.
Comments are supported in HTML, Javascript and CSS. Each one uses a slightly different syntax:
-
HTML
<!-- This is a comment --> -
CSS
/* This is a comment */ -
Javascript
// This is a one-line comment -
Javascript
/* This is a comment that can span multiple lines */
In the real world most developers, particularly senior level developers, will actually spend more of their time reading code than writing it, so good commenting and clean formatting are essential.
function likeButton() {
This creates a function called likeButton. The code inside the curly braces will not be run when the .js file is loaded, but we can call the likeButton() function at a later time to run the code when we choose.
likes = likes + 1;
This takes out likes variable and increments it by one. THe new value is equal to the current value plus one. The first time the button is pressed it will become one (0 + 1). The second time two (1 + 1) etc.
var myButton = document.querySelector("button");
As we learned in the introduction, document.querySelect uses CSS selector syntax to search for elements on a page. This will save a reference to the first <button> it finds, so it's operating on the very fragile assumption that we only have one.
If you were to add more buttons in the future you would need to return and refactor (update) this code. One option would be to add a class, say <button class="like-button">Like</button>. You could then target that specific button with the CSS class selector like so: document.querySelector(".like-button"). Notice the . prefix indicating it's a class selector.
For the moment however, the Like button is our only button, and this code gets the job done just fine.
myButton.innerText = "👍 " + likes;
The final piece here is what updates the text inside the button itself. We update and replace the innerText of the button with a thumbs up emoji, then we use the + operator to concatenate the value of the likes variable onto the end of the string.
This can be a bit tricky for newcomers as the + operator is being used for something other than math. It depends on the context. If you have two numbers on either side like 1 + 1 then Javascript will evaluate that as a math operation and return a value of 2.
If either one of those values is a string (or both) then Javascript will instead treat them both like strings and concatenate them together. So "hello" + 1 would evaluate to "hello1". It's one of those fun quirks of the language that becomes second nature after awhile, but it certainly does cause some confusion when first learning. The best way to become comfortable with it is simply repetition and practice.
So for our example, if the button has been clicked once, then "👍 " + likes will be the same as "👍 " + 1 which will be evaluated as "👍 1" and that's the string that will be placed as the innerText of our button.
Of course we won't know until we try it out. Load the page with the updated Javascript, and start mashin' that like button!
script.js
var likes = 0;
// Adds 1 to the number of likes, and updates the text of the button
function likeButton() {
likes = likes + 1;
var myButton = document.querySelector("button");
myButton.innerText = "👍 " + likes;
}
How many likes can you get to before your hand gets tired? Congratulations, you've created the world's most uninteresting game.
At this point we will bring our discussion on Javascript to a close. We've only just scratched the surface of what's possible, but I hope you've got enough of an introduction and confidence to begin branching out and trying new things.
Remember don't be afraid to mess around. Copy and paste from the internet. Come up with crazy ideas and try to build them. Keep it small to start so you don't get overwhelmed, but don't be afraid to fail.
Javascript isn't something you just "learn" and then you're done. It's an ongoing process that will probably continue for your entire career. I've been writing Javascript for six years now, and I learned something new while writing this complete beginner's tutorial.
The best thing you can do in your development journey is keep your mind constantly open to learning new things and improving.
What are the best free resources for learning Javascript?
Kyle Simpson's digital book series You Don't Know JS is the gold standard for deep diving into learning all the ins and outs of the language. Highly recommend, and totally free to red online
Written by Douglas Crockford, creator of the JSON data format, this book distills all the important stuff about the Javascript language you need to know. This is the first book I ever read about JS, and I give it a lot of credit for helping teach me the fundamentals (ok I guess this one isn't free, but it's good):
For a quick reference for all things JS, there is no better resource than:
Node.js
What is Node.js
Node.js is a program that can run Javascript code outside of a browser.
It is one of the main reasons why Javascript has become one of the most popular programming languages in the world.
With Node, you are no longer restricted to requiring a web browser open to run your Javascript code. You can write Javascript for things like renaming photos on your computer, or sending automated emails, or even full blown desktop applications with tools like Electon.
To try Node yourself, simply follow the instructions on the site and download and install it. Once installed you should be able to open a command line terminal and type:
node --version
And get an output like v16.13.2 depending on what the latest version is when you installed it.
To you is you simply type node followed by a Javascript file. Here's a simple example, I'll create a file called script.js in the directory we are currently in:
script.js
console.log("Hello world!");
Now save it and run this command:
node script.js
You will see "Hello world!" appear on your terminal.
It's as simple as that. The applications just get bigger and more complex from there.
(Note that because your code isn't running in the browser, you will not have access to some of the common browser-specific APIs you might be familiar with. For example document.querySelector which returns a DOM node -- something that doesn't make much sense without the context of a browser)
One of the most common uses of Node.js is to build web servers. It's very popular because it allows you to write both your website (front-end) and web server (back-end) which provides the necessary data for the front-end both in Javascript.
Although you can write your whole web server entirely with code specific to Node itself, to simplify the process most people use a library like Express.
What are the best free resources for learning Node.js?
There are tons of great resources on learning Node.js out there, and they're free!
MDN will introduce you to Node and cover building a simple web server with a tool called Express
The Odin Project full free curriculum for teaching Node.js and Express
Node.js Crash Course great YouTube video series on Node.js from The Net Ninja
Command Line Terminal
If you are going to be working in any kind of web development job, you're going to need to become familiar with the command line terminal. Many of the programs you will use don't have a graphical interface and are designed to be run on the terminal.
Fortunately you don't need to be an expert, and this tutorial will go through the basic commands you need to know.
How do I use the command line terminal?
How you access the terminal will depend on your system. If you are on Mac or Linux it'll be called "Terminal", on Windows you might choose to use PowerShell which is very similar. PowerShell comes bundled with Windows automatically, you can find it in your start menu.
Or you can download something like Git bash which comes included when you install Git and will give you a unix-style terminal even if you are using Windows.
I'll be using bash for this tutorial. Even if you are using PowerShell on Windows most of the commands will be the same or similar.
When you open your terminal it will look something like this:
Most terminals will show the directory directory you are in on the left. Right now I am in the ~ directory which is an alias for my "home" directory. On Windows it would be something like c:\Users\YOUR_NAME on Linux it might be something like /home/YOUR_NAME.
Let's create a new folder called example-folder.
mkdir example-folder
That will create example-folder in your home directory. Now let's "change directory" into that folder with:
cd example-folder
Protip: use the tab key to help autocomplete when working on the terminal. It's one of the most powerful shorthands you'll be able to use for efficiency (and avoiding spelling errors).
Our terminal directory is now in the folder we just created. Let's create a file!
touch hello.txt
(This one will be different on PowerShell, you'll need to type New-Item hello.txt).
If you navigate to that folder in your graphical interface you'll be able to see it has been created!
Now let's go back to the terminal and take a look at the contents of this folder.
ls
That command means "list" and lists the contents of the directory. You should see your hello.txt file show up.
That's enough of that file, we can delete it with:
rm hello.txt
Run ls again and should be gone.
Let's return to the parent directory.
cd ..
The two dots ".." is a shorthand for "parent directory" and a single dot "." is a shorthand for "this directory".
Finally let's remove that folder we created.
rmdir example-folder
And that's the absolute basics of navigating around on the command line. You're now at least equipped with the ability to navigate between folders which is one of the most common operations you will use.
What else do I need to know about the command line terminal?
Make sure you understand the difference between absolute and relative paths. This is not just for the command line, you'll need to understand the different when writing your code as well. You often need to import "modules" from other files and you need to describe to the editor where to find those files.
Get familiar with one of the command line text editing tools so that you can quickly make changes to text and code files without having to boot up VS Code. I prefer Nano for quick edits but there are lots of options including emacs, vi, and more.
(If your terminal opens files in vi and you can't figure out how to get out, type escape then :q. Quitting vi is one of those rights of initiation for anyone working in a terminal).
You'll want to know how to open up the help pages for any program you are using. Say you just installed git but have no idea how to use it. Depending on your platform it will either be:
man git
OR
git --help
You can replace git with the name of whatever program you are trying to learn about. Usually one of the other will get you what you want. The man command stands for "manual" and is intended to open up the manual.
What are the best free resources for learning the command line terminal?
The Odin Project command line basics
The Art of the Command Line beginner's tutorial
Git
What is Git?
What is a Version Control System (VCS)?
Having a good understanding of Git is critically important for working in almost any software job. I'd go so far as to say that if you company doesn't use it (or at least an equivalent version control tool) you may want to consider another position.
It's that important to a healthy software lifecycle. So for that reason I want to make sure I explain it well, because despite its important, it can be very daunting to learn and understand for a beginner who isn't used to thinking this way.
Git is a version control system which is a fancy way of saying that it's a tool for taking snapshots of data at a certain point in time.
If you've ever worked on a file and made a copy of it called Resume.doc and Resume-backup.doc and Resume-FINAL.doc etc then you can imagine why a tool like Git might need to exist.
It works for any kind of file and is not specific to coding or software development, although that's where it's most commonly used.
Software developers and teams use it for two primary purposes:
To create a saved state at a certain point in time in case an issue comes up later and changes need to be reverted back to how they used to be, for one file or many files.
To allow multiple developers to work on files in a project at the same time, in the same directory and often even the same file. Git keeps track of who is making changes where, and helps you resolve and merge those changes together, ideally automatically without any input from the people making the changes at all.
For example, if you have a big Javascript file called my-code.js with 1000 lines, developer A could make edits to line 200, and developer B could make edits to line 300. Afterward they would perform a Git command called merge and Git would take care of combining the separate changes both devs made on their lines on their individual files into a single file with both changes.
There are a number of ways to use Git, the most common is through the command line terminal but there are many tools out there designed to make it easier to use. See this section for more info.
Let's take a quick look at how you can use Git
How do I use Git?
First you need to install it on your machine. Check out this link for instructions on how to install depending on what operating system you are on.
You will know you are successful when you are able to open a command line terminal and type:
git --version
You should see a response like git version 2.35.1 or whatever version is currently the newest when you install yours. If it says anything like command "git" not found then you need to double check your installation. Sometimes you need to close and re-open your terminal for newly installed programs to be visible.
Now I am going to create a new folder. You can create it anywhere that you like as long as you know how to navigate to it in your terminal. You can make it with the mkdir git-example command or you can just "Create New Folder" with your mouse and call it git-example.
After the folder is created open up your editor (I'll be using VS Code) and go File -> Open Folder and find that folder you just created.
You can see I have my VS Code terminal open there, it will automatically navigate you to the folder you have open. To open your terminal you can use ctrl + ~ or simply use the menu with View -> Terminal.
Just before we get started you'll want to run the following command:
git config --global init.defaultBranch main
If you are on a newer version of git the default branch will already be named main, but if you are on an older version it will be called master. This command just makes sure that your defaults match what we will be using for this tutorial.
The first command you will always need to use if you are creating a new "repository" (the name for a collection of folders and files tracked by the git program). The command is:
git init
You will receive a message that says Initialized empty Git repository in... with your folder path. That means git-example directory is now a git repository. Any files or folders created within that directory can be tracked as part of your "project".
Note that if you join an existing project/team, you will not need to initialize Git. When you clone a copy of their work it will already have been initialized for you, we only need to git init when we are creating a new project ourselves from scratch.
Now let's create a new file called sample.txt. To create a new file in VS Code simply right click on the left side under git-example and New File. Inside it I'm going to add some text, quite literally the phrase "Some example text".
Now I will introduce you to a couple of the first git commands you should learn, git add and git commit.
git add: Will tell git to add new files to "track" in your project. Presuming that you want to keep track of every file in the directory (this is very common) then you can simply use the.character which in most terminals is a shorthand for "this directory". Sogit add .means "add all files in this directory to my git project.git commit: Will tell git that you want to save a snapshot of all tracked files at this current moment. Most commonly you will also include the-mflag which means "message". A commit message is a description of the changes you have made since the last time you committed.
(Worth noting that you can create a file called .gitignore in the root directory of your project and put the names of any files and directories you don't want to include in your repository, so even if you run the add . command those files will not get added. Useful if you have things like environment files that contain secrets and passwords you don't want to upload publicly with the rest of your code)
With that new knowledge in mind our commands will be as follows:
git add .
git commit -m 'initial commit'
You might be able to come up with a better message than that, though it's a common one for the first commit on a project. The common standard for commit message is to write your message as if it follows the start of the sentence "When applied, this commit will...".
So an example would be "change the primary button colour to blue". So that is the format you should use rather than something like "I changed the primary button to blue". Consistent subject and tense makes commit messages in large projects much easier to read and understand.
(If you want to get really deep down the rabbit hole, you can encourage your team to adopt something like conventional commits which applies strict rules about how commit messages are written.)
So now that you have created your first commit, let's learn how to create another one, and navigate back and forth through time and change the state of our project.
Add another line to your sample.txt file. Something like "Some more text" on the next line below the first line. Doesn't matter what the text says, we just want to update the file.
Now run these commands again:
git add .
git commit -m 'add a new line of text'
Technically the git add in this scenario does nothing since we didn't create any new files, but it's not a bad habit to get into as normally creating new files in projects is common, and you want to make sure you add them unless they are being explicitly excluded.
Now that you have two commits, and two "saved" states of your project, you can go back to one if you need to. Let's say that you just want to "see" how things were before, but not actually lose your newest changes.
Start with this command:
git log
If will show you a list of all your commits, with their messages, and a unique string character hash (purple arrow points to in image below) that you can use as an identifier. Note that yours will not be the same as mine, they are randomly generated.
To go back to that state simply type:
git checkout YOUR_COMMIT_HASH_HERE
So in my case it would be git checkout c849819c6f45ef72429abc36b1ee3891c3ede779 but that value will be different for you.
This brings us back to the first commit we did, notice that the content of your sample.txt doesn't have the second line you added. It's not gone, we are simply looking at a different state of the project in the timeline.
At any point you wish to return to the most up to date state just use:
git checkout main
In this context main is the name of the branch you are on. If you have been following this tutorial you will have set your default branch to main at the start. You can always double check what branch you are currently on by typing git status.
Branching is a critically important part of git. The idea of branching is that you create a separate place to track changes, outside of the main branch that acts as the central source of truth for your project. For example, whenever you release a new version of your website or app, that release is almost always done off main.
If you are working on a new feature on a separate branch, those changes won't be released when the main branch is released. Only when you merge the changes from your branch into main will those changes actually be included in the main product.
I'm not going to get into branching for this tutorial, but make sure that you are at least familiar with it before you apply for your first role. You can learn more about git branching here.
So at this stage, if you have learned the basics of add, commit, log and checkout (to switch between branches).
That covers most of the fundamentals you need to know to work with git locally as a solo developer.
But as you've probably heard, git is also used to track changes in a project between developers working on different machines. How does it do that? Well that's where additional tools like Github come into play.
What is the difference between Git and Github?
A common source of confusion for new developers is the difference between git and Github.
Git is a free open source program that runs on your computer and helps keep track of file changes within a project.
Github is a website owned and operated my Microsoft that hosts git repositories online so that you can have access to your files wherever you go and share them with other developers. Think of it like Dropbox with a bunch of extra features specifically designed around working with git repositories.
Github will always have a "copy" of your Git repository and whenever you like you can use git commands like push and pull to synchronize changes you've done on your computer with the ones hosted on Github.
If you are working by yourself it can simply act as a backup system, and help you track issues and to-do's within your project.
If you are working with other developers then it will act as the central location where all changes made by all team members are pushed to and synchronized.
Let's show an example of working with a repository on Github. I'm going to create one locally and show you how to move it up to Github from the command line so that other developers can download or even contribute code to it.
First I am going to make a new project from the command line:
mkdir example-git-project
cd example-git-project
git init
Then I am going to copy the files I created for the tutorials we did on HTML, CSS and Javascript.
If you did not complete those tutorials, don't worry, you don't actually have to understand HTMl, CSS or Javascript for this. We're not even going to run that code, we are simply trying to save a copy of it remotely where other devs can view it.
You can copy the three files directly from the Simple Website Template section.
(Don't worry about what they do, that's not the focus of this tutorial, we are simply trying to show how to push those files to your remote repository.)
After adding those files, run these commands to add them and make your first commit for this project:
git add .
git commit -m 'first commit'
When complete your example-git-project directory should look like this:
Now we are ready to move this project up to Github.
If you don't already have a Github account, create one now.
Once you have an account and are logged in, navigate to "Your repositories" and then look for the green "New" button to create a new repository.
Create a project following this basic template, give it a name and a description. The name does not have to match the same folder name you used when you created your local repository, but it helps if you want to avoid confusion between the two.
Make sure it is set to public if you want other people to be able to view and contribute to the code.
Once it is created you will get a screen that looks like the below. It will include all the commands that you need, the only difference will be that they will use your Github username rather than mine that you see in the screenshot:
All the commands you need are now visible on the screen for you. We would like to push the repository we created on our computer to this remote repository.
The first step is to tell git on our machine that this repository we created is the remote version of our repository. To do that we run the following command:
git remote add origin YOUR_REPOSITORY_URL
This command tells git to create a new remote with the name origin. The URL that you use will depend on how you have Github setup. You can use either an HTTPS or an SSH URL. SSH is normally preferred but you will likely want to go through the What is SSH section first to set it up if you are not familiar.
(The long and short of it is that HTTPS will require you to enter your username and password every time you interact with the Github repository. Setting up SSH means you don't need to do that because the auth key will exist on your machine and be provided automatically.)
Once you have added the remote repository you can confirm it is correct with this command:
git remote get-url origin
You can see the highlighted text in the above example that the origin is correct for the repository I just created.
With that complete you are ready to upload your code. To do that we use the git push command. Push says to "push the current state of my local repository to a remote one."
The first time you do this to a new repository you have to state what remote branch you want to push your current local branch to. In almost all cases this is simply a remote branch with the same name. The command looks like this:
git push -u origin main
Where -u stands for upstream. In this example we are on the main branch, but if you were working for another branch called cool-feature for example, the command would instead be git push -u origin cool-feature.
You only need to do this once, from now on just typing git push will default to pushing to the same upstream branch unless you change it.
Once this push command has been run you should see some upload status messages in your command line, and when you next refresh your Github repository URL it will look like this:
Seeing this indicates you have successfully made your first Github push. Congratulations!
You can now share your Github URL with other people (or even yourself on other machines) and they can instantly get a copy of this project.
Feel free to try it yourself. CLick the green "code" button and then copy the repository URL from there. Create a totally branch new directory anywhere on your machine and run this command:
git clone YOUR_GITHUB_URL
Where YOUR_GITHUB_URL is the URL of your repository. In my case it's git clone git@github.com:alexeagleson/example-git-project.git.
When the command finishes you will have an exact copy of your repo with all the files you added and committed in this new directory elsewhere on your machine. You can make changes and commit them to update the remote repo with the git add, git commit and git push commands same as always.
This applies to other developers on other machines as well!
There's certainly more to learn, but just having these basics down will position you very strongly for using git effectively with any large project at your company.
What else do I need to know about Git?
Important topics you should make sure to learn about include:
Working With Remote Repositories like Github for example
What are the best free resources for learning Git?
The Odin Project curriculum on Git basics
Learn Git Branching is a little interactive game that is great for teaching you more about the concept of branching
Oh my Git! an open-source game designed to help people learn git.
The Github documentation will teach you how to use git and Github at the same time.
APIs
What is an API?
API stands for application programming interface and (in context of web development) it has become basically a catch all term for any system that your code communicates with outside of the code.
The reason that we need an API is because we never want to gives users direct access to your data. Imagine you had a social network that displayed things like name, age, etc about your users.
If you let browsers request that raw data directly, they could also choose to display things like password, or credit card numbers, or any other sensitive data that your app might have stored for one reason or another.
Those are extreme examples but the fact is that even if something isn't critically sensitive, most of the time we want to protect our data and only share it with those people who should have access to it.
For that reason we create APIs. I will allow my web server direct access to all my data, and then the app that is running in the browser may "request" some of that data. My web server will decide if the app / user requesting it should have access to that data, and return it if so, or return an error if not.
A front-end developer needs to know how to read from an existing API. That might mean one developed by back-end developers on their team at their company, or even publicly available ones on the internet.
There are many public APIs out there you can start working with when building an app. Some popular ones include the open weather API, the PokeAPI, and the cocktail API.
These services allow you to query data and display it in your app. Regardless of what type you are working with you usually need to authenticate yourself to use them due to the fact that internet bandwidth is not free, so every time you query for data there is a cost associated with that being paid by whoever is hosting the API. (Most of them do offer free tiers for low traffic apps though.)
If you are a back-end developer you will be responsible for creating the APIs. This means you will write the code for them in a language like Javascript, or other common back-end languages like C#, Java, Go, Python, or Rust.
How do I create an API?
You can create an API very easily with just Javascript and NodeJS. Make sure you have read those sections and are familiar with those tools first.
Open up VS Code and start a new blank project. Create a single file called my-api.js with the following contents:
my-api.js
const http = require("http");
const host = "localhost";
const port = 8000;
const requestHandler = function (req, res) {
res.setHeader("Content-Type", "application/json");
res.writeHead(200);
const weatherData = { toronto: { temp: 30, humidityPercent: 80 } };
const weatherDataString = JSON.stringify(weatherData);
res.end(weatherDataString);
};
const server = http.createServer(requestHandler);
server.listen(port, host, () => {
console.log(`Listening at http://${host}:${port}`);
});
The first line loads the built-in HTTP module in Node.js.
Next we define variables to set the host and port that our server will run on.
The requestHandler is a function which is designed to take two arguments, variables that represent the request and response of an HTTP message. The values in these variables are populated by the Node HTTP module whenever requests are made to your server.
Inside the function we call built in Node HTTP methods like setHeader and writeHead to begin crafting the response and HTTP status codes.
If you do not understand these concepts please take the time to read up on web servers.
Next we save some imaginary API data into the weatherData variable. In a real API this data was likely fetched from a database which itself was populated by data from some kind of hardware device like a digital thermometer. Web servers are not an appropriate place to store data since all data is lost when they are rebooted or shut down, hence why we need databases.
For our simple example though we are just creating some dummy data as an example. This data represents an imaginary weather server response from someone who has made a request to our server for the current weather in Toronto, Ontario, Canada.
The weatherData object is then converted into a string so that it can be sent over the network. weatherDataString is converted into JSON, a textual string representation based on Javascript objects (hence the name).
Since it's just text, it does not technically require Javascript to use, any language can output data in JSON format. You can convert a Javascript object to a JSON string with the JSON.stringify() function.
Finally the end method is what we call when we are done settings the headers and ready to return the data to the device which is making the request to our API.
Let's give it a try!
Save your my-api.js file and open the command line terminal in the same directory as your .js file and run this command:
node my-api.js
You will see the output Listening at http://localhost:8000
Open up your browser and go to [http://localhost:8000] to get a response that looks like:
Depending on your browser it may look slightly different since different ones format JSON responses in different ways, but either way, there you have it!
Remember that the primary purpose of most APIs is to send raw data so websites and web apps can be built using that data. Rather than actually displaying it raw like we do here your app would realistically query that URL using Javascript with something like the fetch method and then display it on the screen wrapped in some pretty HTML and CSS.
What are the best free resources for learning APIs?
If you simply want to learn about the concept of APIs, why they are needed and how they are designed here's a fantastic Stack Overflow response and discussion on the topic that covers all the fundamentals.
For more information of building your own API (at least from a Javascript perspective) check out the resources listed in What are the best free resources for learning Node.js?
Libraries and Package Management
What is a library?
What is a package?
In the context of web development, a library (also sometimes called a package, or even a framework in different contexts) is typically used to refer to "someone else's Javascript code" that you download from the internet and add to your code.
Libraries are a necessary and fundamental part of building websites and web applications. Without them it would require us to re-write the same basic code over and over again each time we start a new project.
To give a very simple example:
<html>
<head>
<script src="https://cdn.jsdelivr.net/npm/lodash@4.17.20/lodash.min.js"></script>
</head>
<body>
<p id="p-tag">hello world</p>
<script>
var pTag = document.getElementById("p-tag");
pTag.innerText = _.startCase(pTag.innerText);
</script>
</body>
</html>
In the above example we are loading the popular lodash Javascript library from a CDN inside the <script> tag.
That loads all the Javascript code from that library. Lodash (hence the name) stores its functions on a variable whose name is just the underscore character.
We then use Javascript to grab the <p> element by its ID and replace its lowercase "hello world" text with the return value of Lodash's startCase function. The startCase function transforms any string so the first letter of each world is capitalized.
There is no built-in Javascript function which does this (only all lowercase or uppercase) so either we write one ourselves, or simply add this library to do it for us.
Of course there are many other considerations you need to be aware of, this whole library for example has a lot more code in it than just the startCase function so it might slow your websites average load time down.
Everything in web development is a trade-off so you and your team always need to consider the pros and cons when making a decision.
What is a package manager?
What are NPM and Yarn?
NPM is something called a "package manager" and it's a tool that is automatically installed on your system when you install Node.js.
Make sure you don't confuse NPM the tool (which you run on your command like like npm install PACKAGE_NAME) and NPM the online repository that stores those packages which you can explore at https://www.npmjs.com/. They both have the same name, but can mean one or the other depending on context you are talking in.
Yarn is an alternative to NPM you can install on your system which works very similarly. For a beginner you will not notice any difference between Yarn and NPM, so I would only recommend you try it if you are curious, or if your project/company is using it.
You can create a branch new NPM project in an folder with this command:
npm init
After the project has been initialized you will see a package.json file which describes all the libraries and packages your project has access to. You can add a new one anytime from the command line like so:
npm install PACKAGE_NAME
Where PACKAGE_NAME is the name of the package listed on https://www.npmjs.com/.
You would learn what functions are available to use from the library in the example above) typically by reading the library's documentation.
That documentation may exist right on the NPM page, or it might be on the Github source code for the project, or most commonly at the project's official website.
Here's an example of the API documentation for the jQuery library.
Let's take a look at a practical example using the lodash package.
Create a new folder in the terminal, navigate to it and run the following commands:
npm init
npm install lodash
Remember you can replace lodash with any other library you find on the NPM registry. That is the source for Javascript packages, and after running the npm install command you will be able to use them in your code as follows if you create a fill called script.js:
script.js
const _ = require("lodash");
console.log(_.startCase("hello world"));
The above will print the start-case'd "Hello World" to the console when you run node script.js.
Remember that libraries available on NPM are public and free to use, so don't hesitate to play and experiment!
Databases
What is a database?
In the context of web development, a database is simply the location where your website or web app will store its data. Basically a fancy hard drive that is accessible over the internet.
The main difference between and standard hard drive and a database is that a database assumes you will be accessing data constantly and will be optimized to provide ways to search for that data extremely quickly.
A database uses a concept called indexes which are exactly like you would expect if you're familiar with the index of a large book, a list of terms or keys that it creates to identify the exact location of information based on certain criteria (an index on text data might be alphabetical for example).
Databases used on the web are usually classified into one of two categories: relational and non-relational (also often called SQL and NoSQL).
(SQL stands for "structured query language" and is usually pronounced as "sequel", but some people prefer S-Q-L.)
Some examples of popular relational databases are MySQL, PostgreSQL, and Microsoft SQL Server. An example of a popular NoSQL database is MongoDB.
If you are just learning then deciding which one to use and learn makes little difference, either option will introduce you at least to the fundamentals of working with databases including indexes, schemas, creates, reads, updates, and deletes.
Typically the responsibility for working with databases will fall on the back-end developer. The front-end developer will have little to no direct exposure to the database.
The backend developer will be responsible for creating an API (see also What is an API?), which is basically code that reads information from the database and transforms it into a shape that the front-end client can use.
If your back-end is written in Javascript, then the developer would write Javascript code that uses an NPM package that gives them access to the database and write SQL queries that are sent to Javascript functions and then onward to the database.
Let's say that you want to build a page that shows current in-stock levels for a website that sells plants.
In your database you have a table which contains both the name of each plant your store carries and the number that are in stock.
(If you've used Microsoft Excel or Google Sheets before then you can think of a database as very similar, just significantly more powerful and able to store and process orders of magnitude more data.)
(Typically in a real relational database the items and stock levels would be in separate tables and marked with an ID number, a process called normalization, but we are keeping it simple for now)
A SQL query to get plant name and inventory information for plants that are currently in-stock might look something like:
SELECT (name, num_in_stock) FROM plants WHERE num_in_stock > 0;
Where plants is the name of the table and name and num_in_stock are the names of the columns that contain the data inventory data.
Once this data is returned the back-end developer writes more code to provide an API endpoint that the website can send requests to in order to get that plant inventory data and display it on the page.
An endpoint is simply an URL identifier designed to provide specific data, for example https://www.myplantstore.com/inventory.
It's important to understand that the website itself cannot query the database directly, because to do so would require you to include the login and password of your database on the website, which would then be accessible to everyone. It wouldn't long for someone (or some bot) to gain access and control of your database.
So one of the reasons we create and use an API is to provide a very specific interface via URL that only allows data to be requested from certain trusted sources, and is only programmed to return specific types of data.
Maybe we also store customer names and addresses in the database, but as long as we don't write code on our back-end to query that data and provide an interface for it to be accessed, then it will be safe as long as nobody (except those with permission) have direct access to the database.
Ultimately all you need to remember as a front-end developer is that a database is a place to permanently store data for your web app, and the back-end developer is responsible for providing you (the front-end dev) access to specific parts of it that you need in order to build your app.
How do I use a database?
This question can be interpreted in a few different ways. Someone working as a DBA (database administrator) would interpret this question as How do I install and setup a database? likely including follow up questions like what kind of data will I need to store?, should it be SQL or NoSQL?, how much data and traffic am I expecting? etc etc etc.
As a back-end developer you might may or may not need to include yourself in these discussions. Usually it depends on the size of the company. In small companies back-end developers often find themselves playing the role of the DBA as well as developing the API. At large companies that is less likely to be the case.
The way we are going to answer this question is specifically on the software development side since that is the focus of this tutorial. In most cases a database will already be set up for you, and your job will be to develop an API that can query it, maybe process the data a bit, and then return it to the user (usually front-end dev) in a shape that aligns with their needs to display it on a page to the user.
For our example we will be using a fantastic and user friendly SQL database which is totally free called SQLite. All the basic queries you would use for managing data in SQLite like SELECT, INSERT, CREATE TABLE etc are the same as you would use when working in all the industry standard SQL databases like MySQL, PostgreSQL etc.
SQLite has bindings for Node.js, which is a fancy way of saying your can just install it as an NPM package and get up and running in seconds.
We can create our SQLite database in one of two ways: either create it right in the code when the program loads (called doing it "in memory") or load up the database from a file on your computer.
Loading from a file mimics a real world use case a little closer, but requires some more configuration so we'll be doing it in memory in this example. If you want to learn how to load the database from a file here's a tutorial you can check out.
As we have learned already in the what is an API? section, an API typically involves a web server that acts as a middleman between a website/app and a database. So we are going to extend the example we showed in the API section to now include querying from a database.
We'll begin by navigating on our command line to the folder containing the my-api.js file from the How do I create an API? example and run the following command:
npm init
Go through the question prompts with all the defaults then run:
npm install sqlite3
(If you aren't sure what we are doing here you may need to revisit the What is a package manager? section)
Next, update the my-api.js as follows:
my-api.js
// Database setup
// 1
const sqlite3 = require("sqlite3").verbose();
const db = new sqlite3.Database(":memory:");
// 2
db.serialize(() => {
// 3
db.run("CREATE TABLE weather (city TEXT, temp INTEGER)");
// 4
const stmt = db.prepare("INSERT INTO weather VALUES (?, ?)");
stmt.run("toronto", 30);
stmt.run("vancouver", 50);
stmt.finalize();
});
// Web server config
const http = require("http");
const host = "localhost";
const port = 8000;
const requestHandler = function (req, res) {
res.setHeader("Content-Type", "application/json");
res.writeHead(200);
// 5
let requestedCity = "";
switch (req.url) {
case "/toronto":
requestedCity = "toronto";
break;
case "/vancouver":
requestedCity = "vancouver";
break;
}
// 6
db.get(
"SELECT * from weather WHERE city = ?",
// 7
[requestedCity],
(err, row) => {
// 8
const weatherDataString = JSON.stringify(row);
res.end(weatherDataString);
}
);
};
// Web server start
const server = http.createServer(requestHandler);
server.listen(port, host, () => {
console.log(`Listening at http://${host}:${port}`);
});
This is getting a bit more complex, so I'll added a few numbered comments I'll refer to below explaining what is going on here. I do not include any explanations for the web server code since it was covered in the APIs section already.
- Load the
sqlite3package that we installed from NPM. What this literally means "look at thepackage.jsonfile in thenode_moudles/sqlite3directory and see if there is a field called "main" which tells me the location of a Javascript file to start loading and running code from. The next line creates a new SQLite database based on the classes defined in that JS file, and:memory:tells it we will be creating the DB from memory and not from a file. -
serializeis an SQLite function that means "run all the commands inside this function one at a time making sure each one finishes before the next one starts". - Standard SQL syntax for creating a table.
- Prepare an
INSERTstatement to add data into our database. We prepare the statement first since the statement itself doesn't change, only the values we are inserting (represented by the?character). Once this is finalized and run we will have two rows in our database, one for eachrunfunction called, with temps for Toronto and Vancouver. - We jump ahead to the point after our web server has been initialized. We introduce one new concept to our server itself and that's routing. I wanted the user to be able to define which city they want the weather for, rather than getting every single city every time, which is a waste of resources.
req.urlwill have the route portion of the request, so if the URL ishttp://localhost:8000/torontothenreq.urlwill be/toronto. We then save that city data into a variable calledrequestedCity. - Next we invoke the
getfunction on our SQLite database and run a basicSELECTSQL query for the data. The?in the statement is replaced with the value in our variable which presumably will be eithertorontoorvancouver(or fail if the user requests anything else). It's important that we use the?syntax to insert the variables that came from the user. Remember that all user provided data must be considered potentially malicious, so using prepared statements and the?substitution instead of directly concatenating the value onto the strings to help project against SQL injection attacks. - This array is where the variable values are taken from to replace the
?characters in the strings. There should be exactly as many values in this array as there are?characters in your statement. - The query result is returned inside of this variable we've called
rowbecause it represents a row in your databaseweathertable. If you're not familiar with this syntax here (the function as an argument that takesrowanderras arguments) it's called a callback function and it's one of the more challenging topics to learn as a new Javascript dev, so don't worry if you don't get it right away. Thisrowis returned as an object so we canJSON.stringify()it and return it as the payload for our HTTP request.
Let's give it a try! Boot up your web server with:
node my-api.js
Visit http://localhost:8000/toronto in your browser to GET the weather from Toronto that is saved in your database! Try changing the route to /vancouver and see what happens as well!
This example here provides you with a really solid introductory example of what a "day in the life" is like of a backend developer. You'll likely be writing SQL statements, creating and updating tables in databases, writing code to query tables in the database and returning that data to users by creating "endpoints" using routes that follow a specific set of rules you control for how data is accessed and who is allowed to access it through authentication and authorization.
What are the best free resources for learning databases?
SQLite Tutorial for Node.js to keep going further with the Node.js based exmaple of working with SQL beyond what we've done so far.
MongoDB Univeristy for those devs going the NoSQL route, MongoDB is one of the most popular databases in that space (particularly in the Node and Javascript world) and one you are likely to encounter at some point in your career.
Khan Academy's Introduction to SQL includes videos and tutorials on everything SQL
CS 186 Berkeley an amazing free course that covers pretty much everything you need to know about databases as a back-end developer
The Red Book the classic book on database theory available to read free online. Although it's extremely comprehensive, it's also fairly academic and probably more than the majority of back-end developers will need. Recommended when you have all the basics down and are ready to dive deeper into the fundamentals.
Front End Frameworks
What is a front end framework?
New developers often hear that they "need to learn a framework" in order to get a job, and that of course begs the question: "What is a framework?".
There is no one-size-fits-all answer to that. Many people have different definitions, but the simplest one in the context of Javascript and web development is that it is a library/package that provides structure and opinions on how you should organize your code, and typically also provides tools and helper functions to build the code itself.
What are React, Angular, Vue, Svelte and jQuery?
Popular front end frameworks in the web development world include React, Angular and Vue. These tools are chosen because they provide much better ways of building and managing re-usable code templates for UI elements than the native browser does.
To give an example, you could create a React component called Card which includes <h2>, <p> and <img> tags wrapped in a <div>. It is created as a Javascript function that takes an object as an input argument with text/links to fill in those values. Once built you now have a "component" you can use like an HTML tag in the format <Card> over and over to build, for example, a page with a list of employee profiles.
The language used to build these components is called JSX and is basically a mix of HTML and Javascript. Here's an example of how the Card we just described would look in React:
(In the below example, props is a Javascript object with three properties: url, title, and text, each of which are strings)
Card.jsx
export const Card = (props) => {
return (
<div>
<img src={props.url} />
<h2>{props.title}</h2>
<p>{props.text}</p>
</div>
);
};
Then using your custom component on your website/app looks like:
App.jsx
<div>
<Card
url="www.example.com/steven.png"
title="Steven Lastname"
text="Steven is a wonderful employee!"
/>
<Card
url="www.example.com/nancy.png"
title="Nancy Lastname"
text="Nancy is here to help!"
/>
</div>
Each framework has different levels of how opinionated they get. For example React is a lot more flexible as to how you set up your file structure, but it provides very strict rules about how its components are built.
Angular is also very opinionated about how components are structured, but much more than React enforces a particular directory and file structure within your project as well.
Vue and Svelte are much less opinionated in that regard.
Another one you may have heard of is jQuery. In its heyday, jQuery was te go-to JS tool for providing additional functions that made creating and updating the DOM (the elements on your website) much easier. Much of the reasons developers no longer reach for it is that many of its functions have now been implemented into the Javascript built-in standard itself (for example document.querySelector for DOM manipulation and fetch for AJAX calls), so the language would not be what it is today without jQuery having paved the way.
What is a CSS framework?
What are Bootstrap and TailwindCSS?
A CSS framework is a term typically used to refer to packaged code that focuses on provided pre-written CSS rather than Javascript (though many CSS frameworks including Bootstrap also include Javascript code as well to provide additional functionality).
Two popular CSS frameworks worth knowing about are Bootstrap and TailwindCSS.
Both libraries focus on simplifying and reducing the amount of CSS you need to write, and creating systems to make things like margins, paddings and layout more consistent across your site so you don't need to build and implement your own design system.
Bootstrap popularized the 12 column grid system you'll see in many layout tools these days, for example using a CSS class like col-3 to represent 3/12 (or 25%) of the screen.
Bootstrap is far more opinionated of the two (and therefore a larger footprint in terms of size in your application) but provides some great defaults for developers who are not design savvy and prefer to focus on the function of their application. Bootstrap, similar to jQuery, was far more of a standard in the earlier days of web development as has gradually fallen out of favour, but you'll still find it commonly used in many applications still in operation today.
TailwindCSS on the other hand has seen a massive rise in popularity in recent years mostly due to its small form factor and simple to use classes, as well as being easy to customize. Tailwind is a great choice for devs and designers who want to get a nice looking up up off the ground quickly, while still leaving room to customize it to your desired look and feel.
If you want to really quickly get a feel for what using a CSS framework is like, the simplest way is to simply include the <link> tag example from the Include via CDN section on the front page of https://getbootstrap.com/ in your index.html file and use the Bootstrap documentation to try out some of the different classes.
Here's a super minimal example of a site that loads and uses bootstrap. The class="btn btn-primary" and other classes on buttons is what's hooking those elements into the Bootstrap styles.
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<link
href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.0/dist/css/bootstrap.min.css"
rel="stylesheet"
integrity="sha384-gH2yIJqKdNHPEq0n4Mqa/HGKIhSkIHeL5AyhkYV8i59U5AR6csBvApHHNl/vI1Bx"
crossorigin="anonymous"
/>
</head>
<body>
<button type="button" class="btn btn-primary">Primary</button>
<button type="button" class="btn btn-secondary">Secondary</button>
<button type="button" class="btn btn-success">Success</button>
</body>
</html>
How do I use a front end framework?
How do I use React?
Once you have a strong grasp of the HTML/CSS/Javascript fundamentals, it's a good idea to get familiar with at least one framework (the most popular of which at the time of this writing is React).
Kent C. Dodds has a good introduction on the specific Javascript you'll want to know for React before diving in.
I highly recommend you get yourself to a comfortable level with Javascript and understand all of the topics in the above link before you start. Many frustrations people often experience with React when starting with it too early are actually Javascript frustrations.
The fastest and easiest way to start writing React is to use a pre-configured tool like Create React App or Vite.
Create React App (CRA) has been the de-facto standard for many years, also Vite has been picking up traction recently. From the perspective of a beginner learning the basics it won't make much of a difference. Let's start a react app with CRA using the following command on the command line:
npx create-react-app@latest my-cool-app
cd my-cool-app
npm run start
Notice the first command is npx and not npm. The third argument is just the name of the app you want to make. The second command cd is to change into that directory when the installation is complete.
Then when you run npm run start in that new directory you browser will be opened automatically and you'll be taken to http://localhost:3000 where your new app is being served on. It should look like a big animated spinning atom with some title text describing how to edit your app.
Create React App provides a "live reload" dev server which means that changes to your app will be reflected in the browser instantly, making it very easy to make changes to your app and quickly see and debug the results. Try making changes to the src/App.js file and seeing what happens!
What else do I need to know about React?
You should know the difference between functional components and class components. Class components are still perfectly valid, though are considered the "old" way to doing things and all modern React features and syntax are designed primarily to support functional components moving forward.
You should know what hooks are.
You should know what rendering a components means in the context of React.
You should understand React state and understand why React prefers to replace values rather than mutate (hint: it's to make it easier to keep track of when something changes to know when to update the DOM)
You should understand what a lifecycle effect and how you can use a hook like useEffect to watch values and trigger different actions/events when those values change.
You should know what global state management solutions are and why people use them. This includes bu not limited to ReduX, MobX, Zustand, Recoil, etc (there's tons). You should also understand the Context API and when it does and doesn't act as a global state management tool.
What are the best free resources for learning React?
My Blog Post on React shameless plug for my blog post where I go into more detail into how to configure a React project from the group up to get a better understanding of what's going on
Official Documentation and The Official Beta Docs written by the React team should be your first source of information. The beta docs are quite new, but they are much improved and updated to use modern React syntax, so you should always check them first before falling back on the original docs if you can't find what you're looking for.
Reactiflux mark Erikson's (developer of Redux) suggested path for learning React.
Codeacademy's React course.
The Road to React by Robin Wieruch. Not a free resource I admit, though I felt I should include it because I did read it while learning React and think it was extremely helpful for improving my understanding.
Typescript
What is Typescript?
What is the difference between Typescript and Javascript?
Typescript is an absolutely incredible programming language. It is largely responsible for adoption of Javascript to build large-scale business applications that might otherwise never have been possible or realistic without it.
Typescript is Javascript. That's one of those really critical things to realize.
Typescript is just Javascript code with additional syntax added on top of it to check for correctness and potential errors while you are writing it that otherwise would not be caught until you actually run the program with standard Javascript.
If you are proficient in Javascript, you still may not know how to write Typescript. However, if learn Typescript, then you also know Javascript as well. A good TS developer would be more than qualified for any JS job.
It can be difficult to explain to new developers why Typescript is so important. Often they will find it frustrating that they cannot get code to work, or it feels too complex with little payoff.
When it comes down to it, if you want to be employed as a web developer professionally, Typescript is unquestionably the way to go. You will severely limit your job prospects if you only learn JS.
This is probably a good time to show an example of the difference between JS and TS:
script.js
function addNumbers(a, b) {
return a + b;
}
script.ts
function addNumbers(a: number, b: number): number {
return a + b;
}
The first JS example is pretty simple. It takes two arguments, and adds them together. If you run the following:
const result = addNumbers(3, 4);
console.log(result);
The output will be 7
What if we did the following though?
const result = addNumbers("3", "4");
console.log(result);
What would the output be? The answer is the strong "34" because each argument was actually a string, so Javascript just assumed you meant "concatenate" when you used the plus sign.
Next let's take a look at the second example above that was labelled as script.ts. It's the same function but the parameters are annotated as number and number also appears after the parentheses to indicate that the return value should also be a number.
The screenshot below demonstrates what you would see when writing this using VS Code:
So although this is a simple example, you can immediately see one of the many benefits. Typescript has stopped us from making a simple syntax error and using our function incorrectly.
Remember that even if you look at this and think "I would never make such a simple mistake", in reality, when working on large projects for long hours everyone makes small stupid mistakes. All the time.
And even if you don't, your coworkers will.
Typescript is there to help you with a warning as soon as you make these errors so you can correct them and get back to working on your code.
So that's great, but how do you actually use it? .ts files?
Browsers do not understand Typescript. They only understand Javascript. So modern working setups are created to allow you to write Typescript code, but then transpile _convert) it into Javascript code when you are ready to run it.
How do I use Typescript?
The easiest way to practice and learn it is with the Typescript playground.
Once you move beyond that and want to start writing your own Typescript code on your machine, the most basic setup involves the following:
First, install Node.js on your machine. This will automatically install
npm.Next, create a folder for your project, then navigate to that folder on the command line and run
npm init. Just hit enter to select all the defaults.Run the following command:
npm install --save-dev typescript
That will install Typescript in your project as a "dev dependency". You should be able to see it listed with a version number in the package.json file that NPM created.
- Run the following command:
npx tsc --init
(Note that's npx not npm. npx is a "package runner" which is different from your package manager. It can run packages that are installed in your project as code directly)
This will create a tsconfig.json file which has all the configuration for your Typescript project. You can learn more about tsconfig.json here
- Create a
script.tsfile with any Typescript code you like in it. This file should be in the project root in the same directory as yourtsconfig.json.
You can use the example above with the addNumbers function if you like, code below:
script.ts
function addNumbers(a: number, b: number): number {
return a + b;
}
const result = addNumbers(3, 4);
console.log(result);
- Now you need to convert that
.tsfile into Javascript. Run the following command.
npx tsc script.ts
That will run Typescript on the script.ts file and output a script.js file right beside it with all the type information removed.
That information was only there to help you with development, once you have verified there are no errors none if it is necessary anymore, which is great, because it means it does not add any size/bloat to the actual code that you will be including in your site.
- Once the
script.jsfile has been generated, run it with Node!
node script.js
If you copied the above example the output will be 7!
What are the best resources for learning Typescript?
Official documentation As far as I'm concerned there is no better source than the Typescript docs themselves. Lots of great examples starting at the beginner level and up from there.
No BS TS Some great videos on getting up and running with Typescript quickly
Web Hosting
Where do I host a website?
How do I put my website on the internet?
Web hosting is, simply put, the act of putting your website or web app files onto a machine or service somewhere that the general public can access them. There are basically a million different ways you can do this and a lot of factors that go into the decision of which one you might choose, so in this tutorial we are going to focus on the simplest ones.
Things that are important to us right now:
- Simplicity & cost (ideally free)
Things that are not important to us right now:
- Scalability (ability to handle large amounts of traffic, with large referring to hundreds of thousands of requests and beyond)
So with those in mind I'll start by showing you two great options for hosting a simple website built with HTML, CSS and JS. This type of setup we call a static site which basically means all the files used are "static" in that they are already written and don't change (as opposed to a dynamic app which generates HTML automatically, something like React for example).
The two options I would suggest depend on whether or not you have set up a Github account yet, and pushed your site to a repository.
If your code is already on Github, then I recommend Static Site Hosting Option 1: Github Pages if not, then I suggest Static Site Hosting Option 2: Netlify which is a great service with an excellent free tier for hosting projects.
Static Site Hosting Option 1: Github Pages
This section will follow up with the tutorial that teaches you how to push your site to a remote Github repository. We will be using a repository that is hosting the Basic Website Example but you can host your own custom site if you choose.
Navigate to your site's repository on Github and choose Settings -> Pages:
Use the dropdown to select which branch you want to publish (default is main if you followed the tutorial, but if you're on an older version of git it could be master and then click Save).
...that's it! You're done. You'll be given a custom generated URL based on the name of your Github account and repository that you can share with anyone. Here's mine:
https://alexeagleson.github.io/example-git-project/
Github pages is an absolutely fantastic way to quickly host and share static websites.
If you've reached a point where you are now wondering where to host more complex web apps (React apps for example) or Node apps/APIs then skip ahead to the How do I host a web app? section.
Static Site Hosting Option 2: Netlify
If your HTML, CSS and JS files are on your computer and you haven't learned how to use Github yet don't fret, Netlify is a great option.
Navigate to the Netlify website and create a free account.
Once you have logged in your will see a dashboard that gives you three options: to host a project from Github, or use a template, or upload files manually. We are going to upload the files ourselves:
I'm going to click "browse to upload" and select the directory that has my index.html, script.js and style.css files in it from the Basic Website Example. You can take those files for learning purposes, or upload your own site.
The process will take a few minutes, Netlify will be configuring its web server to load your files as well as creating a custom domain name (URL) for your site that you can share with other people.
Cool! My upload is done, Once finished yours should be publicly available just like mine. Here's the link I received with the files I uploaded, feel free to check it out:
https://stellular-brioche-c71cfe.netlify.app/
That's pretty much it. If you own your own domain you can direct it to the site you just uploaded with the tools they provide and add an SSL certificate as well if you like. Otherwise the randomized Netlify domain they provide you automatically is enough to be able to share your work with others.
Working with free services like this the main downsides you will get is that once your site reaches a certain level of traffic Netlify will likely shut it down until you registered for a paid tier.
This practice is pretty universal, you'll find that it's easy to find free hosting for projects as long as they don't get too much traffic.
If you're looking for a more scaleable option that you are willing to pay for with hosting, then check out services like AWS, Microsoft Azure, and Digital Ocean.
(I'll take this opportunity to warn you to avoid _Godaddy at all costs just in case that comes up as an option in your search, I won't waste time getting into the details, but suffice to say there are far better options. Here and here and here can get you started on reasons if you're curious)._
How do I host a web app?
How do I host a React app?
This section will discuss options for hosting web apps, we'll focus specifically on React apps, but the basic premise is the same for other popular frameworks (like Angular, Vue, etc) as well.
First we will create a basic React app with the popular tool Create React App. For a major production React app for your business, there are probably better options in 2022, but for quickly getting a simple React app up and running with little to no configuration it's still the best option out there.
(Note that the following command requires Node.js to be installed on your machine. If you haven't done that already, make sure you check out that tutorial first. It also assumes you have already learned how to hos your project on Github)
npx create-react-app example-react-app
Next I will go to my Github profile and create a project called example-react-app.
Back on my terminal I'll change directory into the project directory, add the remote Github repository I just created as the origin and then push my code.
cd example-react-app
git remote add origin YOUR_GITHUB_URL
git push -u origin main
Here is my personal repository where I've pushed by React app. Yours will have a different URL.
Next navigate over to Netlify, login to your account (or create one if you don't already have one), select "Start new project" and then "Import an existing project from a Git repository".
You will need to give Netlify permission to access your Github profile, and then either select the repository to give permission manually, or give permission to all repositories. Once permission is given you can select your React app repository.
For configuration select the main branch, and unless you've altered the default configuration, you can leave all the rest of the commands as-is. Netlify will go through the process of deploying your site, and provide you with an automatically generated public URL afterward.
That's it! It's that simple. If you want to make updates you can simply commit changes to your repository, and then choose to redeploy on Netlify. You can even configure it to watch for changes on your Github repository, and redeploy automatically whenever you push new changes to the main branch.
Here's the result of my upload and the public URL that is generated, yours should look very similar:
https://magenta-conkies-c988a1.netlify.app/
How do I host a Node.js server?
How do I host a Node.js app?
Hosting a Node app is a little bit trickier than a standard website, but not too much so. You'll have more difficulty finding a free tier for a Node app.
Before getting into other options, I should say I've heard very good things about fly.io. I've never used it personally, but it seems like a potentially great free option for Node.js hosting. If you're interested give this tutorial a try and let me know how it goes.
One other common suggestions is to use AWS Lambda. One benefit of lambda functions is that although you will still need to provide your credit card, they will only charge you based on actual usage. So if you and your friends are the only ones using the app, you're likely only looking at a few pennies a month.
I personally haven't used AWS Lambda, so I'll be focusing on a different option for this tutorial, A service provided by Digital Ocean called droplets.
Droplets are simply a fancy name given to access to a Linux server that is fully accessible to anyone on the internet. They're great because you can run pretty much anything you want on them. The lowest tier which is more than enough to run basic Node applications is only $5 per month, and will more than serve our purposes.
It's a pretty small price to pay for something that you can use to host almost any project you work on, including the websites and web apps we've already discussed.
Once you have signed up for a droplet, log into your account and select it.
You will want to make sure you can access your droplet from the command line on your machine. To do this you need to set up SSH. If you have not already created SSH keys on your machine then check out the What is SSH? tutorial to create them.
Once you have created your public key, from your digital ocean droplet dashboard click Settings -> Security -> Add SSH Key. After it is added, copy the IP address for your droplet and return to your terminal.
You can now access your remote Linux server (droplet) with this command:
ssh root@YOUR_DROPLET_IP_ADDRESS
When successful, your terminal will show a welcome message (by default) and you are in a different location/directory. This will be the home directory of the root use of your droplet. You can now create additional users if you choose, or whatever you like.
Once you have access to your droplet via SSH, you are in a good position to begin following the official guide for running a Node.js app on Digital Ocean:
Here's a quick overview of what it will show you how to do, and why each step is necessary:
Step 1 — Installing Node.js: Node is not installed on Linux by default so you need to install it on your droplet yourself.
Step 2 — Creating a Node.js Application: The tutorial assumes you will be writing the application on your droplet, which most often won't be the case. This step is where you may need to deviate a bit. If you have a Node app hosted on a Github repository, then you will want to install
giton your droplet as well and then clone your repository onto your droplet. That way the app you created and pushed will be on your droplet and ready to run.Step 3 — Installing PM2: PM2 is an amazing robust production quality tool for running Node.js apps. Technically you could run the normal command
node my-app.jssame as you do on your machine, but what happens if it crashes? PM2 will take care of running the app, as well as automatically rebooting it if it crashes along with a number of other quality of life features like monitoring.Step 4 — Setting Up Nginx as a Reverse Proxy Server: Nginx is one of the most popular web servers in the world and a fantastic tool. The reason you need it in this case is to control access to your app from the outside world. If your app is running on port 300 for example and you want people to access it on a domain name you bought like
mycoolapp.com, Nginx is the one responsible for directing requests to that domain name on your droplet to your app on the correct port.
So with that context provided, here is the tutorial to help get your Node app up and running live:
What is a CDN?
CDN stands for content delivery network and it's basically a hosting service designed to maximize speed and uptime for resources on the web (files, images, full sites themselves, etc).
The main difference between standard hosting and a CDN is that content on a CDN will be hosted in multiple places, potentially all over the world.
So if one user from your site needs to load Cat-Picture.jpg and they are in USA, and another requests it in France, the CDN will serve the same cat picture from a physical server located in the USA to the user in the USA, and vice versa (or at least the nearest one).
Obviously there's much more to it than that, but this definition should be more than enough to get you to know what people are talking about when they use the acronym.
One of the biggest CDNs out there is called Cloudflare.
If you want to learn more about CDNs then Wikipedia is a great place to start.
Web Domains
What is a URL?
What is a domain name?
What is DNS?
A domain name is simply some text that gets converted into an IP address through a process called DNS.
An example of a domain name is www.google.com. The https:// is the scheme and technically not part of the domain name.
DNS (domain name system) servers exist all over the internet and act as kind of a global dictionary of names and the IP addresses they belong to. They are constantly being updated as names and IP addresses change. There is no one single DNS server that acts as the source of truth, there are countless DNS servers out there and you can even choose which one you want to use to resolve a domain, or host your own.
If you've ever seen the dreaded "This site cannot be reached, server's DNS address could not be found" then that's because your request could not find a way to translate the name into the address of an actual server that is hosting the website or app you are looking for.
How do I get a custom domain name?
In order to get your own custom domain name you must purchase it first from a domain name registrar. Typically these names are purchased as an annual plan that can be renewed. You will always have first choice of renewal, but if you ever opt not to renew there is nothing to stop someone else from buying the name and preventing you from ever getting it back (or having to pay a steep price to buy it from them).
I will not get into the nitty gritty of the business of domain names, but suffice to say it can be big business and common phrases in the .com space an easily go for tens or hundreds of thousands of dollars.
Fortunately there's a near infinite number of possible names out there and as long as you aren't too picky you can probably get something close enough to what you want for as low as a few dollars a year.
First you must choose where to purchase from. There are plenty of options. I'd recommend either Gandi or Namecheap or Cloudflare. Avoid Godaddy if at all possible (Google their reputation around customer service before making any decisions).
After you've purchased the name, most of the services that sell you the name will also be willing to sell you site/app hosting services as well. You can use them if you wish, but it's not necessary, they will have options available for you to point your domain name to your existing server, whether it be something like a Digital Ocean droplet or anything similar.
The final step you need to arrange after buying and configure a domain name is called an SSL certificate so that you site can be accessed over secure HTTPS rather than insecure HTTP.
What is SSL?
What is HTTPS?
How do I get an SSL certificate?
The full scope of exactly what HTTPS and SSL are is beyond the scope of this tutorial, but they are interesting topics if you wish to read more about them.
I will be focusing on the practical application of setting up an SSL certificate for your domain. The first thing I will stress to you is that generating an SSL certificate is a completely free process. I stress this because although it requires a bit of effort, there are no shortage of domain name sales services that will gladly charge you a $50+ fee to "secure" you domain for you.
It's a completely predatory charge that targets non-technical folks who don't know any better. Don't fall for it.
How you generate it will really depend on the hosting service you are using. For example if you are using Digital Ocean as I have discussed throughout this tutorial, then this guide will get you up and running.
If you are using another hosting service then simply Google their name along with "ssl" and you will almost certainly find a tutorial to generate one for free among the top results.
SSH
What is SSH?
SSH (secure shell) is a very important concept to be familiar with, though it is often challenging for beginners to understand. I'll try to explain it as simply as possible.
SSH provides a way for two machines to communicate securely. It is most commonly used over the command line. It provides a way to authenticate a machine without explicitly requiring a password (though a password can optionally be used).
Though SSH can be used to transmit data for a variety of applications and uses, the most common use of it you will encounter in web developer is authenticating your machine when logging into remote servers (for example ones that may be hosting your web app) and for authenticating for version control services like Github, so that when you want to push your code to your company's repository, your machine is already authenticated and don't need to provide your username and password.
How do I use SSH?
What are SSH keys?
So that explains what SSH is as a tool, now let's take a look at how to use it. SSH uses the concept of keys, specifically a public key and a private key.
(The explanation of how it actually works to provide security is far above the scope of this tutorial, but it's a fascinating topic and I'd recommend you check out this Wikipedia page if you want to learn more about it.)
We will focus on the most common developer's use case, using SSH to authenticate ourselves so we can push code to Github. If you're not familiar with Github you can check out the What is Github section of the tutorial and return here when you reach the point of setting up your SSH keys.
The idea behind the public and private keys is that when you generate them, your private key should remain on your machine and you should never ever share it with anyone. As soon as anyone gains access to your private key, they immediately gain the ability to impersonate you, and if you ever suspect that may have occurred (someone got access to your computer for example), you should delete your keys and generate new ones.
The public key on the other hand can freely be shared with anyone. That is what you will add to Github, and whenever a connection request is made from your machine, Github will use that public key to verify the request being sent from your computer with the private key matches.
The keys themselves are simply long strings of text characters, usually a few hundred depending on the algorithm used. When the keys are generated two files will be created, and you can differentiate between the public and private keys with the extension.
The private key will be generated as FILENAME (the filename again will depend on the algorithm used) and the public key will be generated in FILENAME.pub. So remember whenever anyone or any service asks you to provide your SSH key, you want to always make sure you provide the one in the file with the .pub extension.
How do I generate SSH keys?
Rather than go through the actual step-by-step instructions on how to genertae them, I will direct you to one of many great tutorials out there. Generating the keys is easy on any operating system using a free command line tool called ssh-keygen.
(Before showing how to generate keys from the command line, I would also take the opportunity to suggest the SSH key generation and SSH agent in 1Password. Full disclosure, this is the company I work for and I don't usually like to pitch products, but this is a rare case while I am genuinely impressed by how useful it is to manage SSH keys in 1Password and be able to share them between different machines I'm working from.)
That said, it's absolutely not necessary to use at all, just a nice convenience thing. The below links show you how to generate your own keys on the command line completely free:
Github itself also has a own tutorial if for any reason you prefer to use that, but both it and the Atlassian one should give you the same result.
(You have the option of adding a password to SSH keys that you need to enter each time you use them. SSH keys themselves are already very secure, I personally find adding a password on top of that not worth the inconvenience, but it's completely up to you.)
Once your keys are generated, make sure you know where the .pub file was creating. On macOS/Linus you'll find it in the ~/.ssh directory, and on Windows the %userprofile%/.ssh directory. You can view its contents by opening it in any text editor.
To add it to your Github profile, copy the contents of the .pub file and go to your Github dashboard. Click your profile icon then Settings -> SSH and GPG Keys. Now click the green New SSH Key button.
Paste the text of the key itself in the Key text box and give it a title. Typically the title refers to the machine the key is tied to, so if I generated it I might give it a title like "Alex's Personal Laptop" or "Alex's Work Laptop" etc. Probably good to provide even more details if you work with multiple machines.
Once that is saved you are ready to clone, push and pull Github projects over SSH. Make sure that from now on you are always copying the SSH version of the URL and not the HTTPS one. You can tell which is which based on their structure, examples below:
- SSH URL Example: git@github.com:alexeagleson/example-git-project.git
- HTTPS URL Example: https://github.com/alexeagleson/example-git-project.git
If you have already been working with a Github project over HTTPS and want to switch an existing project, you will need to change the remote URL. To do that, navigate to the project on your machine and run this command:
git remote set-url origin YOUR_REPOSITORY_SSH_URL
That will update the default origin to use the SSH URL and you will no longer need to enter your username and password when pushing to it.
DevOps
DevOps is one of those terms that can mean ten different things to ten different people. I will not make any attempt to assign any kind of formal definition to the term, my only concern is helping you understand the basic concept.
DevOps is at its simplest the automation of the deployment process. We've talked at great length about what a website and web app is, but maybe a little bit less about deployment. Deployment is simply the act of getting your site or app online and available to access for your consumer.
In the distant past there was a very clear divide between software developers and systems administrators (often called SysAdmins or just more generally IT personnel). As the industry matured it became clear that the divide between these two roles was not as large as once thought, and that a lot of benefits could be gained from having developers who were familiar with how their apps were deployed, as well as system administrators who were familiar with code, so that each could communicate their needs better to one another.
These days very few companies manage their own infrastructure (the servers their code is deployed on) and even fewer have their own physical servers. The majority of tech companies deploy their products using cloud services like Microsoft Azure or Amazon Web Services (AWS).
Using these services rather than purchasing and maintaining physical servers allows tech companies to focused entirely on their product and not maintain a large infrastructure team. As their application userbase grows and scales tools like AWS are designed to automatically handle that increase in traffic in real time in ways that would be far more difficult if not impossible to do if it were necessary to purchase and install more physical servers.
That feature of course comes at a cost, but that cost presumably will be less than trying to manage your infrastructure yourself.
Nevertheless, managing the needs of a high traffic application can be very complex. Tools like AWS are designed to be easily configured by code rather than through direct access to the servers themselves. DevOps personnel are particularly adept at building and maintaining configurations for cloud services so that developers do not need to think as much about how the code they write is actually deployed and served to the public.
What is CI/CD?
In addition to managing things like cloud configuration, a good DevOps engineer also takes care of building an application's CI/CD pipeline. CI/CD stands for continuous integration and continuous delivery. It essentially means creating the needed processes so that developers can continue to build and implement features for the application with minimal risk of introducing bugs or errors.
DevOps engineers will use features within tools like Gitlab or Github to ensure that in order for code to be allowed to merge into the primary main or master branch of the project, it must meet certain conditions.
Those conditions can range in anything from simple linter checks to full blow end-to-end tests which run real simulated user actions on your code and check to see if they match conditions you have set. If they fail, the code a developer submitted will not be allowed to merge.
Continuous integration refers to the idea of frequently merging new code into the priamry project branch, rather than keeping it in a separate branch. This has the benefit of keeping every developer up to date with the most recent state of the project, and avoids the risk of large merge conflicts if separate devs have been making changes to similar areas of the codebase over days or even weeks and months.
Continuous delivery refers to the idea of releasing these changes frequently to the customer. This provides the significant benefit of being able to quickly turn around customer feedback into real usable features or bug fixes. If your CI/CD automated pipeline is solid then you can be confident that any code changes which have passed all your tests are potentially ready to be released to your users without the need for extensive QA (though manual QA is always a good idea regardless of how good your pipeline is.
Containers
What is Docker?
Docker is a tool that allows you package the environment for running your application along with the application itself. You can accomplish this as simply as including a single file called Dockerfile with your project.
A developer might choose to use Docker because it provides guarantees that the versions of each tool installed (like Node, Python, NPM, MySQL, etc) are the same for every developer working on the project, regardless of what they have installed on their own machine.
If you've ever had trouble getting your environment setup properly to start your development work, that's exactly what a tool like Docker is designed to solve.
It uses a concept it calls containers which are lighter weight (require less resources) than full on virtual machines to create the environment for your application. These containers are designed to be extremely portable which means that you can quickly deploy them anywhere, and also scale up your app quickly by simply deploying more copies of your container.
All you need to do is define the requirements for your environment in the Dockerfile (for example Ubuntu 18, Node.js, etc) and every time your container is started on any machine, it will recreate exactly that environment. So you already know in advance that you will not have any issue with missing dependencies or incorrect versions.
If you would like to learn more about Docker from the perspective of a Javascript developer I have written a brief introductory Docker tutorial.
What are the best free resources for learning DevOps?
DevOps is more challenging to learn on your own than some other programming topics, simply because at its core its about empowering development teams at scale which is difficult to emulate when trying to learn as a solo developer.
Remember that we discussed how being a good DevOps engineer is about understanding the needs of the development team. Being a good DevOps engineer requires you to have a very solid understanding of a lot of developer and sysadmin fundamentals including but not limited to: Git, Linux, bash scripting, and different cloud services (particularly the one the company you work for uses).
Make sure you have a solid understanding of Git and Linux commands before you go any further:
What are the best free resources for learning the command line terminal?
What are the best free resources for learning Git?
After that depending on your code repository and hosting provider you'll want to familiarize yourself using their own tutorials and documentation:
This really good reddit post about DevOps resources
I'd like to end this by acknowledging that I am certainly no DevOps expert, the resources and descriptions I have included here are best effort and hopefully do not offend any serious DevOps people. There are still further many advanced topics I have not covered that will inevitably come up if you take the plunge into the DevOps world.
If you are interested would encourage your to at least familiarize yourself with additional tools like Kubernetes, Ansible, Jenkins and Terraform. Their use cases are mostly beyond my needs as someone who is focused primarily on the development side, but are undoubtedly critical for anyone looking to dive further into DevOps.
Interviewing and Job Hunting
In this section I'll be discussing general topics and frequently asked questions as they relate to the web development career space and software industry in general.
These responses will inevitably be a bit more opinionated than the other sections, but I do my best not to state any advice as the "only way". There are an infinite number of different paths you can take to success in this industry, it's all a matter of varying degrees of speed and effectiveness.
The vast majority of it is simply based on my own personal experiences and years spent in online developer communities and forums reading experiences from other developers at similar stages in their career.
How long until I will be ready to apply for jobs?
Everyone is different of course and there is not going to be a single answer that applies to everyone. Some people will have more time in a day to invest into their learning.
Some people will be learning in the evenings / weekends while supporting themselves with another job, others will have the freedom to make learning itself their full time job.
The important thing to remember is that while the process will be faster for some, everyone has the capability to make it eventually if it's something they are genuinely interested in.
My extremely ballpark'd answer for the majority of people would be about one year. For those who can dedicate to learning full time, it could potentially be more like 6 months. Others who are extremely busy and only able to learn a few hours a week might be looking at closer to 2 years.
How do I know when I am ready to apply to jobs?
This is a very common question, and the honest answer is that there is no specific threshold. Some companies are willing to hire people with very limited skills and experience who are willing to learn on the job, other companies have very high requirements for skill level before they are willing to hire someone.
Often there is really no way of knowing which company is strict about the requirements they ask for, and job descriptions unfortunately are notorious for not actually defining the real requirements for the job.
Many jobs that "require 5 years of experience" or "must know Angular" will end up hiring someone with 2 years experience who has never used Angular at all. The reality is that the market is very competitive and companies are often willing to settle for candidates that only tick some of the boxes who have a good attitude and sound like they will be willing to learn and train in the areas they might be missing.
The only way to know is to apply. I'm not saying to start applying right away before you can even put together a basic project, but if you have been learning for 6 months straight and get to a point where you are comfortable with the basics of HTML, CSS and Javascript then I would encourage you to think about applying for positions, even if you don't meet all the requirements.
The "worst case" is you get to practice interviews and get a better understanding of what companies are really looking for. The "best case" is you get hired! Honestly, both cases are a win for you.
For more information on preparing for your first job check out the What are the most important factors in getting hired? section.
Where do I find jobs?
Your best resource will probably be LinkedIn. Keeping your LinkedIn profile up to date is critical for people looking for work.
Start building your professional network however you can. Look for meetups, conferences, and talks in your area. Find ways to connect and start chatting with other developers. Many people find that some random network connection was the key they needed to get into their first job.
Aside from that you should look up companies that you are interested in and view the "careers" page on their website. Often applying to a company directly is an effective tool. Make sure to include the reason the company interests you in your initial point of contact.
If you are a student, do absolutely anything you get to get into an internship or a co-op program. The reality is that the most effective way to get a job is through existing professional experience, and internships and co-ops provide one of the easiest paths to get that experience. Do not pass up that opportunity under any circumstance.
Lastly, while you're learning, remember to showcase your skills. Two great methods to do that are by blogging or recording videos.
You can start to build a respectable network entirely online without actually meeting other developers in person this way.
Remember you don't need to be an expert to write a blog. Keep your topics small and focused on things you have learned, and let the intention be to share what you have learned with others. You might be surprised at some of the contacts and opportunities you can get if you keep it up.
What programming language should I learn?
Why are there so many different programming languages?
This is a great question, and there is no right answer for everyone. It really depends on what kind of work you want to do. You might wonder "why are there so many programming languages?" and the reason is that each different language is particularly good at something.
Python is known for being a great first language to learn, it's good a relatively simple syntax that is easier for beginners to understand, and it has a lot of different practical use cases including task automation, data science (crunching numbers and statistics) and building web servers.
If you want to get into mobile app development, then you'll want to learn Kotlin (for Android development) or Swift (for iOS development).
If your goal is simply to get employed, then Javascript is definitely your best bet. Although it is region dependent (you'll want to search in your local area for what kind of jobs are available) in most parts of the world Javascript (and web development in general) remains the most in-demand skill, and all signs point to it remaining that way for the forseeable future.
Everything these days is web driven, from apps on your phone to home appliances.
Maybe companies use web frameworks to help speed development, organize their code and build apps more efficiently. Some you may have heard of include React, Angular, Vue and Svelte. It's well worth it to learn at least one of these frameworks, but don't jump into them too quick, as each one is built on top of the fundamentals of HTML, CSS and Javascript and typically require a solid working knowledge base of those three in order to learn effectively.
Which framework you choose is up to you, though if you are targeting employment make sure you search the jobs in your area. In the vast majority of the world, React jobs outnumber all other frameworks by a large margin (though there is a sizeable market for Vue in Asia).
If web development doesn't sound like your thing, maybe systems programming is more up your alley (embedded controllers, hardware devices, internet of things (IoT) and etc).
To become a systems programmer there are many paths to take, but most start through the C programming language and build from there. It will be important to have a stronger grasp of computer science fundamentals in this field than in web development since you will be interacting with low level concepts like the operating system and memory directly.
Check out the section called What are the best free resources for learning computer science? to find some great resources on learning systems programming concepts.
What if I fail?
What if I get overwhelmed?
Learning software development is extremely challenging, for everyone. Any dev you see who makes it look easy almost certainly has years of practice and failure behind them, it's no different than any other skill that takes years to develop.
Along the way you are almost certainly going to find days where nothing goes right, or everything seems way too overwhelming and it's impossible to keep up with.
The only advice I can give here is to say that this is perfectly normal and part of the process. Failing at building a project will teach you a lot more about that project then not starting it at all. Sometimes you'll find that you've bitten off more than you can chew, and that's okay.
There's nothing wrong with taking a step back and slowing down. When you encounter a topic that seems too large to digest, see if you can break it down into small pieces. Take a day to learn more about just one small aspect of it. Then move on to the next thing. And the next thing.
And remember, there's no set amount of time when you will have "learned something." New devs often say things like "I'll give myself six months to learn Javascript". It doesn't really work like that. I've been writing Javascript for years and I'm still learning. Your goals should reflect concrete tangible targets, focus on learning specific aspects of the languages, rather than the whole language itself.
What are the most important factors in getting hired?
How do I get a job when all companies want existing work experience?
This is the real question right here. Honestly when it comes to software development, finding your first job will the most difficult stage of your career by a significant margin.
Work Experience
Those who are still students should do absolutely everything they can to take internships and co-op placements, having those will give you a massive leg-up over other devs in your peer group who don't when it comes to full-time hiring after graduation.
If you're looking at bootcamps then make sure you pick one specifically that offers networking support and helps connect you with employers after graduation.
For the rest of us getting into development later in life, the best thing you can do is allow the reality to sink in that it's going to be very challenging, accept it, and do your best not to allow it to deter you.
The vast majority of your applications will be rejected. And that's perfectly okay, it's almost certainly due to a lack of experience, not a lacking in skill or ability on your part.
It's important to train yourself not to take it personally. Rejection does not mean "I'm not good enough" it simply means that particular companies needs didn't align with your skills at that moment.
That's it and nothing more.
The fact is that most companies are risk averse. They see someone new to the field with no proven track record of working for an organization and they don't have the confidence that you have the skills and abilities required to contribute. The reality is that if you think you do, you probably do -- but unfortunately many companies just aren't willing to take that risk.
So since this seems like a catch-22 scenario where you can't get experience, how exactly do you break into the field?
The best advice for new devs is that you have to look at it like a numbers game. If there are 100 companies out there, and 1 of them is willing to take a chance on new devs, then you need to apply to 100 companies to get your job.
Apply like crazy! Come up with a solid but generic resume, and start sending it out. Target all the web dev jobs in your local region, look for companies online that are hiring remote. Make the expectation that most will reject you and be perfectly okay with that.
Every failed interview is experience at interviewing. The more you do the more comfortable you will get. Get your resume into as many hands as possible and do as many interviews as you can.
Be completely honest about your skills. When asked a question you don't know the best answer is always "I'm not familiar with that, but I would love to learn more about it."
All you need to remember is this: you only need one company to say yes, and you're in. Once you've got that, then you'll have work experience, and everything from that point on just gets easier and easier.
Now that we've talked about work experience, let's look at some of the other critical factors at play when it comes to getting hired.
Networking and Relationships
When I say networking I'm not talking about networking I'm talking about networking.
Which is unfortunate because if you're like a lot of people (myself included) learning the OSI model is a lot easier than building a professional network. Like many other things in life, the earlier you start the better off you'll be in the long run.
One of the most helpful things when I started to internalize this was the realization that your network doesn't necessarily mean "people you've met in person". You can build a network entirely online through contacts you make on social networks, reddit, Github, Stack Overflow, Discord, etc.
Particularly with the rise of remote work, you never know if the person you were talking to or helping out online two weeks ago could be the person who connects you with your next job. It happens all the time.
I should clarify that having a network of developers is absolutely not required for finding a job. The good old fashioned method of sending out 100 copies of your resume to 100 different companies still works great too. In fact if your goal is to get employed realistically you should be pursuing both these methods.
If you fancy yourself a writer or a speaker, don't sleep on blogs and Youtube tutorials. It's a common misconception that you need to be an expert. Certainly do your homework, but after spending some time getting confident enough with a small topic (even something as simple as loops or if statements) try writing a blog about it!
This is something many bootcamps heavily encourage students to do. It can be a great way to build confidence and also expand your personal network.
Lastly, don't sleep on LinkedIn. Yes, everyone is on there to self promote, and yes the news feed can be really difficult to stomach. The good news is you don't need to use it for that. Don't even look at it. All you need is your own profile up to date, and with some experience under your belt, the recruiters will be reaching out to you rather then the other way around.
Technical Knowledge and Interview Performance
What can I expect from an interview?
The standards for developer interviews are all over the map.
One company might simply want to chat and talk about projects you have worked on. Another might want to run you through technical aptitude tests. Another might give you a take-home project to work on in your spare time.
You should be prepared for any of these and more. As a junior developer your expectation should be a strong working knowledge of HTML, CSS and Javascript, Git, and the command line.
You'll want to supplement that with whatever additional technologies and tooling the position is asking for. So if they are hiring for a junior React position, obviously you would want to be familiar with the basics of React as well.
I think it's really important to taper your expectations and be ready to encounter scenarios where companies are hiring for junior positions, but after getting into the interview it becomes clear they are actually looking for a very experienced developer with the hopes of only paying them as a junior.
Unfortunately all you can really do in these scenarios is your best, ask lots of questions, be honest about your skills, and don't let it discourage you.
Companies will often be willing to relax their skill requirements a bit if they find someone with a good attitude who appears they are ready and willing to learn. Allow yourself to be that person.
Don't forget you are interviewing them as well. Ask questions to try and get an idea of their workload, company culture, what an average day looks like etc.
And don't hesitate to answer a question with "I don't know".
It's a much better answer than making something up or guessing wrong. You can follow it up with something like "I don't know, but here's something similar I've encountered before" or "I don't know, but here's how I would start looking for the answer if I encountered this".
Interview Styles
Show the interviewer that you are proactive when it comes to encountering situations where you don't know the answer, because as we've already discussed, these situations will happen almost every day in a developers career. Embrace that fact and leverage it in your interview.
Let's take a look at some of the different styles of interviews you might encounter in your job search: Here's a realistic look at three different hypothetical interview approaches at three different companies:
Company A: Tell me about some projects you've worked on. Tell me about why you chose the tools you did (discussion style).
Company B: Open up this online browser tool and use Javascript/Python/whatever to reverse a string (whiteboard style).
Company C: Here's an assignment to build a landing page for a website with an interactive menu. Take it home and work on it and then send us the results tomorrow (take home style).
Of course there are plenty more scenarios, but this captures sort of the three main "styles".
The first (discussion style) is based on a conversation of you discussion your knowledge and experience.
Personally I find these the best for junior positions. Most people starting out have a very difficult time programming while under pressure (even for simple stuff) and given an opportunity to discuss they knowledge, the interviewer can ask questions and probe to make sure they actually understand the things they're talking about.
The second (whiteboard style) may be done with actual code or may be done on a board where you simply use a marker. The interviewer usually isn't necessarily looking for a correct or complete solution, but an approach that shows an understanding of the problem, even if there are minor errors or edge cases.
Also important with this style of interview is the candidates ability to ask good questions and clarify assumptions. Sometimes there will even be missing information in the question intentionally and the candidate is supposed to get that information by asking questions. Despite being a coding challenge, this style of interview is very much focused on a discussion of the problem. Typically, depending on the complexity, you'll want to discuss it for up to half the allotted time before you even begin to write code.
When you get up in the higher levels and more competitive companies (often referred to as FAANG or MANGA companies), these styles of interviews get more common and much more difficult than reversing strings.
If you're interested in pushing for those top tier jobs, check out the DSA, Leetcode and Systems Design section for more information.
The final interview style (takehome style) typically involves giving the candidate a small challenge to do on their own time. This can have the benefit of allowing you to work at your own pace without the pressure of someone watching, but it also has the downside of being time consuming, and the majority of companies will not be paying for your time.
Early in your career I can understand agreeing to take home interviews when you are simply trying to get any job you can, but as you progress in your career you'll find yourself passing on this style of interview as you simply don't have the time to build multiple small projects for companies in your limited spare time. Fortunately this interview style is the least common of the three, and rarely used by the top tech companies.
Soft Skills
Don't sleep on soft skills when it comes to finding a job in the industry. Technical skills will certainly help get you the job, but good soft skills will often fast track you should levels and promotions faster than technical skills alone.
What do I mean when I say soft skills? I'm talking about things like positive attitude, the ability to communicate clearly (both spoken and written) and _willingness to share knowledge and help others.
Good mentors and teachers are often looked on very highly by companies, because it shows you can contribute to improving the level of knowledge and skill within the company. If this is something you have interest and experience in (even if it's just something like blogging or videos) make sure that it's something you share during the interview.
Many companies have what's called a cultural interview as one fo the steps in your interview process. While some companies might state they have metrics to quantify this value, the reality is that many simply evaluate you on their "feeling" about how well you would fit in with the company based on the attitude and disposition you display during the interview.
Education
Do I need to get a degree?
Do I need to go to college?
One of the great things about a career in software development is that it does not require you to complete a four year degree or college program to get hired. I can't speak for percentages, but many companies are more concerned with a candidates skill level and ability to produce working software than their educational background.
I don't want to discount how much of a benefit a university or college degree can bring however. If you are someone who has the time and resources, then in the long term a computer science degree will almost certainly be worth the investment you make into it, for a couple of reasons: First is that there are still many companies out there that do look for a degree before hiring a candidate, and second that the fundamental knowledge you gain in computer science will be incredibly valuable in teaching you problem solving skills that translate directly to work you do in the field.
If you do go the college route one of the biggest benefits career-wise are the co-op and internship programs, do not pass up those opportunities if they are available to you, they are one of the most effective ways of breaking through that initial barrier of getting your first job, which most new devs describe as the most difficult hurdle of their career. See How do I get a job when all companies want existing work experience?.
Still, for those that do not have the means to complete a full degree, if you are motivated and disciplined enough it is absolutely possible to teach yourself everything you need to know through a combination of free online resources and building your own practice projects with the knowledge you gain from those resources.
Another popular option these days is bootcamps. They can be a great middle ground between self teaching and a college degree. They are good for those people who feel they may not be able to motivate or direct themselves enough and benefit from having a very strict curriculum to follow.
Bootcamps have a reputation of being very challenging and being one of those things that really gives back the effort you put into it, so make sure you are ready to invest the huge amount of time (and often money) it takes to get the full benefits. Also make sure you do your research on the quality of the bootcamps, you'll find the full array of well regarded ones and poor quality bootcamps. If possible try to find one that also includes help with job placement as part of the package.
Luck
Let's be honest, when you ask many people how they got their first job they'll say "well, I was lucky..." and proceed to tell some anecdote about their good fortunate.
As they say, luck is the intersection of preparation and opportunity. Many of these people who describe themselves as lucky had done preparation in advance that allowed them to take these opportunities when they presented themselves.
Allow yourself to accept that there's always going to be some luck involved, but you can dramatically improve your chances of that luck finding you if you're well prepared.
Which factors most influence potential income?
I've grouped these two questions together as they often go hand in hand. How much you as a candidate appeal to a company has a direct impact on your potential value.
As you can imagine, this is a very popular question, and like many other complex questions, the most accurate answer is going to be "it depends"... but let's take some time to break down as best we can into exactly "what" it depends on.
Location
Not necessarily a huge factor when it comes to getting a job -- but quite possibly the most important factor when it comes to income. Without a doubt, both average and top end software development salaries the U.S. dwarf pretty much every other country.
That's not to say they aren't still well above average in pretty much every country, it's simply pointing out just how much "above" that already high baseline they are in the U.S. You can still live extremely comfortably as a software developer in pretty much any country in the world.
Here's an aggregate by country from Codesubmit showing the different average values between countries. The actual values themselves are less important than the variance between countries.
For developers in the U.S., here is the data directly from the U.S. Bureau of Labor Statistics directly. Similar metrics from the Government of Canada here.
If you're outside North America you should be able to find data from your government's statistics reporting with a quick Google search.
Of course there are tons of factors that go into total income. Cities with significantly higher salaries also have higher costs of living, and there are many other quality of life considerations to take into account as well.
Nevertheless, even when you account for regional cost of living, there's still pretty much no question that developers whose only goal is to maximize income should be aiming to relocate to the U.S.
That said, this particular advice really only applies to the small subset of folks who aren't already in the U.S. and are also young enough and motivated enough to uplift their entire lives.
For the rest of us (myself included in Canada) there are plenty of other factors listed ahead to consider to help maximize potential earnings without the need to relocate. The rise of remote work is (slowly) shifting the balance and bringing salaries up in non-U.S. countries, and there are more opportunities than ever to work remotely for a U.S. company while living in another country.
Product
What kind of product does the company you're applying to develop? Oftentimes in the tech world, depending on the company's market, they either view software developers as "revenue generating" or an "operating cost".
Not surprisingly, companies that view developers as a source of increased revenue tend to pay more than companies that look at devs as a cost.
Take tech companies like Facebook for example. The more developers hey hire, potentially the more features they can release and the more revenue they can generate. Hiring good devs gives them a direct line to more money, and as such they tend to pay more.
Alternatively consider a major restaurant chain. They need developers of course to manage their websites, maybe the software in their restaurants, and any number of internal tools they build to help manage their company, but ultimately a business like that is going to treat devs more as a "cost of doing business" rather than a source of revenue.
So when seeking higher paying jobs, make sure you are considering the company's product. Is the main product or service they offer software based? If so chances are they're going to value their developers higher than a brick-and-mortar business, and you're likely to get a better offer from them.
Size and Funding
Smaller companies for reasons that should be obviously simply cannot afford to pay the big software salaries that larger companies can.
Working for a small company can be a great experience though, you'll often be able to have a much bigger impact on the product and be involved in more major decisions, but in doing so there is often a price to pay income as compared to the larger companies out there.
That said, an exception to this rule can be small startups that are well funded. When a software focused startup company receives a large round of VC funding, often the biggest chunk of that funding is intended to go directly into hiring more staff to scale their product to a wider market -- so get in there and get your piece!
Base Salary vs Equity
This topic is way bigger than I can possibly go into (and I'm no expert either) so I'll simply link this great blog post on the topic
Suffice it to say that you short of guaranteed stock for an already publicly traded company, you are often best to consider any private equity or options as zero value when it comes to negotiating your salary.
Because in the case of startups (early stage ones in particular) most often that's exactly what it ends up being worth.
Having some ownership in the product you work on is great, but please don't let a company take advantage of you with promises of great value "someday" when they do public. Too many great devs have been burned by this. Make sure you get the base annual salary that you need first, no matter how small the company, if their product is solid they should be able to pay their talent. Full stop.
Once you've got that nailed down, then you can comfortably discuss options on top of that.
What other factors should I consider when applying to a company?
Remote Friendliness
Is the company you're applying to remote friendly? Do they allow permanent work from home? Hybrid model?
Remote work has become more and more common. Even for juniors starting out it's not unrealistic to aim for a remote job.
If it's something that's important to you, make sure you are upfront about it with the company before the interview process begins.
Company Culture
Before beginning the interview or even applying to a company, try and gather as much information you can about what it's like to work at the company.
Ask on developer communities like Reddit, Discord, etc if anyone has experience or anecdotes about what it's like to work for those companies.
Check sites like Glassdoor, Blind and Layoffs.fyi to get accounts from people who have worked at these companies.
try to filter out the most extreme positives and negatives from these sites if you can. Companies can and will find ways to get paid positive reviews. Focus on the ones that sound the most like a "slice of life" honest account if you can. Obviously the bigger the company there more you'll find the easier it will be to get an impression.
Finally make sure you ask in your interview as well. Don't just say "what is your company culture like?" because you'll just get a canned answer.
Ask specific questions like "what time do most developers start and finish work each day?" to try get an idea how much team pressure there might be to "work extra" even if it's not officially "required".
Another great question is "what is your training/onboarding process like?". A question like that can give a good idea whether they've really got their act together when it comes to training new hires, or whether it sounds like you'll just be thrown into a project with nothing more than a "good luck!".
There's tons more of course. Really the questions you want to ask are the ones that reflect things that are important to you. They may not be the same things that are important to someone else. Here's a blog post with some more examples. Consider picking 2-3 that best reflect the kind of work experience you are looking for.
What if I find a job, but it's not what I was expecting?
This section of the post is primarily aimed at those developers who have been been able to find work, but unfortunately find themselves struggling with unrealistic expectations, or pressure to work unpaid overtime, lack of support, or at worst -- straight up verbal harassment including insults, mocking or derision.
Let me tell you straight up so there can be absolutely no misinterpretation: GOOD JOBS, AND GOOD COMPANIES, DO NOT TREAT PEOPLE THIS WAY. EVER. PERIOD. FULL STOP.
There are no exceptions to that statement.
Is it possible that maybe you aren't keeping up, or you are struggling? Absolutely! Maybe it could be that you weren't quite ready for thr job you were hired for. That's an unfortunate reality, but it's not a death sentence.
There are ways of approaching this situation that good managers and good companies will be have plenty of experience with.
One thing I read recently that I think is really critical for developers to remember is this: nothing said in a performance review should ever come as a surprise.
If you wake up tomorrow and have a performance review (whether it's an official one, or simply your manager talking about your performance 1-on-1) and you're told that you've failed to meet expectations, what it really means is that your manager has failed at properly addressing it earlier on when they should have (unless they follow that statement with a plan to support you).
A good manager will approach the topic in a positive way, willing to work with you to come up with a solution. Do you need more training time? More time to shadow other developers? Are the tickets you are being assigned currently too far above your level and you need to spend more time tackling smaller ones to build experience?
These are the kind of questions good companies will encourage managers to ask in performance reviews. You are part of the team and that's how you should expect to be treated.
Following a discussion like this, after whatever the agreed upon period is (whether weeks or months) if you still are unable to work out an approach that helped you work at the level expected of you -- then maybe the tough discussions might start about your fit for the role.
But the key point being made here is that it should never, ever, come as a surprise.
If what I am describing here sounds totally unrealistic or like some kind of "dream company," and you find yourself in a position where you think that mistreatment and unrealistic expectations are the norm -- then I'm happy to tell you that you simply have Stockholm syndrome (I mean that in the nicest way possible).
There are no shortage of companies out there that don't treat people this way.
There has never been a better time to be a developer. I would encourage you to polish off the resume and start your search for that career you deserve.
There's not too many incredibly strong opinions I hold about the industry, but the belief that no matter your skill level that everybody deserves to be treated and spoken to with respect is one of the few complete dealbreakers for me. I'll put up with a lot of stuff, but that's where I draw the line. I think everybody should.
The more we put our foot down for behaviour like that, the more companies will be forced to address it.
Negotiating an Offer
A lot of people will tell you there is no harm in negotiating an offer. That's not exactly true, but it's still good advice.
There's really two most likely scenarios that will occur when you try to negotiate an offer:
- The company will accept or counter (good)
- The company will stay firm at current offer (fine)
Those are the most likely scenarios and since both are options in your favour, that's the reason most people will encourage you to negotiate.
There is a rare third scenario where the company rescinds the initial offer entirely which can happen -- but the most oft repeated advice to that is that "a company that does that probably isn't a company you want to work for anyway."
Whether you should negotiate or not really is a personal choice. I think there are good reasons and scenarios where you might choose not too (the offer is in the range you were expecting and the company is one you are interested to work for.) I personally would never fault someone for accepting an off as-is in that scenario.
Other factors to consider is the amount and your leverage.
A good rule of thumb is 10%. Most companies won't be too surprised if a candidate counters at 10% above the offer that was made to them. If they company is genuinely interested in you, 10% if probably a small price to pay to close the deal.
More than that and you should probably make sure you are confident in yourself and have leverage.
Leverage is basically evidence to show value. The further you are in your career the more track record of proven value you will have and the more leverage you will have. Negotiating up as a new graduate with no experience is possible, but much riskier.
Another way to get leverage is having multiple offers. If you are fortunate enough to have more than one offer from more than one company, and the one you would prefer to work for has offered less, you can use the other offer as leverage in a (very friendly and professional) communication that you have another offer, but would prefer to work for the other company if they would be able to match $X amount.
The final point to note is that when you negotiate or try and leverage multiple offers against each other you have to be willing to lose the offer. That's part of the risk. If you aren't willing to walk away, don't take the risk.
Pay Bands
Make sure you are as familiar as possible with the pay bands (salary range) of the role you are applying to at the company your are interviewing with.
Remember that it's in your best interest not to provide this range yourself as you are much more likely to undersell yourself. Any respectable company or recruiter should be able to provide you with the potential pay range for the role you are applying for, though it may take some pressure on your end to get it out of them, it's well worth it.
If they will not provide you with a range in advance it may be in your best interest to walk away unless you are desperate for the job. Interview processes can be very lengthy and time consuming and there is nothing worth than getting to the offer stage and finding out you had a completely different expectation than the company did.
Be sure to educate yourself in advance using tools like levels.fyi. Remember that software developer pay range is extremely location dependent so you need to ensure you are filtering not only by the company you are applying to, but also your location.
Although levels is the best indicator, particularly for tech companies, you should also make sure to check Glassdoor and Blind as well just to get the most well rounded number you can.
DSA, Leetcode and Systems Design
If your goal is to maximize your income, then you've arrived at your destination.
I mean, full disclosure -- I don't work for a FAANG company. I haven't done the grind myself and don't intend to. I work for a great company and could hardly ask for a better career, but I am familiar with the requirements and can certainly point folks in the right direction for all the resources they need to study to take that leap.
DSA stands for data structures and algorithms.
If you studied computer science in college/university then this is probably old news to you, but if you're someone who has been just learning web development on their own in their spare time it might seem a bit overwhelming. And that's okay! Let's break it down.
In order to understand why DSAs are important you need to kind of take a step back and look at the big picture of software engineering as a whole rather than web development in particular.
Regardless of whether you've learned Javascript, or Python, or C++, or Java, or Rust, or Ruby, or C# or whatever -- each programming language when you boil them down to their core elements is really just a different flavour of approaching the same topic: representing and manipulating data.
How that data is stored covers the data structures part and how it is manipulated falls into the algorithms.
Big tech companies like the FAANG/MANGA crew and similar monoliths are in a very unique position. The small mom and pop shops in your local area have to do a lot of work to seek out developers that can both do all the odds and ends dev work that needs to be done for average to below average pay -- but the big bois can sit back while every new grad and they dog climb over themselves to try to work for them.
This endless supply of potential dev talent means they have the luxury of being a lot pickier about who they hire than most companies.
But how do they decide how to filter out the best of the best?
Well as it happens, they've all done their research, and it seems like the most consistent way of identifying top talent in the software industry isn't necessarily based on work experience or knowledge of any one particular programming language -- it's a candidate's base understanding of fundamental computer science topics like data structures and algorithms.
The idea behind it is that if you can understand the thought processes behind the underlying concepts, the actual language you write the code in is pretty irrelevant.
It's much easier to teach a strong logical thinker how to write Python than it is to teach a Python developer how to think.
So with that background established we've paved the way for the birth of platforms like Leetcode to exist, which despite the stupid name, is unquestionably the most important resource available to you as a developer if your long term goal is to maximize your income.
All the top paying tech companies right now like Amazon, Apple, Facebook, etc draw most of their engineering interview questions directly from the pool of questions listed on this site. Whether similar and adjusted slightly, or in many occasions almost identically word for word.
There's no tricks or cheating involved in having access to them in advance. The whole idea is that they are challenging enough to require weeks or months of practice to internalize the concepts. If you are able to do so successfully then it demonstrates to these companies that you are capable of a level of logical thinking that they expect, and so having the solutions practices and even memorized is enough to identify you as a valuable candidate.
This is what's called the Leetcode grind, and as painful as it can be, it's widely considered to be the most valuable way you can spend your time if your goal is maximizing your income. Grind out a few problems per day, work your way up into the mediums and hards, and you'll be ready for your FAANG interview in no time.
For a new grad or someone with no experience, this is often enough to get your foot in the door. For those developers targeting the higher level positions at the big tech companies you'll also need to spend time studying system design.
Systems design in a nutshell is simply an outline of all the factors you need to consider when building a large scale software system. Consider a trivial example of a website. I make a website with HTML, CSS and Javascript and host it online with Github pages, or purchase some web hosting with Godaddy and upload my files. People love it! Every day I get more and more visitors.
Tomorrow I log on and my site is down. It got too popular! Turns out I only had 1GB of bandwidth with my hosting provider and I blew through it overnight when my site went viral. Damn. How big were the images I was hosting? What was my caching setup? What were my plans for scalability? I didn't have any?
Well no wonder everything fell apart.
In a systems design interview you'll get an example of some kind of business idea or product that might need to be built. You'll be expected to be able to discuss as many factors or considerations that need to be accounted for in building that system.
You'll need to discuss both functional requirements (what features does this product need to support?) as well as infrastructure (how can we handle potentially large amounts of traffic and data storage requirements?).
What solutions are available? What are the pros and cons of each one?
If you're still not sure exactly what we're talking about, here's a couple classic examples based on real interview questions you might encounter on this subject:
These videos will give you a great idea of how you will be expected to answer questions like this in a big tech interview.
Lastly, before moving on I should like you with a couple of the foremost standard resources in this space. The book Cracking the Coding Interview is considered the gold standard. It's not free unlike most other resources I've linked, but since you're presumably only here because you're looking to maximize your earning potential, $40 is probably a pretty small price to pay to get you there.
For systems design there are great books too, but honestly YouTube is pretty much your best friend for this one. It's really great to just listen to people walk through their thought process for different problems. Just watch to avoid the crypto shills like TechLead which I will not link out of principle.
A simple rule of thumb to follow is that if the person is only speaking about the topic and answering exactly the subject you searched for, you're probably in good hands. If they're starting or ending their video encouraging you to "check out" something totally unrelated you should proceed with extreme caution.
Good luck! Let me know in a comment if you manage to land a sweet gig :D
More Learning Resources
What resources should I use to learn web development?
My personal #1 recommendation to anyone trying to get into web development as a career would be to go through The Odin Project
It is an absolutely incredible resource that teaches all of the fundamentals of web development (including HTML, CSS, Javascript and Git) and more in a completely free digital environment.
They even have a Discord server for users to help each other out while going through the curriculum.
If you go through the entire Odin Project from start to finish and complete every step and every project I genuinely believe you will be in a position to start applying for jobs. It uses all the same technologies that real companies use and mirrors the kinds of tasks and challenges you would find in a real professional web development position.
In addition to the Odin Project, Free Code Camp is also very highly recommended as a free resource to learn web development.
- What are the best free resources for learning HTML
- What are the best free resources for learning CSS
- What are the best free resources for learning Javascript
- What are the best free resources for learning Git
- What are the best free resources for learning Databases
What are the best free resources for learning computer science?
If you are interested in learning about the more generalized field of "software development" then there are some absolutely incredible free resources for that as well.
Anything that you learn about the development in general will almost certainly help propel your understanding of web development as well. The great thing about software is that ultimately most of the concepts are the same regardless of which specialty you choose.
Learning how to sort an array in C++ or Python will use all the same general concepts as sorting an array in Javascript. Learning how to do it in one language one will make learning it in the other significantly faster. Often you'll even learn tips and tricks that you might not have been exposed to working exclusively in one language.
The gold standard free resource for getting introduced to programming and software development is Harvard's free CS50 course. Seriously, watch the preview video to get an idea, it's absolutely fascinating subject material and extremely well presented. I would recommend this course to anyone who was thinking about getting into development.
After that we have the incredible OSSU which is an entire university level computer science available free online. Once again, this is one of the most amazing resources you will ever encounter, and entirely free.
We also have teach yourself CS which is very similar to OSSU in that it aims to be a complete computer science education.
Lastly, I'd like to also share two other great resources for people interested in the field of software development, depending on where you interest lies:
If you are interesting in using software and programming to solve practical everyday problems, check out Automate the Boring Stuff with Python. After completing this if you're working a white collar job using Excel in an office, there's a good chance you'll find you can automate away half the stuff you do on a daily basis.
The other is for people who are more interested in the "how does software work at the lowest level". It's a project called Nand to Tetris and it basically goes through the process of going from electronic hardware logic gates to a working game of Tetris. Very involved and complex, but incredibly rewarding.
If you are interested to go even lower, down to the bare metal, then you'll definitely want to check out this incredible video series from Ben Eater on building an 8-bit computer from scratch. If you complete a big project like this you'll learn more about computers than any single college course or video lecture will be able to teach you.
Simple Website Template
The following is a simple example of a complete website that uses HTML, CSS and Javascript. These files are used as the basis of a lot of examples in this tutorial such as using Github, website hosting, and learning HTML/CSS/JS.
The purpose of this section is to link to in those other parts of the tutorials to copy these files, but it may also serve as an example of a simple website setup that shows some of the fundamental concepts of HTML, CSS and Javascript.
Feel free to use it for any part of your learning or projects in any way that you like.
It consists of three files called index.html, script.js and style.css which are all intended to go into the same folder/directory. The contents of each of those three files is as follows:
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My Animal Blog</title>
<link rel="stylesheet" href="style.css" />
<script defer src="script.js"></script>
</head>
<body>
<header>
<h1>My Favourite Animals</h1>
<h2>Enjoy these furry friends</h2>
</header>
<main>
<article class="card">
<img
src="https://res.cloudinary.com/dqse2txyi/image/upload/v1657421273/blogs/intro-to-web-development/cat_k4fcww.png"
alt="Cat Playing Chess"
/>
<div class="card__container">
<h3>Chess Cat</h3>
<p>He's planning his next move.</p>
<button onclick="likeButton()">Like</button>
</div>
</article>
</main>
<footer>
<p>© 2022</p>
</footer>
</body>
</html>
style.css
body {
color: #333333;
font-family: Helvetica, sans-serif;
margin: auto;
max-width: 800px;
}
main {
margin-bottom: 40px;
}
header,
footer {
text-align: center;
}
h1 {
font-family: Arial, sans-serif;
}
h2 {
font-style: italic;
font-weight: lighter;
}
.card {
width: 350px;
margin: auto;
box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
border-radius: 10px;
overflow: hidden;
}
.card > img {
width: 100%;
height: auto;
}
.card__container {
padding: 16px;
}
script.js
var likes = 0;
// Adds 1 to the number of likes, and updates the text of the button
function likeButton() {
likes = likes + 1;
var myButton = document.querySelector("button");
myButton.innerText = "👍 " + likes;
}
When placed together and hosted with a web server, this will be the output when you visit the URL:
Conclusion
I hope you found this guide useful and informative. It's been extremely challenging to try and decide the right format to present it so that it can be helpful to as many people as possible.
If you have any suggestions or feedback please leave a comment behind. Despite the length and scope of this guide I still consider it to be a work in progress and am very open to any ideas for improvement.
Lastly, to everyone, I wish you good luck on your learning journey. Learning a new skill, especially one as complex as software development, takes a lot of time. Go easy on yourself, and remember that the goal is not overnight success, but rather a little bit of progress each day.
All the best,
~ Alex
Top comments (7)
Alex, this is great stuff, it really is, but man for someone coming in new to web dev this is an unscalable mountain of information.
Also, it's so long that by the time they finish reading it half of it's probably changed lol.
I don't have a better way of going about it and you put in a ton of effort, but yea i feel it's too much for newbies to read just because it's information overload, especially considering most newbies won't need to know 90% of it to get their job done.
Still, a great write up and any dev should take the time to read through it at some point, it's worth the little nuggets you pick up even when you are experienced.
I'm definitely open to idea for better ways of presenting, I'll probably continue to iterate and tweak over time. I think I probably need to move part of the introduction here and lead off with hammering down how the intent is to be something to reference as topics come up organically, not to consume as a whole.
Particularly around the idea that there's only about 5 things you really should know before starting to apply to front end roles. Everything else can just be picked up on the job.
One thing I will counter with confidence though is the idea that these things will change anytime soon. I think that maybe with only the exceptions of the discussions on front end frameworks and maybe the devops, everything else here would be exactly as relevant when I started 5 years ago as it is today.
The focus really is on the fundamentals, and those things have been pretty stable and rock solid for a long time, with no indication that's going to change anytime soon 😄
Thank you for taking the time to share your experiences and knowledge! In the span of everything covered. Well written for anyone really just trying to get the core ideas and fundamentals needed and a lot of great links and resources were mentioned. I may be biased to the Odin project because of this article and that’s even after a bootcamp, w3schools, freecodecamp and MDN. I feel they all have their strengths but the Odin project so far has been the most engaging and best when it comes to really gaining muscle memory and getting in a habit of developing a work flow. I would recommend this article to anyone thinking about web development or needing some guidance on their own personal journey! 🤘
It’s rare to find so many gems of good information without having to hop multiple pages/platforms/resources. Awesome work!
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 🫰
Great work @alexeagleson 🔥
I remind you that you can divide the article into several chapters to focus more on the article you want to read.
Thanks! That's a good point, this ended up being much longer than I was planning when i started it, I'll break it into a series of posts and use this one as the table of contents. Just an exercise in updating anchors.
Cheers
Thank you so much, i really need this.