It's a new PHP library that allows you to access a very fast JavaScript interpreter (called V8) from within PHP. Some people aren't too happy about using JavaScript inside of PHP, their reasoning probebly being something like this:

PHP is objectively a somewhat poor language. Some of the reasons for this include an inconsistent, redundant standard library that doesn't match current best practice, features that don't work together optimally, redundancy, new language features that are later once again removed, lack of various popular features that many people feel are important for high productivity.

It is felt by some that PHP by virtue of being a poor but popular language has attracted a large body of sub-par programmers.

JavaScript is not as universally loathed as PHP, but even it's admirers admit that JavaScript has seem peculiarities that make it uncomfortably easy for bad programmers to write very bad code.

For the above reasons, people fear that once the PHP coders get a chance to start using both PHP and JavaScript together, the result will be the most spectacular clusterfuck of all time.

To be fair, the V8 code runs the js natively, in the V8 engine. All that's happened here is the ability to take a string of js code and pass it to the V8 library from PHP. You can get the same effect by runng V8 from the shell against a temp file; this approach obviates the need for a separate process to do this.

A little context then: BF3 is a game, Battlefield 3. Metro is a Close Quarters focused map. With 64 players on it, it is a total clusterfuck. The USAS12 is an automatic shotgun. The frag rounds are explosive rounds, they explode on impact, making the USAS 12 a Handcannon. Combine both, and then you get V8 for PHP

Oh, I remember reading some php, that was actually just html with parts php. But some parts were javascript, with some parts of php inside the javascript. And in the javascript, there were some nice eval functions, and in the php there were some double escaped strings (as the javascript needed escaping of some chars), or, due to the evals, triple escaped ones. And in the middle of those strings, the php would end or start as to let some plain html in. And this was just something someone wrote without trying to make it complicated.

With the javascript interpreter inside php, we can add some extra indirection in there to spice it up a bit :) Very flexible!

That was mostly due to type coercion, which is generally avoidable behavior. You just need to be careful that operands are of the type you expect, and to use === instead of == to check for equality, which avoids confusing type conversions.

What other languages do you even use that you think PHP is so amazing?

Most dynamic languages have some kind of optional strict typing

All languages have hashes or arrays and most of them work better and look nicer than PHP's "associative arrays"

WTF, "c-like" == short learning curve? I guess if you already know C.

I have no idea how you are quantifying this statement. "Doesn't randomly crash" seems pretty far from high praise to me.

It doesn't scale that well. (Most people that scale PHP don't actually do anything other than just use a bunch of memcache and/or a reverse proxy). If you have numbers to prove otherwise I'd love to see.

If I had to pick an actual advantage of PHP it might be that you can turn it into C fairly easily since it largely just wraps a bunch of C libraries. But if you really want your app written in C you should probs just write it in C.

Variable parameter lists (with defaults) can be implemented in JavaScript using the arguments object, however without using a helper it's not nearly as sugary as PHP.

As for includes, depending on where your JavaScript is being executed you might be able to dynamically load stuff with <script> insertion, CommonJS's module system, or some other script-loading scheme.

Please note that I'm not trying to start an argument or anything; I agree with your overall sentiment.

Incidentally, the language doesn't have much to do with the quality of coder. The coder does that work.

I mean, seriously, I've seen some terrible Java coders, and that language is one of the better-architected ones out there. And, yes, they get jobs. Don't ask me how, but I suspect it's because your code reviews don't go on your resume.

Looking at it from a language standpoint it is quite nice. Closures, first-class functions, interesting OOP, C syntax... it gets a lot right.

Plus there was that whole NBL/Next Big Language blog deal a few years back about ECMAScript4 and how it was the bomb. Then Adobe based ActionScript3 on ECMA4 for Flash, all the major browsers delayed plans for JS2, and it lost its shiny. It's too bad too because that optional static typing and various other improvements would have been really nice right about now. :(

