http://www.perlmonks.org?node_id=62685

CiceroLove has asked for the wisdom of the Perl Monks concerning the following question:

I am doing a couple of personal projects lately and I am running into a lot of things that could be done either in JavaScript or Perl. It got me to wondering -- Besides the obvious answers of client-scripting vs. server-scripting overhead, what kind of guidelines do you use to decide whether to go JavaScript or Perl? Especially when it is form oriented?

Your input is most interestedly spied.

CiceroLove
Fates! We will know your pleasures: That we shall die, we know; 'Tis but the time, and drawing days out, that men stand upon. - Act III,I, Julius Caesar

Replies are listed 'Best First'.
Re: Perl vs. Javascript
by Chady (Priest) on Mar 07, 2001 at 12:12 UTC

    I have been into that matter for some time; not being able to decide what type of language to use for a specific task.

    But since you are working on the web and processing forms, you're down with two solutions; Perl and JavaScript.

    Here are some of the diffrences :

      JavaScript

      • This is Client-Side scripting, so you will be depending on the user's browser to support or not your scripts.
      • In order to access specific objects (form fields values, or list values) you will need to setup a way to access them supporting all the browsers ex: Netscape calls the form diffrently than IE, and another diffrent one is NS6 (and that's only two types of browsers)
      • Processing texts of forms is a little hard to do right with JavaScript
      • I'm sure you will find more...

      Perl

      • This is Server-Side scripting, so all your scripts will run whatever browser asks them to.
      • In order to access specific objects, you just use CGI.pm and you have an object with all the values you need in it.
      • Processing text is as simple as "writing the right RexEx" in Perl.

    Finally, If you have a lot of text to process, and you need to do it quickly and efficiently, go for Perl, it's faster(in programming) and more reliable.

    If you only need to 'get the contents of a field and put it in another' you can make it in JavaScript.

    I hope this information helps you decide

    Chady | http://chady.net/
(crazyinsomniac) Re: Perl vs. Javascript
by crazyinsomniac (Prior) on Mar 07, 2001 at 12:35 UTC
    Redundancy, redundancy, redundancy!

    While JavaScript can help reduce overhead, you can not guarantee(unless you stop js'less people from using) people will use the javascript, and thusly you must do it in perl, that is if the client is gonna have any communication with the server, aside from requesting pages and providing %ENV vars ;-)

     
    ___crazyinsomniac_______________________________________
    Disclaimer: Don't blame. It came from inside the void

    perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Re: Perl vs. Javascript
by Corion (Patriarch) on Mar 07, 2001 at 16:30 UTC

    I almost never use JavaScript except when I'm directly scripting effects for my browser of choice (IE). Trying to support more than one browser/OS/Version combination with JavaScript fails in spectacular ways.

    If it's at all possible, JavaScript can greatly augment the client experience by providing instant feedback when entering data fields, and I'm considering dynamically created JavaScript for data entry forms that duplicates the logic from my Perl scripts (the Perl scripts operate on logic read from the database/a hash anyway).

    For fancy stuff, there are great JavaScript libraries that (try to) insulate you from the nasty world of browser differences, like http://www.dynamicdrive.com/ or OverLib.

    If you think it's absolutely necessary to have JavaScript, consider that you will block/annoy all those people who surf with JavaScript disabled (like me)...

Re: Perl vs. Javascript
by chromatic (Archbishop) on Mar 07, 2001 at 22:16 UTC
    Unless you're in an environment where you can count on people having JavaScript enabled, you will still have to do input validation on the server. (Even then, I wouldn't trust the client and would perform validation anyway.)

    In my opinion, just about the only reason to use JavaScript is to improve the rather poor UI available with the standard HTML widgets. With a bit of client-side scripting, you can autofill boxes, bind buttons to functions, and make things slightly easier. As an example, consider the Message Inbox at Everything2. If you hit a 'Reply' button next to a private message, it fills in a textbox with the commands to respond to the sender and gives that textbox focus, so you can start typing immediately.

    Even better, if you have the 'autofill' checkbox enabled, and are using a newer browser than Netscape 4.7x, you can simply run the mouse cursor over the comment and it will autofill the box.

    It's also possible to send extra data to the web browser with a module like WDDX and update available selections on the client side.

    Just beware -- this does not make user data any more secure, and it should degrade gracefully, unless you can guarantee that nearly all users will have JavaScript enabled for your site. (Private intranet site? Yes. Public? Probably not.)

Re: Perl vs. Javascript
by Tyke (Pilgrim) on Mar 07, 2001 at 16:07 UTC
    Any time you want to run something from the command-line rather than a Web-browser you're almost always better off going for Perl rather than for JavaScript ;)

    Sorry for stating the obvious but I get the impression that some people still don't understand this! I'm not targetting any monk, just some of the AMs that pass by.

    -- I knock my pate and fancy wit will come Knock as I please, there's no one at home a pontiff paraphrased
Re: Perl vs. Javascript
by toadi (Chaplain) on Mar 07, 2001 at 14:07 UTC
    Just see you have mod_perl installed. That will take care of the overhead.
    Try to forget javascrit exists :-) Write everything in perl from the start!
    You're in control of what happens cos it's serverside!

    --
    My opinions may have changed,
    but not the fact that I am right

      mod_perl takes care of the server overhead, but the network latency may inconvenience users, especially those with poor connectivity to your server.

      The main advantage of client side validation is that it gives users an immediate warning that they need to correct their input, without having to wait for the server to respond to their request.

        I understand what you mean. But then you have to do double work. Program in javascript and then do it server-side again.
        Why this? Cos taint checking is only secure server-side.
        If you want to do everything double ok for me.

        --
        My opinions may have changed,
        but not the fact that I am right