Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 102
Интересно было-бы почитать сравнение (нормальное) между Node.JS и PHPDaemon.
Было бы интересно узнать — какие, на ваш взгляд, у PHP есть преимущества перед Javascript?
Это был не позыв к холивору, просто интересны действительно факты.
Большой плюс к Node.JS это в его поддержке. Очеь много манов, доков, модулей. Для PHPDaemon'a к сожалению найти что-то очень тажело.
Большой плюс к Node.JS это в его поддержке. Очеь много манов, доков, модулей. Для PHPDaemon'a к сожалению найти что-то очень тажело.
Это несовсем холивар. Мне действительно интересно — что движет людьми, которые выбирают PHPDaemon для построения приложений.
В чем причина? В том, что PHP знают практически все?
В чем причина? В том, что PHP знают практически все?
>PHP знают практически все?
Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем PHPDaemon, ведь мы уже знаем PHP!
Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем PHPDaemon, ведь мы уже знаем PHP!
Отсутствие внятных и быстрых шаблонизаторов.
Конкатенация строк в JS может превратить в ад работу разработчика.
Хотя, я могу и ошибаться по обоим пунктам.
Конкатенация строк в JS может превратить в ад работу разработчика.
Хотя, я могу и ошибаться по обоим пунктам.
В принципе, server-side templating не особо нужен, так как, из-за event-driven платформы, большая часть взаимодействий с сервером происходит через AJAX. И все шаблоны можно обрабатывать на client-side
JSON вынуждает переносить тонны кода на сторону клиента. Это неплохо для сервера, но не сильно хорошо для самого клиента. Особенно, когда количество данных превышает 1Мб за транзакцию.
mustache — застрелите меня сразу, отсутствие логики генерирует тонны микрофайликов.
ejs — темплейт система из 90х
jade — вот это действительно интересно! Но хочется посмотреть на более сложные примеры, а не на hello world.
В общем заинтриговали
ejs — темплейт система из 90х
jade — вот это действительно интересно! Но хочется посмотреть на более сложные примеры, а не на hello world.
В общем заинтриговали
Лучше сразу смотрите в сторону github.com/creationix/haml-js
Нет, конечно. Есть серьезный аргумент за HAML, — он очень удобен и кроссплатформенен.
Как насчет этого
Это не аргумент «против» — это просто сравнительный тест. Взял doT для текущего проектика — доволен.
Это не аргумент «против» — это просто сравнительный тест. Взял doT для текущего проектика — доволен.
Ну, исходник там приведен. Мне кажется все довольно очевидно — вызывается компиляция шаблона. Кстати, изначально я дал ссылку на устаревшую версию. Вот обновленная
Насчет конкатенации не совсем вас понял, вы о чем?
Некоторое сравнение PHP и nodejs можно посмотреть тут:
b.brainscode.com/2011/04/nodejs-vs-php.html
b.brainscode.com/2011/04/nodejs-vs-php.html
Лучше буду на наркоманском ерланге писать, чем на мерзком PHP.
Для особо интересующихся могу порекомендовать бесплатный (на время beta-тестирования) хостинг для node.js: nodejitsu.com/
Joyent тоже дает бесплатный (пока?) хостинг.
Есть еще наш www.akshell.com который поддерживает CommonJS modules но использует синхронный I/O.
>… использовать огромный выбор уже существующих инструментов командной строки. Node способен порождать тысячи дочерних процессов и работать с их выходными потоками данных
>Это означает огромный выбор программистов на любой вкус и цвет на рынке труда, да и у вас в компании скорее всего уже есть нужные кадры.
издеваетесь, да?
>Это означает огромный выбор программистов на любой вкус и цвет на рынке труда, да и у вас в компании скорее всего уже есть нужные кадры.
издеваетесь, да?
По-моему, сейчас javascript знает практически каждый второй web-developer (хотя бы на базовом уровне).
на базовом уровне его знает какждый первый, а так чтобы нормально структурированные программы писать, а не огрызки скриптов-затычек — днем с огнем найти не можем.
Простите, а где вы работаете, если не секрет?
не секрет. работаю в ipark ventures и у нас есть вакансия js-девелопера.
Вы про русские издания книг?
На самом деле для разработки RIA на JavaScript вовсе не требуется каких-то «магических» знаний. Нет таких ресурсов — зашел, великий гуру поделился своими секретами, и ты — мастер JavaScript.
Вобщем-то знаний по JavaScript хватит из одной книги с носорогом (JavaScript: The Definitive Guide).
Но вот дальше начинается то, из чего и состоит так называемый профессиональный уровень разработчика: понимание ООП без привязки к конкретному языку, паттерны проектирования, разработка архитектуры и проектирование, юнит-тестирование и т.д.
Т.е. с большой долей вероятности профессионал, разбирающийся в вышеперечисленном, но использующий другой язык программирования, изучив книгу с носорогом или ей подобную, попрактиковавшись немного, сможет создать хорошее RIA приложение с толстой клиентской частью.
Вобщем-то знаний по JavaScript хватит из одной книги с носорогом (JavaScript: The Definitive Guide).
Но вот дальше начинается то, из чего и состоит так называемый профессиональный уровень разработчика: понимание ООП без привязки к конкретному языку, паттерны проектирования, разработка архитектуры и проектирование, юнит-тестирование и т.д.
Т.е. с большой долей вероятности профессионал, разбирающийся в вышеперечисленном, но использующий другой язык программирования, изучив книгу с носорогом или ей подобную, попрактиковавшись немного, сможет создать хорошее RIA приложение с толстой клиентской частью.
Cейчас jQuery знает практически каждый второй web-developer. А вот JavaScript на достаточно высоком уровне знают не многие, ибо знание
jQuery !== JavaScript. Многие знают JavaScript на уровне «прикрутить плагин jQuery по мануалу», «написать не сложный плагин к jQuery».Только вот с одним «базовым уровнем» в данной технологии далеко не уедешь. Всёравно PHP больше людей знает.
Насчет разработчиков согласен.
Людей, действительно хорошо разбирающихся в JS, мало. Отчасти это вызвано тем, что сложные client-side приложения приходится разрабатывать куда реже, чем серверные. Также Дуглас Крокфорд, например, заявляет, что не видел ни одной приличной книги по JS за исключением The Definitive Guide от Дэвида Флэнагана. Ну и в целом отсутствие привычной модели ООП (c классами и интерфейсами) тоже играет свою роль.
JavaScript — Самый недооцененный язык в мире (несколько старовата, но тем не менее)
Людей, действительно хорошо разбирающихся в JS, мало. Отчасти это вызвано тем, что сложные client-side приложения приходится разрабатывать куда реже, чем серверные. Также Дуглас Крокфорд, например, заявляет, что не видел ни одной приличной книги по JS за исключением The Definitive Guide от Дэвида Флэнагана. Ну и в целом отсутствие привычной модели ООП (c классами и интерфейсами) тоже играет свою роль.
JavaScript — Самый недооцененный язык в мире (несколько старовата, но тем не менее)
Руководство по убеждению руководства ;)
Поправьте, пожалуйста:
Да, Redis, CouchDB, Cassandra, MongoDB, Riak и так далее выглядят очень аппетитно. Примерно, как то яблочко, которым соблазнилась Ева. Вы уже рискуете, используя Node.js, и вам не стоит усугублять этот риск еще одной новой технологией, в которой вы, скорее всего, пока не разобрались до конца.
Конечно, можно найти много аргументов в пользу документ-ориентированных БД, но если ваше приложение должно приносить прибыль, надежность использования проверенных технологий (Postgres или MySQL)
А мне кажется более оправданным вариант с использованием, скажем, MongoDB + традиционная технология типа PHP/ASP.NET/Java/Ruby.
Ещё Node.js манит тем, что один код без изменений может быть выполнен как на клиенте так и на сервере. Пример: валидация форм, шаблоны
Вы уж меня простите, но я немного посравниваю PHPDaemon и Node.JS (без конкретных характеристик — какашками чур не кидаться):
Задача: чат с каналами. В результате вместо текстовых сообщений будем гонять разные команды, типа «Счётчик, обновись на такую-то величину», «Блок со списком ХХХ — вставь в себя такие-то данные и т.д.»
Этап 1 — Hello World
PHPDaemon: 18 часов настройки окружения, доустановки всего-всего-всего, установки собственно демона и получения внятного ответа в браузер
Node.JS — 1 час на установку + час на написание демонизирующего скрипта .sh (start|stop|restart)
Этап 2 — Транспорт
PHPDaemon — 6 часов на реализацию и прикручивание бесконечного iframe
Node.JS — 20 минут на установку socket.io + 2 часа на придумывание — как бы не броадкастить всех, а только в канал засылать данные
Этап 3 — Логика приложения (callbacks, команды, защита от падучести (несловленного исключения и т.д.) и иже с ними)
PHPDaemon — уже не участвует
Node.JS — несколько часов, сейчас точно не вспомню
Итого. Примерно за 2-3 вечера не напрягаясь был построен рабочий прототип (не просто рабочий, а выполняющий все поставленные задачи, пусть и немного нерационально, там есть ещё что оптимизировать). PHPDaemon заставил меня выкурить много-много сигарет, перелопатить всё, что находилось из скудной документации и примеров, выпить много-много кофе и т.д за неделю.
П.С. Может кто-то скажет, что я просто не умею готовить PHPDaemon — я соглашусь, но не настолько же!
П.П.С — если что — сервер собственный, на базе Atom N450, 2 ГБ памяти.
Задача: чат с каналами. В результате вместо текстовых сообщений будем гонять разные команды, типа «Счётчик, обновись на такую-то величину», «Блок со списком ХХХ — вставь в себя такие-то данные и т.д.»
Этап 1 — Hello World
PHPDaemon: 18 часов настройки окружения, доустановки всего-всего-всего, установки собственно демона и получения внятного ответа в браузер
Node.JS — 1 час на установку + час на написание демонизирующего скрипта .sh (start|stop|restart)
Этап 2 — Транспорт
PHPDaemon — 6 часов на реализацию и прикручивание бесконечного iframe
Node.JS — 20 минут на установку socket.io + 2 часа на придумывание — как бы не броадкастить всех, а только в канал засылать данные
Этап 3 — Логика приложения (callbacks, команды, защита от падучести (несловленного исключения и т.д.) и иже с ними)
PHPDaemon — уже не участвует
Node.JS — несколько часов, сейчас точно не вспомню
Итого. Примерно за 2-3 вечера не напрягаясь был построен рабочий прототип (не просто рабочий, а выполняющий все поставленные задачи, пусть и немного нерационально, там есть ещё что оптимизировать). PHPDaemon заставил меня выкурить много-много сигарет, перелопатить всё, что находилось из скудной документации и примеров, выпить много-много кофе и т.д за неделю.
П.С. Может кто-то скажет, что я просто не умею готовить PHPDaemon — я соглашусь, но не настолько же!
П.П.С — если что — сервер собственный, на базе Atom N450, 2 ГБ памяти.
Добавлю — оба фреймворка я видел впервые. Разрабатываю на PHP и JS уже давненько так что вопрос изучения основ не стоял.
демо: nitrogenproject.com/demos/comet2
код всей страницы: nitrogenproject.com/demos/viewsource?module=demos_comet2
думаю, ноджс нервно покуривает в сторонке.
код всей страницы: nitrogenproject.com/demos/viewsource?module=demos_comet2
думаю, ноджс нервно покуривает в сторонке.
Это эрланг. Я выбирал инструмент по критерию: «Я знаю основы языка»
Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем PHPDaemon и node.js, ведь мы уже знаем PHP и JavaScript!
нет, ну правда же.
мне вот ерланг очень нравится, основы языка знаю, пару прототипчиков наваял, но чтобы серьезно этим заниматься — надо валить, напрашиваться юнгой в какой-нибудь опиумный притон — и то зачморят сишечкой и окамлем.
мне вот ерланг очень нравится, основы языка знаю, пару прототипчиков наваял, но чтобы серьезно этим заниматься — надо валить, напрашиваться юнгой в какой-нибудь опиумный притон — и то зачморят сишечкой и окамлем.
На самом деле разобраться с синтаксисом Erlang и написать простой «чат с каналами» без использования OTP можно за неделю вечеров. Дня 2 на осваивание www.rsdn.ru/article/erlang/GettingStartedWithErlang.xml чтоб синтаксис и основы работы узнать, день чтоб с сокетами разобраться и потренироваться и остальное чтоб дописать само приложение ИЛИ собрать из готовых библиотек.
Если же вникать в OTP то еще на месяц-другой может растянуться.
Фишка в том, что знание синтаксиса JS и того как программировать на нем веб-странички избавит вас только от первого этапа, но от вникания в фреймворк и изучения специфики разработки под этот фреймворк знание JS вас не избавит.
Если же вникать в OTP то еще на месяц-другой может растянуться.
Фишка в том, что знание синтаксиса JS и того как программировать на нем веб-странички избавит вас только от первого этапа, но от вникания в фреймворк и изучения специфики разработки под этот фреймворк знание JS вас не избавит.
Сам по себе синтаксис не пугает. Очень помогает при написании чего-либо на Node.JS понимание принципов:
— замыкания
— контекст
— асинхронное программирование
Плюс — как я говорил выше — я вообще не заботился о транспорте до клиента. Socket.io умеет:
— WebSocket
— если нет — Flash WebSocket
— если нет — Ajax Streaming
— если нет — Jsonp Polling
— если нет — File Polling (aka бесконечный ифрейм)
— если нет — Long Polling
— и наконец — обычный Polling на таймаутах
(в порядке могу ошибаться, советую почитать на сайте: http://socket.io/)
— замыкания
— контекст
— асинхронное программирование
Плюс — как я говорил выше — я вообще не заботился о транспорте до клиента. Socket.io умеет:
— WebSocket
— если нет — Flash WebSocket
— если нет — Ajax Streaming
— если нет — Jsonp Polling
— если нет — File Polling (aka бесконечный ифрейм)
— если нет — Long Polling
— и наконец — обычный Polling на таймаутах
(в порядке могу ошибаться, советую почитать на сайте: http://socket.io/)
В общем то замыкания, контекст, в каком-то смысле и асинхронное программирование активно используются и в Erlang.
Бэкенд для Socket.io есть и для Erlang github.com/yrashk/socket.io-erlang, проект довольно активно развивается крутым эрланговцем хабраюзером yrashk (последний коммит 2 дня назад). Проект правда молодой достаточно.
Ладно, с другой стороны я вас понимаю конечно)
Бэкенд для Socket.io есть и для Erlang github.com/yrashk/socket.io-erlang, проект довольно активно развивается крутым эрланговцем хабраюзером yrashk (последний коммит 2 дня назад). Проект правда молодой достаточно.
Ладно, с другой стороны я вас понимаю конечно)
не вижу ничего erlang специфичного, такой же точно шаблонизатор, сваливающий в кучу представление и логику, можно хоть на pascal'е написать.
а в случае nodejs даже веселее получится, чем в случае erlang'а и паскаля, как раз из-за того, что язык один и тот же на клиенте и на сервере (сей заезженный аргумент тут оказывается как раз к месту).
там где на nitrogen'е приходится писать мутный код в стиле
а в случае nodejs даже веселее получится, чем в случае erlang'а и паскаля, как раз из-за того, что язык один и тот же на клиенте и на сервере (сей заезженный аргумент тут оказывается как раз к месту).
там где на nitrogen'е приходится писать мутный код в стиле
page.apiThree(Bert.atom('hello'), Bert.atom('robert'), 12345) и заворачивать его в строчку с (о боги-боги) написанным руками тэгом a (см. nitrogenproject.com/demos/viewsource?module=demos_api), в nodejs все будет единообразно. 
Хотя в глубине души поддерживаю, но вроде как Nitrogen уже не развивается?
Да нет, вон github.com/nitrogen/nitrogen 88 форков и последний коммит в этом году, так что всё нормально.
>не пытайтесь построить на Node систему жесткого реального времени с гарантированным временем отклика. Для этого гораздо лучше подойдет Erlang.
Автор статьи про эрланг не знает ничего. Какой, нафиг, жёсткий риал-тайм? Это вообще-то от ОС зависит в немалой степени.
Автор статьи про эрланг не знает ничего. Какой, нафиг, жёсткий риал-тайм? Это вообще-то от ОС зависит в немалой степени.
node.js работает на движке, который создан для браузеров. Ведь там совсем другая специфика, страницы живут недолго, очищаются при закрытии, а для node.js нужен 24/7/365.
Вот интересно, если разработчики V8 вдруг встретят развилку, где одно решение ухудшит работу в браузере, а другое в node.js, что они выберут?
Вот интересно, если разработчики V8 вдруг встретят развилку, где одно решение ухудшит работу в браузере, а другое в node.js, что они выберут?
Выберут первое, естественно. Уже заметно на примере node 4.x. Он на 64-битных системах медленнее, чем node 2.x.
Надеюсь, позднее V8 допилят :)
Надеюсь, позднее V8 допилят :)
Значительная часть расширений ноды, использующих внешние линкуемые библиотеки, работает очень нестабильно. Утечки памяти и падения на каждом шагу. Интересующимся деталями могу посоветовать попробовать, например, распарсить подряд несколько сотен мелких XML-файлов (или один большой) при помощи одного из рекомендуемых модулей.
Встроенный сокет-клиент следует использовать с величайшей осторожностью, если отправить большой кусок данных, пока предыдущие еще не ушли — процесс намертво зависает. Не уверен, впрочем, что это баг, а не особенность реализации. Здесь я с этим боролся с большим или меньшим успехом.
И так далее, по мелочам и по-крупному иногда.
Основной нетехнической проблемой является крайне низкое качество кода модулей или библиотек, написанных внешними разработчиками.
Лучшим способом решить, подходит нода или нет — создать прототип, по максимуму использующий требующиеся возможности, сразу выбрать, какие модули вы используете, и хорошенько все это погонять. Если сомневаетесь — пишите под Торнадо (для которого даже Socket.IO-шный сервер есть) и ждите еще пару лет, пока проект немного созреет.
Встроенный сокет-клиент следует использовать с величайшей осторожностью, если отправить большой кусок данных, пока предыдущие еще не ушли — процесс намертво зависает. Не уверен, впрочем, что это баг, а не особенность реализации. Здесь я с этим боролся с большим или меньшим успехом.
И так далее, по мелочам и по-крупному иногда.
Основной нетехнической проблемой является крайне низкое качество кода модулей или библиотек, написанных внешними разработчиками.
Лучшим способом решить, подходит нода или нет — создать прототип, по максимуму использующий требующиеся возможности, сразу выбрать, какие модули вы используете, и хорошенько все это погонять. Если сомневаетесь — пишите под Торнадо (для которого даже Socket.IO-шный сервер есть) и ждите еще пару лет, пока проект немного созреет.
Слава богу мне никого убеждать не пришлось.
Просто были у меня скрипты, который крутились под Microsoft Active Scripting и Windows в собственном Active Scripting Host приложении. Опрос датчиков и запись в БД. За пол дня это все переехало на NodeJS и Linux. Без изменений в основном коде скриптов. Глобальный объект, конечно, надо было подстраивать под методы и объекты, которые предоставляло старое приложение, но это не заняло много времени.
Нет вру конечно. Не пол дня. Мне нужен был доступ к Firebird, а такового в NodeJS не было. Но я сделал. За 3 месяца где-то, на нужном мне уровне функциональности.
Просто были у меня скрипты, который крутились под Microsoft Active Scripting и Windows в собственном Active Scripting Host приложении. Опрос датчиков и запись в БД. За пол дня это все переехало на NodeJS и Linux. Без изменений в основном коде скриптов. Глобальный объект, конечно, надо было подстраивать под методы и объекты, которые предоставляло старое приложение, но это не заняло много времени.
Нет вру конечно. Не пол дня. Мне нужен был доступ к Firebird, а такового в NodeJS не было. Но я сделал. За 3 месяца где-то, на нужном мне уровне функциональности.
А да забыл добавить, что еще по событиям от датчиков и не только оповещаются HTTP клиенты, но это, собственно, классическая задача для NodeJS.
И есть у меня еще одна вещь, которую я бы переделал на NodeJS, это сервис репликации данных, но с такой особенностью, что репликация идет из Oracle в сокет-сервер, который поддерживает только одно подключение, а надо реплицировать несколько наборов данных одновременно, т.е. это что то вроде своеобразного мультиплексора. Сейчас сделано как многопоточное приложение, ну и все прелести с синхронизацией на лицо. Разобраться как оно работает, кому-то другому будет нелегко. Да и я уже подзабыл, хотя доки есть и код относительно чистый. Вот на Node оно было бы красивее и проще, только с Oracle он пока не работает. Я во всяком случае не видел ничего. Но можно переделать на MS Active Scripting пока — это 100%. Скорость там не критична. Да и движок из 9го IE вполне себе шустр. Не знаю только как у него с текучестью :-).
И есть у меня еще одна вещь, которую я бы переделал на NodeJS, это сервис репликации данных, но с такой особенностью, что репликация идет из Oracle в сокет-сервер, который поддерживает только одно подключение, а надо реплицировать несколько наборов данных одновременно, т.е. это что то вроде своеобразного мультиплексора. Сейчас сделано как многопоточное приложение, ну и все прелести с синхронизацией на лицо. Разобраться как оно работает, кому-то другому будет нелегко. Да и я уже подзабыл, хотя доки есть и код относительно чистый. Вот на Node оно было бы красивее и проще, только с Oracle он пока не работает. Я во всяком случае не видел ничего. Но можно переделать на MS Active Scripting пока — это 100%. Скорость там не критична. Да и движок из 9го IE вполне себе шустр. Не знаю только как у него с текучестью :-).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Node.js — руководство по убеждению начальства