Which Is The Better Approach To Working With Javascript?

"Twayne" <nobody@devnull.spamcop.net> wrote in message
news:5q3dk.403$P11.290@trndny06...

<snip>

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

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

interesting. maybe you could provide a sample of js code that is translated
to php so that your argument has a bit more meat. in most source code, the
more verbose the code, the less experienced the author. as it is, having
written my share of source in each i see no way to agree with that
statement.

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

you can't justify what you've claimed based on mere inference or belief,
though i understand the assumption and what it's based on.

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

i would think from a business stand-point that if server-sided js was as
capable and robust as php or asp that using one language in the company's
web development would be a huge, pragmatic plus. imo, ss-js simply isn't
there yet nor is there a developer-based demand for it to be in the near
future.

cheers

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g50ja8$gu4$3@registered.motzarella.org...
> 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.

saw that one coming!

> Hint: javascript does NOT run on the server.

hint: your head is up your ass, jerry. plenty of server-side javascript
servers...only one though, need be demonstrated to prove you wrong and
several have been mentioned in this thread. as it is, as long as you have an
interpreter, you can run any scripting language anywhere. but, based on the
quality of your posts, i've seen no sway from the norm in regard to seeing
you in err.

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g529d3$9us$2@registered.motzarella.org...
> 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 like how you can speak for all web server installations, jerry. further,
when proven wrong about js being client-side only, you just change pace and
say, 'well, no one has that on their server!'. you simply tried to speak
with authority on a topic you obviously know nothing about. why not just say
you were wrong and then move on?

Patient Guy wrote:
> "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.

From the Wikipedia reference it appears that only JAXER has any DOM
capabilities, and whether it can deal with MathML you would need to
investigate. I'm thinking not. Most, if not all server side JS
implementations are not concerned with doing client side type stuff,
it's a very different animal than client side JS. Remember that the JS
you are used to using only runs through a browser, that there is no
standalone client side JS.

Now, it seems to me that rather that go through all this to possibly
get nowhere that learning a little more PHP would be easier. It looks a
lot like javascript to me to the point that when I embed javascript in
my php it's hard for me to tell which is which!

Jeff

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

Message-ID: <X6ednW-yAY4aT-nVnZ2dnUVZ_qLinZ2d@earthlink.com> from Jeff
contained the following:

> Now, it seems to me that rather that go through all this to possibly
>get nowhere that learning a little more PHP would be easier. It looks a
>lot like javascript to me to the point that when I embed javascript in
>my php it's hard for me to tell which is which!

But easier. I find de-bugging JS a real pain.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

In article <Ll4dk.855$dc7.134@newsfe06.lga>,
"Barry" <no.one@example.com> wrote:

> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:g529d3$9us$2@registered.motzarella.org...
> > bill wrote:
> >> Jerry Stuckle wrote:

[snip]

> >>> 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 like how you can speak for all web server installations, jerry. further,
> when proven wrong about js being client-side only, you just change pace and
> say, 'well, no one has that on their server!'. you simply tried to speak
> with authority on a topic you obviously know nothing about. why not just say
> you were wrong and then move on?

Because he's not wrong in any material sense.

On Wed, 09 Jul 2008 16:15:15 +0100, Geoff Berrow wrote:

> Message-ID: <X6ednW-yAY4aT-nVnZ2dnUVZ_qLinZ2d@earthlink.com> from Jeff
> contained the following:
>
>> Now, it seems to me that rather that go through all this to possibly
>>get nowhere that learning a little more PHP would be easier. It looks a
>>lot like javascript to me to the point that when I embed javascript in
>>my php it's hard for me to tell which is which!
>
> But easier. I find de-bugging JS a real pain.

It can be a bit like chasing a ghost at times.

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

Willem Bogaerts <w.bogaerts@kratz.nl> 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.
>
> 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,

Thanks for input.

The basic assumption here has been that the Javascript I intend to use has
been for form validation. That is absolutely not true at all.

This developer decided to write a translator tool, one that converts a
pseudo-math notation in ASCII plaintext to MathML; I need to check the
code to see if the MathML is output as a long string or whether it is
output as XML/MathML-specific DOM objects. He wrote it in Javascript
probably because he ran it all on his browser (client-side) for his own
purposes rather than through a server. Someone else decided to take the
input string on the server side and process on that side, porting the
whole thing to PHP.

At any rate, I will probably just set up a web page that runs it all on
the client side for my own purposes rather than set something up on a
server for others who might have otherwise wanted the changes I made to
the code. At least for the time being.

The general consensus in this group---no surprise---is that I should work
with the PHP ported code (instead of the Javascript/ECMAscript) if I want
to make changes/improvements in server side-based Text->MathML
translations, since anyone like myself who has more than beginner
experience in code development should already know core (typically useful)
PHP or should quickly acquire a facility for it. I will accept this
opinion and move my "learn basic PHP" to-do item to the top of the list.

On Jul 9, 9:18*am, Willem Bogaerts <w.bogae...@kratz.nl> wrote:
> 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/

Willem's response is correct. You cannot rely on JavaScript being
enabled (or worse, failing to process correctly) on the users browser.
Therefore, you must also validate all input on the server.

Where JavaScript can be used is to drive dynamic content based on the
users input, either pre-loaded and hidden or using AJAX. And to speed
up the validation process, by not having to go off to the server where
something can be easily checked on the browser first.

But, as I said, don't rely on the browser validation.

Rob.

"Tim Streater" <tim.streater@dante.org.uk> wrote in message
news:tim.streater-00DBBD.16201109072008@news.individual.net...
> In article <Ll4dk.855$dc7.134@newsfe06.lga>,
> "Barry" <no.one@example.com> wrote:
>
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:g529d3$9us$2@registered.motzarella.org...
>> > bill wrote:
>> >> Jerry Stuckle wrote:
>
> [snip]
>
>> >>> 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 like how you can speak for all web server installations, jerry.
>> further,
>> when proven wrong about js being client-side only, you just change pace
>> and
>> say, 'well, no one has that on their server!'. you simply tried to speak
>> with authority on a topic you obviously know nothing about. why not just
>> say
>> you were wrong and then move on?
>
> Because he's not wrong in any material sense.

the 'material sense' would be that he can't know what is installed on every
web server out there. obviously, materially, if development is being done on
products such as LiveWire and other server-side javascripting engines then
there are web servers with such animals installed.

in every sense, he is wrong...and that doesn't even address that servers who
don't have this or that package installed usually do so on request (payment
consideration aside). either way, his arrogance is only upstaged, and
highlighted, by his lack of correctness. :)

cheers.