It’s a great time to be a web developer.
There’s so many options, so many frameworks, so many places to learn.
But for a new developer, it can be tricky to see how it all fits together. How do you actually get from the thing you’ve been learning to something on the web that real people can use?
Maybe you’ve been reading all these great articles on React or Vue. Or maybe you’ve been learning HTML and CSS from freeCodeCamp. Or maybe you’ve been playing around with WordPress to set up your very own blog…
You’ve been working with it on your computer, you are able to get stuff to happen. But how do you get from working on stuff on your computer to a website everyone can see?
How do you actually publish this project as a website?
Don’t worry, you’re not alone in feeling stumped. There’s a lot of different pieces that go into making the web work, and it’s not always easy to see how they fit together.
This article aims to fill exactly that gap: starting from playing around with a website on your laptop, what are the things you need to know to get it live on the internet. It is aimed at beginners, so if you’re an expert feel free to scroll on by, and if you’re confused about anything scroll down and leave a comment. No question is too basic.
Let’s start from the user side - what actually happens when you browse the web?
As a user your experience of the web is pretty much exclusively through the browser.
A web browser acts as combination document renderer + switchboard operator.
As a model for a document renderer, think about something like Microsoft Word. Word takes a document in a particular format (“a word document”), and lets you view and interact with that document.
Thus your browser, as a document renderer, translates a set of documents into an interactive page or application.
The other thing that a browser does, and what makes the web magical, is it operates as a switchboard operator to go out and find the exact documents that it will render.
When you type a web address (aka URL) into your browser’s address bar (say for example https://zendev.com/friday-frontend.html, the address for my newsletter), the browser translates it into a request that it will send off to a webserver (computer) running somewhere on the web. It figures out from the domain (zendev.com) which server to send it to, and from the protocol and path (https and /friday-frontend.html respectively) what type of request to send.
That request is what will eventually result in the browser having a new set of documents to render, which brings us to the next key piece of our puzzle: What webservers are and how they work.
When a request comes in, the webserver sees what that request looks like - hey, someone is asking for
/friday-frontend.html, and has to decide how to respond to it.
The simplest possibility is if it already has a copy of that page exactly. This is how my website works, and generally is what is referred to as a “static” site.
Static means the webserver doesn’t do anything to change the content based on the request… it just maps straight from the request to an existing file and passes that file along as the response.
The next way that a webserver might respond with HTML is dynamically. This means that there is no file that holds exactly the HTML document that is going to be returned - instead the server will execute some logic (and often look up data from a database or something similar) and use that to create the HTML document that is going to be returned.
For example, if we were creating a user profile page, and we wanted to locate those pages in a predictable way, for example
/users/coolcat. Each user’s profile would contain some information about that user, possibly stored in a database. Instead of creating actual html pages for
coolcat, we could use a dynamic server that recognized all routes of form
/users/[:username], looked up data from a database based on the username, and rendered that data into a template to create the final HTML.
These API “endpoints” (a fancy name for a URL that accesses a particular API) can also handle all sorts of different operations - from saving data to processing credit cards, and everything in between.
Once it is rendered, the user can interact with it, and you’re off and running. Clicking on links or submitting forms will start the cycle again with a new request.
So what does this mean in terms of creating our web projects and getting them visible on the web?
First off, this means that no matter what you’re building, if you want it to be loadable by users there will need to be a webserver involved somewhere.
Similarly, there are a myriad of WordPress hosting companies that will let you “self host”, giving more control than the prepackaged solutions like WordPress.com, but will still take care of setting up a server to run WordPress. I’m not an expert in this, but WordPress.org (who are very much the experts here) recommend Bluehost, Dreamhost, and Siteground.
If you’re trying to find a way to host a fully static website, your options are much broader… you can use GitHub pages, Amazon S3, Netlify, or pretty much any other service that lets you make files accessible on the web.
For these too, there are hosting solutions customized to their use, but you’re probably looking at either taking on a higher technical burden or paying for some more expensive handholding. Probably the simplest place to start is Heroku, which handles an awful lot of the technical burden/operations for you, but gets expensive as you start to scale up.
One key item we didn’t cover was how a browser actually does it’s address lookup. When you type
https://zendev.com/friday-frontend.html, how does it know that for
zendev.com it needs to go to my server to make its request?
The system that manages this is called DNS - I’m not going to go into too much detail about it in this article, but at a high level you need to either purchase a domain name or piggy-back off of someone else’s domain.
Piggy-backing off of someone else’s is like if I had a website at
https://zendev.squarespace.com. It’s typically tied deeply into a more managed service, and is definitely not great from a branding perspective, but can be fine as you’re working on getting your site set up.
For getting your own domain, you’ll need to purchase one via a domain registrar and set it up to point to your webserver.
In terms of registrars, I highly recommend Hover. I’ve switched all my domains over to them, and don’t even look at other registries anymore.
In terms of setting up the domain to point to your webserver, that tends to be very specific to your hosting, particularly when using more managed services, so you should look at your hosting provider’s documentation. If you have trouble figuring it out, feel free to leave me a comment below and I’ll help point you in the right direction.
Once you’ve identified where you’re hosting your website or application, the next question is how do you actually get your files in place?
The “old school” approach is to find a way to “just put the files in place”. This relies on a convention - where do the files need to be? This varies by hosting provider, but it’s extremely common for there to be a “magic file directory” such as
/var/www where the files will automatically be served by a webserver.
If this is the case for your provider, typically they will suggest a way to upload files to that location such as FTP. Even setting things up yourself, a “just get the files in place” solution can often be simplest. For my website zendev.com, I run a webserver called nginx that simply serves files from a particular directory. When I make an update, I just
scp the files into that directory, and the changes show up.
The next most common way of pushing out code today is probably a source-control triggered deploy.
The word “deploy” is used to describe a discrete update of a set of things, and even if you’re using a “just put the files in place” approach, I recommend grouping changes into a deploy and tracking when you do updates.
Github pages are built from a git repository, where you configure if the pages should be served from the
master branch, the
gh-pages branch, or a
/docs folder in the master branch. After configuration, any push to the mentioned branch will deploy an update.
Similarly, applications hosted on Heroku deploy based on pushes to a git repository.
Additional deployment approaches include things like packaging up docker images and more.
This article is intended to give you a big picture understanding of how web applications actually get from a development environment into something that real people can access and use. If there’s anything along the way that still feels unclear, please don’t hesitate to ask in the comments below.