I understand that the question does not specifically concern the Javascript language but rather the concept of running a language in the client, specifically in a web browser. In this sense, it seems that the answers were straight to the point.
There are several reasons why someone wants to run a language on client. Some are legitimate, some are not.
Usability, Interactivity, User Experience
Happy user keeps using the system and values the business.
- Validation during completion, with feedback immediate.
- 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 those who access a page. A news site, a photo gallery, all this is much better with Javascript.
For many this may seem like something sup,rfluo. If you think so, argue with the founders of Google, Amazon, Facebook, Microsoft, Apple, etc.
Integration with local resources
Another area not so explored is access to local resources, that is, that are on the user station. Examples are digitizers, barcode readers, mouse and keyboard.
Of course in most cases Javascript is not enough for this, but I am referring to browser plugins or Activex components, for example.
Load balancing
More recently, with the rise of CSS, HTML5 and faster and more powerful browsers, many RIA applications have begun to emerge (Rich Internet Application), that is, that begin to bring much of the processing previously carried out only on the server back to the client.
The centralization of processing seems to fluctuate over the years. First of all everything was processed in one mainframe and accessed via "dumb" stations. Then came the desktop and everything started to be distributed in the clients. Then came the web and took the opposite direction. We return to the "smart" server and the stations that only display and send data. Currently, we are at a more balanced point. Most of the business rules run on the server, but the stations are increasingly "smart" in the sense that they are interactive and rich visually and in functionality.
We have as good examples of this technologies as Google GWT or Cappuccino.
A GWT project, for example, is implemented in Java and has two main packages: client and server. The part client is converted into javascript and runs in the browser, usually responsible for all the visual and 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 user response 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 a language called Objective-J, which is a mixture of Javascript and Objective-C, to generate a rich application. The back-end or server should use some language to allow data communication and persistence, but the implementation is independent of that layer.
Javascript serves to give more dynamism, effects, control and agility to pages. For example, a site has to be doing a full page request all the time and let’s say very heavy to the server, when it was necessary to update a small div with information of only 2 fields (value1 + value2). This is something extremely costly to the server. In javascript, vc solves this. There are other cases q js helps with ajax
– Tafarel Chicotti
So I think I understand: Each side has its own responsibility. The answer was satisfied. Thank you to the few who answered and sorry for the bias that I include in the question.
– Sid