PHPJS is an effort to bring the mammoth PHP API into the land of JS., where it can be used for web apps as well as the increasing number of Javascript applications outside the browser.

The homepage explains some of the philosophy behind this project:

PHP is a language with many high-level functions and while they’re not always implemented as consistently as we’d like (mostly to blame on its underlying C parts), it has a huge following familiar with its syntax so it makes sense to pick its API as a reference. Eliminating the need for our own documentation, thus making life easier, we hope.

We recognize JS – on the other hand – has beautiful language features, and we encourage you to learn them. Never let php.js be an excuse not to.

For the same reason, we’re not porting entire language or control structures of PHP; we stick with the functions.

That said, we think of it as a challenge to port everything and decided to also port low-level PHP functions like strpos even though it may have a JavaScript counterpart (String.indexOf). Cause besides the intellectual challenge for us, porting more also opens up php.js to all kinds of thought excercises and study purposes. And so we leave it up to the developer to decide what to take from this resource. And what not.

It’s not new – the project’s been around a while and went to GitHub last September. However, it’s noteworthy as it appears to be fairly unknown in parts of the Javascript community, judging from recent Twitter responsage to a mention of the project. (It was news to me, and I dabble in PHP.)

Moreover, there is significant progress here: project founder Kevin van Zonneveld yesterday announced CommonJS support. The homepage indicates it’s “first steps”, but longer term, this potentially brings a huge corpus of library functions into the realm of CommonJS, a win for reuse and a win for all the PHPers getting into JS.

I thought the project was kind of odd at first but have later found times were I needed to do something in JavaScript that I know PHP has a built-in function for. Was nice PHPJS had already ported a JavaScript equivalent that I can grab quickly.

It’s horrible IMO. The code itself isn’t all bad, although many of the functions leave a lot to be desired (see: exit, wordwrap, array_push … and a bunch more…). I can’t see why one would want to do this — PHP and JavaScript are so different.

Since JavaScript is the domain of many different server-side camps (Ruby, PHP, C#, etc), we’re used to getting some heat from people not so PHP-minded. That’s to be expected & ok I suppose.

I love JavaScript (to do php.js we actually had to write a lot of it ; ) but it’s just not fully equipped with high-level functions. And that’s ok. Many other libraries exist to fill this gap (http://jsclass.jcoglan.com/ for example), feel free to use any of ’em.

We’re just another resource for those that need functionality and aren’t about to build it from the ground up. You’ll be amazed how tricky it is to write a decent strtotime, sha1, bin2hex, number_format or even stripslashes (I promise your first attempt will have at least 1 bug).
Having such functions out there that are being tested, bugfixed & improved upon by thousands – and being able to just take that & use it can save you a lot of trouble, I think.

Yes there are some functions that don’t make a lot of sense in the browser world.
Keep in mind that Sometimes they’re meant for server-side JavaScript, Sometimes they’re used to configure php.js,
and yes, Sometimes it was just too much fun to see if we could do it : ) Sue me (please don’t)

Of course we could have tried and fix all of PHP’s mistakes while building these functions, and probably make some of our own in the process.
But I don’t suppose that would have the functions any easier to work with.
Millions of developers already know PHP’s API by heart, and though I like for folks to learn, I don’t want them to waste it on another set of API conventions while I can’t really offer added value in return.

That doesn’t mean however that someone can’t fork our Git repo and start fixing those annoying needle/haystack and naming inconsistencies, anyway. I mean, it’s all MIT so do as you please.

I do like phpjs: we’re moving in a direction where we may share templates between php and javascript and sometimes phpjs functions – with a bit of a fix – just come in handy, like for example when I’m converting a php template to a javascript template and I need a quick object count or something similar.

I really don’t see the point I’m afraid. Fair enough, I understand that its not a vast library but a variety of functions to pick and choose – in that regard, it could be useful. But if you concede that the PHP API is inconsistent and unwieldy, why go to the trouble of replicating it? Why not aim for something better?

@kissmyawesome: I think it’s like why go with English instead of Esperanto… Esperanto may be more consistent in its rules, but we’re also dealing with people who don’t want to start all over (and as with Esperanto, since our governments have not agreed to an international conference to standardize on it and teach it in all schools of the world, since whatever API we came up with would also not be familiar and standard, people are less interested in learning yet another API–while PHP, on the other hand, like English, can act more like a de facto API/standard). There are definitely cases for starting over, and all power to you if you do, but we think it’s sometimes it’s easier to deal with the ugly reality and standardize on that (HTML5 is kind of doing this also in making current (complex and ugly) implementations the standard, detailing all of the processing rules, rather than starting over and migrating to the simpler-ruled XML).

@kissmyawesome – I hear you. You know, it wouldn’t take _that_ long for someone to review the hundreds of functions in PHP and redesign argument order or naming (e.g., underscores vs. none, whole words vs. abbrevs, removal of redundant “array_” in the context of an array class, etc.) and then try to promote that as a new “standard” API (maybe even PHP would be amenable to it!). But again, without a strong effort to promote it and maybe formalize it so that it can become an effective standard, such an effort might lead to an uglier reality that no one ends up wanting to take the time to learn a whole different (and not well used) API when they can just use the PHP API they may already know which also has a side effect of allowing them to learn more about PHP if they do PHP coding. If someone can get a standardization effort going, maybe we can get our compiler to generate modified versions of the functions–just an idea anyways!

@emehrkay – Since JS has no associative arrays, Kevin took the tough but reasonable design decision to let ubiquitously-used object literals fill that gap–despite the admitted challenge presented by the ECMAScript spec which says that iterating object properties is implementation dependent (though it seems to me that it is really IE which is the barrier here since if you delete a property, IE actually remembers the fact the property existed there earlier if you try to add it back later, thus making it impossible for us to sort such arrays in place, at least in IE). We try to return a genuine JS array where it makes sense and where the original input was an array, but when we mimic the PHP functions which allow non-numeric keys (or allow complete removal of elements while preserving keys), it wouldn’t make sense to return a regular array (well, in the latter example, it would be possible, but it would lead to a misleading case of the array having undefined values in the old places and preserving the array’s original length despite the removal). It sure would be nice if ECMAScript could require sequential iteration of objects since building a workaround object is quite ugly.