8 ms·

Run Perl in the browser with WebPerl

148 points by mfontani 8y ago

WrtCdEvrydy 8y ago
We're flying too close to the sun here.
- tacostakohashi 8y ago
  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/Windows/PerlScript.html#client_side http://docs.activestate.com/activeperl/5.22/perl/Components/...
tyingq 8y ago
Discussion on perlmonks: https://www.perlmonks.org/?node_id=1220426 https://www.perlmonks.org/?node_id=1220426
platinium 8y ago
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.
- liveoneggs 8y ago
  that has been done already
- wwweston 8y ago
  > why would anyone new want to invest in Perl There's lots of discussion on HN of languages that see less use than Perl. Often the reason people invest in them is that they think learning the lesser-known/used language might offer them a novel view of development or provide extra capabilities in some niche. It isn't particularly different with Perl, although there is the difference that many devs think they already know what they need to know about Perl even if they've never done anything serious with recent 5.x or 6 (or at all). > Imho they should just fork Perl 6 and continue developing Perl 5. [insert "what if I told you" meme here]
  - platinium 8y ago
    > Imho they should just fork Perl 6 and continue developing Perl 5. [insert "what if I told you" meme here] I meant rename Perl 6 into something else and develop Perl 5.xxxx into Perl 6....
    - aseipp 8y ago
      That ship already sailed way over a decade ago (or longer) and changing it now would just massively add to the confusion between what Perl 5 and 6 are. You can't retroactively rewrite every webpage and reference in history, and it's not a particularly hard to explain that they're essentially separate languages. Perl 5 will continue to be maintained and evolve in a compatible way, and Perl 6 is a much different language altogether. They quite literally "forked perl 6, and continued developing perl 5". Forking an existing, newer language just so you can do what amounts to a meaningless, useless major version bump of an existing, established language, is pretty much the exact definition of a breaking change for frivolous reasons.
      - platinium 8y ago
        Agreed on everything. However, nobody new (read: young) will want to learn a language that is not able to receive a major version bump. (notable exception I guess, Python). A language that can't receive major version bump will be (is?) perceived as a dead language. Perception does matter. Ads, marketing, etc etc, the world is run by perception.
        kbenson 8y ago
        I don't really think most people think like that (or even necessarily initially have the information to be able to). To me, it seems like most language adoption is driven by fads, what people are hiring for, and random interesting projects. Have you ever actually been interested in a language and looked to see whether it was able to have a major version number bump or not prior to deciding whether or not to pursue it?
        aseipp 8y ago
- pletnes 8y ago
  A different perspective: there’s probably a few command line perl scripts out there that could be nice web services or perform some task in a browser. This way you don’t have to rewrite those scripts.
- smacktoward 8y ago
  I remember having this argument a lot in 1999. It's nearly 20 years later now, they made their decision long ago, it's time to let it go and move on.
  - cygx 8y ago
    Which argument? The mug-throwing incident that initiated Perl6 development happened 2000-07-18, and it took a couple of years after that for the language to take shape...
    - smacktoward 8y ago
      My memory was off by a couple of years. You know what I mean, though.
    - labster 8y ago
      smacktoward lives in the UTC+1752000 time zone now. Update your datetime libraries.
