Which Is The Better Approach To Working With Javascript?

Which is the better approach in working with Javascript?

1. Server side processing: Web server gets form input, runs it into the
Javascript module, and PHP collects the output for document prep.

2. Client side processing: Web server gets form input and passes it to PHP
which includes the Javascript written in a way to make the form input
processed on the client side and rendered (probably using DOM function
calls) on that side as well.

I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an apparently
less trafficked newsgroup and the post was the TLDR kind, but it has the
background and details of why the code must be in Javascript and why PHP
must work with it somehow. It also gives the details of the server and how
it forks and communicates with processes to parse/generate output.

Patient Guy wrote:
> Which is the better approach in working with Javascript?
>
> 1. Server side processing: Web server gets form input, runs it into the
> Javascript module, and PHP collects the output for document prep.
>
> 2. Client side processing: Web server gets form input and passes it to PHP
> which includes the Javascript written in a way to make the form input
> processed on the client side and rendered (probably using DOM function
> calls) on that side as well.
>
> I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an apparently
> less trafficked newsgroup and the post was the TLDR kind, but it has the
> background and details of why the code must be in Javascript and why PHP
> must work with it somehow. It also gives the details of the server and how
> it forks and communicates with processes to parse/generate output.
>

3. Try a javascript newsgroup. This one is for PHP.

Hint: javascript does NOT run on the server.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle <jstucklex@attglobal.net> wrote in comp.lang.php:

> Patient Guy wrote:
>> Which is the better approach in working with Javascript?
>>
>> 1. Server side processing: Web server gets form input, runs it into
>> the Javascript module, and PHP collects the output for document prep.
>>
>> 2. Client side processing: Web server gets form input and passes it
>> to PHP which includes the Javascript written in a way to make the
>> form input processed on the client side and rendered (probably using
>> DOM function calls) on that side as well.
>>
>> I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an
>> apparently less trafficked newsgroup and the post was the TLDR kind,
>> but it has the background and details of why the code must be in
>> Javascript and why PHP must work with it somehow. It also gives the
>> details of the server and how it forks and communicates with
>> processes to parse/generate output.
>>
>
> 3. Try a javascript newsgroup. This one is for PHP.

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.

>
> Hint: javascript does NOT run on the server.

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.

Patient Guy wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote in comp.lang.php:
>
>> Patient Guy wrote:
>>> Which is the better approach in working with Javascript?
>>>
>>> 1. Server side processing: Web server gets form input, runs it into
>>> the Javascript module, and PHP collects the output for document prep.
>>>
>>> 2. Client side processing: Web server gets form input and passes it
>>> to PHP which includes the Javascript written in a way to make the
>>> form input processed on the client side and rendered (probably using
>>> DOM function calls) on that side as well.
>>>
>>> I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an
>>> apparently less trafficked newsgroup and the post was the TLDR kind,
>>> but it has the background and details of why the code must be in
>>> Javascript and why PHP must work with it somehow. It also gives the
>>> details of the server and how it forks and communicates with
>>> processes to parse/generate output.
>>>
>> 3. Try a javascript newsgroup. This one is for PHP.
>
> 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.
>
>> Hint: javascript does NOT run on the server.
>
> 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.
>
>
>

That is correct. Javascript runs on the client. Communications between
PHP and javascript is limited. PHP can generate javascript code, and
javascript can submit data to the server for PHP to process.

But there is no javascript interpreter on the server. That is the
browser's job.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Patient Guy wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote in comp.lang.php:
>
>> Patient Guy wrote:
>>> Which is the better approach in working with Javascript?
>>>
>>> 1. Server side processing: Web server gets form input, runs it into
>>> the Javascript module, and PHP collects the output for document prep.
>>>
>>> 2. Client side processing: Web server gets form input and passes it
>>> to PHP which includes the Javascript written in a way to make the
>>> form input processed on the client side and rendered (probably using
>>> DOM function calls) on that side as well.
>>>
>>> I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an
>>> apparently less trafficked newsgroup and the post was the TLDR kind,
>>> but it has the background and details of why the code must be in
>>> Javascript and why PHP must work with it somehow. It also gives the
>>> details of the server and how it forks and communicates with
>>> processes to parse/generate output.
>>>
>> 3. Try a javascript newsgroup. This one is for PHP.
>
> 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.
>
>> Hint: javascript does NOT run on the server.
>
> 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.
>
>


Here, try this on for size.

Javascript is run **ONLY** on the client. In any script that puts up a
page, if there is Javascript, that script is run on the client
**BEFORE** anything is sent to the server.

If a php script is invoked, either via a page post or from the href of
an anchor or from an httpRequest, it is invoked on the **SERVER**. It
gathers input from the calling form in one of two ways. It can get that
from $_GET or from $_POST or both, depending upon the method of the
calling form.

