If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Question: Express.JS vs PHP

first at all excuse my english. I'm from germany. So I'm the Co-Founder of a new Start Up and i'm developing our prototype atm. I have to make a big decision and could need some help.

I'm considering two programming languages for the server-side implementation. The Choices are Express.JS (Node.JS) or PHP. Each language has its benefits.

The project is a type of a social network. The main aspect is a very large database, which is constantly in use. We are talking about 500k-1000k registered Users at peak.

So, lets list the benefits of the languages:

Express:

has socket.io
is non-blocking
easy to learn
event-based
both JS on Server and Client
=> fast applications and minimized Server-Costs
BUT:
less employees which are good
the employees cost much money
not so many documentation and helpers (frameworks etc) as PHP

PHP:

Very wide spreaded language
very much documentation and frameworks
easy to handle
many many and cheap employees
BUT:
slow in the execution if there are is so much DATA

Well, PHP has socket support (e.g. see fsockopen()), and I'm not sure there's any reason to think there is any significant speed differences. If there is a lot of data, then any speed issues are most likely in the DBMS, not in the application code -- unless you've written bad code, of course. (I work on a PHP-driven site with a PostgreSQL DB that deals with millions of records in some of it tables -- though we create Solr collections for optimization of the most-used searches.)

Anyway, unless you plan on doing most of the coding yourself, I would recommend finding one or two key architect/developers you feel good about working with, then let them choose the best platform based on the combination of what they know, what makes sense with your particular requirements, and what the people they know in their personal developer network would be most productive in using (as opposed to choosing the technology first, and then hoping you can find the right people to implement it).

"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation

thanks for your answer! Aren't there speed differences just because node.js is can be written in non-blocking code? I plan to do most of the coding myself at the beginning. I have to implement a prototype and then when we raise money for the company i can get some employees. I don't want to go in detail too much. I've coded all the time in PHP. I had a conversation with some webdevelopers which all said i should use node.js and that php has no future and is just dead already. I disagree but the "new" technology is interesting and i'm getting to understand the depths of node.js.

Have you got some recommendations for some books or articles for advanced php and good db structures or mangagement systems?

First off, I am not a Node.js expert -- not really even a novice. What little bit I understand about the non-blocking stuff in Node, it only applies to I/O types of operations. Assuming that is correct(?), it would only seem to be a significant gain for you if you expect your server-side app code to have to make multiple I/O calls of various sorts that can logically be done asynchronously (i.e. call B doesn't have to wait for info from call A to figure out what it needs to do). But learning new technologies is always a good thing, regardless of whether there is a meaningful gain to be made. That being said, you also want to weigh the cost in time (which is money) to learn and become proficient with a new technology. Therefore, I tend to take with a grain of salt claims of significant performance gains with any web programming language, when most of our performance issues tend to lie in the database and the Internet itself. Hopefully some Node expert will stop by and tell you that I have no idea what I'm talking about and how Node will run 100% faster than PHP doing the sorts of things you need to do.

As far as PHP books go, no single book did more for me than "PHP Objects, Patterns, and Practice" by Matt Zandstra. I won't claim it's the greatest book of all time, but I read it at the right time in my development as a programmer to really make the OOP thing "click" in my head. As far as database stuff goes, I can't think of one book that was important to me: I seem to have learned what I know more in bits and pieces from the web, co-workers, etc. For performance issues, learning how to use EXPLAIN can help, along with understanding good use of indexes. Data normalization principles are important, too -- though you may find you also want to use denormalized solutions like Solr for creating optimized search collections (but use that in conjunction with a "regular" RBDMS).

I've just started looking at the Laravel framework for PHP, which looks quite useful and promising -- nothing dramatically new: yet another MVC framework.

PS: PHP has been declared dead by fans of newer languages for at least 15 years now. I suppose someday they'll be right, but I wouldn't bet the house and farm on it right now.

Last edited by NogDog; 08-13-2014 at 10:51 PM.

"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation

The thing about PHP is you have to remember what it was made to be -- GLUE.

It is NOT a general purpose computing language meant for the PROCESSING of data, it's meant as glue to put data from something more optimized like a database engine into markup, or to quickly turn client-sent data into something digestible by the database engine. While it has a very robust and quite speedy library of functions, using it for anything more than that is simply trying to shove that square peg into a round hole.

I want to like node.js, and probably would if it was anything but JavaScript. Using the same language server-side as client-side has a lot of advantages, but in terms of raw performance being JavaScript it's no more or less efficient (in my experience) than PHP if you have any clue what you are doing. Admittedly, a very high bar...

JavaScripts lack of a proper object model (sad when even PHP has it better), grossly inefficient and painful array behaviors (a result of that whole "no real typecasting" crap), and buggy/bizzaroland methods of interfacing things like mysql drags it way down.

... and of course much of the new web API stuff makes the things node.js does -- including why Dahl created the language (progress bars on uploads)-- obsolete.

I'm much more impressed with node.js CLIENT side when mixed back into Webkit/Blink as with node-webkit. It's actually really useful when you want to build a cross-platform crApplet.

Honestly, it would come down to what I was really doing. If I'm building a WEBSITE that has accessibility as it's focus, I'd probably use PHP. If I was building a crapplet or pissing all over accessibility with scripttardery client-side, node.js might start to make sense.

I don't tend to favor the latter as it does more to alienate users than draw them in.

BUT -- have you considered BOTH? Right tool for the right job scenario. You build the site to work properly without any javascript using PHP, then as you enhance it with scripting client-side you can use node.js to make the async stuff the AJAX calls in parallel. PHP and client-side scripting building markup and doing pageloads, node.js handling AJAX requests from the client. (Though honestly I very much doubt you'd have better performance in a JS engine than you would PHP on that!)

Of course, PHP does have PDO, so you can scale/rewrite quickly to other database engines. I'm not sure how deep support for other database engines runs in node.js -- last I knew it was a pretty shallow pool; the ones I'm aware of not even having consistent API's making migration from one to another painful at best, even taking the differences in SQL engines into account.

-- edit -- Oh, also a LOT of the speed complaints about PHP are people just doing stupid things; like stuffing an entire result set from a query into a massive memory wasting array instead of iterating with fetch; like creating variables for NOTHING just because all the examples online do so... wasting processing time on double quotes instead of singles.

That last one is a stunning example of developer stupidity in the EXCUSES people come up with as for it "making no difference" in their mind. Single quoted strings are generally 1% faster than double quoted. You'll hear the lame excuse "Ooh, 1% faster when making a string, who gives a ****" usually followed by abusing the "premature optimization" argument... but you add it up 100 times in a program and then add in 100 other tiny little things LIKE singles vs. doubles (say... string addition instead of comma delimits on echo) and variables for nothing -- and suddenly you've wasted half your execution time on things that could simply be avoided by not hitting shift, moving your finger over one key, and using less code. (respectively).

Again, see commas vs. period string addition on commands like echo. String additions are run BEFORE the command is sent, meaning the memory for the entire result has to be allocated all at once. Comma delimits are sent individually, meaning just the pointer to the static string is passed and the result doesn't have to be allocated on the stack. (or PHP's equivalent to same)

The string addition has to be built BEFORE it's sent to echo, meaning the entire result has to be placed in memory. The comma delimits are sent individually so they actually run in code order, AND reduces the memory footprint.

A LOT of the places people call PHP "slow" or "inefficient" is just developer ineptitude and/or ignorance.