I digress. Point being, as a language, JS is fun and interesting and can be elegant if done right.

THe static typing peices went against what JS is though. It adds a little more efficiency in things like statically typed arrays which chrome supports - but as a whole its nice only having strings and floats.

Yeah, true, but since actually working with some statically typed languages, I've found its main advantage is in enforcing stuff you want to be enforced. Which is why optional static typing is pretty sweet. You can still use JS like JS was meant to be used, but when you need to really ensure something is enforced, you can do that too. Not just for the compiler, but for your process.

I disagree. While there are some pretty major fuckups in JavaScript, it does get a lot of things right as well. I especially like how they reuse the same concept in many different ways, e.g. objects are also hashes are also namespaces. Implement one language feature in a way that it becomes so powerful that you can do many different things with it.

As someone who's coded professionally in: Objective C, C++, Java, Ruby, PHP, Perl, JavaScript, and AS3, is well-trained in design patterns and architecture: You are wrong. I love JavaScript, and I know many who do. It's simple and elegant and does exactly what it's meant to do. The only things I wish it had are Ruby's terse block syntax for closures and true inheritance/interfaces.

There are similar modules for Ruby (rubyracer and rubyrhino). I did a project where we used a javascript-based templating language (handlebars) in a Rails app that rendered the template server-side when you navigated directly to the url, but rendered it client-side side when you clicked on a link in the page. We could use the same code in both places, while still being able to use everything that is convenient about Rails.

If performance overhead is a consideration, why are you using a non-optimizing scripting language? Why are you using one of the slowest options in that family of languages in PHP?

If runtime performance is anywhere near your priority list for a project (performance, not scalability), I think that PHP has to be immediately disqualified because it is the slowest way to write a web application. As far as I can tell, its runtime is the slowest, but even if it wasn't, its runtime model of spinning a new process and reinitializing everything every request is an absurd waste of resources. There are cases where PHP is not a terrible choice for a project, but not in a resource constrained environment.

Just to be that guy. Facebook does ridiculous amounts of traffic. Pretty much any dynamic language was going to have to be revamped to handle their needs. This is a false way to try to show that PHP is slow.

*Edit: just to clarify: PHP IS comparably slow, but that example was not appropriate for showing it.

You make a good point in that the architectural goal of using mustache on both server/client side should involve having one, authoritative code source to transform (model, etc) data into data format consumable by mustache. This can be accomplished by specifying a server side class to handle the transformation (on the server side), and the same class can be used to transform your data into JSON that can be reused on the client side. That way, on the client side, you getting a response that is (as far as mustache knows) that same data that was used on the server side and all you have to do is render the template with the JSON data. The client side should be 'dumb'. I think that your problem is that you implemented the data transformation (from JSON/XML/etc to mustache data) on your client side and then decided that this should be done on the server side to reuse your code. It was good that you looked to reuse your code, the problem was not doing the transformation from the server side to begin with. My 2 cents ;). I'd have to vote against server side javascript (for your issue and in general).

The server-side rendering was done so that the pages could be crawled by search engines. The client-side rendering was done so that there could be persistent elements on the page (in this case a music player).

It's not moot in any way by Node.js, because Node.js leaves you stuck in evented programming hell with javascript as your only option, while these projects lets you call out to javascript for very specific things. Not all of us have interest at all in running Node.js, but that does not mean there aren't tons of use cases for wanting to be able to execute some javascript here and there. For example, if you want to let your Ruby apps safely execute user provided scripts.

The top comments consist of saying "this is bad because PHP is derp herp and Javascript is herp derp so now PHP coders will derp hep while they herp derp". This whole thread brought my esteem of r/programming way down.

"Why you should x" "Why you SHOULDN'T x" "What you missed in the whole should/shouldn't x debate today" "Why people in San Francisco x better than New York" "Why you should do x better in New York than in San Francisco"

