JavaScript and CGI: General questions

[Kevin O'Gorman]

On Sun, Jul 21, 2002 at 04:35:49PM -0400, Joel Hammer wrote:
> There would not be a lot of processing going on, just reformatting some input
> forms. The amount of data that would be transferred is minimal. NO IMAGES.
> 
> I am really impressed by the lack of standardization on the part of
> javascript implementations.  And, I am impressed that users can do
> things like turn off javascript and popup menus, which will defeat
> javascript. I can't see a customer having the patience to figure out why
> my javascript won't run on his computer.  Aside from Internet Explorer,
> no two versions of any other browser I have tried have worked the same,
> if they have worked at all.  I mean, the typeof command seems to be
> killing netscape and the book claims that netscape originated that
> thang. A very attractive characteristic of Internet Explorer seems to be
> that there isn't much the user can do to (mis)configure it. I know that
> the lack of configurability bothers some people, but the advantages become
> obvious right away when you start writing javascript. So, MS delivers
> on the idea of a mass market, and they will reap the big bucks. That's
> proves the universe is just.
> 
> So, I guess the message is, do everything possible on the server side,
> and keep the javascript short and very compatible.
> 
> I a sorry to hear that PHP has shot itself in the foot with progress. That's
> typical. Who ever thought of leaving a good idea alone. Anyway, this means I
> can keep my books on PERL and CGI programming with PERL!
> 
> Joel


You may want to explore Python as an alternative.  It's about as standard,
though it lacks the huge number of modules that Perl boasts.  It's main advantage
AFAICS is that the code is _much_ easier to read a year later when you want
to modify it.  Perl just keeps too many things cryptic or buried in context
that you no longer remember.

++ kevin


> 
> 
> otOn Sun, Jul 21, 2002 at 12:51:53PM -0700, Kevin O'Gorman wrote:
> > On Sun, Jul 21, 2002 at 11:22:50AM -0700, Ken Moffat wrote:
> > > Joel Hammer wrote:
> > > > This sounds interesting.
> > > > Will it make it impossible/difficult for people to steal your web site
> > > > content by just downloading the html and using it locally? It sounds like it
> > > > will.
> > > > Joel
> > > > 
> > > 
> > > 
> > > Yes, the code is generated by php, so all the browser sees is the 
> > > resulting output, which is not your source.
> > > 
> > > Python is also excellent, as noted by Richard. Just depends on where you 
> > > are comfortable.
> > > 
> > > -- 
> > > Ken Moffat
> > 
> > Seems to me there's a bit of confusion here.  The use of Javascript is
> > orthogonal to the use of Python for sure, and maybe PHP as well.  That's
> > because Javascript is executed by your browser and allows things to happen
> > there without further interaction (and delays) over the internet.  Python
> > for instance, is perfectly capable of emitting Javascript mixed in the
> > HTML; probably PHP can do this is as well.  They can be used together
> > because they do very different things, and do them at different places.
> > 
> > This is the disctinction between server-side and client-side programming.
> > Python is server-side, and your browser sees only what the Python program
> > outputs (HTML, XML, Javascript, binary images; whatever) and not the Python
> > source.  Client-side things like Javascript and Java applets have to be
> > downloaded for them to execute on the browser.  With Java, bytecodes are
> > downloaded, not the source, so it's moderately secure (but can be dis-
> > assembled to recover something very like the source).  With Javascript,
> > the source itself is downloaded, which is why you can enable/disable
> > Javascript at the browser.  You'll note that you cannot disable Python
> > or PHP, because they don't execute on your machine but at the server.
> > 
> > If you have a task you want done _at the browser_ you cannot expect to
> > satisfy the need with a server-side programming tool.  Javascript is
> > therefore going to be around for a while.
> > 
> > ++ kevin

-- 
Kevin O'Gorman  (805) 650-6274  mailto:kevin at kosmanor.com
Permanent e-mail forwarder:  mailto:Kevin.O'Gorman.64 at Alum.Dartmouth.org
At school: mailto:kogorman at cs.ucsb.edu
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://kosmanor.com/~kevin/index.html

"Life is short; eat dessert first!"