PHP can then send HTML back to the client for display. PHP does **NOT**
run Javascript.

Is that clear enough for you?

On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:

> Patient Guy wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> wrote in comp.lang.php:
>>
>>> Patient Guy wrote:
>>>> Which is the better approach in working with Javascript?
>>>>
>>>> 1. Server side processing: Web server gets form input, runs it into
>>>> the Javascript module, and PHP collects the output for document prep.
>>>>
>>>> 2. Client side processing: Web server gets form input and passes it
>>>> to PHP which includes the Javascript written in a way to make the
>>>> form input processed on the client side and rendered (probably using
>>>> DOM function calls) on that side as well.
>>>>
>>>> I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an
>>>> apparently less trafficked newsgroup and the post was the TLDR kind,
>>>> but it has the background and details of why the code must be in
>>>> Javascript and why PHP must work with it somehow. It also gives the
>>>> details of the server and how it forks and communicates with
>>>> processes to parse/generate output.
>>>>
>>> 3. Try a javascript newsgroup. This one is for PHP.
>>
>> 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.
>>
>>> Hint: javascript does NOT run on the server.
>>
>> 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.
>
> That is correct. Javascript runs on the client. Communications between
> PHP and javascript is limited. PHP can generate javascript code, and
> javascript can submit data to the server for PHP to process.
>
> But there is no javascript interpreter on the server. That is the
> browser's job.

Except that you can run server-side javascript... though I don't know why
you would want to.

--
"Remain calm, we're here to protect you!"

..oO(sheldonlg)

>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.
>>
>>> Hint: javascript does NOT run on the server.
>>
>> 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.
>
>
>Here, try this on for size.
>
>Javascript is run **ONLY** on the client.

Wrong. JavaScript is just a language and can run everywhere if an
interpreter is available. Even PHP can be run in a client's browser if
you have the required plugin (at least for IE such a plugin exists!)

>In any script that puts up a
>page, if there is Javascript, that script is run on the client
>**BEFORE** anything is sent to the server.

Correct, but now you're talking about a particular implementation of a
JS engine and the most common use of JS. But there are also various JS
engines available that run on a server.

http://en.wikipedia.org/wiki/Server-side_JavaScript

>If a php script is invoked, either via a page post or from the href of
>an anchor or from an httpRequest, it is invoked on the **SERVER**. It
>gathers input from the calling form in one of two ways. It can get that
>from $_GET or from $_POST or both, depending upon the method of the
>calling form.
>
>PHP can then send HTML back to the client for display. PHP does **NOT**
>run Javascript.

If there's a JS engine available, then of course PHP can invoke a Java-
Script like it can call a Perl script, Python, Java ... whatever. A
programming language is never restricted to just a single environment.

Micha

> .oO(sheldonlg)
>
>> 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.
>>>
>>>> Hint: javascript does NOT run on the server.
>>>
>>> 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.
>>
>>
>> Here, try this on for size.
>>
>> Javascript is run **ONLY** on the client.
>
> Wrong. JavaScript is just a language and can run everywhere if an
> interpreter is available. Even PHP can be run in a client's browser if
> you have the required plugin (at least for IE such a plugin exists!)
>
>> In any script that puts up a
>> page, if there is Javascript, that script is run on the client
>> **BEFORE** anything is sent to the server.
>
> Correct, but now you're talking about a particular implementation of a
> JS engine and the most common use of JS. But there are also various JS
> engines available that run on a server.
>
> http://en.wikipedia.org/wiki/Server-side_JavaScript
>
>> If a php script is invoked, either via a page post or from the href
>> of an anchor or from an httpRequest, it is invoked on the
>> **SERVER**. It gathers input from the calling form in one of two
>> ways. It can get that from $_GET or from $_POST or both, depending
>> upon the method of the calling form.
>>
>> PHP can then send HTML back to the client for display. PHP does
>> **NOT** run Javascript.
>
> If there's a JS engine available, then of course PHP can invoke a
> Java- Script like it can call a Perl script, Python, Java ...
> whatever. A programming language is never restricted to just a single
> environment.
>
> Micha

I mean no offense here, but I think the original answers based on the
level of the OP were probably good ones; run it client side because the
server likely doesn't provide it?. Perhaps the missed point was simply
that servers would have to be checked to see if they would serve js,
same as checking to see if and what version of PHP they provide, if they
provide it, which almost all do AFAIK. So js is normally intended to be
run on the client side, not the server side.
Or am I all wet? I'm not sure I see any value to running js for the
client on the server side. Seems like js could put quite a load on a
server if many people used it that way, since it's so prevalent in
coding these days.

I got curious so I checked my own servers and they do not provide any
js capability that I could find. I didn't ask support though; I'm
trying to avoid js, but it can be pretty handy for some things, I know.