Are the demographics of HN's user base really anything close to the way it's portrayed? I can't imagine too many serious software people would want to wade through that much linkbait. I feel like it's bad for me in a way that I never felt even on my worst days on reddit. I've never been to the Bay area and I can't help but think it's prejudicing me against considering a job there.

HN has some smart people with good ideas. Mostly, it's a bunch of leeches who either want traffic to their shitty blog or get angry when someone in the comments doesn't agree with the hive-mind (much like reddit, and probably just like any other group that considers itself "enlightened" but is bound by the same ape-like nature that everyone else is).

I read HN because for each 100 links that goes on there, there is at least 1 per day that is really interesting and worth wading through all the garbage for. Plus, people with a good amount of experience tend to comment on technical issues, which can give really good insight.

EDIT: as far as the bay area goes, I'm not a fan. People are snobs, dicks, etc etc. It's great if you love the tech world and can stomach complete tools getting millions from dumbass investors for really retarded ideas. If you can find work in Santa Cruz, go there. It's close enough to the action, but far enough to get away from the stench of it all. Then again, I'm biased because I love skating/surfing.

Sweet, that actually seems really cool to me. Assuming you can "export" PHP functions into the V8 runtime, maybe you could do away with PHP, the language, entirely. It's like Node.JS, but for normal shared LAMP setups.

The point is to let your users safely create scripts for a parent application. Totally sandboxed (they only can manipulate the variables, objects, and methods you give them access to), and completely open to what they can accomplish.

A few examples of why this would be useful:

Many years ago I wrote a PHP web-based game called Legend of the Green Dragon. It started as an homage to the old BBS door game Legend of the Red Dragon. One of the features are companion and buff systems that are scriptable. For example, a "Pink Elephant" buff which increases attack and decreases defense as you get increasingly drunk, but only over a certain drunkenness threshold, as well as doing damage himself. Sure, that's easy to write in game code, but the point is to let the admin create his own unique buffs to differentiate his server. It was a lot more challenging to create a DSL (Domain-Specific Language) for that sort of functionality, and it performed like crap.

If I had had something like this, I could have made scriptable enemies too. Badguys who know how to heal each other, or maybe a blob monster which halves in power, but splits in half each time you hit him. Maybe a monster which can intercept attacks against a weaker higher-dps brethren. Whatever, it's up to the admin, and what he can conceptualize / realize.

Business rules: if you're a SAAS (Software as a Service) provider, you might want to let your customers customize certain aspects about how your software behaves. It sure would be nice to provide them a runtime (and maybe sell some consulting services for helping them create software in that runtime) rather than having to pre-guess every possible use case and have a setting for it.

Wikipedia is moving in a similar direction. They're going to be implementing a LUA runtime for templates because the DSL they've been using has met its natural limits. You'd use V8 for the same purposes as you'd use LUA for - an embedded scripting space for your users to safely perform complex operations.

Not gonna lie, lotgd inspired me to learn PHP and thus decide to major in CS. I was convinced I was gonna be a web designer, but after playing lotgd I wanted to make my own for my own site. It never really got anywhere, but it was my first attempt at a major project and it really got me into programming.

Completely unrelated to OT, but it's just odd to run into you now on reddit.

It's awesome to hear stories like yours. It's an odd feeling to know I helped set the course for someone's life like that. Also it's a bit humbling, when I started the project, I just wanted a way to play LoRD in my browser, I hadn't really set out to contribute to anyone's destiny but the dragon herself.

You know, I was about 13 or 14 or so when I found out about lotgd and decided I would get some webspace to install the script on. I loved doing it and ran a small server for me and a couple of friends. That motivated me into learning PHP and today I'm in college, learning to be a web developer. Thank you :>

I love hearing stories like yours! That's awesome! I wish my PHP code in LoGD was a better example, I was just out of college when I started that project, and I created myself a lot of legacy junk to deal with =). It was also my first significant PHP project, so there were a lot of learning bumps and bruises too.

