Editor’s note: This is part 2 of a guest post by Bryan J. Brown. You can read part 1, The Basics, here.

After learning HTML and CSS, the next steps on your path to web development greatness depend largely on what you want to do. Depending on your personal and/or professional interests, you should decide whether you want to dive into server-side or client-side scripting (or if you are even interested in going further, HTML and CSS may be all you want). To understand the difference between server-side and client-side code, it’s helpful to know just what happens when you go to a web page.  When you type a URL, you are requesting a specific page from a specific server on the web, and that URL contains that page’s exact location. Let’s use “example.com/index.php”. This URL points to the file “index.php” sitting on the “example.com” server. When the “example.com” server recieves this request, it processes it and responds by sending the requested page’s source code (along with any CSS or JavaScript code associated with it) back to your browser. When there are server-side scripts associated with a web page, the server runs these scripts as part of it’s processing of the request. The script tells the server to do something, and this can be anything from outputting the current date and time to pulling information from a database and outputting it as HTML. This new, dynamically created web page is then sent as the response. If the page has client-side scripts in it, these are sent as part of the server’s response (the server does not process the client side code at all, this is the key difference). When your browser receives the response from the server, it starts building a visual representation from the HTML and CSS (this is what you see in your window) in a process called rendering. Any client-side code is then processed by the browser and applied to the rendering or behavior the page. If you have ever seen moving parts of a web page, such as  buttons that expand or contract, this is client-side code being run directly in the browser.

Image made available by the author under a CC0 1.0 license.

There are many languages that can used for server-side scripting, including (but not limited to): PHP, Python, Ruby, Perl, and Java. None of these languages are “the best”, as they are all good for different situations. For instance, Ruby is a great choice if you want to build a complete web application very quickly (using the Ruby on Rails framework, also called “RoR”) and Java is extremely mature and reliable. The most popular server-side scripting language is PHP, and if you are interested in learning about server-side scripting then PHP is definitely a good language to start with. PHP runs more websites than any other language, and is the most marketable server-side language to know. It is the most simple of the server-side languages because it was created specifically for the web (the other languages are general purpose, but can be used for web development). PHP’s popularity also means that it’s available on virtually all servers, and there’s a wealth of help available for newbies all over the web. PHP also has the best manual ever. Unless you have a specific reason to go with a different language, I would highly recommend starting out with PHP. Aside from the awesome documentation, you can also find great tutorials from Zend, Codecademy, and W3Schools.

Server-side scripts also commonly make use of databases to create full-blown web applications. A classic example of this concept in action is a form. You enter your information into a form and hit “Submit”, and a server-side script saves all of that information to a database and then dynamically produces a new page with all of your information on it. Most databases use a language called SQL for manipulating, storing and retrieving data, and different pieces of database software can be used almost interchangeably once you understand SQL.  You can find good tutorials for learning SQL at W3Schools and SQL Zoo (my favorite). The most popular database software for web apps by far is MySQL, but of course there are many others as well. PHP and MySQL go together like peanut butter and jelly, and are the foundation of many well known web applications like Omeka, WordPress and Drupal. A combination of a server-side scripting language and supporting database software is called a “stack”, and the LAMP stack (for Linux, Apache, MySQL and PHP) is the elephant in the room when it comes to web development.

Client-side scripting is the other side of the web development coin. Historically there have been many different languages for client-side scripting (like Adobe Flash or VBScript) but those languages are dying, if not already dead. JavaScript is the only modern client-side language worth learning, especially now that HTML5 makes use of it exclusively for many of it’s groundbreaking new features (and despite it’s name, it has nothing to do with Java). This makes client-side scripting especially attractive for newbie web developers since there is really only one language to know and grow with. Instead of being faced with lots of different server-side scripting languages, client-side developers just have to know JavaScript, and JavaScript works the same no matter what server-side language is serving it. JavaScript has many supporting libraries that can be used to make development easier so you don’t end up reinventing the wheel every time you build a web page.

A popular example of a JavaScript library is jQuery, which is great for adding drag-and-drop functionality and moving elements to a web page. Another benefit of learning JavaScript is the abundance of tools for working with it. JavaScript has gone from black sheep to  rock star in the past few years, and as a result almost every browser has built in tools for debugging and testing JavaScript (this isn’t possible with server-side scripts since they don’t get sent to the browser). I can say from experience that learning to use these browser tools has drastically improved my understanding of how browsers make use of JavaScript, so if client-side scripting sounds cool to you, check your favorite browser to start looking at the scripts used on your favorite websites. To learn how to code up some fresh JavaScript yourself, check out HTML Dog, W3Schools, and Codecademy (which also has good lessons for jQuery, as well as lessons for putting it all together). Mozilla also has great resources for learning to use JavaScript (and other things, too).

Moving Forward

So now that you know the differences between server-side and client-side scripting, which one should you pick, if any? Whichever one you think will be more applicable to your career. For instance, I work with an archival system that uses PHP to edit and display manuscript metadata which is stored in a MySQL database. This knowledge also crosses over to my work with Omeka and WordPress which also run on PHP and MySQL. The more I learn about the PHP/MySQL stack, the better I become at my job.  If you work in a department that uses a specific language, get to know that language and the systems that use it. If you don’t have access to the server, or you just want to spend time with a language that you can use on any system, then JavaScript is a great choice (especially if you are more artistically oriented, JS can add a great “wow!” factor to your pages). If you have absolutely no idea what you want to learn, research them all and pick the one that sounds the coolest to you. If you have absolutely no interest in learning to program, then just learn HTML/CSS and leave the rest to someone else (code written by people who hate coding usually stinks anyway).

The best tip I can give you is to pick a language and stick with it. You will be tempted to switch gears and start learning something totally different, but you should only do this if you have a very good reason (like needing to know it for work). Things you learn about one language commonly apply to all languages (they all have different variations on the same logical themes), so if you stick it out with JavaScript or PHP and become really good at it, other languages will come to you easier if you need to learn them. If you switch languages every few weeks, you won’t be able to do anything meaningful in any of them (being able to print “Hello World” does NOT mean you can list a language on your resume). Programming is a lot like music, and languages are like instruments. It’s fun to play around with lots of different instruments, but if you want to be successful you need to pick one and practice all you can. The first instrument you learn can be challenging because you have to learn other things like how to read sheet music and what scales are, but once you know those things and have a firm grounding in music theory, the things you know on one instrument can be applied to others. If you end up wanting to learn another instrument, the second one will be significantly easier to pick up. Music is music no matter what instrument you use to make it, and programming is programming regardless of the language.

So, to sum things up, you should definitely learn to code, but what kind of coding and how much you want to learn are entirely up to you and your situation. There is no “best language” or “best resource”, it all depends on what you want to do and how you prefer to learn. Whether you are learning JavaScript from a book, Ruby from a night class, PHP from a web tutorial or HTML from some YouTube videos, the only path forward in learning is to be consistent, try things on your own and have fun. Try not to take it too seriously. If you are going to keep coding, you have to keep coding fun. Like I said before, no one is expecting you to become a master. There is always more to learn. Knowing a lot about programming is better than just knowing a little bit, but knowing a little bit is light years beyond knowing nothing at all.

Bryan Brown is a second year MLS/MIS student at Indiana University’s School of Informatics and Computing in Bloomington, IN with a focus on digital libraries. He works as a Web Development Assistant at the Lilly Library, and as a Scanning Technician for IUL Digital Collections Services. His professional interests include library metadata, web development and digital preservation, but he also plays a mean banjo. Find out more about him on Twitter (@bryjbrown) or from his blog (www.bryanjbrown.com).