Re^3: What's this I hear about Client Side Perl?

Your question was about client-side scripting - it doesn't matter what server platform you're running - client-side scripts run in the browser.

PerlScript is ActiveState's Perl plugin for Windows Scripting Host. WSH is kind of like a virtual machine for running scripting languages. By default it comes with Javascript and VBScript support, but other scripting languages can be plugged in. (ActiveState also makes a Python plugin IIRC.) WSH happens to be what Internet Explorer uses to run scripts - this means that Internet Explorer can run not just Javascript, but any other WSH scripting language, provided the right plugins installed.

So you can write client-side script in Perl, but it will only run in Internet Explorer, and only if they have the right plugin installed. Apart from very limited circumstances where you have enough control over the client platform to ensure Internet Explorer plus PerlScript is available, when it comes down to it, Javascript is the only game in town for scripting in the browser.

Another option is to use a programming language that can be compiled into Javascript.

Perlito is a pure Javascript implementation of a subset of Perl. (Perl 5 and Perl 6!) You can write in Perl and compile it into Javascript, which can run in your web browser. However, it won't be Perl as you know it. You won't be able to use CPAN modules - not even most of the modules that are part of the Perl core will be usable.

Dart, Haxe, and CoffeeScript may be better options if you want to go the compile-to-Javascript route. They're more mature.

That said, I don't quite understand the resistance to Javascript. It's actually quite a nice language. It has its warts, but so does Perl.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Comment on Re^3: What's this I hear about Client Side Perl?

Replies are listed 'Best First'.
Re^4: What's this I hear about Client Side Perl? by Jenda (Abbot) on Jun 04, 2014 at 08:22 UTC
I'd add TypeScript into the list. It extends JavaScript while keeping the syntax mostly untouched. It's easier to debug that way. Jenda Enoch was right! Enjoy the last years of Rome.	[reply]
Re^4: What's this I hear about Client Side Perl? by taint (Chaplain) on Jun 04, 2014 at 00:59 UTC
Thank you, tobyink, for such a long, and informational response -- you must be in Book Writer mode. ;) Honestly, my aversion to JavaScript isn't that I dis-like it, so much as that it seems a bit fragile (easily disabled), and, if at all possible, I like to keep things in the same language. It's more efficient, and tidier. Less maintenance, and housekeeping too. Something else that that frustrates me, is that Perl, and JavaScript are so darned similar. Yet, Perl isn't scriptable at all on the Client-Side. But then again, then it'd just be JavaScript, and I'd still be complaining. :P Anyway, it seemed that maybe serialization might hold some sort of solution. While I've had little time, working with it. Is seemed it might hold some possibilities. Albeit probably a little less responsive. All of this is why I've posed the question(s) here. With all the vast accumulated knowledge the PM holds collectively. I was sure that if anything in this area was possible. Surely a Monk would know. :) Thank you again, tobyink for all the information. --Chris ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH	[reply]
Re^5: What's this I hear about Client Side Perl? by Your Mother (Archbishop) on Jun 04, 2014 at 06:39 UTC
I like to keep things in the same language You can do server side in JS just fine… e.g. node.js.	[reply]


Problems? Is your data what you think it is?
	PerlMonks