Скажу даже больше - он для этого и создан.
NodeJS хорош всем. Понятный лаконичный язык (javascript), устройчив в качестве веб-сервера, куча плюшек вроде асинхронности, потоков, и т.д.
Минус один - ни один из виртуальных хостингов его не поддерживает.
Будьте добры - покупайте VPS.
Олексiй Чечель: затем, что нормальный шаред за ту же цену будет производительнее, его не надо настраивать и администрировать. Так что своего клиента шаред всегда будет иметь. Правда не всегда в хорошем смысле = )
Олексiй Чечель: а вы по-сравнивайте сколько ресурсов, за какую цену дают в случае VPS и сколько сколько в случае с шаредом. Не забудьте вычесть из ресурсов VPS сколько он потребляет в холостую (OS, ПО), без полезной нагрузки.
Видел несколько раз, как производительность сайта проседала после переезда с недорогого шареда на чуть более дорогой VPS.
У таких ребят как godady и hetzner клиент держит на шаредах несколько сотен сайтов. Сайты упираются в лимит по объему и количеству файлов, но не по ресурсам процессора, памяти, диска или канала. Чтобы БД там тупила я вообще ниразу не видел. И всё это у него работает там без мемкеша. Были попытки садить его сайты на VPS, получилось уж точно не дешевле в пересчете на ресурсы. А с учетом администрирования дороже в разы.
Silm: а мне наоборот ни разу не попадались "нетуплящие" виртуальные хостинги, может везло на "соседей"? А еще случалось, что банили сайт клиента из-за того, что был на одном ip с каким-то абузным. Да и вообще процессор чаще всего даже не заявляют в характеристиках шареда. Зато vps обычно выдает более-менее честный заявленный результат.
Олексiй Чечель: зависит от хостера. Когда приходилось размещать сайты на дешевых шаредах, если начинались беспричинные тормоза, то норм хостеры, по обращению переносили сайт на менее нагруженный сервер.
На топовых шаред тарифах известных хостеров вообще хоть какие то проблемы редко возникают.
Нода хороша для задач, завязанных на событийную модель. Под задачи, с последовательным выполнением ноду лучше НЕ брать.
Пхп хорош под задачи web, не требующие хранения состояния (или с внешним хранилищем под сессии на пример) язык идеален.
Нода не может быть заменой пхп, а пхп - заменой ноды. Они предназначены для разных задач.
Учитывая все это + хранение стейта, загруженых файлов в RAM (Что позволяет хоть все конфиги держать в YAML. P.s а он весьма долго парсится), возможность оперировать с C++ либами - Node.js уже давно оставил PHP позади.
И не забывайте, что PHP язык веба, а JS в последнее время стал общим (хоть мобильные приложения, хоть сайты, хоть консольные утилиты).
HoHsi
Да я не спорю, что можно и на ноде в синхронность. На пхп тоже демонов пишут. Вот только зачем? Что там что тут это костыль для решения не свойственных задач.
На счет памяти и конфигов: это решается через кодогенерацию+opcache, посмотрите симфони и доктрину. Можно использовать и что-то более общее redis например.
На счет С++ либ: собсно и что с того? Мы же тут сравниваем под web вроде как. Если бизнес задачи требуют писать либы на С++ вполне возможно, что ни нода ни пхп вам просто не подходят, и стоит смотреть в направлении java, с#, c++, golang...
OnYourLips
Может, но далеко не всегда это правильное решение.
Касаемо кодогенерации, пререндера в кеш, конфигов в редисе и прочего - вот настоящие костыли, это уход от проблемы, а не ее решение (все он в любом случае медленнее и менее удобны чем RAM).
А почему мы сравниваем только вэб? Если это что-бы как-то оправдать сравнение с PHP, то да, но язык учится не на один проект, и куда перспективнее знать Node.js, а не PHP.
HoHsi
> а в чем костыльность нативных await?
нейтивные - это принятые стандартом языка, ES7 на данный момент еще не принят, так что ни о какой нейтивности не может быть и речи.
На счет либ, что вы сбросили - да, есть еще async. А теперь скажите мне, эмулировать синхронность - это не костыль?))
> это уход от проблемы, а не ее решение
Ну как сказать, в случае разделения нод между серверами вам так или иначе придется использовать внешние хранилища, типа redis или memcache, даже на ноде (например под те же сессии). На счет opcache - он и так в ram хранится.
> А почему мы сравниваем только вэб?
потому, что автор спросил про замену php, а php - это web.
> но язык учится не на один проект, и куда перспективнее знать Node.js, а не PHP.
Посмотрите количество вакансий php и node, обычно перспективней учить то, что более востребовано))
На счет либ, что вы сбросили - да, есть еще async. А теперь скажите мне, эмулировать синхронность - это не костыль?))
Вторая ссыль - ошибочная, я это упомянул. На счет того, что это еще не стандарт, согласен, но учитывая, что это уже стандарт в TS, Babel и прочих популярных препроцессорах, в скором появлении их в стандарте сомневаться не приходится.
Касаемо Async - это не совсем то, это очень старая либа, она расчитана на callback, а не на промисы, так что считать ее костылем вполне резонно, а вот нативный Async/Await - нет.
Ну как сказать, в случае разделения нод между серверами вам так или иначе придется использовать внешние хранилища, типа redis или memcache, даже на ноде (например под те же сессии). На счет opcache - он и так в ram хранится.
Возможно мы не поняли друг друга, я имею ввиду конфиги вроде i18n и прочих, которые можно спарсить один раз в RAM и быстро оперировать с ними (а порой они оооочень долго парсятся, особенно если сделаны с удобным API)
потому, что автор спросил про замену php, а php - это web.
Но вы же понимаете, что мир не сошелся на Web. И если спрашивающий захочет, допустим, написать демона или консольную утилиту, ему придется учить что-то новое, а знай он Node.js он смог бы сделать это без труда.
Посмотрите количество вакансий php и node, обычно перспективней учить то, что более востребовано))
Дык раньше все повально учили perl, basic, ASM, двоичное шифрование, транзисторную распайку. Технологии устаревают, и node.js это тоже не минует (это лишь вопрос времени), так что появись более удобный для меня инструмент, я без особой боли перейду на него.
> Возможно мы не поняли друг друга, я имею ввиду конфиги вроде i18n...
Под переводы лучше использовать старый-добрый gettext, сам уже обжигался на этом. На счет конфигурации приложения: очень удобным является метод, на основании констант (как приятный бонус - хранение в RAM без ручного вмешательства).
Вообще говоря система конфигурации как правило - это задача фреймвока.
> И если спрашивающий захочет, допустим, написать демона или консольную утилиту, ему придется учить что-то новое, а знай он Node.js он смог бы сделать это без труда.
Главное, что бы без эффекта утенка)). Дело в том, что при выборе только одной технологии можно очень легко стать ее заложником для ситуаций, где эта технология не совсем применима.
> так что появись более удобный для меня инструмент, я без особой боли перейду на него.
что скажете про golang?))
Я бы на вашем месте задумался кому вы сможете продать свои знания с этим node.js
Node.js я бы не стал рассматривать как альтернативу php в реальном мире. У него есть своя небольшая ниша под узкий круг задач. Который, кстати, Go успешно покрывает с лихвой и даже больше.
Ефим Соколов: скажем так: я работаю в достаточно крупной компании и есть один нагруженный проект с вебсокетами. Проблемы с тем, чтобы найти javascript-ера не было. Но решили делать на Go
> "Я бы на вашем месте задумался кому вы сможете продать свои знания с этим node.js". Как кому, это же js, рынок огромен. Но и nodejs кодеры довольно затребованы.
Олексiй Чечель: пока только в сомнительных стартапах. Реально же рынок труда, связанный с php несравнимо объёмнее того, что могут предложить под именно node.js
akubintsev: не в стартапах а в полне обычных проектах на стабильную ЗП. Сейчас на ноде делают все, начиная от обычных сайтов и заканчивая сложными распределнными SaaS приложениями.
AirWorker: go может компилиться в js, если что. Но это и не нужно, ничего не мешает использовать js на клиенте, а go на сервере. Как серверный язык, go меня очень удивил после php и ноды. Он чем-то похож на ноду в плане модульности, но в разработке он гораздо прозрачнее и стабильнее. Хотя я go знаю только несколько месяцев, а с нодой уже вожусь года четыре, сожалею, что не уделял этому языку должного внимания. Конечно не без минусов, и первые недели кое-какие вещи здорово бесили, но сейчас открываю проекты на ноде и сплошные фейспалмы.
Олексiй Чечель: возможно, go заруливает на больших проектах и командах. Может он вообще заруливает, может я просто не дорос еще. Но в данный момент я вообще придерживаюсь мнения, что сервер по барабану на чем писать, просто нужны хорошие инструменты - легкий http-фреймворк, query builder для Postgres, и конечно же очень важен шаблонизатор. Я до этого писал на Питоне, и как язык он мне нравится сильно больше чем JS. Но когда пишешь на JS - ты знаешь, что неважно, где будет работать код - на сервере или на клиенте. Мысли о Ноде начали приходить, когда в очередном проекте было в 4 раза больше кода на JS, чем на Питоне. Фронтенды все сложнее и сложнее, их доля в web-проектах растет. Плюс интеграция фронта и бека, и плюс отсутствие переключения контекстов в мозгу девелопера. Я обязательно попробую go, но сейчас тащусь от Ноды.
AirWorker: по поводу переключения контекста, это не всегда плюс) В больших проектах бывало зависал, пытаясь понять, где же какой-нибудь код предназначен работать) В остальном согласен, до каждого инструмента нужно дорасти что-ли)
> В остальном согласен, до каждого инструмента нужно дорасти что-ли)
А я вот думаю, что вся сегодняшняя web-индустрия еще не доросла до того, чтобы по полной раскрыть потенциал применения JS на сервере и клиенте. Там еще огромное море возможностей, и в ближайшие несколько лет произойдет качественный скачок в web-разработке. Ну и конечно же Нода будет мейнстримом, будет Нода и все остальное. А go так и останется просто хорошим языком, коих много.
Знаешь JS и не хочешь изучать с нуля пхп - изучай ноду.
сам пишу преимущественно на пхп, но иногда делаю что то на ноде вполне нравится, но полностью пока переходить не хочу, только там где нужны сокеты.
на пхп просто очень много готовых наработок и своих и сторонних готовых библиотек, ближайшие годы без него пока никак.
в любом случае рекомендую тебе с ноды хотя бы начать, ничего не потеряшь.
в ноде со сложной бизнес логикой могут быть проблемы. сейчас делаю игру где на серваке производятся кое какие игровые вычисления, незнаю как она себя поведет, интересно сколько клиентов сможет одновременно выдержать. по сути если рассчет происходит 100мс и у тебя 10 клиентов - то каждый клиент по сути будет по секунде своей очереди ждать...
Юрий: зависит от того, что за вычисления. Под ноду написано много нативных модулей на c/c++ как-раз для задач, которые на js писать не стоит. Свои же сложные вычисления выношу в go, обычно до 50-100 строк, делающих именно нужные вычисления. Ну а вообще, по своему опыту, бывало, что код, который на php выполнялся полсекунды, правильно переписанный на ноду выполнялся миллисекунды.
Олексiй Чечель: про пхп полсекунды с трудом верится. может на пхп он просто был не правильно написанный.
бизнес логику игры вообще нет желания на си переписывать, там и так не мало, а если еще на си, то будет ад, особенно поддерживать. по времени пока не знаю насоклько накладно 100 мс для примера указал.
Юрий: я же и не предлагал переписывать на Си, я писал о том, что для ноды уже написаны различные готовые модули, делающие какие-то рутинные, но тяжелые вычисления, например физические движки или графические библиотеки, они написаны на Си. Интереса ради, сколько планируется онлайна в секунду для игры? Признаюсь, что сейчас, имея 7 лет php, три года node.js и полгода изучения golang за плечами, я бы не рискнул писать игру на php)
Очень советую vibed.org асинхронная модель, крайне высокая производительность, удобный синтаксис, а главное на выходе будете получать бинарики, который сможете просто брать и запускать без траты времени на настройку окружения.
