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

Barry wrote:
"The Natural Philosopher" <a@xxx> wrote in message news:1215639211.19016.0@xxxxxxxxxxxxxxxxxxxxxxxxx
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.

all good points, however languages like PLC ladder logic and assembly are really the exceptions since most languages that exist are 4GL. assembly (et. al.) are only target-specific based on OS & hardware anyway, and that at compile time. so, i can use assembly to program a cell phone or a pc or an eprom. the point is, the language is only context-specific in terms of what it is meant to handle, which is low level, granularity control of hardware and circuitry. still, those examples fail to live up to what you're saying since no assembly language i know of will only work a specific chipset, as you say. they may have different contraints on features that can be used per chipset or may require different compilers, however the comparison is like PHP as CLI or CGI, etc..

as for javascript, yes, that is the origination but, like most other burgeoning languages (PHP inclusive) they quickly outgrow the niche that spurred their creation. case-in-point, perl.

but again, you do make a very good case that there are languages that do, in fact, restrict themselves entirely to specific environments and implementations. i just don't agree that these are the rule.


Well if you looks at things below the hood so to speak,you will find that a huge amount of processing power is devoted to executing the processor specific machine code. Far more than is probably used, across all the microchips that are in use, than are used to compile C++..

You have to understand that I come from a hardware background, a huge area that is complately unknown to most 'computer programmers' whose life begins and ends with an interpreter or compiler..


btw, my original reply to you was shearly in jest. :) why not name your language? hell, if i made one, i'd at least have fun with naming it.


It was only after I left that particular contract that I rtelised I had, in fact, written a sort of interpreter for a sort of language.

At the time, it was just the simplest way of storing commend sequences, with a little bit of branching/subroutine in it.


cheers.


.