I'd been working on a 2.0 version in around 2004 / 2005 or so, which broke a lot of compatibility but shed a lot of the legacy problems. That was about the same time I got into a job that required 10 hour days + 3-4 hours commute time, so my free time dropped to about zero for the next 6 years or so. I never finished that: I did hand that code off to the Dragonprime crowd, but I don't think it ever went anywhere.

:> No problems, I wasn't looking too much at the code back then because it was too advanced to learn anything from for a complete beginner, but it still got me into looking up some guides and tutorials, and to try out things

Aah, it should have been object oriented. Would have been so much simpler, but I just didn't get objects like I should have when I was writing that subsystem. Still, pretty happy with where it ended up! Glad to hear someone else found some spark of inspiration there!

Business rules: if you're a SAAS (Software as a Service) provider, you might want to let your customers customize certain aspects about how your software behaves. It sure would be nice to provide them a runtime (and maybe sell some consulting services for helping them create software in that runtime) rather than having to pre-guess every possible use case and have a setting for it.

My name is the first name in the copyright. I wrote it in some sense, but of course being open source, it's actually the product of a number of talented developers. I started the project though, and worked on it for about a year before even showing it to friends and family, then later open sourcing it.

I'm pretty sure people have always hated PHP even at the height of its ubiquity. It was my first programming language nearly ten years ago and at the time, even without another language to compare it to, I bitterly hated the inconsistent standard library and thought that even I could have done better. Then people kept berating me for only knowing PHP until I learned some more languages.

It's just more hated now because we've had more practice with this whole web programming thing. PHP itself is a little better than it used to be, but other things simply fill the same niche better, and at this point PHP subsists purely on inertia.

edit: and the number of absurd bugs that make it to stable releases of a supposedly world-class platform is just unacceptable compared to most of its competition.

I cannot stand curly braces now. It's like when you make the jump from VB to C# and you have a, "Holy shit, VB is incredibly verbose" moment. I can't handle PHP anymore. I use Python for everything now.

You're probably right in a way. The programming world has matured. It's sort of how "programmers" used to code for IE5/6 and get away with horrible HTML markup which broke on other browsers. The language catered to those so that a larger number of people would pick it up. But it is really the responsibility of the programmer to do a good job coding.

PHP is only as bad as the person using it. This functionality is hardly the worst thing in the language, and does serve a purpose for the talented PHP programmers out there. (And yes, there are plenty - lots of major sites use plenty of PHP)

I used the similar pyv8, which is v8 for python. It actually saved my life.

I used the fat client paradigm for better reactivity for the users but I had had to check server side that calculations made by the client are correct. I didn't want to code in js server side, nor translate the same javascript code into python. Instantiate a powerful javascript interpreter is the best thing you can do in this case.

I think we don't have to worry, no body will instantiate a javascript interpreter in the middle of php code if it is not absolutely necessary.

I love this as a front-end JS developer. I can write my templating, API calls, etc for the front-end. We can use pushState for URL "faking," but then when someone hits a page for the first time, we can generate the actual page content using our javascript we wrote for the front-end via PHP (as opposed to basically writing our front-end in JS and PHP and maintaining two separate codebases that generate the exact same HTML).

We were just researching setting up a bunch of node.js instances, but being able to ship this out to PHP would make our stack a LOT simpler. Sure PHP is like a dirty whore you found on craigslist, and running JS in it is like licking her butthole, but if it works and makes it so we don't have to scale www servers AND node.js servers, I'd definitely spooge.

Actually this is pretty awesome news for me. I have a CLI PHP project (yes I know, horrible language choice, just wait) and I've been stuck maintaining this beast for months without time to make a new program in Java (yes I have my reasons for Java). I was going to use Rhino in the new project to interpret a metric ton of javascript functions for data mapping, only issue is that the metric ton of functions are currently all in PHP... So if I wanted to port to Java I would have to port all of those functions all at once, now I can move to JavaScript in the existing project and it should be 100% compatible with version 2 written in Java.