
React is a PHP port of NodeJs non-blocking I/O platform - romainneutron
http://nodephp.org/
======
Edootjuh
Let me make sure I understand...

Is this meant to be run on a web hosting service that supports PHP in the
'traditional' way or do you need permission to run this as a daemon?

If it's the former, I can definitely see its benefits, but if it's the latter
I can only imagine the target audience being people who refuse to program in
anything but PHP and people who are by some bizarre policy required to use PHP
but are allowed to run their own HTTP server.

~~~
vog
I fully agree that for a new project, you shouldn't use PHP for any other
reason than the ubiquitous hosting.

However, for existing projects and/or existing teams there might be another
reason to stick with PHP: As a common denominator across all team members.

~~~
jtreminio
Or because I really enjoy using it, I'm comfortable in it, and my products
work?

Blanket statements like yours reek of elitism and have no real value behind
them, other than "this language sucks you should use this one".

~~~
ralfn
Not all quality aspects of language design are subjective. Even its authors
fully emphasize that this is not how they would intenionally design a
language, but PHP just kind of grew from a template system and very practical
requirements.

There are many reasons to pick/use PHP, indispite its (lack of proper)
language design. Easy to find extremly cheap programmers. Easy and cheap to
host. Good and fast c based libraries.

But in no reality is its language design considered competitive by any one
except by uneducated hobbyists.

~~~
ralfn
@jtreminio

I did not claim one cannot run succesfull projects in PHP. I stated the exact
opposite. And im doing that again now, in the hope your reading is just
suddenly improved.

PHP has a legacy. It started off as a template language, and slowly got more
and more control structures. So, its an accidental programming language.

Language are not competitive, but language design features sure are. Nobody
with the actual skillset to design and implement a programming language would
consider, for example, merging vectors and dictionaries into some kind of
mutated frankenarray.

This does not make the language unusable. And language design features are not
the most crucial arguments to pick one language over the other in the short
term. But they are, for a community and industry in the long term.

To my surprise, i read in this thread that PHP now finally has a cyclic
garbage collector. That's a good example of a competitive language design
feature, which utility is not in any way subjective. A large range of
algorithms and design patterns couldn't be implemented efficiently or
effectively without this particular feature.

And its too easy to cry "elitism" every time somebody points this out.

~~~
notJim
> Nobody with the actual skillset to design and implement a programming
> language would consider, for example, merging vectors and dictionaries into
> some kind of mutated frankenarray.

Why is this bad?

~~~
ralfn
Well, answer me this:

Whats the order of complexity of adding an element in the middle of "an array"
in PHP?

So, it's bad, because it makes it very confusing, what the exact
implementation is. If you can't tell how much slower your algorithm that
calculates something from an 'frankenarray' gets, when the array gets bigger,
you have a problem.

That's one problem. The other problem is with language itself. When we call
something an array, which isn't actually an array (an array being a very
specific implementation of a vector) people get confused.

Imagine how you would feel if PHP used the word 'variable' to mean function
and the word 'function' to mean variable.

So, a hash and an array are not just semantically different (that they refer
to a completely different ADT's), but they are also completely distinct
implementations of those ADT's.

Now, this is not a problem, when you are using PHP as it was originally
intended. To add a small bit of logic to a template that mostly uses fast,
well written c functions in it's built-in library.

But people are abusing PHP to write large scale libraries and frameworks. Many
riddled with security issues, and unpredictable performance bottlenecks,
because the language wasn't designed to actually allow you to write well
defined algorithms.

Now, we've seen workarounds for these problems. Facebook wrote a PHP to C
compiler, and moved all crucial algorithms to C. You can use unit-testing to
supplement the lack of any usable type information, and to combat the
automatic casting that PHP does (which creates all kinds of bugs in edge
cases, that is hard to track or test against). You can use profiling to track
performance issues, and fix code that interacts with frankenarrays, in a sort
of trail-and-error kind of way.

People once wrote all their code in ASM. Discipline can make all the
difference. But highly skilled disciplined, well educated professionals aren't
the target audience of PHP.

All this required discipline can be justified on practical grounds. PHP
programmers are generally paid the worst (or as an employer would call, are
the cheapest). Hosting is cheap. And for many use-cases you can just drop in
ready to go code (Wordpress, Drupal, Joombla, etc.) and just skin it.

So, i'm not saying picking PHP is a bad financial choice for a company. If you
don't take on difficult projects, and don't intent to hire highly skilled
coders, it can be cheap and productive.

But that doesn't make the language any better..

~~~
notJim
It's interesting that I asked a simple technical question, and rather than
just answering it, you threw in a slew of insults and opinions about PHP and
PHP programmers. Why do you have such strong feelings about PHP and PHP
programmers so much? How long did you actually use PHP, and which companies
did you work for that used it?

It's not your assertion that PHP is a crappy language that I disagree with. I
fully agree there. Where I disagree with you is in your assessment that a)
there aren't many skilled programmers who use PHP, and c) language features of
PHP make it very difficult or impossible to write well-designed software.

