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

Dear fellow Monks,

Has anyone tried using Perl.js (or anything similar) to write client-side web applications in Perl?

Could this be the end of the traditional Perl on the server / JS in the browser split? While Node.js is bringing JS onto the server, have the Perl.js developers pluckily occupied the browserspace with Perly tanks* while the Node legions weren't looking?

(*or possibly more monastically appropriate huts, gardens & allotments!)

To return to the 'tank' analogy, perhaps the engines could do with a little tinkering yet.

Replies are listed 'Best First'.
Re: Perl.js: porting Perl to the browser?
by ww (Archbishop) on Apr 27, 2015 at 02:08 UTC

    Your first para contains a reasonable question for posting in SOPW.

    What follows is mere speculation with no demonstration of any real relevance. And I, for one, am not going to play with what's displayed at the unknown site to which you linked without locking it down in a sandbox.

    If you're so inclined, why not find out what is claimed and write some code to test what it does. Then you'll have a node that's worth inconveniencing the electrons cooped to create it.


    check Ln42!

      Then you'll have a node that's worth inconveniencing the electrons cooped to create it.

      Bonus points for considering the tortured disenfranchised electrons.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

      … unknown site to which you linked without locking it down in a sandbox.
      from the OP's URL I guess the source code is at https://github.com/gfx/perl.js

        Address in the link (which is https://gfx.github.io/perl.js) is easy enough to read (hover on link w/browser which shows content) without opening it; "unknown" refers to "trusted" or "untrusted." Without prior recommendation from a reliable source, the site's "mission in life" (development effort, malware distro, etc) is "unknown."

Re: Perl.js: porting Perl to the browser?
by LanX (Saint) on Apr 27, 2015 at 08:19 UTC
Re: Perl.js: porting Perl to the browser?
by BrowserUk (Patriarch) on Apr 27, 2015 at 08:07 UTC

    Nn-ert! Crashed my browser!


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
Re: Perl.js: porting Perl to the browser?
by Anonymous Monk on Apr 27, 2015 at 23:49 UTC

    I tried it on firefox 31.6.0, under my regular profile, memory quickly climbs above 600mb and I have to kill it -- memory leaks are not impressive :)

    Then I tried it under -safe-mode, and lo-and behold, no memory leak (~150mb) but it doesn't run

    TypeError: asm.js type error: Disabled by javascript.options.asmjs in +about:config perl.js TypeError: sessionStorage is null perl.js:34

    so i create a new profile and memory shoots up quickly again, but it doesn't start swapping, the memory isn't running away, its keeping steady under 200mb , firefox pups up a stop or continue runaway script perl.js, I can finally interact with firefox again, so I continue and I'm presented with it

    preload time: 183740 ms This is perl 5, version 18, subversion 1 (0x51c238) built for js...

    I run hello world, it runs

    starting again and its the same deal all, no caching benefits nada -- sessionStorage is sessional :P  preload time: 148459 ms ... so thats about 2.5-3 minutes load time

    Yeah

Re: Perl.js: porting Perl to the browser?
by locked_user sundialsvc4 (Abbot) on Apr 28, 2015 at 01:10 UTC

    Dunno ... we also have a COBOL-to-JavaScript compiler, too.

    But, frankly, I would toss them both into the same “experimental” bucket ... and then push the handle mounted conveniently nearby.

    I think that we, as an industry, have “lately gone a little nuts” for the notion that:   “the only plausible way to do anything is to use ‘JavaScript and HTML(5),’ more-or-less exactly as we did in the early uh-oh’s.”   And then, to try mightily to press every square-peg we come across into that one hole.   Even though technicians prove again and again what can be done, it just doesn’t take too long, IMHO, for such things to completely lose their relevance.   No tool has to do everything.   No one way of doing anything fits everywhere.

    The Perl language, like Javascript, reflects its upbringing and its heritage ... and these factors also determine what it’s really good at – and, what it isn’t.   There will always be two sides ... client, and server.   There are tools steeped in one of those two, others in the other, none in both.

      sundialsvc4: Dunno ...

      yeah, its not like the authors call these things experimental, no need to toss them into sundialsvc4s bucket

      A reply falls below the community's threshold of quality. You may see it by logging in.