 So, we start off with discussing what is actually a web application versus a website. And there has been a question in previous lectures, for example, because sometimes I use these words interchangeably. And one of the sources, if you look at Wikipedia, basically says the general distinction between having a web page that's dynamic and a web application is not really so clear. And this is exactly why these words are used interchangeably. But websites are most likely to be referred as web applications, other ones that basically have a similar functionality to a desktop software application. So for example, if you would take, let's say Google Docs, which is similar to Word, you would definitely call it a web application. Whereas a small website that describes, I don't know, your personal website describes yourself and basically maybe your CV or so on would be a website. So this is not clear, it's not entirely clear cut the distinction, but in this course we use the definition, the web application is a dynamic website with a functionality similar to desktop software. And this is good enough to work within this course. So generally, when I refer to a web application, I mean something that's a bit more substantial than just content. Now as a reminder, we've covered how client and server are distinguished and how the client can send a request to the server. For example, we can send a get request to get the URL description of Wikipedia. And then at some point we get a response, hopefully we get a status code 200, everything is okay. And we get the document we want to read. Now generally, everything that is on the client here is described as the client side, which of course makes sense from the terminology or sometimes also as the front end. So it's the stuff that is in the front towards the client basically. Whereas everything that is on the server is on the server side, it's in the back end. And of course this, remember this is a simplified view, quite often you have multiple servers. So you could have an application server, a web server, a database server and so on. But all of that together is referred to as the server side. And what this generally means is if you have something that is on client side, it means logic is executed on the client in the browser. It happens after the server has returned a page and that means that the server also has to send all of this logic. So for example, JavaScript is a typical, originally is a typical client side language. And that means that all the JavaScript is executed in the browser. And this also means that the server has to send the JavaScript file to the client. The client can basically look at it. And of course on the server side it looks opposite that the code, the logic, whatever we have is executed on the server before the response is sent back. And this means that for example you could execute some logic and depending on what happens you send back different HTML code or different pictures or whatever. And typical language is for this is the classical one I would say is PHP, but also things such as Java, Java server pages and so on. And nowadays, and this is also what we cover in this course, there is also JavaScript in the back end. But the basic principle is everything is executed and then something is sent back. And if we compare this or summarize this, a client side web application is an application that uses client side languages. So for example, JavaScript in the browser, whereas a server side web application would use server side languages and execute the code on the server side. But of course, this is not very clear cut because you could have both. I could have some PHP scripts here. I could have some JavaScript that runs on the server. Then I could still send some JavaScript to the browser. So typically I would say you have applications that are both containing client side and web and server side code. And this means typically you don't talk about what kind of application is it, but you rather talk about where is my code executed. So you talk about, okay, this script is client side executed. It's stuff that runs in the browser. Whereas maybe some of this code is in the back end, it's server side executed. So typically you talk about the execution. You do not talk that much about is it a client or a server side application. Because in most cases, it's both. Now, why do we have this distinction? Or why is it important to think about it? There are certain advantages and disadvantages with both approaches. And if we look at the server side execution, the good thing is the code is private. Because it's executed on the server, you only send results back. That means the client never sees your code. And that can have certain advantages. For example, the client is not able to change the code. Whenever you send something back to the client, technically they can do whatever they want with it. Because it's saved on their machine. The other thing is in JavaScript, for instance, we look at different versions. And you also remember from HTML and CSS that there is a history. And we have to support all different versions. If you run your code on the server, you can specifically define which version you are installing. And that means whatever code you write, you don't have to be as careful that it's compatible with different versions of your language. So you can enforce a specific version. This means that you can typically use non-standard language elements. So you can use elements that are not available everywhere. And also, you can actually access server-side resources. So for example, the database. This is, of course, one of the main advantages why this is used. Because you would like to directly access your data, different applications, and so on. So this is the server side execution. The client-side execution then means, of course, the code is public. We have to send it back. This is typically happening through a GET request. And then the server sends a response with, for example, the JavaScript file. And this means you can change the code. This is, remember, similar to cookies or cascading style sheets, where in my browser, during the runtime, basically while my website is visible, I can change things. This is usually OK, but still, you have to be aware of it. Plus, if you have lots of vulnerabilities in your code, they're directly being exposed. You have to be compatible with different browsers and language versions, because you're never sure what your client has running on his or her machine. One of the big advantages, and this is why it's getting, why it is popular, is that it lowers the execution load on the server. So the client executes all the logic and assume you have a script that takes five seconds to execute. If you send this to a million clients, then it takes each client five seconds. If you run the code a million times on your server, then the server has all of the load added, basically. So in a way, by distributing the code to the client, it might run a bit slower there, but it scales. It scales much better. This, of course, comes at the cost of network traffic. So if you have to send the script to the user, you have to send the response. And nowadays, scripts can be quite large, so this adds up to the network traffic, actually. Whereas on the server side, you send the request, all the execution happens on the server, and then you only get the result back, which is typically much, much smaller than sending all the scripts to the client as well. So this is a little bit the distinction between client-side, server-side applications, or rather, as we said, client-server-side execution of languages of code.