
Run Perl in the browser with WebPerl - mfontani
https://webperl.zero-g.net/
======
kbenson
This is long overdue. As I'm sure any Perl developer that's had a
chance/reason to use Javascript in more than the simplest of contexts will
likely attest to, Javascript often feels like someone took some ancient proto-
Perl, changed the syntax, and added a bunch of features that weren't tested
for how well they meshed with the language at all.

Perl has it's fair share of syntactic oddities and mistakes, but once you
understand the underlying themes and goals of the language,and how a few
_core_ differences from almost all other languages inform it's use (
_statement context!_ ), it comes across as very thoughtfully designed and
implemented. That isn't always apparent at first, and some people disagree
with the design goals, but it does feel like it makes sense.

Javascript rarely feels that way to me. The more I can rely on only those new
features the more I can fool myself into ignoring the ugly warts underneath,
but they pop up whether you want them to or not (equivalence testing, null
_and_ undefined, etc).

------
tyingq
Discussion on perlmonks:
[https://www.perlmonks.org/?node_id=1220426](https://www.perlmonks.org/?node_id=1220426)

------
xrd
If you host the page using Apache and ModPerl does the entire thing become
isomorphic?

~~~
SwellJoe
Pedantic mode: mod_perl has been neglected and somewhat discouraged as a way
to run Perl web apps for at least a decade (for a variety of reasons, similar
to the reasons mod_php, etc. are discouraged). There are a number of very good
modern application servers in the Perl world, as you would find in most other
languages commonly used for web apps.

~~~
jaytaylor
Care to share any links to said best practices?

~~~
justinator
[https://plackperl.org](https://plackperl.org)

[https://mojolicious.org](https://mojolicious.org)

[https://github.com/miyagawa/Starman](https://github.com/miyagawa/Starman)

~~~
arbie
Having deployed Plack and Mojo in production, I would say Mojo's documentation
is hard to digest.

If you stray from a simple web-server with routes, you are relegated to
reading Mojo source code to identify how to integrate esoteric middlewares
(I'm looking at you, JSON-RPC 1.0 and Azure AD). Weirdly, it shares this "no
help off the golden path" problem with Varnish Cache's VCL docs.

However, Mojo is still the most full-featured library out there, and you can
easily bend it to your will. Hypnotoad is a process-based worker pooling
engine for Mojo; its performance is not terrible and debugging issues is easy.

~~~
SwellJoe
I found the Mojo docs to be better than most Perl frameworks, but Perl web
frameworks, in general, suffer from a severe lack of good examples and docs.
There's just not as many people using them as Node or Ruby or Python or PHP or
whatever, so you don't find as many videos and tutorials and such for anything
outside of the most basic stuff. I think there's also a bit of bias toward
expertise; most people still using Perl have years of experience, and so there
tends to be a lot less hand-holding, which is a problem if (like me) you
haven't followed Perl web development closely, and only have a sort of old
school understanding of it. There's quite a bit of "now draw the rest of the
fucking owl", situations, for me, in dealing with modern Perl concepts.

But, I like Mojo, nonetheless. It's really concise and does a heck of a lot
with a vanishingly small amount of code (it's inspiring to see Perl excelling
at something pretty modern, honestly).

------
Ultimatt
There's also a recent Rakudo Perl 6 in the browser via 6pad
[https://perl6.github.io/6pad/#b4b147048a70e333e61ec8c2980964...](https://perl6.github.io/6pad/#b4b147048a70e333e61ec8c298096491)

------
egfx
How is this different then Embperl?
[https://perl.apache.org/embperl/](https://perl.apache.org/embperl/)

We used this old framework on a major corporate website I used to work on.

~~~
romed
Embperl runs on the server.

I’ll note that running Perl in browsers has long been possible, if the browser
is MSIE on Win32 with Perl installed. I deployed a client-side Perl “solution”
at my university in the 90s.

------
lukeholder
Also related, PHP in the browser using webassembly:
[https://github.com/oraoto/pib](https://github.com/oraoto/pib)

------
WrtCdEvrydy
We're flying too close to the sun here.

~~~
tacostakohashi
I wouldn't worry too much, they already tried this in the 90's and it didn't
catch on...

[http://docs.activestate.com/activeperl/5.22/perl/Components/...](http://docs.activestate.com/activeperl/5.22/perl/Components/Windows/PerlScript.html#client_side)

------
pjmlp
So it continues, pandora's box was already open. :)

~~~
zzzcpan
Do you mean people bringing their own compilers with web pages?

~~~
pjmlp
Yep, unless browser vendors change course, the revenge of plugins is near.

Prepare for Flash 2.0.

~~~
smacktoward
But if they all just compile down to WASM, why should anyone care? It's not
like you'll need to install a new plugin for each new language you run across.
You have a WASM interpreter already, you don't have to know or care about the
process by which the site you're visiting turns source code into WASM
bytecode.

~~~
kbenson
> But if they all just compile down to WASM, why should anyone care?

Because some sites/people will implement a new deployment scheme that
implements a new layout engine in a canvas, and use that to "prevent
plagiarism" or protect data. Think an online retailer preventing price
scraping, or some site that gets visions of grandeur about a more multimedia
rich experience (like every photographer's website 15 years ago), or wanting
to prevent ad-blockers or use dark patterns that browsers finally actively
prevent.

There are business incentives for all these, in some cases if not necessarily
for the end user, then for a company to trick end-users into thinking they
need ("click here and for $10/mo more we'll add our patented anti-
scraping/copying technology to your site!").

~~~
terandle
Seems like your issue is with the canvas tag and not necessarily with wasm as
you could just do that in JS as well.

~~~
kbenson
No matter how minified, JS is much more easily reversed and dealt with, and
won't have the level of same performance that WASM does, so it's a harder
sell.

It's sort of like saying that shipping an interpreted language file is just as
hard to reverse engineer as a compiled binary. Sure, you can make the
interpreted language harder to read by obfuscating it, but it's hard to
compare with straight up machine code or byte code.

In addition, all the obfuscation techniques feed into each other. WASM through
a canvas to protect content isn't all that useful if the content is built from
JSON which is easily visible. But if that JSON is itself encrypted/obfuscated,
that's harder. But determining the obfuscation method from JS code (minified
or not) is much easier than determining it from machine/byte code. In both
cases enough skill will bypass any mechanism since it's locally running code,
but all you have to do is raise the bar high enough to dissuade _most_. An
occassional switch of some underlying obfuscation methodology to make those
bypassing have to continuously work at it, and you've got a system that does
most of what's needed.

In the end, it's just like door locks. There's lots of technology that can be
used, all of it is defeatable in some fashion, but there's things you can do
to make it not worthwhile for all but the most determined. In the case of
canvas content rendering, I think WASM might be the tipping point that makes
this really feasible. I guess we'll see, it's not like there's really any way
to stop it (nor is it clear we should try).

------
platinium
Pretty cool, but why would anyone new want to invest in Perl when it has the
language problem of Perl 5 or Perl 6 ?

Imho they should just fork Perl 6 and continue developing Perl 5.

~~~
gkya
Perl 5 is a great language and does not deserve any of the hate it gets.
Unfortunately the dev community is always on the look for bandwagons to jump
into. It's a well thought out language with a comprehensive list of features
nicely integrated together, a vast ecosystem of packages, very good
documentation (has the best offline docs among all of the popular languages
out there, after C stdlib), and has stood the test of time.

Perl 6 is a nice experiment and may hold some ground in the future, but is not
a practical tool or something in the same space as Perl 5 today. It's very
unfortunate naming IMO.

~~~
SwellJoe
Perl 6 is as realistic an option as several other new languages. It is
new(ish), and still has some performance issues compared to Perl 5 (though
this is becoming less a thing, and there are now several areas where 6 is
faster than 5), but it has had regular stable releases for nearly three years.
You can deploy it today and expect the code to keep running in the future
without major modifications.

I'm not using it in production, but I think one reasonably could. I suspect
we'll be able to start shipping Perl 6 code in a couple of years (my company
builds installable applications, and we don't want to maintain Perl 6 packages
ourselves, so we need our target platforms to have good packages for Perl 6
available before we can ship it).

~~~
3rdAccount
What does your company do to where they're chill with trying to ship p6? Just
open-minded?

~~~
SwellJoe
Who's "they"? I'm the founder of the company. It's small, we do what we want.

~~~
3rdAccount
Ah sorry. I assumed a 500+ company with bloated and old-school IT like my own.
I shouldn't have assumed that :).

------
jaboutboul
Why? Just why?

