|
|
|
|
|
|
by Udo
5357 days ago
|
|
|
So it's desirable to eventually converge PHP and JavaScript? You're right: I don't get it. Why then have PHP at all? I'm not saying that retrofitting a language is a bad idea per se, I just don't see the appeal of doing it when there was a perfectly fine alternative to begin with. The new array syntax is great, and introducing closures was way overdue, but this one..? Oh well, it's in there now, so I guess there is no point of discussing it. But I do believe, on a more general note, that saying "no" to features is important - and bindTo() would have been an excellent point to say no to. For better or worse, PHP is not JavaScript and vice versa. Their paradigms are not really compatible to begin with. Transplanting stuff from one to the other just because it saves 7 bytes in developers' brains is not enough of a reason to do that in my opinion. |
|
|
PHP has always been about making coding easy and fun. Since more people are doing JavaScript, it only makes sense to make things familiar.
> Why then have PHP at all?
That's a question that will have to be answered soon.
For now, the answer that I'm coming up with, is that with PHP-FPM you can make PHP properly threaded. All of the server-side JavaScript implementations are event driven. The threaded model has advantages when jobs are cpu or io heavy.
Right now, I'm working on an implementation where Node.js is receiving calls via websockets and handing that off to PHP-FPM via FastCGI for processing. A hybrid system like that has advantages of both the event model and the thread model.