Questions about future direction

[matthewrobb]

Firstly: cool project!

I am curious what your plans are going forward. I understand that there is a great deal of differences to smooth over when transpiling from JS to PHP however here are my thoughts:

• Break runtime out into a separate repo js-env.php that can be published via composer etc.
• Merge philosophies with the other js2php project. Basically try to transpile to PHP that could be consumed by other PHP and interact with other PHP without adapters or API knowledge.
• Only wrap operations that absolutely need it. Many operations can be inlined and would be better off for it.
• Get the rocambole library to upgrade to the latest esprima-fb which comes with many fixes and the latest (final) ES6 Modules support.
• Write transpiler in ES6 and compile output using esnext & es6-module-transpiler

I had some more thoughts as I was playing with things but I have to run, if I remember I will post them in this thread.

[sstur]

Hey Matthew. Thanks for checking out my project!

I like your ideas, especially using esprima-fb which is what we use at Facebook to support classes and arrow functions and all the nice ES6 stuff that is solidified in the spec and not likely to change. I plan to support that in js2php, but not till after I get through most of my current ES5 todo-list.

I'm not sure where I'm going with this in the long term, but I do know this:

• I want it to be able to transpile itself. The browserified code we run in the demo should successfully transpile into PHP and run on the command line. We're not quite there.
• I want to support fs and mysql modules as well as the existing (experimental) http module that can be found in php/modules/ directory
• I want modules to be opt-in at compile time, so by default any JS you compile will be safe to run in any PHP environment without it having filesystem or network access. Optionally you could specify js2php --modules=all to compile trusted code
• I want to build a simple demo web app in pure JS that will compile to PHP and run on a standard LAMP stack as sort of a proof-of-concept

I could understand breaking the runtime and the transpiler into two git projects. That makes a lot of sense, but I don't have a compelling reason to do it at the moment.

Now the bigger question is reconciling this project and it's goals with @endel's js2php which has different goals. The world could really use a much lighter-weight syntatically simple compile-to-php languange, and it could be a subset of ES6 like @endel is doing. I've actually thought many times while working on this project: wow, there's really a case for a simplified PHP with all the built-in-functions modularized and object-orientified, and some of the legacy ugliness fixed (error handling, lexical scope, etc).

Take for instance the hundreds of global built-in functions! It uses up so much namespace, and it's not chainable so you have nested calls like:

$a = strtolower(array_join('-', array_slice(array_split('/', $array), 1, 2)));

Wouldn't it be nicer to write:

a = array.split('/').slice(1, 2).join('-').toLowerCase()

That reads in the order it executes and you don't have to worry about parenthesis matching and all that.

Or take for instance $data = file_get_contents('file/does/not/exist') which doesn't throw, instead it returns false... what does that mean? File doesn't exist? or the directory doesn't exist? or permission denied? Well an E_WARNING gets logged to the console, but what good is that to my application logic? There's a round-about way of overriding all warnings and intercepting them in a global set_error_handler but that's not very developer friendly!

Or take for instance, variable scope. Since PHP never had proper variable declaration like JavaScript's var there's no clear way to statically determine where a variable's scope starts and ends! So they put that burden on the developer by introducing the clumsy use statement.

$a = 1;
$f = function($b) use ($a, $log) { $log($a + $b); };

This could all be smoothed out in a transpile step!

But I'm not sure @endel's project goes far enough (yet), I'd like to see it really re-think PHP. And I'm not sure the name is right (it doesn't really accept JS but a PHP-variant who's syntax is a subset of JS). He's solving a fundamentally different problem than I am and although we could share some parsing and codegen logic, I don't know if it would be worthwile to "merge" the projects, but I'm totally open to the idea.

Anyway, I'm happy to accept pull requests, particularly for inlining operations that would benefit from it. But keep in mind one of the core principles of this project is to produce readable PHP (not beautiful, but readable) for debugging and the sanity of the future developers.

Please feel free to contribute!