As to your assertion that PHP is only good for simple projects employing low-
skilled developers, tell that to the various PHP startups paying top dollar
for skilled PHP developers.

PHP arrays are actually ordered hash tables. This information is readily
available. If you really need a real array, there is SplArray.

> Now, we've seen workarounds for these problems. Facebook wrote a PHP to C
> compiler, and moved all crucial algorithms to C.

At the scale of Facebook, nobody uses scripting languages, so I doubt this is
purely because of PHP. This would be like me telling you to not to use RoR
because Twitter switched to Scala (people said this, but those people are
stupid and I'm not among them.) Twitter and Facebook have problems you and I
are unlikely to have.

> You can use unit-testing to supplement the lack of any usable type
> information, and to combat the automatic casting that PHP does (which
> creates all kinds of bugs in edge cases, that is hard to track or test
> against). You can use profiling to track performance issues, and fix code
> that interacts with frankenarrays, in a sort of trail-and-error kind of way.

PHP's type system is crazy, that is absolutely true. But it's not as hard to
work around or as frequently a problem as you're suggesting, at least in my
experience. JavaScript is another language that has a crazy-ish type system,
but it doesn't get the hate that PHP does.

I have never had a case where PHP's arrays caused performance problems, but
that's probably because I've also never written an application that didn't
interact with some kind of back-end store like a database that was inevitable
slower. I've done a fair amount of work to make apps faster, and the big wins
were always in fixing bad data access or caching patterns and algorithms. I
imagine that there would be a point when I need to worry about not using PHP
arrays, but I guess I haven't hit it. And again, if/when I do, there's always
SplArray.

> But people are abusing PHP to write large scale libraries and frameworks.
> Many riddled with security issues, and unpredictable performance
> bottlenecks, because the language wasn't designed to actually allow you to
> write well defined algorithms.

There are some really shitty PHP projects. I suspect a big part of that is
that they took off before there was the widespread knowledge of best-practices
we have now. (I'm assuming you're thinking of wordpress, drupal and joomla.)
I've worked with Wordpress a bit, unfortunately, and the main reason it's so
damned slow is because the queries are badly written, and the data access and
caching patterns are awful. PHP's arrays never crossed my mind as a
bottleneck, because they don't even show up in my profiling tools.

For what it's worth, I used to see a lot of people's code because the company
I worked for required code samples when we were interviewing people. I saw a
lot of really shitty RoR code, and I do not blame that on the language or the
framework.

~~~
ralfn
>Where I disagree with you is in your assessment that a) there aren't many
skilled programmers who use PHP, and c) language features of PHP make it very
difficult or impossible to write well-designed software.

a) didn't make that assement b) ?? c) difficult, yes

>As to your assertion that PHP is only good for simple projects employing low-
skilled developers, tell that to the various PHP startups paying top dollar
for skilled PHP developers.

No, my assertion was that PHP is only a good economic choice, when you choose
to hire low-skilled, cheap employees. That's its niche.

>Twitter and Facebook have problems you and I are unlikely to have.

Agree. But that does not make what Facebook did with PHP, anything less than
working around the issues caused by the initial commitment to PHP.

