5 ms·
That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP, and with php-fpm and mod_php it has first class support with Apache and Nginx. No
by bkanber 10y ago
That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP, and with php-fpm and mod_php it has first class support with Apache and Nginx. Node isn't very good at HTTP, Python doesn't have first class support with HTTP servers, Java has great HTTP libraries but is stateful, etc.
If you want to handle HTTP requests quickly, reliably, repeatably, with minimal setup and maintenance, I still argue that PHP is one of the best. And yes, because of Apache and Nginx, but that doesn't nullify the point.
- astrodust 10y ago"Node isn't very good at HTTP" is just blatantly false. Most languages don't "have to do HTTP" and those that do often do a pretty terrible job. Somehow Node not only does it, but does it well, where a bare Node process behind some load balancers is often enough to get the job done. PHP on the other hand needs all sorts of hand-holding to work properly.
- bkanber 10y agoNode is stateful and not threaded, but yes you're right that it serves http out of the box. Http was a module in the early days but I see now it's core API and has been for a while. My mistake.
- astrodust 10y agoNode isn't a pure functional language, and neither is PHP. I'm not sure what you mean by "stateful" otherwise. JavaScript does have threading facilities like WebWorkers, but they're often largely overlooked since the code complexity that comes with it isn't worth it and the multi-process model generally works fine. A single Node process can do a lot of work because of the aggressively asynchronous approach to processing it takes. Node + Express is actually a pretty slick package.
- fiedzia 10y agoWebWorkers have nothing to do with threading. They will not let you share memory, and this means that you waste time on seriazlizing/deserializing anything you pass to them, so from optimization point of view, they are more like processes. This makes js completely unsuitable for things that are data-heavy and cpu-bound (just cpu-bound may work, but it still not the best choice).
- astrodust 10y agoThey do have a lot to do with concurrency, which is often what threads are used for. They do have limitations to fit in with the JavaScript model. JavaScript is generally a lot better at compute intensive tasks than contemporaries like Ruby, Python, PHP and Perl due to the incredible performance of the V8 engine and others like it. The language is ugly, but it's more easily optimized by the JIT compiler. If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
- fiedzia 10y ago> If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development. Java and Go work just fine here and both are used for webdevelopment. My point is that js in not suitable for many cpu-bound operations and neither webworkers nor multiple processes are enough to help it with that. In the browser you don't have other option, but on the server you can (and in practice people do) use other languages like java or go (not to mention C/C++). This is were things like image processing or full-text search goes.