Use JS to relieve PHP

In my view, the question is about using javascript to do the PHP work. A request made with ajax can return data formatted in back-end or it can receive a json and format for composition of a view. My answer is based on this assumption.

I will give as an example a simple request containing an array of 2 indexes, only first and last name and formats in JSON , XML and HTML for comparison purposes only.

DATA

 array( array( 'Papa' , 'Charlie' ) , array( 'Papa' , 'Charlie' ) )

JSON

LENGTH : 39
STING  : [["Papa","Charlie"],["Papa","Charlie"]]

XML

LENGTH : 191
STING  : <usuarios>
             <usuario><name>Papa</name><lastname>Charlie</lastname></usuario>
             <usuario><name>Papa</name><lastname>Charlie</lastname></usuario>
         </usuarios>

HTML

LENGTH : 66
STING  : <div>Papa</div><div>Charlie</div><div>Papa</div><div>Charlie</div>

An output in HTML will use the server to process the data, and you can display the data using simple functions. It may be the best option when having little data flow or for those who are not so familiar with javascript. On the other hand, we have a greater flow of data and can make the application more secure.

Data in JSON is easy to work with type object , in addition to having a much shorter length than other formats, and this is an interesting point for bandwidth savings. JSON and XML are more flexible and simple to implement webservices, APPs, desktop, mobile devices ...

I did not find a benchmark of respect that I could use as a comparison effect, but I do not see such a major drawback in processing time between PHP and javascript that it implies as a deciding factor for change. In fact PHP consumes more resources to build the HTML, while the javascript composes with low cost. But to answer which one to use or when, depends on the need - reduce traffic, flexibilizar the application to other platforms ... I think they are points of greater importance in the choice.

Some interesting references

• Why is it bad practice to return HTML instead of JSON? Or is it?

AJAX - Using JSON vs. echo HTML

• Why Facebook, Twitter and GMail render all their date to the browser as JSON as opposed to HTML?

• PHP vs. node.js: The REAL statistics

• The AJAX response: XML, HTML, or JSON?

• Creating HTML: PHP server-side vs. jQuery clie

Hello.

First of all, let me start by mentioning a little something that people usually say or think when they come across such questions:

JavaScript Although it is one of the main web languages, you can never replace PHP in a web application that wants to maintain the total integrity of the data that goes from the client to the server and vice versa (< a href="http://en.wikipedia.org/wiki/JavaScript"> read this if you think I'm wrong).

Another thing is, alleviate with Javascript , it is nothing more than pre validate data before being sent to the server according to your question.

Then you have the principle of validating with Javascript and then re-validating with PHP or another language that is acting on the server side. Even framework does this, but in another way.

In the end I do not know if I answered your question, but I hope you understand that Javascript should never replace PHP, try to make your server-side script more efficient.

Validations must be done in PHP (server side) regardless of what happens on the client side (js, html).

To "ease" processes, it is advisable to apply JavaScript validations to avoid requests to the server.

Examples: Validate email format Validate number of characters Validate data only numeric or only letters

It's worth stressing again that regardless of whether there are validations on the client side with JavaScript, the same validations must be done on the server side with PHP.

"Relief" is also useful for accessibility. For the user on the client side, it is visually better and more performative.

TL; DR: It depends a lot on your application and the cost benefit of switching functionality to the front end.

Using JavaScript to ease the backend is good. But whether you should use or not depends a lot on your application, if you have an application that is slow in the back end, it pays to leave more tasks for the front end. If you have a small application that is generating documents on the back end without any performance issues, you may not need to modify it and start using JS.

One must take into consideration the work that will change the application and how much it will imply in the performance. If it is a major modification, it will take many hours of work and that will remove little load from the back end, so it is not worth it. On the contrary if the modification is not so complex, but rather relieving the server then it is worth doing.

As already mentioned in other answers here, tasks like data validation should always be done in the back end, can be done in the front end to give faster feedback to the user, but should be redone in the back end to check the integrity of the data, since if the data is validated only front-end would create the possibility of a malicious user to disable JavaScript and make a site attack such as a SQL Injection .

Another important point is that more and more cloud computing services are being used for hosting, these services usually charge for usage time and / or CPU usage, so the less processing is used, the more economical it gets. So the more functions you give the front end and the cheaper back-end, the service will be.

To play firewood on the fire, I can do a client-side "CLEAN" code until I get to the server side, and continuing to program javascript on the server side just use nodeJs .

  

link

So the question of validating on the server side or on the client side will depend on what you are validating, if it is something that will not compromise the of a database , or leave a client-side javascript where it can override a function to change something in such cases leave everything on the server side.

But a type validation type your login which is the email, and a function that checks if the email has an @ in the middle of the string, in which case I can quietly play this on the client side.