Ei Maung’s Blog

In my previous post, I wrote about breaking the rule in using requests. How many things we are not clearly understood in web standard? This time, I try to learn another standard. What is difference between SESSION and COOKIE? I thought I knew it, but actually not. I made some Googling. And here are the results…

HTTP is a stateless protocol

HTTP is stateless protocol. A stateless server is a serve that treats each request as an independent transaction that is unrelated to any previous request.

That mean, the request you make doesn’t associate in any way with the previous one. So, how about the request we want to make frequently, like user name or id? As you know, we could store our data in COOKIE. When we store data in COOKIE, the browser will send the cookie data to server for each request. We already could use SESSION for this kind of task. So, what is difference between SESSION and COOKIE?

COOKIE
A cookie is a text-only string that takes a place in the memory of user’s browser. If the lifetime of the cookie is set to be longer than the time user spends at that site, then this string is saved to file for future reference. User could be disabled the cookie in their browser setting.

SESSION
Session values are store in server side not in user’s machine. A session is available as long as the browser is opened. User couldn’t be disabled the session. We could store not only strings but also objects in session.

The Differences
We got three differences in general. The key difference would be cookies are stored in client side and sessions are stored in server side. The second difference would be cookies can only store strings. We can store our objects in sessions. Storing objects in sessions were really useful according to my experience. Another difference was that we could be save cookie for future reference, but session couldn’t. When users close their browser, they also lost the session.

Compiled Languages
Computers do not actually understand the code we write. We need to translate our human-readable code to machine-readable code. Our code need to be translated into bits and bytes that can be executed by computers. This translation process is called compilation. Languages that require compilation are called compiled languages. C, C++ and Java are compiled languages.

Scripting Languages
Languages that not require compilation are called scripting languages. Perl, PHP, Python and Ruby are scripting languages. Those languages rely on our source-code all the time. Scripting languages didn’t have compiler or a compilation process. Those languages used interpreters to translate our source-code to machine executable code on the fly.

Compiled Languages vs. Scripting Languages
Mostly, we have been using compiled languages like C, C++, Java and Visual Basic. Java has an interpreter but it need to compile first. Earlier versions of Visual Basic were interpreted. Visual Basic 5 and later came with compiler. So Java and Visual Basic should be called as compiled languages.

Imagine; you wrote an application with Java. Then you compile your application with javac. After compiling completed, you run your application. When running your application, you notice a bug. To fix it, you have to stop your application, go back to source code, fix the bug, wait for the code to recompile, and restart your application to confirm that it is fixed. And if you find another bug, you’ll need to repeat that process again.

In a scripting language, you can fix the bug and just need to reload your application —no need to restart or recompile anymore. It’s as simple as that.

But, the scripting languages have a big performance problem. Translating on the fly can affect the application’s performance. Typically, the pre-compiled code is faster than on the fly translating. But, good news is, there are ways to speed up scripted languages, including techniques such as code caching and persistent interpreters.