- gkya 8y ago
  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 8y ago
    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).
    - justinator 8y ago
      I think in 10 more years it's going to be anazing. Amazing just takes time to get right.
      - kbenson 8y ago
        It might be amazing (to some degree, it already is), but unfortunately I don't think I'll be using it for much. TIMTOWTDI is great, but like most things, too little or too much are both problematic. This wasn't always my point of view, I came to after many years of following Perl 6 development (from all the way back in the Parrot days). As the language implementations started maturing and people implementing things to show off (often for Advent calendars), I started realizing that I was having a really hard time following how each thing was implemented, because there were far too many ways it could be implemented, but in a fundamentally different way than Perl 5. Perl 5 gives you a good set of primitives, a lot of flexibility, and then tasks you with using this mix of core types, context, and namespaces to do what you want, how you want. The actual things you need to know to reason about most code you encounter is fairly simple though, and if not immediately known to the average Perl programmer, they'll have a good idea to figure out what it is, and what the usual suspects are for really weird stuff (I'm looking at you, indirect object notation). Perl 6 has so many core, fundamental things to know, that in any piece of code I might encounter, the number of things that could be in use is staggering. I've read the Perl 6 Synopses, end-to-end, years ago. I remember a lot of what's in there. Hell, I was really excited about those features when reading about them. When I saw them start to be put into practice, that's when it crystallized for me. Specifically, I started having real doubts when I saw Larry implement a solution for Rosetta code in Perl 6 using a sigilless[1] style. What's the point of these? Just to represent special characters, as in the example? But they're also constants, because they have no containers? And there's also defined constants, but those have sigils?[2] Don't get me wrong. Perl 6 has some (a lot!) of good ideas. I mean, it sort of has to, since it actually has all the ideas. That's the problem. Not all ideas area good, and even if you only selectively implement all the good ideas, they aren't always still good when they are forced to coexist with each other. At this point I see Perl 6 as a really interesting experiment to see how some of the more interesting ideas work in practice when used in a less opinionated language. I'll probably do some simple stuff in it eventually (I mean, I'm still fairly familiar with it just from following it for almost 15 years), but I don't have high hopes for using it for any professional projects, or for using it on a project with many other contributors. That's okay, I never stopped writing Perl 5, it's what I do for my day job, so I'm not missing it too much. That said, I still have a very soft spot in my heart for Perl 6. It's an extremely quirky and wonderful language when viewed purely as a language and a thing to play with. That I think it won't ever see professional success is fine. There's lots of things in life that are great without that, and there's lots of types of success other than that to aim for. And that's totally okay. 1: https://docs.perl6.org/language/variables#Sigilless_variables https://docs.perl6.org/language/variables#Sigilless_variable... 2: https://docs.perl6.org/language/variables#The_constant_prefix https://docs.perl6.org/language/variables#The_constant_prefi...
- toast0 8y ago
  People seem to be ok with Java and JavaScript having pretty much nothing to do with each other. The couple of people trying to retcon the name to ECMAScript have not succeeded. Perl5 and Perl6 are the same situation: on first glance they seem closely related, but they're not, end of story. It's been clear for a long time that Perl6 is not a replacement for Perl5, it's a different language from the same creator. It would have been great if it were named something else, but changing its name is something its community would need to do, and won't erase the years of history that already exist.
pjmlp 8y ago
So it continues, pandora's box was already open. :)
- zzzcpan 8y ago
  Do you mean people bringing their own compilers with web pages?
  - pjmlp 8y ago
    Yep, unless browser vendors change course, the revenge of plugins is near. Prepare for Flash 2.0.
    - smacktoward 8y ago
      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 8y ago
        > 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 8y ago
xrd 8y ago
If you host the page using Apache and ModPerl does the entire thing become isomorphic?
- SwellJoe 8y ago
  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 8y ago
    Care to share any links to said best practices?
    - justinator 8y ago
      https://plackperl.org https://plackperl.org https://mojolicious.org https://mojolicious.org https://github.com/miyagawa/Starman https://github.com/miyagawa/Starman
      - arbie 8y ago
        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 8y ago
        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).
denniskane 8y ago
On a not completely unrelated note (seeing as Perl is just a beefed up version of the *nix shell)... I've created the first (that I know of) implementation of the Shell Command Language (POSIX Std 1003.1) in JS for the purpose of building a new kind of web native OS. I just tried to get some traction here on HN with a post of a link that goes to a page on my site. I called the post "Building a more recursive web". Here's the link: http://lotw.xyz/HOWTO/videos.html http://lotw.xyz/HOWTO/videos.html
egfx 8y ago
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 8y ago
  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.
jaboutboul 8y ago
Why? Just why?
kbenson 8y ago
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).
lukeholder 8y ago
Also related, PHP in the browser using webassembly: https://github.com/oraoto/pib https://github.com/oraoto/pib
Ultimatt 8y ago
There's also a recent Rakudo Perl 6 in the browser via 6pad https://perl6.github.io/6pad/#b4b147048a70e333e61ec8c298096491 https://perl6.github.io/6pad/#b4b147048a70e333e61ec8c2980964...