>JavaScript is another language that has a crazy-ish type system, but it
doesn't get the hate that PHP does.

But it did. Even now, claiming that Javascript's language design isn't optimal
isn't somethign people will argue against. Say the same thing about PHP, and
you get threads like these...

>I have never had a case where PHP's arrays caused performance problems, but
that's probably because I've also never written an application that didn't
interact with some kind of back-end store like a database that was inevitable
slower.

Now, the type of problems I'm pointing at, are the ones that read their head
when the datasize gets larger. For example, an algorithm interacting with an
array in PHP. Every loop it inserts or removes an element. Now depending on
where that data can be found in the array, and if it's key is a number or a
string, if these number-keys are close together in range or not, the
algorithmic complexity is anything from O(n) to (2^n).

In other words, the normal fauna of sorting algorithms are very hard, if not
impossible to correctly implement in PHP.

This is not very relevant, if you just need a good sorting function for your
array, since that is build-in. This is not relevant if you datasizes are
always small.

So, this is not relevant in the small-scale world. But if there is a chance
that will need to be implementing a complicated algorithm in PHP, that perhaps
needs to interact with large datastructures, than PHP is a dangerous choice.

Beyond the limited scope of a database powered template with a bit of logic,
it is simply not suited. It is not designed well enough to be 'general
purpose' programming language, and its civic duty of all to warn those who
think it is. (like the authors of this Node.php project)

