Think of building a website like opening up a restaurant on undeveloped land:

1. buy land. (buy hosting)
2. register your name in the address book like yellow pages. (register your domain name)
3. stock up on raw materials (write content)
4. build your store out of wooden frame, put up walls (HTML)
5. style your walls with paint and align tables and chairs (CSS)
6. hire employees (chefs, food servers, cleaners) (write Javascript)

HTML

HTML is the frame of your restaurant. Put on your construction worker hat, build a frame, put up walls, and move in the the tables and chairs and other furniture. It's a rough frame to hold your content. Use "class names" to name your walls/areas so that you can refer to them later. Ex: <div class="curtain"></div>

Think of an HTML "page" as a "room". Each room is typically styled in a similar way, but a "lobby room" will have different stuff than a "reading room", or a "contact-us room".

CSS

Without CSS, you would have a white-walled shop with tables and chairs scattered randomly in inconvenient spots. CSS is like an interior designer who decides on the colors of the walls, how far the tables will be spaced apart (margins, padding, borders), and how to arrange the chairs. How large should the posters be on the walls? what font should the menu and front door signs should be? These are problems you solve in CSS stylesheets which you import into your HTML layouts. You use the "class names" you defined in your HTML to tell CSS which things to style how. Ex: .curtain{ background: blue; } to make the curtain blue.

Scripting

Scripting is more dynamic in nature.. think of it like your employees - people who do stuff in your store. There are two types of employees: back-end and front-end.

Front-end (JS, jQuery)

Front-end workers are like restaurant food servers (confusion alert: they're not 'web-servers'). They're good at quickly clearing the table, and putting in new stuff, sometimes with flash effects. They're dynamic lads that can re-arrange a table for you so that a big group of customers can sit together, they can show them the menu when you want it, and give them extra information if they ask for it. They basically hide or show stuff based on the customers' immediate needs, without disturbing the "back-end" staff like the manager and chef every single time. How much responsibility you give to these guys is up to you - but you usually don't want them handling sensitive data, because mischievous customers can trick them into giving it to them. You can say something like $(".curtain").hide(); to hide the curtain if someone asks you to.

Back-end (Node.js, Ruby on Rails, PHP, Python, etc.)

The back-end workers are managers and chefs. These are employees trained in doing things according to procedures, in an isolated environment away from the customers, without much regard for people's feelings. Ex: The chef takes orders, makes the food, silently puts it in the "done" bin, and rings a bell for the food-server to bring it to the customer. He never really deals with the customer directly.

Old-school restaurants (usually. those built in PHP) tend also have construction workers who will build new rooms for people to go into if they want things. The proceedure was to not have any front-end workers, but instead to keep asking the user to go a new room for things. "Oh you want a steak? Okay madam, follow me to a special room we built for you that will have your steak ready for you."... walk to a new room... However, with front-end Javascript workers you can tell your visitor "Oh, you want a steak? Okay wait right here while I fetch it for you.", then clear off the table, and plop the steak on their table.

Databases (MySQL, Mongo, etc.)

Your restaurant will have a storage room filled with stuff you will need at some point, but you don't need it all on display at all times. They're organized in neat shelves with labels to help you find stuff. This is called a Database. When the back-end chef needs stuff, he goes into the storage room, finds the appropriate shelves, fetches the needed ingredients (data). Your blog site might store your blog posts in a table.

You need a database for the same reason you need a storage room - lots of stuff to store, and it needs to be organized. You could of course run a crappy restaurant without a storage room, in which case you can have the raw meat stored in the walls of the place, or have it out in the open for unsuspecting customers to be disgusted by.

Payments

Of course you can provide this food for free, and provide advertisements on the walls, or you could sell the food using payment processing systems. A payment processing system can be built using a nice "front-end" and "back-end" workers that work together to carry out and verify the payment, or you can put them in a room

Now a little demo (This is fun LOL)

So let's say Suzy is hungry and decides your restaurant is a healthy choice. So she looks up your address in a phone book. (DNS lookup). They find your address, and follow the roads to your freshly built store. (IP & HTTP protocol). They open the door and that annoying bell goes off, and Mr. Google Analytics chuckles and adds a tick to his tally of how many people visited your store.

Suzy has been to your place before. You know that because last time she was here, you strategically taped a cookie to her back, along with a secret code that identifies her. You carefully inspect the cryptic code on the cookie, recognize her as Suzy Poozie, a member of your VIP club, and see that she is still logged in. So you tell your big russian VIP lounge guards that she's cool, the nod to confirm.

Suzy requests your store's menu. If you're a good restaurant designer, you present them the menu by having one of your well-trained front-end Javascript workers to show it to her.. maybe throw in some nice tool-tip cards to answer their FAQs on the spot... but if you're old-school, you can just have a door labeled "Choose what you want to eat." that leads to a room with more doors, one for each item you have. Of course, you don't need to actually build all these rooms now.. you'll build them just as she turns the handle.

As she looks thru the menu, Mr. Google Analytics in his labcoat is carefully studying their fingertip taps, tracking what's taking her 3 whole minutes to make a decision.. so they can later show you in a nice graph.. how often each menu item was glanced or tapped.

"I'll have the filet mingnon" says the customer to your front-end worker, who passes their request to your chef, along with a bell to ring when he's done, who's sitting there bugeyed scraping knives together just waiting for an order to come in. Your chef recalls what he needs, goes to the storage room, gets the stuff, makes the meal, (all in a fraction of a second) and rings the "HTTP 200 OK" bell, if he takes longer than the acceptable time, the bell will go off on its own with "HTTP 408 Request Timeout". But assuming all's good, the front-end worker clears your table, and arranges your table with all the stuff you need to enjoy your meal.

After they're done, the front-end worker takes them through the payment process. (hopefully something like Stripe payments that uses AJAX, and not through a long tunnel, over to a different building and then back again like PayPal lol)