Node.js for simple sites. Is PHP worth it?

Question

PHP

Right off the bat, I’ll say that I know PHP superficially, but I don’t know Node.js at all, but I know JS. One way or another, you will need to delve into server technologies. Is it worth it to start with a node right away and use it for simple sites (50-150 rupees with relevant requirements)?

For the node:
+ There are already virtual hostings for it, there will be no special problems here.
+ So far, all the applications that I write do not work under high loads, but if this happens, I will have to somehow switch to it or to a similar technology.
+ I learned the asynchronous concept a long time ago.
+ It is possible that there will not be as many asynchronous tasks in the server part as in the frontend and there will not be such noodles from callbacks.

Against:
— I hate callback noodles. I can’t imagine how you can write something serious in JS without using Frameworks that somehow imitate synchronism. At worst, jQuery. If node.js is close to native JS, it will be more difficult. Or you will have to look for a framework for it.
- I like PHP for a bunch of built-in functions (working with arrays, strings, databases, image processing, etc.). If the node has ES4-level functionality and there is stupidly no library to shrink the image on the server, wouldn't it be too deplorable?
Is the devil as scary as he is painted. It is clear why asynchrony is needed on the client. But on the server? Only the database and communication with other servers (if this occurs in real life). Maybe there are ways to optimize this without async? Maybe the PCPs will come up with it in half a year?

Answer 1

— I hate callback noodles. I can’t imagine how you can write something serious in JS without using Frameworks that somehow imitate synchronism. At worst, jQuery. If node.js is close to native JS, it will be more difficult. Or you will have to look for a framework for it.

To avoid callback noodles, in simple cases it is enough to simply use named rather than anonymous callbacks. In complex cases - async. Node.js is close to native JS. But just in case, there are 30,000 packages on npm.

+ It is possible that there will not be as many asynchronous tasks in the server part as in the frontend and there will not be such noodles from callbacks.

If you have a lot of synchronous tasks, then Node.js is not the best choice.

- I like PHP for a bunch of built-in functions (working with arrays, strings, databases, image processing, etc.). If the node has an ES4
-level functionality and there is stupidly no library to shrink the image on the server, wouldn't it be too deplorable?

There is nothing in the node. npm has everything. ES5.

Is the devil as scary as he is painted. It is clear why asynchrony is needed on the client. But on the server? Only the database and communication with other servers (if this occurs in real life). Maybe there are ways to optimize this without async? Maybe the PCPs will come up with it in half a year?

What else does the backend of a web application actually do? Does the number pi up to the billionth place count?
Conclusion - everything is in order, you are using node.js.

Answer 2

No one bothers to play around - try to write a simple application in Node.js, take a look. Also, to simplify the callback noodles and some useful goodies, I highly recommend CoffeeScript, since Node.js works quite well with it without additional dances with a tambourine.

Answer 3

I would not recommend you to use a node for simple projects.
The node is good for highloading and tasks where realtime is needed.
But with the presence of modules for simple sites of the joomla level, it’s a bit tight, as with hosting.
Although, of course, the future belongs to the node, IMHO.

Answer 4

I hate callback noodles.

Rather, a far-fetched problem and a matter of habit. It is possible to structure the code without noodles.

Is the devil as scary as he is painted.

The advantage of nodejs is that it supports many connections without much overhead. For http (no sockets) it doesn't really matter. For messengers, games, some specific interactive must-have functionality.

Answer 5

I am for. I myself recently made a small project on a node - the impression is excellent.

Answer 6

There are already virtual hostings for it, there will be no special problems here.

-And I would advise you not to bother with the choice of virtual hosting, but look towards VPS with all the ensuing advantages, since there are a lot of services and prices are not so biting, well, the knowledge gained during setup will be useful.

Answer 7

- Use the async module to solve the noodle problem .
- There are a huge number of modules in the npm repository .
- Asynchrony is needed so that the server does not wait for io.

Answer 8

I would recommend using both.
Put nginx in front, which forwards PHP + node requests and returns static (this solution only slightly loads the server, but if you have at least 10% of static, you will only win). In the future, write on what is more convenient for a specific task . For example, I have nginx which forwards to erlang, node, php.

Answer 9

Definitely NodeJs. I agree with the previous comment, VDS, and you don’t care so much)

Answer 10

Of course, for simple sites, use php, what else is there to think about.
You need realtime updates on the page - use the comet server, from dklab for example (http://dklab.ru/lib/dklab_realplexor/). Need full asynchrony - phpDaemin or Reactphp. Although specifically for these solutions there are troubles such as memory leaks. It's better then to take erlang and use the new N2O (http://synrc.com/framework/web/), which is faster than anything you can think of, including a node.
Noda (like monga, by the way) are cool things at first glance, which, when faced with rough reality, become a problem for the developer. java.dzone.com/articles/f-mongodb-f-nodejs-and-f-you

Answer 11

By the way, here is an interesting CMS on node.js - Apostrophe 2 apostrophenow.org/
I myself am still for PHP, because it also does not stand still, it develops.
And the customer will usually prefer PHP.

Answer 12

The concepts of "node.js" and "the first server-side language" are not compatible.

Answer 13

And where will these simple sites on node.js be hosted?
PHP is better anyway.
A lot of ready-made material for developing a simple website in a matter of hours.
Above they talk about Ruby and Github / Twitter - well, look at Facebook / Vkontakte, which are in PHP. or on Google using Python.
I think no one will argue that these technologies are not used in their pure form on any of the above services. Everywhere additional self-written caches, optimized libraries, server pools and a bunch of balancers.
It all depends on the directness of the hands and the competent use of available technologies, the language / framework is already in the second place.
Each tool is good in its own area.
No need to think that business card sites and small-town online stores will instantly become visited and the servers will go down because the wrong language was used. This is silly. It is much more important that these sites are easy to maintain and do not have to spend months looking for a person familiar with node.js to fix some small bug.