~~~
chipotle_coyote
While this is merely anecdotal, I feel compelled to note that I'm a PHP
programmer -- as well as a Python and a Ruby programmer (in the sense of
"somebody has paid me going market rates for working in these languages) --
and even for PHP work, I am not cheap. And, while I am of course a biased
observer, I'd say I'm not low-skilled, either.

I generally agree with your technical criticisms of the language (I generated
a bit of heat and light a few months ago with a blog post called "PHP is not
an acceptable COBOL"), but I don't think your assertions about the economics
are entirely correct. I don't think most companies choose PHP because they
expect it will let them get cheap help -- I don't think most companies
actually _choose_ PHP. They end up with PHP for any number of reasons that
don't have anything to do with long-term planning. (Also, if you were putting
together a database-backed web site in the early 2000s, there's a very good
chance you'd go with either ASP or PHP unless you had a _lot_ of experience in
web programming in another language. After you built up sufficient inertia,
switching would be difficult.)

On the flip side, there are a _lot_ of companies out here in Silicon Valley
using Ruby on Rails because it fits very, very well into the niche you
describe: take a bunch of Rails gems and learn just enough Ruby to hold it all
together with spit and duct tape. If I were starting a company and wanting to
hit the "low-skilled, cheap niche," the only downside to choosing Rails is
that low-skilled Rails programmers frequently don't _recognize_ that they're
low-skilled, because the mere fact that they've chosen Rails makes them think
they're definitionally awesome.

(N.B.: I like Rails a lot, but gosh, it's attitudinal.)

------
michh
How is PHP's garbage collection for these kinds of things? Usually, it doesn't
need to be that good as you can just release all the memory after a request is
processed in the typical way PHP is used.

Anyone have experience running PHP-based daemons or things like that? If your
React/NodePHP-application crashes on a 'Allowed memory size exhausted' every
two days, it'll get old quick.

~~~
rmccue
5.3 and 5.4 are a lot better, but I can't say I'd use them for long running
daemons. Personally, I usually use Python daemons that spin up a PHP instance
if they need.

~~~
conradfr
GC is sure better in 5.3 as it was not available in 5.2 :)

~~~
shakesbeard
Well, I think there was GC but no cyclic GC in pre-5.3.

------
hinathan
I built the same basic thing a year ago (using libevent for php, same general
API as node.js) for a particular project.

<https://github.com/hinathan/edges-php#summary>

For some these php-but-like-node.js projects are abominations but there are a
few reasonable use cases.

Of course the vast majority of php and the php 'class library' isn't
appropriate for this programming model but neither was most of the existing js
corpus before people built an ecosystem around node.js.

~~~
IsaacSchlueter
Actually, a surprising amount of JS code was already built around event-driven
IO. It took a remarkably small amount of work to get YUI3 running on node, for
example.

------
flashmob
It should not be surprising that this can be done in php.

The libevent extension for event driven non-blocking I/O has been added some
time ago. Together with many nice new features since PHP 5.3, including
improved garbage collection and speed improvements, it naturally follows that
php will be used for these things.

Btw, the libevent extension is really fantastic. If you're doing server
programming, take a look at it, it will turbo-charge your server
<http://php.net/manual/en/book.libevent.php>

Perhaps php lost some if its sexiness, but it's still rapidly evolving and
improving.

------
FuzzyDunlop
So is it called React, or Node.PHP? It seems a little confused with its own
identity.

~~~
IsaacSchlueter
Indeed. It almost seems like Node.js is somehow involved with this project.

(It isn't.)

------
triathlete
To say this is a port of Node is to misunderstand 99% of what node is. In fact
i dont really understand why you even relate this to node at all and why you
use the node logo. Call it evented php or or a port of Tornado or something
but its not node. If you want to learn what node is listen to Nodeup. Its an
awesome podcast with core node people in it that talk about what node is and
why it is what it is and why javascript is so integral to it.

------
KonradKlause
For the German readers, fefe predicted node.php:

<http://blog.fefe.de/?ts=b1b92654>

------
Kiro
I'm proud to say PHP is my main language and this looks great.

~~~
DanWaterworth
This is a little off topic, but can I ask, have you used any other languages
in any significant way and if so what keeps you coming back to PHP?

~~~
kamaal
There are a lot of reasons why people coming back to php. The main is its a
language for 'getting things done' in the real sense. A lot of languages claim
that in their own way. But in my experience nothing comes close to Php and
Perl in the raw power, freedom and ultra fast pace of development they offer.

The other neighboring competitors of Php, namely Python and Ruby are in the
web development market with the help of frameworks. I have yet to see a
serious programming shop that would bet its billion dollar business on
frameworks built by others. Small libraries I can understand. But building the
spirit of your business and betting its survival on a Frameworks is just out
of the question.

Php is the DSL for the web. And it does its job far too well. It can be
learned quickly and you can build things quickly with it. Its installed
everywhere, you can get cheap hosting. Tons of document and help available.

~~~
ralfn
>> I have yet to see a serious programming shop that would bet its billion
dollar business on frameworks built by others.

Even the majority of PHP development uses frameworks these days.

You didnt answer the questions at all. Nor did you provide any of your
qualifications with actual arguments.

And you dont "experience raw power" of a language, instead one can actually
meaure it and formally classify it.

Here is a question for you to put things in perpective. Whats the order of
complexity of adding an element in the middle of "an array" in PHP?

I think you are confusing "raw power" with the sound an idiot makes, when they
write bad algorithms, in languages with questionable language design.

~~~
kamaal
>>I think you are confusing "raw power" with the sound an idiot makes

No replies to ad hominem attacks.

>>when they write bad algorithms, in languages with questionable language
design.

From when was that any criteria for success? Worse is better won a long back.
Fighting that has proven to be futile.

~~~
ralfn
>No replies to ad hominem attacks.

I'm sorry, you are right. That was uncalled for.

>From when was that any criteria for success? Worse is better won a long back.
Fighting that has proven to be futile.

No, it hasn't. Pragmatism won over theoretical grounds. And there are very
many pragmatic reasons to prefer PHP for certain projects. No one is arguing
against that.

But, with legacy and a changing market, some of those pragmatic choices come
back to bite you.

There are many ways to combat this. One can evolve the language, for example.
This has worked better for some languages (Javascript comes to mind) that
share some of design flaws in PHP, than it has for PHP itself.

What I am arguing about, is that, we as an industry, as a community, as a
profession, we shouldn't be aiming for a future where PHP is still dominant,
any more than we should be aiming for a future where horses are our dominant
means of transportation.

Now, maybe we can shoehorn modern features into PHP. It has been tried with
PHP4 and PHP5.

But for what reason? There isn't any decent implementation of PHP (performance
and stability wise). Other syntaxes aren't that hard to get accustomed to. The
algorithmic complexity of core operations has changed between versions. It's
not like there is any important code written in PHP, that must survive some
transition, like there is with C.

Is it just to keep those on board, with no academic training, who only know
PHP? If they were capable of learning PHP by themselves, would other languages
really be that hard for them to use (or abuse)?

------
rheide
Target audience mismatch.

------
nodesocket
Interested in seeing a benchmark between React vs native node hello world.

~~~
lstoll
I'd rather see a benchmark of a more real-world case. These hello world
microbenchmarks don't show anything.

~~~
Nikkau
It's useless for absolute perf but to compare 2 solutions doing the same job,
it's a good start.

------
usamec
this is a joke, right?

~~~
fsniper
I think it's not a joke. look at the source code on github.

But I can't understand this elitism. Programming language choice must not be a
cult. Anyone should be free whatever language they like to use whatever they
want to do.

So bringing something good or seemingly good to any ecosystem should not get
bad responses. They are trying to combine two worlds into a "new choice". Let
them do even if yo do not like it. Nobody asks you to praise but just don't
give uninformative bad responses.

~~~
usamec
Trying to build fast platform on top of a superslow language is a joke.

~~~
fsniper
PHP as a platform is not super slow. Have you ever visited
shootout.alioth.debian.org? most of the time PHP performs better than ruby,
python or perl. It's up to 3 times faster.

------
adeelk
Simple deployment is the only advantage people usually cite of PHP, and this
seems to eliminate that. So, why?

~~~
Joeboy
Availability of coders is another advantage. Not necessarily particularly
great coders, but they have the numbers.

------
mmaunder
This is awesome, congrats! Long polling coming soon to pure PHP with 10,000
times less memory consumption.

~~~
Kudos
Long-polling of what? Connecting to any datasource is going to block the event
loop.

~~~
mmaunder
Clients connecting (long polling) to the node.php server which is presumably
using epoll.

------
tdot
PHP doesn't have closure like JavaScript. JS accomplished language for evented
approach. Because JS have got closure, cascaded scope and prototype chaing.

~~~
notJim
PHP has had closures for 3 years.

~~~
tdot
yes it's true. but didn't have closure like js. did you try to make nested
closures in php?

~~~
notJim
Yes, I've done it. Very handy for dealing with trees.

------
smagch
Luvit, Vert.x and React! A lots of projects from NodeJs. This tells how
revolutionary NodeJS is. I bet React is the slowest one.

~~~
eropple
Hate to burst your bubble, but "how revolutionary node.js is" has very little
to do with anything. For example, Vert.x is a formalization (albeit a good
one) of Netty-based practices we've been using for years in the Java ecosystem
--I've got a "Vert.x prototype" in my projects graveyard and it's been there
for years. Pretty much the same idea, though with a lot less love poured into
it.

Don't get me wrong, I like Vert.x's API quite a lot and it's why I'm looking
at using it. But it's not really "new", it just has a nicer coat of paint. And
claiming that node.js is "revolutionary" because of it is a fairly criminal
disservice to the ridiculously smart people behind Netty, Mina, and similar
projects that have been around for a long time.

------
benschwarz
I want to say this library is the best troll ever. Then I see all the real
code on Github.

~~~
Zash
Dear lord, what will they come up with next? PHP as browser scripting
language?

~~~
tomjen3
There is a php to c++ compiler and with emscripten you can compile c++ to
javascript....

------
gcb
I'd see more value in a non blocking Apache.

------
tknew
ugly

------
endymi0n
Why? Why? Whyyyyyyyy???? o.O

~~~
gpmcadam
Why not?

~~~
Kudos
Well, for starters the whole standard library is blocking, so are all the
third-party libraries.

Then you have the fact that any good developer who knows PHP is also going to
know enough Javascript to get by already.

The only reason I can think of for this to be a good idea is to allow you to
use your existing PHP libraries in an evented system. React does not (and
cannot) do this.

