Why use Javascript if there are so many other technologies to generate dynamic content?

Question

Specialized technologies and programming languages for the Web, such as PHP, have as part of their set of roles, generate dynamic HTML content (the page will be presented by the browser according to various conditions). And there are several technologies that make pages very dynamic: PHP itself, Java Servlets and JSP, Perl CGI, ASP.NET, etc...

And this Javascript was made to run in browsers to generate dynamic pages.

The question is: If these server-side running technologies already add so much dynamism to the pages, then why Javascript?

Answer 1

Differences

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

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

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

Server-Side basically is:

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

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

• Interactions with mouse, keyboard.
• Animations, drag in drop, sliders.
• Requisitions ajax.
• Diomic 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 Client-Side, although the vast majority of its use is for this purpose. Nowadays the same is also used as a Server-Side language, see the example of Node.JS, and even for some applications.

Follows a great article of Diego Eis do Tableless commenting on the Client-Side layers for the web.

One language completes another and vice versa like beans with rice.

Server-side

The server language, or server-side scripting, is the language that will run "behind the scenes", providing the main logic of the application. It works like this: 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 requirement (Request) and do the processing. Then, transform the final result in an XHTML and send to the browser. It is the server-side language that will check if the user is logged in, will fetch information on database etc.

How the server-side language processes requests before sending to the browser, it means that a once the page has been sent to the user’s browser, there is nothing else that the server-side language can do until a new "Request" is sent. That is, it is not possible to use these languages to manipulate the user page in real time. For the user, the language server-side doesn’t matter, and he can’t even 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, i.e., on the user’s own computer, and is therefore used in situations where the server-side language has no range. Among the client-side languages, there is Javascript, which is the only language that actually runs in the user’s browser. Using Javascript, it is possible to manipulate the user’s page directly, doing dynamic things ranging from changing the value of a form field to creating a resizable area that can be dragged by the page.

As 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 the languages client-side are insecure to do things like access a bank data. Together, the server-side and client-side languages become complement. (Wikipedia)

Answer 2

Your question already answers.

There are several reasons, I will quote only the main.

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

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

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

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

Answer 3

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.

Answer 4

I think a very complete answer was formulated by one of the founders of the Stack Exchange network, Jeff Atwood, in the article Javascript, the free language of the Web.

Selected tickets:

Radically open source, viral nature from the "View Source Code" menu is certainly 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 the client machines; so much power, in fact, that even a dynamic and interpreted language like Javascript can be a reliable development environment client side.

^[...]

In spite of all the pretenders to the throne, Javascript will not be leaving any time soon because its computing time is the most ubiquitous in the world. It’s time we learn to accept and adopt Javascript instead of fighting it blindly. That doesn’t mean we can’t explore alternatives -- but the best way to transcend Javascript’s limitations 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 of the Web. The danger of ignoring it is totally yours.

^[...]

There are exciting alternatives to Javascript on the horizon. Some will succeed, others will not. Amid all the commotion about new tools and options, do not forget that the Javascript remains an excellent choice for developing rich internet Applications -- and, as a lingua franca of the Web, its success is guaranteed.

---

And for those who want to follow Jeff’s trajectory and his relationship with Javascript, I recommend studying his new venture: Discourse, an open source Forums tool. It’s practically the same technical/sociological concept behind the Stack Overflow, but applied to discussion in forum format.

Answer 5

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

Answer 6

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

• Fast response time for GUI operations

• Save bandwidth from both user and server

Reasons to use javascript in general:

• widely used, therefore the support is guaranteed

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