Re: Which Is The Better Approach To Working With Javascript?

Barry wrote:
"The Natural Philosopher" <a@xxx> wrote in message news:1215626765.10535.0@xxxxxxxxxxxxxxxxxxxxxxxxx
Michael Fesser wrote:
.oO(The Natural Philosopher)

Patient Guy wrote:
So, based on your response, you are telling me that a PHP processing implementation has no interprocess communication capability, or ability to interface with a (Java)script interpreter.

Java SCRIPT (as opposed to java) runs in the browser exclusively.
Wrong. Various engines for running JS outside a browser context exist,
as already mentioned in the thread. JS is already incorporated in a
number of applications and document types that have nothing to do with
HTML or a browser.

http://en.wikipedia.org/wiki/Javascript#Uses_outside_web_pages

It makes local decsison without reference to the server. This is great for speed..you can change screen appearance fast and dynamically, producing e.g. drop down menus and the like) at the expense of having to download all the code TO the browser and more data than you probably need.

PHP is EXCLUSIVELY server side
PHP can also run in a browser (a proof-of-concept plugin for IE exists),
on the local machine, as a shell script, with a GUI ... It could even be
used like JS or Python for scripting in standalone applications.

Halfway huse s do exist - Ajax - where partial page reloads are done dynamically, using I think javascipt on e browser and PHP server side.
AJAX has nothing to do with either of them, at least not by definition.
It's just an overestimated hype, but in fact it's nothing new. It's just
a slightly different way for sending HTTP requests, but doesn't say
anything about the language(s) to use or the type of data that's sent.

A plugin or even an external application might be able to access the
browser's XHR object directly without any JavaScript, and the data
doesn't have to be in XML format. So what's left from "AJAX" in
practice? Just the "A" for asynchronous.

A server, or a server-associated process, can start a script host, passing some form of input to it, and the script host does the script interpretation, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface, based on your response.

Oh, its perfectly possible to pass commands from PHP to some other engine: teh classic example is the Mysql server, which is interfaced to PHP with a library ..but no one would ever attempt to execuste java SCRIPT on the server
There's no reason to not do it. And in fact some do.

because its a bloody awful language
Depends. It's a totally different way of thinking and programming. You
simply can't compare it with a classical OOP language. But once you've
understood it, you might find prototype-based programming quite useful
in certain situations.

and is only by and large written for broswers.
No language is written just for a single environment.

Once you are server side you can in principle write in any language you like, PHP being just a common popular one, but shell script python, C, C++. PERL Java and so on are perfectly possible.
Exactly. You can use _every_ programming language you like. And JS
undoubtly _is_ a programming language.

Micha
Strictly you are correct. In practice for most people I stand by the original post.

I see almost no reason to use javascript at all except when its the only option, and that is the case when its the only (well supported) language a browser can run.

Likewise expecting people to have php plugins for their browsers..is..at best, expecting a lot.


Oh, and several languages have been written for a single environment: I wrote one myself in fact.

'several' is not 'one'...and i hardly think anyone but you actually uses your home-brewed version. ;^)

can you name another of the several?

Basically of course not: By definition they were and are specialised things, used in specialised environments. Like macro languages for speialised apps..

Mine went into a product to store commands and data for a large bulb matrix display for a sports arena. No one but me and whoever maintained that code after me knew what it was, since a primitive GUI interface (pre windows here) constructed it, and a bit of 8086 assembler interpreted it and threw high speed serial commands down a piece of wire to the display.

And I never gave it a name either: it was just a sort of communications code: byte one tells you what it is, byte two tells you how LONG it is and teh rest of the bytes are the data...

Want more? how about the actual machine microcode in a modern processor. That interprets what you call machine code, and turns into intra chip instructions like 'flip that pin high'

Then there is stuff like HPGL interpreters, only ever designed to drive plotter heads.

There were more than a few application and even chip specific low level languages around when I worked on military radar.

General purpose languages - algol, cobol, B, bcpl, fortran, forth, basic, java, pascal, C, lisp, and so on are the exceptions, not the rule. Assembler languages are designed to work on a specific chipset: they have little meaning outside of it.


Jav*** was designed - if that isn't too strong a word - to make browsers do tricks.

It wasn;t origally deigned as a general purpose language at all.
The fact that you can get bits of it to work independently of a browser environment and the DOM is an a curious aberration, Like getting a monkey to drive a car. I will admit its possible, but I cant see the point really.





.