Which Is The Better Approach To Working With Javascript?

..oO(Twayne)

>I mean no offense here, but I think the original answers based on the
>level of the OP were probably good ones

We don't know much about the OP and its level. But his posting and the
one he referred to seem to be worded quite thoroughly, so he might know
what he's talking about.

>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,

Sure, but a lot of people run their own servers or use hosts which might
install additional software if you ask them nicely. Just because such a
setup is quite unusual doesn't mean it's impossible or pointless.

>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.

Nothing wrong with that. As said - it's just another programming
language. Whether you do your server-side scripts in PHP, Perl, Python,
JS, Whitespace, Brainfuck or use executable binaries written with C/C++,
Delphi, whatever doesn't really matter. They all serve their purpose.

>Seems like js could put quite a load on a
>server

Not more than any other interpreter. Why should a JS interpreter cause
more load than the PHP interpreter for example? They do exactly the same
work, it's just another syntax and some different semantics.

>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.

Because it's not very popular on servers. But if one prefers that
language to also do server-side stuff - heck, why not.

Micha

Michael Fesser <netizen@gmx.de> writes:

> .oO(Twayne)
>
>>I got curious so I checked my own servers and they do not provide any
>>js capability that I could find.
>
> Because it's not very popular on servers. But if one prefers that
> language to also do server-side stuff - heck, why not.

It's actually been done. Netscape web servers had a JavaScript
module that parsed some <script> elements before sending the
page. There was an attribute that indicated which ones were to be
parsed on the server, but I forget what it was.

That said, I haven't seen a Netscape server in use for at least a
decade, and I have no idea who ended up with the rights for their
server products.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

Jerry Stuckle <jstucklex@attglobal.net> writes:

> What interpreters are available for javascript on the server

There's mod_wxjs for Apache:

<http://www.wxjavascript.net/mod_wxjs/index.html>

I've never actually used it though, so I can't recommend either for or
against it, simply point out its existence. I keep such things in a
folder of "might be handy some day" bookmarks. :-)

> and what hosts have it installed?

I suspect none. You'd probably have to lease a dedicated server, so
that you could customize your Apache install with your own modules.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

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.

Do not assume the client has JavaScript enabled and especially do your
validations on the server. You can do validations on the client as well,
but mainly to provide faster/better feedback to the user.

Best regards,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

Jerry Stuckle wrote:
> 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.
>

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

bill wrote:
> Jerry Stuckle wrote:
>> 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.
>>
>
> http://en.wikipedia.org/wiki/Server-side_JavaScript
>

And how about the second part of the question - what hosts have such
packages installed?

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

I seem to have inadvertantly started a drift in the topic here so in
order to not hijack the thread I'll apologize here and make a couple of
inlines; after all it's only "drift" so far ;-).

> .oO(Twayne)
>
>> I mean no offense here, but I think the original answers based on the
>> level of the OP were probably good ones
>
> We don't know much about the OP and its level. But his posting and the
> one he referred to seem to be worded quite thoroughly, so he might
> know what he's talking about.

True, I now realize; in fact it seems just the opposite - there's a lot
of experience there in at least some areas. I assumed there was a level
of ignorance re server sides based on the first post and the lack of any
indication that the OP was familiar with what was/wasn't available on
most servers. Actually IMO there seems to be a hold-back of useful
information plus it's well over my head beyond anything I've already
stated, which to me means I'm pretty much done reading the thread. I
can not contribute anything more to it.

>
>> 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,
>
> Sure, but a lot of people run their own servers or use hosts which
> might install additional software if you ask them nicely. Just
> because such a setup is quite unusual doesn't mean it's impossible or
> pointless.

Right; that's why I said "likely" rather than "never" etc.

>
>> 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.
>
> Nothing wrong with that. As said - it's just another programming
> language. Whether you do your server-side scripts in PHP, Perl,
> Python, JS, Whitespace, Brainfuck or use executable binaries written
> with C/C++, Delphi, whatever doesn't really matter. They all serve
> their purpose.

lol!

>
>> Seems like js could put quite a load on a
>> server
>
> Not more than any other interpreter. Why should a JS interpreter cause
> more load than the PHP interpreter for example? They do exactly the
> same work, it's just another syntax and some different semantics.

Maybe my assumption is wrong, but IME my js is a lot more code bytewise
than the PHP code I use the server for and where reasonable users tend
to minimze server use when it's not advantageous, it seems like running
js there would be slower, more machine intensive and more voluminous
code to run. js being what it is, it seems it could pretty easily put a
load on a server if very many visitors and/or other sites ran it there.
I could easily be wrong; I have no actual experience in that area
other than the little twerps I've run on my local server so I'm not
presenting an arguement as much as I am justifying why I said what I
did.

>
>> 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.
>
> Because it's not very popular on servers. But if one prefers that
> language to also do server-side stuff - heck, why not.

I guess. I might think seriously about it at least but I'm too ignorant
of the nuances to be sure right now. Nuances of the server side use, I
mean.

Cheers,

Twayne



>
> Micha

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.
>

Java SCRIPT (as opposed to java) runs in the browser exclusively. 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, and is used to generate context
sensitive pages, often coupled to a database engine. It takes as much
processing and decsion making out of the brwsers hands as possible,
cincentraying te cde where its more easily maintainable - on teh sever
itself.

Halfway huse s do exist - Ajax - where partial page reloads are done
dynamically, using I think javascipt on e browser and PHP server side.




>> 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.
>

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, because its a bloody awful language, and is only
by and large written for broswers.

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.

>

On Tue, 08 Jul 2008 20:41:34 -0400, Jerry Stuckle wrote:

> 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.

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

I've played with some of it back when I was looking for a single language
solution to client and server side scripting. It was much less trouble to
learn to use PHP and Javascript.



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

On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:

> bill wrote:
>> Jerry Stuckle wrote:
>>> 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.
>>
>> http://en.wikipedia.org/wiki/Server-side_JavaScript
>
> And how about the second part of the question - what hosts have such
> packages installed?

I'd expect you'd have to be running your own server to use any of it.

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