Differences

There is a difference between languages, each one has its reach and so can do specific things.

For example in JavaScript because it is a Client-Side language you could not make a secure connection to the database because your JavaScript is public, and everyone could observe your database server credentials. This is the responsibility of the Server-Side language.

On Server-side, the client does not have access to the code, everything that is there is confidential, all its business logic, access, credentials, and so on. Imagine if Google develops all the algorithms and business logic in JavaScript, everyone would know the big secret, right?

Server-Side is basically:

• PHP, ASP.NET, etc.
• Business logic.
• Access to the database.
• Request and render.

Server-side languages act at the beginning of the Request until the HTML rendering of the page, since Client-Side languages act after rendering, basically:

• Interactions with mouse, keyboard.
• Animations, drag in drop , sliders .
• Requests ajax .
• Diary form validations (you can validate the fields without having to make a new request).

  

Note: Note that the JavaScript language is not exclusive and is not limited to the   Client-Side, although the vast majority of its use is for this purpose. Nowadays the same   is also used as Server-Side language, see the example of    Node.JS , and even for some applications.

Follow a great layers by Diego Eis Tableless commenting the Client-Side layers for the web.

A language that completes another and vice versa than beans or rice .

Server-side

  

The server language, or Server-side scripting, is the language that   will run "behind the scenes", providing the main logic of   application. It works as follows: whenever the user makes a   HTTP request (enters a page, clicks a link, etc), the request is   sent to the server. The server-side language receives the request   (Request) and does the processing. Then, it transforms the final result   in an XHTML and sends it to the browser. It is the server-side language that   will check if the user is logged in, will get information in the   database etc.

     

How the server-side language processes the   requisitions before sending to the browser, this means that a   Once the page has been sent to the user's browser, there is nothing left   that the server-side language can do until a new "Request" is   Sent. That is, you can not use these languages to manipulate   the user page in real time. For the user, the language   server-side does not matter, and he has no way to figure out which language   is being used. (Wikipedia)

Client-side

  

The client language, or client-side scripting, is the language that runs on the client side, that is, on the user's own computer, and is therefore used in situations where the server-side language has no reach . Among client-side languages, there is JavaScript, which is the only language that actually runs in the user's browser. Through JavaScript it is possible to manipulate the user page directly, doing dynamic things ranging from changing the value of a form field to creating a resizable area that can be dragged across the page.

     

Since all JavaScript code is in the browser itself, the user   can see the code and can also, through the use of some   programs, manipulate the code. This makes   clients are insecure to do things like accessing a database   data. Together, server-side and client-side languages   complement. (Wikipedia)

Your question is already answered.

There are several reasons, I will cite only the main one.

Because it runs on the client, javascript does not require constant access to the server.

If you do everything on the server, it should populate low granularity requests (type requests to know if the user has entered a field). Now imagine a system with 2 billion users (like facebook). Certainly the server would need triple the power to support so many requests.

So it's interesting to use javascript to balance the processing between the client and the server.

EDIT: I could talk about features like ajax Cross-Domain and CORS . But I'll leave just a few references.

I understand that the question does not refer specifically to the Javascript language, but rather to the concept of running a language on the client, specifically in a web browser. In that sense, it seems that the answers went straight to the point.

There are several reasons why someone wants to run a language in client . Some are legitimate, others are not.

Usability, Interactivity, User Experience

Happy user continues to use the system and values the business.

• Immediate feedback
• Asynchronous information updates without user action.
• Interactivity: drag and drop, small animations, etc.
• User assistance, allowing you to perform actions with less effort: auto-complete fields, interactive menus, sliders , etc.

All this makes a lot of difference to whoever accesses a page. A news site, a photo gallery, all of this gets a lot better with Javascript.

For many this may seem like something superfluous. If you find this, argue with the founders of Google, Amazon, Facebook, Microsoft, Apple, etc.

Integration with local resources

Another area not so exploited is access to local resources, that is, they are in the user's station. Examples are scanners, bar code readers, mouse and keyboard.

Of course in most cases Javascript is not enough for this, but I'm referring to browser plugins or ActiveX components, for example.

Load balancing

More recently, with the rise of CSS, HTML5 and more powerful and fast browsers, many Rich Internet Application (RIA) applications have started to emerge, that is, they start to bring in much of the processing previously performed only on the server again for the client.

Centralization of processing seems to oscillate over the years. First everything was rendered in a mainframe and accessed via "dumb" stations. Then came the desktop and everything went to be distributed to the clients. Then came the web and went the other way. We go back to the "smart" server and the stations that only display and send data. We are at a more balanced point today. Most business rules run on the server, but the stations are increasingly "smart" in the sense that they are interactive and visually rich in functionality.

We have such good examples of such technologies as Google GWT or Cappuccino .

A GWT project, for example, is implemented in Java and has two main packages: client and server . The client part is converted to javascript and runs in the browser, usually responsible for all visual part and for RPC calls via interfaces to the part that is in the server . Virtually all Google products like Gmail, Drive and Calendar use this technology. The response to the user is much faster and the server is used for what really matters.

The Cappuccino project is a framework that almost totally abstracts the development of a web system. You develop in a language called Objective-J, which is a mixture of Javascript with Objective-C, to generate a rich application. The back-end or server should use some language to allow communication and data persistence, but the implementation is independent of this layer.

I think a very complete answer was made by one of the founders of the Stack Exchange network, Jeff Atwood >, in JavaScript, the lingua franca of the Web .

Selected Tickets:

  

Radically open source, viral nature from the "View Source" menu is certainly a an essential part of the Web's success. But that's only part of the story. The growing maturity of JavaScript implementation in modern browsers is the foundation of the present and future of the Web .

[...]

  

Regardless of the original feelings against language, JavaScript has come a long way since the bad old days of 1995. Now we have CPU power to burn on client machines; so much power, in fact, that even a dynamic and interpreted language like JavaScript can be a trustworthy environment for client side development.

[...]

  

Despite all the pretenders to the throne, JavaScript will not go away anytime soon because its computing time is the most ubiquitous in the world. It's time we learned to accept and adopt JavaScript instead of blindly fighting it. This does not mean that we can not explore alternatives - but the best way to transcend the limitations of JavaScript is to dive into those same limitations. That way, at least you know what you're fighting for, and what the alternatives really mean.

[...]

  

JavaScript is the lingua franca from the Web. The danger of ignoring it is entirely up to you.

[...]

  

There are exciting alternatives to JavaScript on the horizon. Some will succeed, some will not. Amid all the turmoil about new tools and options, do not forget that JavaScript remains an excellent choice for the development of rich internet applications - and, as the lingua franca of Web, your success is guaranteed .

And for those of you who want to follow Jeff's trajectory and its relationship to JavaScript, I recommend studying your new venture: Discourse , a tool for open source Forums. It's pretty much the same technical / sociological concept behind Stack Overflow, but applied to the discussion in the forum format.

All the languages mentioned, to become dynamic for the user make use of JavaScript, otherwise, they are pages that are generated dynamically, but do not have that dynamicity in the eyes of the user.

Reasons I consider the main ones, as a result of javascript being able to run on the client:

• Quick response time for GUI operations

• Save both user and server bandwidth

Reasons to use javascript in general:

• Widely used, so support is guaranteed

• It has a multitude of tools and libraries, which allows you to do almost everything you imagine