148 points by mfontani 8y ago

WrtCdEvrydy 8y ago

We're flying too close to the sun here.

tacostakohashi 8y ago
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/Windows/PerlScript.html#client_side http://docs.activestate.com/activeperl/5.22/perl/Components/...

tyingq 8y ago

Discussion on perlmonks: https://www.perlmonks.org/?node_id=1220426 https://www.perlmonks.org/?node_id=1220426

platinium 8y ago

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.

liveoneggs 8y ago
that has been done already
wwweston 8y ago
> why would anyone new want to invest in Perl There's lots of discussion on HN of languages that see less use than Perl. Often the reason people invest in them is that they think learning the lesser-known/used language might offer them a novel view of development or provide extra capabilities in some niche. It isn't particularly different with Perl, although there is the difference that many devs think they already know what they need to know about Perl even if they've never done anything serious with recent 5.x or 6 (or at all). > Imho they should just fork Perl 6 and continue developing Perl 5. [insert "what if I told you" meme here]
- platinium 8y ago
  > Imho they should just fork Perl 6 and continue developing Perl 5. [insert "what if I told you" meme here] I meant rename Perl 6 into something else and develop Perl 5.xxxx into Perl 6....
  - aseipp 8y ago
    That ship already sailed way over a decade ago (or longer) and changing it now would just massively add to the confusion between what Perl 5 and 6 are. You can't retroactively rewrite every webpage and reference in history, and it's not a particularly hard to explain that they're essentially separate languages. Perl 5 will continue to be maintained and evolve in a compatible way, and Perl 6 is a much different language altogether. They quite literally "forked perl 6, and continued developing perl 5". Forking an existing, newer language just so you can do what amounts to a meaningless, useless major version bump of an existing, established language, is pretty much the exact definition of a breaking change for frivolous reasons.
    - platinium 8y ago
      Agreed on everything. However, nobody new (read: young) will want to learn a language that is not able to receive a major version bump. (notable exception I guess, Python). A language that can't receive major version bump will be (is?) perceived as a dead language. Perception does matter. Ads, marketing, etc etc, the world is run by perception.
      - kbenson 8y ago
        I don't really think most people think like that (or even necessarily initially have the information to be able to). To me, it seems like most language adoption is driven by fads, what people are hiring for, and random interesting projects. Have you ever actually been interested in a language and looked to see whether it was able to have a major version number bump or not prior to deciding whether or not to pursue it?
      - aseipp 8y ago
pletnes 8y ago
A different perspective: there’s probably a few command line perl scripts out there that could be nice web services or perform some task in a browser. This way you don’t have to rewrite those scripts.
smacktoward 8y ago
I remember having this argument a lot in 1999. It's nearly 20 years later now, they made their decision long ago, it's time to let it go and move on.
- cygx 8y ago
  Which argument? The mug-throwing incident that initiated Perl6 development happened 2000-07-18, and it took a couple of years after that for the language to take shape...
  - smacktoward 8y ago
    My memory was off by a couple of years. You know what I mean, though.
  - labster 8y ago
    smacktoward lives in the UTC+1752000 time zone now. Update your datetime libraries.
