|
Re: What's this I hear about Client Side Perl?
by davido (Cardinal) on Jun 03, 2014 at 21:01 UTC
|
This is one of those times when it's probably most productive to go with the flow, and that flow for the past 20 years (correction) 19 years of client-side scripting has been JavaScript in one shiny package or another.
| [reply] |
|
|
Hello, davido.
Thanks for taking the time to reply.
Bummer. I was afraid that would turn out to be the case. I guess it's not that terrible, given the similar syntax to Perl.
for the 19 years of client-side processing has been JavaScript...
True, but JavaScript 1.x, doesn't hardly look like the now "defacto" ECMAScript/Web2. Which is why I was hoping that there may be difference enough to go a different route. Appears not.
Thanks again, for taking the time to respond, davido.
--Chris
¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH
| [reply] |
|
|
Would using a template modified by information passed from a controller work?
| [reply] |
Re: What's this I hear about Client Side Perl?
by soonix (Canon) on Jun 03, 2014 at 21:23 UTC
|
ActveState on Windows offers PerlScript. (Haven't tried, however) | [reply] |
|
|
Reading the linked page, client side PerlScript requires the client PC have ActiveState Perl and PerlScript installed.
I vaguely recall reading that there is a Perl 6 compiler that produces JVM byte code, but Perl 6 is a very different camel.
Update: FYI, for those who don't know, JVM is Java Virtual Machine. Java is compiled into JVM bytecode. Because most (all?) modern web browsers have a JVM built in, a client side "applet" compiled into JVM bytecode will run in the browser.
| [reply] |
|
|
| [reply] |
|
|
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
| [reply] |
|
|
|
|
|
|
Re: What's this I hear about Client Side Perl?
by sundialsvc4 (Abbot) on Jun 04, 2014 at 04:30 UTC
|
As I said in the other thread, there are better ways to write JavaScript. I encourage you to look at http://www.haxe.org, which is a strongly-typed language designed for cross-platform development that can generate, among other things, JavaScript outputs. The very worst thing about JavaScript is that “anything goes” and that there is no real concept of compile-time checking. I have used this tool with astonishing success in the past (for projects much more complex than this), and recommend that everyone should put it on their professional radar-scope. Those guys are on to something . . . it is something that needs to be paid attention to.
| [reply] |
Re: What's this I hear about Client Side Perl?
by perlfan (Vicar) on Jun 04, 2014 at 14:01 UTC
|
Perl is for delivering things to the browser. Once on the browser, it's all about JavaScript. You would remain much saner if you separated your concerns between services provider and client. The client can be anything (a browser, library, etc) - but you're limited to JavaScript based solutions on the browser. I'd look heavily into REST and providing an API on the server side. As I said, if the REST API is decent, you can write a client in anything - so for example, you could bypass the browser altogether and write a nifty GUI client using Perl + some bindings for a Tk or some other GUI library. | [reply] |
Re: What's this I hear about Client Side Perl? (javascript/llvm)
by Anonymous Monk on Jun 04, 2014 at 00:07 UTC
|
| [reply] |
