
Babel-preset-php: PHP7 to ES7 syntax translator - farhadhf
https://gitlab.com/kornelski/babel-preset-php
======
pornel
That's a weekend project and it turned out better than I expected. Thanks to
nikic's php-parser, astexplorer.net and Babel infrastructure handling the
gnarly bits (e.g. source maps just worked).

I started it because I hoped it would speed up rewrites of projects from PHP
to JS, but now that I've actually seen the results, I realised that bad PHP
code makes only worse JS (and there's no point rewriting good PHP code).

Still, I think it could be useful for sharing some logic between client and
the server, without replacing server-side with Node. This isn't a VM, so it
has zero overhead at the cost of being loose with semantic edge cases.

And I find it funny that it now takes 1 line of config to make JS tools work
with PHP syntax instead.

~~~
ichiriac
Hi pornel, just a little precision on the library author, it seems you are
using ichiriac's php-parser :))

~~~
pornel
Oh, indeed! Sorry for miscrediting. Great work.

------
STRML
This is hilarious!

We ran across @kornelski yesterday asking about some old babel code (1.) and
were wondering what the angle is. Kornel's an accomplished coder: he did
pngquant and imageoptim.

The author himself calls it the "stupidest project I've ever done". But it's
probably a nice way to get 90% of the way there when converting PHP fns (such
as validation et al) into the browser. Also, and perhaps most importantly,
it's a great exercise in writing Babel plugins.

I really enjoyed this. Thanks for writing it, @kornelski.

1\.
[https://twitter.com/kornelski/status/884485913627295744](https://twitter.com/kornelski/status/884485913627295744)

------
bluetidepro
While there already is a bunch of "why" type comments in this thread, it's
worth noting that in the description of the repo it does say:

> "This project is silly and exists only to expand Atwood's Law."

So maybe take it with a grain of salt, and just enjoy a neat project for what
it is.

------
mjburgess
This isnt running PHP in the browser. It's running a quasi-JS runtime with PHP
syntax.

To run "PHP in the browser" you'd need tests passing on all the major php
frameworks, as per, Hack's testsuit. Otherwise you're forcing people to learn
some language not quite either JS or PHP.

~~~
pornel
Indeed. For this I prioritized readable and JS-like output (and no runtime)
over handling things exactly. There's a different project doing it via a VM in
JS: [https://phpjs.hertzen.com/](https://phpjs.hertzen.com/) and it handles
most of the PHP test suite.

On the language level most stuff works well enough. However, the biggest
blocker is impedance mismatch between PHP and JS environments, e.g. request-
per-process vs shared server, `echo`, modules vs autoload & namespaces, etc.
so even 100% accurate PHP execution is going to be doing odd things in the JS
world.

------
beager
I've generally found the behavior of builtin PHP methods to be less
predictable and more involved than in JS, so I wonder if the best approach to
writing a transpiler in this case would be to go to the C source and negotiate
from there.

Having done PHP for years and years before the language itself found adequate
elegance, I wouldn't want the burden of replicating all its weird behaviors
for something like this, at least without seeing the source to understand
what's happening.

~~~
awirth
If you want to use an existing toolchain, you could use HPHPc (the predecessor
to HHVM, which transpiled PHP to C code) and emscripten to translate from C to
Javascript. It would probably require some mucking around at the emscripten
layer though to get all the packages linking properly, because HPHPc has a
non-trivial number of (non-optional) runtime deps for supporting all of the
various php modules. You _should_ just be able to compile them separately with
emscripten into a prefix (e.g. don't use emscripten ports, which I've had a
terrible time with) but YMMV.

I dockerized a working version of HPHPc (which is quite difficult to set up
due to bitrot) at [https://github.com/allanlw/hphpc-
docker](https://github.com/allanlw/hphpc-docker) if you want to play around
with the compiler. I might try to take a shot at passing it through emscripten
later.

~~~
beager
That's really cool, and seems like it would take a lot of the hassle of
"understanding" PHP out of the equation. Nicely done!

------
deweller
One interesting use case for this would be to benchmark functions. How much
faster/slower do various functions perform in PHP vs. NodeJS?

It wouldn't be a perfect comparison since the generated JS code might be less
optimized. But it could give one a ballpark estimate.

~~~
ComputerGuru
It's ironic that I have to ask which of the two languages you'd be trying to
benchmark.

------
HugoDaniel
"The conversion is implemented as an AST to AST translation (with source
maps!)"

Amazing that the code actually reads better than the original. (at least for
me)

I wonder how many of the php extensions can be easily ported to JS code as
well ?

------
kodablah
Heh, I did it the other direction back in the day as a toy [0]. Back in
TypeScript's earlier days I figured it could be a neat frontend for the
otherwise ugly PHP...not really.

0 - [http://cretz.github.io/pratphall/](http://cretz.github.io/pratphall/) \-
[https://github.com/cretz/pratphall](https://github.com/cretz/pratphall)

------
awkward
This is a good scary story for anyone who complains too much about the
complexity of modern javascript.

------
megamindbrian
Why not just compile phplib using
[https://github.com/kripken/emscripten](https://github.com/kripken/emscripten)
and call the library functions directly?

~~~
bfred_it
Someone else will do that in the future, both are equally fun projects.

------
csomar
I could see many ways how this can go wrong and be popular with guys who have
PHP code and want to run it on the browser because they 1. either don't master
javascript or 2. want to save time.

------
agumonkey
I wonder how easy it is to translate between dynamic languages since they all
support a quite similar core set (classes, closures, sets, dicts, iterables
...)

~~~
KMag
The semantics can still be quite different. You start hitting a lot of corner
cases very quickly, unless one of the languages was designed to have semantics
close to the other's, or the two languages at least share heavy influence from
a common ancestor.

Many dynamically typed languages treat null/nill/None, empty string, and empty
list as "non-truthy" in a Boolean context, but that's not universal.

JavaScript's notion of a class is very different from Python's. Ruby's take on
who can call private methods is different from most languages. Python is in a
minority for supporting multiple inheritance.

In Common Lisp, functions and variables have separate namespaces, whereas in
Scheme, they share a single namespace.

PHP just has bizarre object conversion and comparison rules that are often
inconsistent and therefore incompatible with most other languages (ignoring
the Turing tarpit).

Getting good enough lexical analysis of the source language to efficiently
implement lexical closures in a target language without them can be a pain.

On the other hand, if you're cross-compiling buggy webapps written by
developers who don't properly understand the semantics of the language they're
written in, maybe you can just ignore the semantic mismatches and get a
different set of bugs coming out the other side while accidentally fixing
other bugs.

~~~
agumonkey
Maybe pre translate each language into a per language subset that can map to a
simple and canonical semantic domain.

Other than that you're right

------
arcosdev
But...but...why?

~~~
crimsonalucard
Why nodejs? Why why? edit: I would argue that both languages are equally
horrible. Yet here we are.

~~~
pluma
I feel you, brother. There are too many people using crappy languages. If only
everybody saw the light and used the only good language out there, Oberon-2.

~~~
crimsonalucard
I feel your sarcasm. Lets be real though, V8 is a fast implementation but
javascript as a language itself separate from implementation is a POS. ES6 and
ES7 is proof that ES5 was just plain bad.

~~~
champagnepapi
I would not say ES6 and ES7 are "proof" that ES5 is bad.

~~~
crimsonalucard
[https://medium.freecodecamp.org/5-javascript-bad-parts-
that-...](https://medium.freecodecamp.org/5-javascript-bad-parts-that-are-
fixed-in-es6-c7c45d44fd81)

------
aussieguy1234
Gitlab is down

------
alansmitheebk
Why?

------
cwyers
Ah, now we can run HN's least favorite language on top of HN's second least
favorite language.

~~~
positivecomment
Well, an admittedly silly poll[1] from nearly 4 years ago showed JS to be the
6th most loved, if you subtracted dislikes from likes:

Python 2093, C 1630, Go 766, SQL 706, Haskell 691, JavaScript 683, C# 666

I know it doesn't mean anything but I think it's funny, at least.

Full list: [https://pastebin.com/3HevKLzz](https://pastebin.com/3HevKLzz)

[1]:
[https://news.ycombinator.com/item?id=6527104](https://news.ycombinator.com/item?id=6527104)

~~~
cwyers
HN has two very divergent opinions on JS but the people who hate it really
hate it,and the people who like JS may outnumber the ones who hate it but you
can reliably expect people to complain about Javascript on every HN thread
about it. JS is third in dislikes on there (Java is actually the second-most
hated language, who knew?), so I wasn't technically correct but I was in the
ballpark.

------
_pmf_
Why not? JSX paved the way for the successful return to PHP3 style
development.

~~~
TomMarius
It also paved the way for a clean and modern MVVM pattern usage.

~~~
_pmf_
WPF is clean. QML is clean. React is not.

~~~
TomMarius
So you can tell me why it isn't, then? I don't see WPF being as clean as React
is. It uses tons of magic strings in XAML files. JSX properties are
expressions and thus can be statically typed. QML is almost the same, just a
little different syntax, but I don't see any difference that would make it
cleaner than React.

------
lolive
So sick! /o\

------
jorgec
Fine but its dangerous. Javascript/Ecmascript, is a poor designed language,
the scope of the variables is broken. Instead, PHP is well defined in this
aspect.

~~~
pluma
This seems like an obvious troll comment.

But I'd like to point out that "the scope of the variables is broken" doesn't
make any sense: prior to ES6 JavaScript only had function scope -- which is
not broken but also not what most people are used to. ES6 added let/const
which are block scoped (and thus more familiar). Neither of the two is broken,
nor did the addition break anything.

The only oddity I can think of that would provoke such criticism would be a
misunderstanding of non-strict-mode JS's behaviour with regard to implicit
globals, e.g. what happens outside strict-mode when variables are used without
being declared or what the "with" statement does (which is heavily
discouraged). But that's like saying PHP is stupid because its array literals
look weird.

~~~
thehardsphere
> obvious troll comment

Honestly, how can you tell? I feel like that's something someone could say if
they are under the misunderstanding you (very aptly) describe.

~~~
pluma
Clue 1: it praises PHP. Even PHP apologists usually restrict themselves to
simply defending PHP rather than praising it.

Clue 2: it calls JS "dangerous" and "poor designed" (sic). This is vague but
provocative enough to invite emotional responses rather than factual
discussion.

Clue 3: it explicitly calls out "the scope of variables" as "broken". Again
this is vague enough to be ambiguous but strongly worded enough to seem
insulting. This is especially confusing if contrasted with PHP, which isn't
exactly known for being intuitive and simple in that regard:
[http://php.net/manual/en/language.variables.variable.php](http://php.net/manual/en/language.variables.variable.php)

But you're right, which is why I said it _seems_ like an obvious troll comment
rather than insisting that it can only be that. It might just be a poorly
worded expression of frustration stemming from an incomplete understanding.
Hence my attempt at a factual response.