gkya 8y ago
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 8y ago
  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).
  - justinator 8y ago
    I think in 10 more years it's going to be anazing. Amazing just takes time to get right.
    - kbenson 8y ago
      It might be amazing (to some degree, it already is), but unfortunately I don't think I'll be using it for much. TIMTOWTDI is great, but like most things, too little or too much are both problematic. This wasn't always my point of view, I came to after many years of following Perl 6 development (from all the way back in the Parrot days). As the language implementations started maturing and people implementing things to show off (often for Advent calendars), I started realizing that I was having a really hard time following how each thing was implemented, because there were far too many ways it could be implemented, but in a fundamentally different way than Perl 5. Perl 5 gives you a good set of primitives, a lot of flexibility, and then tasks you with using this mix of core types, context, and namespaces to do what you want, how you want. The actual things you need to know to reason about most code you encounter is fairly simple though, and if not immediately known to the average Perl programmer, they'll have a good idea to figure out what it is, and what the usual suspects are for really weird stuff (I'm looking at you, indirect object notation). Perl 6 has so many core, fundamental things to know, that in any piece of code I might encounter, the number of things that could be in use is staggering. I've read the Perl 6 Synopses, end-to-end, years ago. I remember a lot of what's in there. Hell, I was really excited about those features when reading about them. When I saw them start to be put into practice, that's when it crystallized for me. Specifically, I started having real doubts when I saw Larry implement a solution for Rosetta code in Perl 6 using a sigilless[1] style. What's the point of these? Just to represent special characters, as in the example? But they're also constants, because they have no containers? And there's also defined constants, but those have sigils?[2] Don't get me wrong. Perl 6 has some (a lot!) of good ideas. I mean, it sort of has to, since it actually has all the ideas. That's the problem. Not all ideas area good, and even if you only selectively implement all the good ideas, they aren't always still good when they are forced to coexist with each other. At this point I see Perl 6 as a really interesting experiment to see how some of the more interesting ideas work in practice when used in a less opinionated language. I'll probably do some simple stuff in it eventually (I mean, I'm still fairly familiar with it just from following it for almost 15 years), but I don't have high hopes for using it for any professional projects, or for using it on a project with many other contributors. That's okay, I never stopped writing Perl 5, it's what I do for my day job, so I'm not missing it too much. That said, I still have a very soft spot in my heart for Perl 6. It's an extremely quirky and wonderful language when viewed purely as a language and a thing to play with. That I think it won't ever see professional success is fine. There's lots of things in life that are great without that, and there's lots of types of success other than that to aim for. And that's totally okay. 1: https://docs.perl6.org/language/variables#Sigilless_variables https://docs.perl6.org/language/variables#Sigilless_variable... 2: https://docs.perl6.org/language/variables#The_constant_prefix https://docs.perl6.org/language/variables#The_constant_prefi...
toast0 8y ago
People seem to be ok with Java and JavaScript having pretty much nothing to do with each other. The couple of people trying to retcon the name to ECMAScript have not succeeded. Perl5 and Perl6 are the same situation: on first glance they seem closely related, but they're not, end of story. It's been clear for a long time that Perl6 is not a replacement for Perl5, it's a different language from the same creator. It would have been great if it were named something else, but changing its name is something its community would need to do, and won't erase the years of history that already exist.

pjmlp 8y ago

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

zzzcpan 8y ago
Do you mean people bringing their own compilers with web pages?
- pjmlp 8y ago
  Yep, unless browser vendors change course, the revenge of plugins is near. Prepare for Flash 2.0.
  - smacktoward 8y ago
    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 8y ago
      > 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 8y ago

xrd 8y ago

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

SwellJoe 8y ago
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 8y ago
  Care to share any links to said best practices?
  - justinator 8y ago
    https://plackperl.org https://plackperl.org https://mojolicious.org https://mojolicious.org https://github.com/miyagawa/Starman https://github.com/miyagawa/Starman
    - arbie 8y ago
      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 8y ago
        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).

denniskane 8y ago

On a not completely unrelated note (seeing as Perl is just a beefed up version of the *nix shell)... I've created the first (that I know of) implementation of the Shell Command Language (POSIX Std 1003.1) in JS for the purpose of building a new kind of web native OS. I just tried to get some traction here on HN with a post of a link that goes to a page on my site. I called the post "Building a more recursive web". Here's the link: http://lotw.xyz/HOWTO/videos.html http://lotw.xyz/HOWTO/videos.html

egfx 8y ago

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 8y ago
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.

jaboutboul 8y ago

Why? Just why?

kbenson 8y ago

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).

lukeholder 8y ago

Also related, PHP in the browser using webassembly: https://github.com/oraoto/pib https://github.com/oraoto/pib

Ultimatt 8y ago

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