PHP and Java are processed Server-Side. JavaScript is processed by the web browser.
If you were processing in real-time with PHP, you would need a piece of JavaScript (such as an AJAX POST) to send the entire chunk of code to the server for re-processing, wait for a return and then replace the entire display with newly formatted text every time a user changes a single character.

JavaScript can do this all itself directly in the web browser and leverage the power of the User’s PC to accomplish the task.

Using JavaScript speeds up the process as nothing ends to be passed backwards and forwards all the time, it lowers bandwidth usage as nothing is passed to and fro and it also reduces the server workload for the same reason.

There is also an argument that it is more reliable and secure. If you are not passing anything back to a server, there is no need to worry as much about properly “escaping” special characters, less of a concern about an insecure piece of server-side code being exploited etc.

It is also good practise to not send anything back and put a load on your server unless there is a good reason to do so.

While you could have a button on your “code editor” which would send an entire chunk of script back to a server for processing and send back a formatted return, it’s generally not the done thing for the reason stated above. Also, a “reformat all” button wouldn’t add much value as you can simply reformat everything in JavaScript.

PHP or Java Servlets are purely server-sided technologies. They can’t do anything unless the user clicks on a link. When you want any interactivity while the website is displayed, you need Javascript, at least for an AJAX call to a PHP/JSP backend.

When you want an application like a code editor the user is interacting with very closely, you want as much of it as possible to run on the user machine. This improves the user experience due to better responsiveness and means less strain on your server resources. When you want a rich application in a web browser, you can either use plugins like Flash, Silverlight or Java applets the user might or might not have installed, up-to-date and enabled. Or you can just use Javascript which – thanks to HTML5 – became almost as powerful as the plugin solutions.

Besides those facts mentioned already, I would like to add that at the heart of all major browsers there is a powerful EcmaScript/JavaScript engine, incredibly improved by years and years of evolution of the Web.

Therefore all major browsers natively speak this language and are capable of running programs in it in the most efficient way. Why in the world would you use something else to write a client-side program intended to run within one of these beasts?

Even when the browsers only speak this language is not like you are forced to use JavaScript to write your programs. Over the years several other languages have been created to try to replace or “improve” JavaScript. You could write your programs in one of these languages and then a compiler translates your code to JavaScript in order to run it in the browser, which is ultimately, what the browser understands.

Examples of these alternative languages are the now decadent GWT which translates Java to JavaScript. Other more modern approaches like CoffeeScript and more recently TypeScript. With the renewd popularity of functional programming these days we have seen the appearance of ClojureScript and Google has not gotten tired of failing trying to dethrone JavaScript and created the awesome Dart programming language for that matter (even one of their browsers named Dartium has a native engine for it). And believe me, Google is not done failing and as we talk they are already working in another one of these called AtScript. Finally, now thanks to the effort in Emscripten you can even port your programs from C/C++. All of these are languages that are ultimately complied to JavaScript in order to run the code in the browser.

So, as you can see it is not like you are forced to “write” your client-side programs in JavaScript, you are just forced to “run” them in JavaScript because that is what most browsers understand.