Ivan Marsh wrote:
> On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>
>> Patient Guy wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> wrote in comp.lang.php:
>>>
>>>> Patient Guy wrote:
>>>>> Which is the better approach in working with Javascript?
>>>>>
>>>>> 1. Server side processing: Web server gets form input, runs it into
>>>>> the Javascript module, and PHP collects the output for document prep.
>>>>>
>>>>> 2. Client side processing: Web server gets form input and passes it
>>>>> to PHP which includes the Javascript written in a way to make the
>>>>> form input processed on the client side and rendered (probably using
>>>>> DOM function calls) on that side as well.
>>>>>
>>>>> I posted this <news:Xns9AD554BCD7E9FUVAA@216.168.3.44> in an
>>>>> apparently less trafficked newsgroup and the post was the TLDR kind,
>>>>> but it has the background and details of why the code must be in
>>>>> Javascript and why PHP must work with it somehow. It also gives the
>>>>> details of the server and how it forks and communicates with
>>>>> processes to parse/generate output.
>>>>>
>>>> 3. Try a javascript newsgroup. This one is for PHP.
>>> 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.
>>>
>>>> Hint: javascript does NOT run on the server.
>>> 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.
>> That is correct. Javascript runs on the client. Communications between
>> PHP and javascript is limited. PHP can generate javascript code, and
>> javascript can submit data to the server for PHP to process.
>>
>> But there is no javascript interpreter on the server. That is the
>> browser's job.
>
> Except that you can run server-side javascript... though I don't know why
> you would want to.
>

What interpreters are available for javascript on the server, and what
hosts have it installed?

It is not part of the package of any web server.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Twayne" <nobody@devnull.spamcop.net> wrote in comp.lang.php:

>> .oO(sheldonlg)
>>
>>> 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.
>>>>
>>>>> Hint: javascript does NOT run on the server.
>>>>
>>>> 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.
>>>
>>>
>>> Here, try this on for size.
>>>
>>> Javascript is run **ONLY** on the client.
>>
>> Wrong. JavaScript is just a language and can run everywhere if an
>> interpreter is available. Even PHP can be run in a client's browser if
>> you have the required plugin (at least for IE such a plugin exists!)
>>
>>> In any script that puts up a
>>> page, if there is Javascript, that script is run on the client
>>> **BEFORE** anything is sent to the server.
>>
>> Correct, but now you're talking about a particular implementation of a
>> JS engine and the most common use of JS. But there are also various JS
>> engines available that run on a server.
>>
>> http://en.wikipedia.org/wiki/Server-side_JavaScript
>>
>>> If a php script is invoked, either via a page post or from the href
>>> of an anchor or from an httpRequest, it is invoked on the
>>> **SERVER**. It gathers input from the calling form in one of two
>>> ways. It can get that from $_GET or from $_POST or both, depending
>>> upon the method of the calling form.
>>>
>>> PHP can then send HTML back to the client for display. PHP does
>>> **NOT** run Javascript.
>>
>> If there's a JS engine available, then of course PHP can invoke a
>> Java- Script like it can call a Perl script, Python, Java ...
>> whatever. A programming language is never restricted to just a single
>> environment.
>>
>> Micha
>
> I mean no offense here, but I think the original answers based on the
> level of the OP were probably good ones; run it client side because the
> server likely doesn't provide it?. Perhaps the missed point was simply
> that servers would have to be checked to see if they would serve js,
> same as checking to see if and what version of PHP they provide, if they
> provide it, which almost all do AFAIK. So js is normally intended to be
> run on the client side, not the server side.
> Or am I all wet? I'm not sure I see any value to running js for the
> client on the server side. Seems like js could put quite a load on a
> server if many people used it that way, since it's so prevalent in
> coding these days.
>
> I got curious so I checked my own servers and they do not provide any
> js capability that I could find. I didn't ask support though; I'm
> trying to avoid js, but it can be pretty handy for some things, I know.

There are several reasons for running it on the server side, which were
all given in the post with message ID

<news:Xns9AD554BCD7E9FUVAA@216.168.3.44>

cited in the original post.

The reason all starts with the need to convert a pseudo-math plaintext
notation into MathML. The parser and generator was originally written in
Javascript, and that was ported to PHP so that string input from a form
textarea control could apparently seamlessly be translated to MathML all
within PHP.

But I want to tweak the code of the parser and generator, and I am quite
familiar with Javascript, and much less so with PHP. It would be no issue
at all if I can work easily with PHP at this very moment, for I would edit
the PHP code rather than the Javascript code.

So given that I would rather make use of the original Javascript code---
and can---then the two ways of making use of the Javascript code was
either to have PHP set up the delivered document to client with the input
string bundled with the Javascript code and have it all done on the client
side, or to run something like wscript or cscript from the server, which
is the host interpreter for J(ava)script, and then run the output to PHP
for deliver (thus, all done on the server side).

Surely both approaches are possible, but which of the two is more
sensible?