Article summary
Or, Why you can’t get your jQueryUI Datatables plugin to keep your data after you refresh the page.
This three-part series is a general, high-level, first-day-of-Intro-to-Web-Development overview of web app architecture. It is written for the past selves of a few of my college friends, the friends who called and asked me the question in the subtitle above, and then showed me a mess of PHP spaghetti code (copy-pasted from various “This is how you make a form!” type tutorials) when I asked them to show me what they had done so far. Strictly speaking, if you’re a web dev already, you’re probably not going to find much value here.
There are a multitude of tutorials on how to do tiny, specific, web-dev-related tasks; but surprisingly few tutorials, explaining how all of the little pieces are supposed to fit together. This lack of information tends to create beginner developers who churn out Frankensteinian PHP scripts (it’s always PHP for some reason), stitched together from W3Schools tutorials and Stack Overflow answers.
How Web Apps Work, Anyway
A user goes to their browser, types in a website, and hits Enter. The browser goes out and finds the internet-facing computer that the website lives on and asks the server for the specific page. The server responds to the request by sending some files over to the browser. The browser executes those files and shows something (hopefully!) to the user.
The user can now visually interact with the website. The code that has been parsed by the browser may or may not have instructions telling the browser to react to user input in various ways: from changing what the page looks like, to reporting back to the server on what it is the user did, to getting even more code to parse and display.
Server vs. Client Side
The main thing to take away from the last paragraph is that in a web application, there are basically two programs running at the same time:
- The code that lives on the server and responds to HTTP requests.
- The code that lives in the browser and responds to user input.
If you’re coming from a world where software development and cat herding are two wildly different things, you’re probably used to writing code in n < 3 && n > 0 languages, packaging it up, and then shipping it off. That is… not the case here.
Deciding what the code on the server should do versus what the code on the browser should do are just a few of the (hundreds of) things a web developer has to decide when they start to write their app. But in general, server and browser decisions tend to be split up like this:
Server-Side Code
- Languages/frameworks include but are not limited to Ruby (Rails), Javascript (Node.js), Python (Django), PHP, C#, and Java; but the list of possibilities is infinite. Any code that can run on a computer and respond to HTTP requests can run a server.
- Stores persistent data (user profiles, instatweets, mybook pages, etc.).
- Cannot be seen by the user (unless something is terribly wrong).
- Can only respond to HTTP requests for a particular URL, not any kind of user input.
- Creates the page that the user finally sees (this is generally only true in web applications that choose to render most of their layouts on the server).
Client-Side Code
- Languages used include: HTML, CSS, and Javascript. Nothing else. But don’t worry, there’s a million frameworks and transpiles-to-[CSS|HTML|JS] languages to choose from (and keep yourself updated on) anyway.
- Parsed by the user’s browser.
- Reacts to user input.
- Can be seen and edited by the user in full.
- Cannot store anything that lasts beyond a page refresh.
- Cannot read files off of a server directly, must communicate via HTTP requests.
- Creates the page that the user finally sees (this is generally only true in single page applications).
Bringing them Together
The generally accepted practice for building a web application—as in an application accessible via a browser that mimics a desktop app, not a static website—is to have your server deliver your homepage and handle saving and loading persistent data, based on simple messages, from the browser (aka making a RESTful API, more on this later).
The actual GUI of your app, all the reactions to your user’s input, and everything related to changing visual appearance are then all completely controlled by client side code. This general style of app is called a Single Page Application. While there are some notable criticisms with it, it’s the best architecture for anything that has to feel like a native app.
This is the first in a series on understanding SPA architecture: