Web Development

Built by maltpress

How to buy your website, part II – how the web works

Welcome to part II of our series on how to buy your website. Last time, we talked about the first step – working out what you need. You should now have a rough list of ideas, links and suggestions from your customers – hang on to those. Today we’ll be taking a tiny diversion to look at how the web actually works. You might be able to skip this if you know a bit about websites.

So, at this stage you should have a reasonable idea of what – ideally – you’d like from your future website. Hopefully you’re getting excited about some of the possibilites as well. Perhaps you’re starting to wonder when we’ll start talking about the scary money bits. Not quite yet, although I’ll mention them today. The best thing to do is start from what you ideally want, and – for now – forget about money. It’s entirely possible you’ll be pleasantly surprised. I’ve spoken to designers and developers before who’ve been told that – from the look of their sites – they’ll be “too expensive” for a particular client, who’s never really asked how much the work might cost. You could potentially miss out on someone who’s a perfect match for you because you think they’re too good for you. But before we get that far, I’ve decided we need to talk technology. Why? Because you need to know what you need, and why it costs what it costs. Hopefully it’ll make things a little simpler later on if you have a basic understanding. I’m trying to strike that fine line between too complex and patronising – don’t take offence if I’m oversimplifying things, and techies – sorry if this is too over simple for you!

Techy bit… but not too techy.

Websites can be built on what’s called “server-side” or “client-side” technologies. Why’s this important to you? Well, the technology used to build a site will – to some extent – determine who’s best to build it for you. Knowing how it works will also help you when you look for hosting. Don’t know what hosting is? This will explain that too.

For both client-side and server-side, the first step is the same. When you type an address into your browser (Internet Explorer or Firefox, for example) and hit return, the browser sends this request into the internet. As an example, let’s use A computer called a domain name server (DNS) looks at the first part – the – and works out which server to send this request to. A server is basically a computer; it’s got a load of files on it and can run programmes.

For a client-side site, the server looks at the second part of the address – /test/page – and uses this to find the right file. First it looks for a folder called test, then – inside that – for a folder called page. In most cases it’ll then look for a file called index.html inside that folder and see what other bits that file asks for – images and style sheets etc. Once it’s found them, it’ll send the whole shebang to your browser… effectively telling it “well, here’s the stuff you wanted. Do what you want – I’m out of here”. The browser will then look at the HTML and show it to you, using the style sheets to work out how big letters should be, what colour things are, and so on.

This is pretty simple. You make your HTML and style sheets (CSS files), pop them on a server (like moving your files around on your PC, effectively) and you’re up and running. You can do it on your own PC if you want. Of course, it takes skill and experience to turn a design into good HTML and CSS – and believe me, there’s a world of difference between good and bad HTML – but that’s the basics.

Now, for server-side things get a bit more complex. Still with me? Good. Have some tea and a biscuit. Here we go.

When the server gets the second part of the address for a server-side site, it does similar things to above (techies only – I know, I know, re-writes and .htdocs and all that…). But this time, when it’s looked in test, found the page directory, and found index.php or index.asp (don’t worry about the difference just yet), it does something more. That file will tell the server it’s got more work to do. It’ll need to pull some information from another couple of files, maybe, and take the content from a database (a database is just a place to store big blobs of completely unformatted data ready to do things with them). Then the server will follow the instructions in these files, stitch it all together, and will create the HTML page before sending it to your browser to do the display stuff. That’s the big difference. For the most part, the HTML – the bit your browser reads, and the bit transmitted to it over the internet – only exists when it needs to.

So what? Well, it means we can do clever things, and we can do them “on the fly”. The server can be told who’s visiting, for example, and give them particular content. More importantly, you can easily write to a database through a web page, so you can store stuff… which is how content management works. So you can update your site without needing to know any HTML. You put your text into a form, that form stores it to a database, and when the visitor comes along, the text is pulled back out of the database and shown to them.

Making a server-side site is a bit more complex than before. You still need to have the HTML and the CSS – but you also need to know how to pull these apart to reuse common bits, and how all the database stuff works. You need a server which can do all the stitching together. You need a database server, too. This adds to the cost. Not necessarily much, but it does.

Different strokes…

Earlier I mentioned index.php and index.asp… and I could have mentioned .jsp, .cfm and many more. What are these, then?

They’re languages. Well, more like dialects – they’re all based on English. ASP stands for “Asynchronous Server Pages”, while PHP is a mind-bending recursive acronym which stands for “PHP Hypertext Precusor” where the PHP in that stands for “Personal Home Page”. Eeep. What this means to you is that your server needs to understand one of these languages.

You might have an Apache server, which understands PHP. This is probably most likely. It’s a bit cheaper to run as the software is free. WordPress – which this site is built in – runs in PHP. Lots (although by no means all) of PHP software is free or open-source, which means anyone can modify it, reuse it and so on. This means lots of people could possibly work on one site. However, this could mean bugs get introduced or security isn’t as amazingly tight as non open-source software. You can get PHP as secure as ASP though, and bugs are squashed quicker in open-source software as lots of people can look for them.

You might have a Windows server, which understands ASP (and its big brother, .NET) and can be taught to understand PHP. It’s a bit more pricey, but bigger organisations will use it because it’s better at talking to their existing servers and software. ASP software is often expensive, and people can be very protective (with good reason) of their work, so if someone builds you a site in ASP it’s unlikely someone else will be allowed to re-use any of that code.

Relating it all back to developers…

So now we get to what this means to you.

  • If you want a flat site (remember them from last time?) all you’ll need is someone good at HTML and CSS. Most developers will know these bits. In agencies you might get team members who concentrate on these bits, and they’ll be damn good at them. Javascript kind of fits in here, too… this (and Flash) is what does anything on a site which moves, changes colour, pops up, jiggles around or directly interacts with you without pages reloading. So a flat site doesn’t necessarily have to be “flat” as in not jiggling around.
  • If you want a dynamic site, you’ll need the right server (your web agency can help you with this) and to pick a language. For you, PHP is probably best, unless someone else can convince you otherwise. Then you’ll need to find a developer who works in that language. Again, at an agency you’ll find that there are people who specialise in this… they might not be allowed to talk to clients, though, for fear of scaring you off.
  • A dynamic site is quite a bit more complicated than a flat one, so there’s quite a leap from a flat site to putting it all into a content management system. It’s not just a case of copying some files or turning something on… it could mean effectively rebuilding the site and then some. So try to avoid using a flat HTML site as a stop-gap before you can get a content managed one. It’ll cost you a lot more.

Future articles in this series will refer back to this post. For now, though, you should have a better idea of how the web works… if you’ve got any questions or comments, please let me have them below! Next time we’ll take a look at who you’re going to have to think about hiring – developers, designers, project managers and more.

Footnote: the difference between good and bad code is basically this (and this is a debate for the developers, too)…. Good code will keep working when new versions of browsers come out, because it complies to certain agreed-upon standards. It works quickly, doesn’t slow your computer or the server, and if it breaks, it does so nicely so you can still do stuff. It’s also easier for someone else to come in and work on good code (if your developer retires or moves away) than it is bad. It’s like plumbing or building. Avoid the cowboys.

Back to blog

One response

Diana Probst

May 24, 2011 at 7:08 pm

That was fantastic clarity, and good to read. Thank you for putting it out in the world; it was a good lesson for me.


Leave a comment

By using this site you consent to our use of cookies. To find out more, see our privacy policy. Continue