Когда-то PHP, Apache и MySQL в сочетании с JavaScript через AJAX был идеальной парой для веб-разработчика. Казалось, этот набор инструментов может позволить решить любую задачу. Однако требования повышались, исходный код разрастался на глазах, нагрузка возрастала и привычные инструменты перестали справляться.
Эксперты были уверены, что всему виной классическая схема «запрос-ответ». Запрос страницы заставлял веб-сервер поднять некоторый скрипт, выполнить его линейно, а результат возвратить браузеру клиента. И лишь только после этого перейти к обработке следующего запроса.
В поисках выхода из этой ситуации, светлые головы вспомнили, что сервер можно написать и на JavaScript.
Тогда это дало бы возможность разрабатывать на одном и том же языке и серверную и клиентскую части сайта. Уже к концу 2000-х годов это был простой и одновременно гибкий язык, позволяющий писать код в разных парадигмах: от обычного процедурного до ООП в сочетании с функциональным стилем. Но решающую роль сыграла другая особенность JavaScript — асинхронность.
Приведем пример ограничений последовательного выполнения кода на PHP, который мы позаимствовали отсюда:
$result = $db->fetchOne('SELECT user_name FROM user_accounts WHERE id = 1');
echo 'Мое имя: ' . $result . ';';В первой строке – простой SQL-запрос к БД на выборку имени пользователя, у которого id = 1. В этом месте скрипт останавливается, и следующая строка не будет выполнена до того самого момента, пока запрос не будет обработан базой, а результат не возвратится в переменную $result. В нашем примере это тысячные доли секунды, но в реальности и запросы гораздо сложнее, и базы по размеру зачастую составляют гигабайты, и запросов таких может одновременно быть пара тысяч.
Асинхронное выполнение кода на JS:
db.query('SELECT user_name FROM user_accounts WHERE id = 1', function(err, res)
{
if (!err) sys.log('Мое имя: ' + res);
});
sys.log('Продолжаем выполнение');Тут опять же создается запрос к базе данных, однако кроме самого SQL-выражения в запросе передается еще и функция-обработчик (callback). Эта функция будет вызвана именно тогда, когда придет ответ от базы данных, а до этого момента выполнение скрипта ни в коем случае не будет прекращаться. Так что, в основе любого варианта серверного JavaScript заложена концепция событий и callback’ов, то есть обработчиков событий. Те действия, которые необходимо выполнять в случае наступления событий, описываются внутри функций обработчиков событий.
Подобные соображения побудили любителей JS к созданию собственных серверных движков.
Node.js
2 сентября был официально представлен первый публичный релиз открытого браузера Chromium. В ходе разработки был также создан V8 – JavaScript-интерпретатор для браузера. Его ведущим разработчиком был Ларс Бак. Основными проблемами, которые пришлось решать разработчикам в движке, стали производительность и масштабируемость.
После успеха браузера светлые головы поняли, что такой быстрый движок можно успешно использовать и на сервере.
Дальнейшие эксперименты привели к появления проекта Node.js — полностью самостоятельной платформы, включающей, кроме движка, встроенный сервер (HTTP и TCP/UDP/Unix-soket) и базовый набор библиотек, а также предоставляющей полностью асинхронную работу с файлами и сетевыми устройствами.Node.js разработал Райан Дал в 2009 году. Он пришёл к выводу, что вместо традиционной модели параллелизма на основе потоков следует обратиться к событийно-ориентированным системам. Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия.
Чтобы запустить HTTP-сервер, способный обрабатывать асинхронно тысячи подключений, потребуется несколько строк кода:
// Загружаем модуль http
var http = require('http');
// Создаем web-сервер с обработчиком запросов
var server = http.createServer(function (req, res) {
console.log('Начало обработки запроса');
// Передаем код ответа и http-заголовки
res.writeHead(200, {
'Content-Type': 'text/plain; charset=UTF-8'
});
res.end('Hello world!');
});
// Запускаем web-сервер
server.listen(2002, "127.0.0.1", function () {
console.log('Сервер запущен http://127.0.0.1:2002/');
});Появление Node.js вызвало ажиотаж в среде разработчиков. Уже на раннем этапе развития проекта его начали использовать такие компании, как Netflix, Walmart, PayPal, Dow Jones и Groupon.
И жили бы они долго и счастливо, но…
В ноябре 2014 года в сообществе Node.js произошел раскол. Некоторые участники были недовольны политикой компании Joyent, курирующей разработку проекта Node.js.
Утверждалось также, что Joyent игнорировала мнение сообщества, действовала только в своих интересах и сосредоточила управление над проектом только в своих руках. Кроме того, Joyent к тому времени отдала абсолютный приоритет обеспечению стабильности кодовой базы, что усложнило интеграцию новых возможностей. Существенных релизов не выходило с начала 2013 года, последняя актуальная на тот момент ветка 0.10 была основана на устаревшей версии движка V8.
Инициативу отделения от Joyent поддержали 5 из 7 ключевых разработчиков Node.js, среди которых был Айзек Шлютер, бывший лидер проекта.
Уже через несколько месяцев выяснилось, что io.js превзошел его и по производительности, и по скорости разработки.
Воссоединение
В мае 2015 года состоялось заседание технического комитета проекта io.js, на котором принято решение о воссоединении с Node.js и дальнейшем совместном развитии под эгидой организации Node Foundation.
Куратором объединенного проекта стала организация Linux Foundation, которая сформировала эффективную и независимою площадку для разработки Node.js. Компания Joyent продолжила своё участие в разработке, поддержке и финансировании проекта, но уже как рядовой участник сообщества. Кроме Joyent, в число основателей Node.js Foundation вошли такие компании, как IBM, Microsoft, PayPal, Fidelity и SAP.
8 сентября 2015 года вышел Node.js v4.0.0 как результат слияния Node.js v0.12.7 и io.js v3.3.0
После объединения сообщество обратило внимание на впечатляющую статистику: в 2010-2015 годах разработчики добавили в хранилище кода более 190 000 модулей для Node.js (и других библиотек JavaScript). Это превышает весь репозиторий Perl CPAN, который создавался на протяжении 20 лет, и обходит Java Maven Central, несмотря на меньшее количество разработчиков Node.js.
Node.js 7
В конце сентября 2016 года вышла Node.js 7 beta. В ней использован обновленный движок V8 5.4. Кроме того, она поддерживает 98% стандарта ECMAScript 6. По сравнению с 56% в Node.js 5 это существенный прогресс.
Однако растут не только номера версий Node.js. По данным Indeed.com, на рынке труда востребованность специалистов по Node.js продолжает расти.
Впрочем, подобная статистика не всегда отражает реальное положение вещей, поэтому мы решили пообщаться с экспертами о способах применения технологии, о конкурентах Node.js и о перспективах развития проекта.
1. Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
2. Как вы оцениваете его востребованность, популярность с точки зрения серьезной разработки в ИТ-компаниях? Насколько она оправдана? Для каких проектов подходит Node.js?
3. Как изменился рынок разработчиков Node.js? Их стало меньше, больше? Как по вашим ощущениям изменилось качество их работы?
4. Можете назвать конкурентов Node.js? Насколько они сильны?
5. Каковы перспективы Node.js на ближайшие 5 лет?
Антон Кулаков, фронтенд-разработчик
Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
После создания Node.js Foundation все стало гораздо лучше. Сейчас меня лично все устраивает.
Как вы оцениваете его востребованность, популярность с точки зрения серьезной разработки в ИТ-компаниях? Насколько она оправдана? Для каких проектов подходит Node.js?
Я не обладаю такой статистикой, поэтому могу судить лишь по моим ощущениям.
Востребованность — определено да. Многие вещи очень просто делаются с помощью Node.js. Популярность — сложно сказать. Однозначно можно сказать, что в среде фронтенд-разработчиков она весьма популярна.
Насколько она оправдана? Тут все зависит от задачи. Для каких-то задач JavaScript подходит лучше, для каких-то хуже. Доверить Node.js сборку фронтенда — это оправдано и это правильно. Доверить Node.js управление космическим кораблем — пожалуй можно, но я бы выбрал более надежные технологии.
Как изменился рынок разработчиков Node.js? Их стало меньше, больше? Как по вашим ощущениям изменилось качество их работы
Я не заметил какого-то резкого изменения спроса на Node.js разработчиков. Пожалуй, владение Node.js стало обязательным требованием для фронтенд-разработчиков в последнее время. Специалистов стало гораздо больше, но качество их оценить сложно. У меня нет такой статистики.
Node.js — это всего лишь инструмент для выполнения JavaScript сценариев. Безусловно, это один из самых популярных инструментов для выполнения JavaScript не в браузере.
Каковы перспективы Node.js на ближайшие 5 лет?
Я считаю Node.js ждет большое будущее. Особенно среди фронтенд-разработчиков. В остальных сферах преимущества JavaScript не совсем очевидны.
Данил Скачков, Senior Software Developer, компания api.ai
Насколько быстро, по вашему мнению, развивается Node.js?
Хорошо развивается, но, на мой взгляд, обвесы развиваются слишком быстро и несколько неаккуратно. К самой node.js как к рантайму претензий нет.
Довольны ли вы текущим темпом?
А почему нет, лучше развиваться, чем стоять на месте.
Как вы оцениваете его востребованность, популярность с точки зрения серьезной разработки в ИТ-компаниях?
Если коротко, то неоднозначно. Но тут всё очень сильно зависит от того, какой язык вы используете для разработки под Node.js. Если чистый JavaScript, то очень быстро можно столкнуться с тем, что станет непонятно, что и как в вашей программе связано. Это следствие того, что JS динамический. В случае же использования TypeScript, например, у вас будет проверка типов на этапе компиляции, и, соответственно, будет меньше нечеткости в программе.
Насколько она оправдана? Для каких проектов подходит Node.js?
Тут от задачи зависит. Для микросервисов, на мой взгляд, – самое то.
Можете назвать конкурентов Node.js? Насколько они сильны?
Ну тут можно вспоминать очень долго. Насколько я это себе представляю, конкурентом будет любой продукт, подходящий для написания backend'а. И у всех продуктов найдутся свои слабые и сильные стороны. Node.js, на данный момент, силен своей простотой на маленьких задачах.
Например, для написания небольших REST-сервисов. При большом количестве кода могут быть проблемы с прозрачностью логики работы приложения, но, как я уже говорил, это особенность JavaScript, которая вполне может быть решена с помощью Typescript или ещё чего-нибудь подобного.
Каковы перспективы Node.js на ближайшие 5 лет?
Перспективы любой технологии на таком временном промежутке довольно сложно предсказать. Думаю, в ближайшем времени популярность будет расти, в связи с популярностью микросервисов и простотой на небольших задачах. Ну а потом посмотрим.
Денис Измайлов, со-основатель Moscow Node.js Meetup, основатель группы Node.js в Telegram, занимается заказной разработкой на международном рынке:
Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
Ещё два года назад можно было быть недовольным, но все мы помним ту историю, когда в январе прошлого года Фёдор Индутный опубликовал форк — io.js, чтобы форсировать внедрение последних версий V8 и сделать процесс разработки более открытым. Это привело к тому, что год назад вышла легендарная версия Node.js 4.0.0 и с тех пор, мы наблюдаем релизы каждый месяц.
Другой вопрос – содержимое этих изменений, но это тема отдельной дискуссии. Радует то, что при таком активном и непрерывном цикле разработке удалось найти золотую середину, и теперь сторонники стабильности остаются счастливы за счёт LTS-версий, которые критически важны для Production и крупных проектов.
Как вы оцениваете его востребованность, популярность с точки зрения серьезной разработки в ИТ-компаниях? Насколько она оправдана? Для каких проектов подходит Node.js?
Для всех, при правильной настройке кластера на Kubernetes. Это то, как мы решили для своих клиентов вопросы с масштабируемостью и эластичностью системы. Но если смотреть на опыт коллег и брать во внимание все нюансы на рынке труда, ещё остаётся небольшой спектр специфичных задач, которые безопасней (с точки зрения бизнеса) было бы сделать с использованием Python, Golang или Erlang — такие как Data Mining, Data Processing и прочее.
Если говорить о востребованности со стороны компаний или ИТ-департаментов, то тут она постоянно растёт и причин целое множество — как уход от PHP, Ruby и Java в веб-разработке, так и возможность изоморфных приложений, о которых я рассказывал уже много в своих докладах на конференциях и митапах. Это всё позволяет существенно сократить издержки и повысить качество продуктов.
Как изменился рынок разработчиков Node.js? Их стало меньше, больше? Как по вашим ощущениям изменилось качество их работы?
Рынок где именно? Глобально он сильно увеличился и продолжает увеличиваться. Востребованность Fullstack JS на международном рынке многократно превышает предложение. Этому способствует как рост стартапов, так и зрелость экосистемы в целом. Многие разработчики уезжают за высокими зарплатами в США, Европу и Азию или просто переходят на удалённую форму работы. В этом ключе на местном рынке мы видим даже небольшое сокращение профессиональных разработчиков с одной стороны, и большой приток джуниоров — с другой.
Именно поэтому мы начали проводить митапы по Node.js в Москве, где ребята могут пообщаться вживую с разработчиками самого ядра Node.js — такими интересными личностями как Владимир Курчаткин и Никита Сковорода.
Можете назвать конкурентов Node.js? Насколько они сильны?
Безусловно тут сразу напрашивается ответ про Golang. Его доля на рынке тоже заметно растёт. Но чаще всего за счёт крупного бизнеса и DevOps-решений, где миллисекунды критически важны. Там вполне может окупиться сервис на Golang, но это если бюджет у проекта позволяет.
Каковы перспективы Node.js на ближайшие 5 лет?
Некоторое время назад у многих появилась надежда на WebAssembly. И то, если уж у asm.js не получилось, то теперь-то точно в браузере можно будет запускать «байт-код», а это значит – программировать на любом языке. Но сегодня мы снова видим, что производители не могут договориться, а это значит – у JavaScript прекрасное будущее.
Сейчас я не буду ничего говорить про многопоточность, аналоги goroutine и channels или про то, что Node.js откажется от V8 после стабилизации ES6, просто потому, что взаимодействие сервисов имеет несколько иную специфику нежели браузеров. Но отмечу вполне интересные шансы у Microsoft вернуть себе лидерство в сообществе, и в этом сегменте в частности, за счёт качественных инструментов.
А пока ждём активно Node.js v7.x, которая обещает нам наконец-то принести async-await.
Илья Кантор, создатель JavaScript.ru, один из первых профессиональных преподавателей языка JS в России:
Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
Сейчас Node.JS развивается очень быстро: как сам Node.JS, так и язык JavaScript и сопутствующая инфраструктура.
Конечно, хотелось бы побыстрее внедрения новых фич, но ситуация и так меняется весьма быстро. К примеру, callback-style недавно сменился на promises + generators, а их сменит async/await в ближайший год. Когда пишешь код, нужно иметь это в виду, чтобы потом не переписывать.
Как вы оцениваете его востребованность, популярность с точки зрения серьезной разработки в ИТ-компаниях? Насколько она оправдана? Для каких проектов подходит Node.js?
Инструментов очень много. Выбор зависит в большой степени от личных предпочтений.
Некоторые преимущества Node.JS:
1) Он быстрый, в смысле производительности. Конечно, есть языки, которые быстрее, особенно компилируемые со строгой типизацией, но в общем и целом — Node.JS довольно быстрый. Как правило, сервис на Node.JS будет быстрее написанного на PHP или Ruby.
Node.JS с момента создания использовался для приложений с большим количеством одновременных соединений, между которыми «летают» данные. С этим, соответственно, тоже нет проблем.
2) Разработка на нём тоже довольно быстрая.
3) JavaScript и на frontend, и на backend при разработке веб-приложений позволяет использовать один код и там, и там. Изоморфные приложения – вот это всё. Да и разработчикам бывает удобнее использовать один язык. После последних улучшений JavaScript стал гораздо приятнее.
Как изменился рынок разработчиков Node.js? Их стало меньше, больше? Как по вашим ощущениям изменилось качество их работы?
Извините, «рынок» не отслеживаю. Хороших разработчиков всегда мало. В плане Node.JS обычно проще вырастить, чем найти готового.
Можете назвать конкурентов Node.js? Насколько они сильны?
Среди платформ на JavaScript у Node.JS конкурентов серьёзных нет. Если же говорить о других языках — то выбор зависит от задачи, а также личных предпочтений разработчика, что ему понятнее и ближе. На чём людям нравится кодить, на том они и будут писать.
Каковы перспективы Node.js на ближайшие 5 лет?
Сейчас всё развивается очень быстро, 5 лет — большой срок. Если смотреть на текущие тренды, то Node.JS быстро идёт вперёд. С другой стороны, важное преимущество Node.JS — это то, что JavaScript является единственным кросс-браузерным языком разработки, именно на уровне браузера.
Возможно, в будущем будет внедрён стандарт WebAssembly, который лишит его этого преимущества. С другой стороны, даже если это случится, то не скоро, и Node.JS к тому времени сильно вырастет. Возможно, это преимущество для него и не будет так уж актуально.
Комментарии (36)
PaulZi
30.09.2016 20:21-1Вот только касательно примера, для пользователя вообще ничего не изменится, т. к. пока база не ответит http ответ пользователь не придет.
G-M-A-X
30.09.2016 22:36+1Со стороны пользователя да.
Но при этом мы можем иметь меньше запущенных процессов для обработки того же количества запросов.
А также нету блокировок (если вдруг не наделали их :) )
caballero
01.10.2016 12:22-2экономия на спичках. При жирм возникает проблема если запросы длинные с обработкой серьезных данных. Тогда либо ответ тормозит либо надо регшать вопросы когла распараьлеливать а когда нет. и смысл этого всего?
demimurych
30.09.2016 22:57+4не вполне так.
Если приложению есть чем заняться кроме как обработать результат запроса, то пользователь получит ответ быстрее, в силу того что время ожидания ответа будет эффективно использовано.caballero
01.10.2016 12:23-3сайты — штука интерактивная — приложению редко есть чем занятся кроме отвечать пользователю. А с фоновой работой прекрасно справляется крон.
G-M-A-X
30.09.2016 22:29-7Главному рисунку полтора года :)
>Однако требования повышались, исходный код разрастался на глазах, нагрузка возрастала и привычные инструменты перестали справляться.
Повышались не то что требования.
Просто некоторые задачи удобней решать на асинхронном Node.JS.
>И лишь только после этого перейти к обработке следующего запроса.
Вообще-то сервер может более одного запроса в один момент.
У PHP несколько дочерних процессов, которые принимают запросы.
>Тогда это дало бы возможность разрабатывать на одном и том же языке и серверную и клиентскую части сайта.
В этом был главный плюс и причина возникновения Node.JS?
>и запросов таких может одновременно быть пара тысяч
Ну да, ну да.
>Подобные соображения побудили любителей JS к созданию собственных серверных движков.
Вы же сами говорите, что он на V8.
>2 сентября был официально представлен
Какого года?
Напоминает: Украина получит безвиз в октябре (уже 10 лет получает :) ).
>Основными проблемами, которые пришлось решать разработчикам в движке, стали производительность и масштабируемость.
JS однопоточный вообще-то.
То есть запускаем 100500 инстансов. Тут не нужно было думать о масштабируемости.
>Эта модель была выбрана из-за простоты, низких накладных расходов (по сравнению с идеологией «один поток на каждое соединение») и быстродействия.
nginx тоже однопоточный.
PHP тоже однопоточный (если не под многопоточным Апачем модулем).
>в 2010-2015 годах разработчики добавили в хранилище кода более 190 000 модулей для Node.js
Какая-то ерунда непонятная.
Там модуля из 10 строк состоят? Модуль используется только автором?
>Кроме того, она поддерживает 98% стандарта ECMAScript 6.
Как считали проценты? :)
>Однако растут не только номера версий Node.js. По данным Indeed.com, на рынке труда востребованность специалистов по Node.js продолжает расти.
Это какая-то ерунда, а не рисунок.
Node.JS — отдельная технология, а сравнивается с отдельными фреймворками других технологий. :)
А также дальтоникам рисунок непонятен :)
>1. Насколько быстро, по вашему мнению, развивается Node.js? Довольны ли вы текущим темпом?
Блеать, та мне насрать на темпы развития.
Или у него есть то, что мне нужно сейчас, или нет.
Вы ж наклепали 200К модулей, самый быстрый язык, прям ракета.
>Я не заметил какого-то резкого изменения спроса на Node.js разработчиков. Пожалуй, владение Node.js стало обязательным требованием для фронтенд-разработчиков в последнее время.
Шта? Спроса нет, но требования обязательны?
>Node.js — это всего лишь инструмент для выполнения JavaScript сценариев.
Блеать, там не браузерный JS выполняется. Или у него интерес просто JS выполнять?
PHP — это всего лишь инструмент выполнения PHP сценариев :)
>Я считаю Node.js ждет большое будущее. Особенно среди фронтенд-разработчиков.
Рилли? (Относится ко второму предложению).
>Если чистый JavaScript, то очень быстро можно столкнуться с тем, что станет непонятно, что и как в вашей программе связано. Это следствие того, что JS динамический.
Что за ерунда?
PHP тоже динамичный.
>В случае же использования TypeScript, например, у вас будет проверка типов на этапе компиляции
А в рантайме придет не тот тип и здрасте :)
>Тут от задачи зависит. Для микросервисов, на мой взгляд, – самое то.
Микросервис — это проект?
О боже, где вы берете таких экспертов.
>Например, для написания небольших REST-сервисов.
Вообще-то, любой HTTP-сервис — уже REST.
>При большом количестве кода могут быть проблемы с прозрачностью логики работы приложения, но, как я уже говорил, это особенность JavaScript, которая вполне может быть решена с помощью Typescript
Статическая типизация не повышает автоматом качество кода…
>то теперь-то точно в браузере можно будет запускать «байт-код», а это значит – программировать на любом языке.
В браузере? Будем запускать Node.js в браузере? Ооо.
>Node.js откажется от V8 после стабилизации ES6, просто потому, что взаимодействие сервисов имеет несколько иную специфику нежели браузеров.
Тупо бред.
Можно отказаться от ES5 в пользу ES6 после стабилизации последнего
Или от V8 после стабилизации ES6, потому что нам не нужен ES5.
Но при чем тут одновременно V8, ES6 и браузеры?
Вообще-то V8 — быстрая числодробилка. Как браузерный — он не сильно оптимальный.
Но Node.JS и не использует его браузерность.G-M-A-X
01.10.2016 15:07-6За что хабрабыдло заминусовало? :)
G-M-A-X
02.10.2016 13:07+1Примерный диалог:
Новичек: Где получать информацию о веб-программировании?
me: Читайте хабр.
Программист: В массе стадо студентов, ламерья. Сейчас из двух десяток заметок — одна стоит внимания. Лучше читать профильные форумы, а хабр в качестве желтой прессы во время кофе с бутербродом.
me: Кстати да. Еще очень самоуверенного.
rax
30.09.2016 23:32+11Комментаторов конечно подобрали завязанных на js. Что еще они могли сказать :)
Нода стала хорошо обновляться, но экосистема по сравнению с фронтом не развивается, все пишут на экспрессе и тулзах, которые еще TJ написал. Все идет к тому, что нода становится придатком фронта в виде дев серверов и билд утилит. Большие проекты пишутся лапшой и костылями, серьезные люди в язык не идут, потому что есть более интересные альтернативы, как результат отсутствие хороших практик в комьюнити и понимания куда двигаться. Это было хорошо видно на Node Intercative Europ 2016: почти полное отсутствие именно Node.js повестки кроме поддержки новых стандартов. Увеличение числа вакансий опять же по сравнению с фронтом мизерное, скорее просто как плюс для фронта.baka_cirno
01.10.2016 13:34+1Здрасьте. Как это не развивается? А Koa, а Hapi? А миллион фреймворков и плагинов к ним для написания микросервисов? А готовые решения вроде Horizon или Deepstream? Вы чего?
PerlPower
01.10.2016 19:15+5Я думаю речь идет о фреймворках уровня Yii, Symfony, Lavarel из мира PHP. Чтобы было коммьюнити, чтобы была какая-то предсказуемость и поддержка, проверенность временем, чтобы в конце концов был какой-то деревянный стандарт уровня PSR. Из PHP 4 за несколько лет сделали язык enterprise уровня со всеми прилагаемыми плюшками, из javascript пока нет.
baka_cirno
10.10.2016 20:11В этом комьюнити больше популярны SPA-приложения, которые дергают API по xhr или вебсокетам.
rax
02.10.2016 21:46Koa и Hapi этот же экспресс, только с сахаром или сбоку, они не решают проблему написания больших приложений, чем являются те же микросервисы. А BaaS существует для всего, нода тут не при чем
baka_cirno
10.10.2016 20:13Да полно есть решений для создания микросервисов. Один Loopback от IBM чего стоит.
dim_s
01.10.2016 00:29+6В плане микросервисов язык Go выглядит на мой взгляд более убедительно, так что в этом плане у Node.js шансы не больше чем у других языков. Будущее конечно же есть, т.к. у node.js в мире фронтенда нет альтернативы, а вот в мире бэкенда у Node.js есть большое количество конкурентов, так что я не вижу большого будущего у node в этом направлении. Полиморфные приложение нужны единицам, они усложняют код, сложны для понимания, стоимость поддержи увеличивается, да и бизнесу сложно объяснить — зачем это все нужно.
TimeCoder
01.10.2016 01:01+1На стороне front-end я знаком с Angular, back-end пишу на asp.net MVC. Есть ли какой-либо резон в освоении node.js? Где можно найти примеры кода хороших, реальных проектов (а то везде этот hello-world..)?
sentyaev
01.10.2016 02:21а то везде этот hello-world..
Поддержу вас. Сам из .NET, сейчас ищу хороший пример испоьзования Redux, по сути ничего путного кроме counter и todo list не могу найти.
Kenya-West
01.10.2016 12:25-1Перспектива появится, когда NodeJS, наконец, отвяжут от тормозного V8 и пересадят на гиперзвуковой Chakra… Ну, или прослойку запилят, чтобы движок можно было выбрать.
serf
01.10.2016 12:54+1V8 / Chakra и тп вторичные вещи по моему мнение. Для большой кодовой базы, большой команды, и написания бизнес логики важны более общие вещи, например строгая типизация, поэтому я за вариант — перспектива появится когда использование чистого JS станет "плохой практикой" (по крайней мере на бэкенде), а обычным делом будет все писать на TypeScript (или чем-то похожем к тому времени).
caballero
01.10.2016 12:30+2не вижу ни малейшей выгоды использхования одного языка на сервере и клиенте. Сервер и клиент полностью. отличается и платформой в целом, и технологиями и задачами которые они выполняют.
Посему один язык как раз нелогичен.
Да и програмист, знающий один язык все равно никому не нужен — но обучении тоже не сэкономишь.
Думаю нода займет свою определенную нишу для кторой она и создавалась — обеспечить быструю отдачу мелких данных. Типа сообщений в соцсетях. Но таких приложений не так много среди всего множства веб приложений.
Аналогичная ситуация с уже проходящей модой на nosql БД. Повыпендривались и поняли что на биг дата (а нарастающее количество инфы все приведет к бигдата) нереляционным решениям в ближайшем будущем делать нечего (кроме разумеется всяких кеширований)
Antelle
01.10.2016 14:51+3Один язык очень даже логичен и востребован. Например:
- проверить какие-то данные достаточно сложным методом, при этом каждый раз не гонять это на сервер, потому что хочется быстрый фидбек
- иметь сложную модель, но чтобы внесение изменений в схему не требовало поддержки в двух местах
- написать модуль для использования на сервере, но приготовиться к тому, что его можно будет легко вынести на клиент, или наоборот
- выполнить клиентский код на сервере, например, если пришёл клиент, который это не умеет (например, google bot)
Вот только нода мне не очень нравится, сейчас это можно решить на C++, скомпилировав код в emscripten. Хотелось бы что-то менее низкоуровневое, надеюсь, что в скором будущем с приходом webassembly у нас таки будет быстрый язык, который будет работать везде.
caballero
01.10.2016 18:30-1проверить какие-то данные достаточно сложным методом, при этом каждый раз не гонять это на сервер, потому что хочется быстрый фидбек
если данные можно не гонять на сервер то какая разница какой там язык
иметь сложную модель, но чтобы внесение изменений в схему не требовало поддержки в двух местах
а на фига вообще на клиенте какие то модели? Следовать еще одной не более чем модной фишке использованию яваскриптовых фреймворков вас никто не заставляет.
написать модуль для использования на сервере, но приготовиться к тому, что его можно будет легко вынести на клиент, или наоборот
клиент и сервер — разные платформы с разными задачами. как вы себе представляете такой модуль? Типа проверка даты на валидность?
выполнить клиентский код на сервере
это вообще какая то екзотика.
попросту говоря ваши аргументы притянуты за уши.
Вот только нода мне не очень нравится, сейчас это можно решить на C++, скомпилировав код в emscripten.
а еще все это может решить старый добрый PHP. Особенно когда там будет сделан JIT компилятор.
Впрочем для подавляющего большинства сайтов это нафиг не нужно, учитывая что железо нынче дешевле труда программиста.
Просто каждый новичок мнит себя Цукербергом и думает что на его сайт будут ходить по милиону в день.
Посему еще раз — проблемы которые вы описали яйца выеденного не стоят.
Antelle
01.10.2016 18:38+3если данные можно не гонять на сервер то какая разница какой там язык
Но проверить на сервере потом тоже нужно. А как?
а на фига вообще на клиенте какие то модели?
Давайте здесь не будем обсуждать, а нужна ли в браузере сложная логика и примем как данное, что нужна. Если не нужна, то и обсуждать тут нечего, всё и так ясно. У меня вот менеджер паролей в браузере, когда будет сервер, я захочу читать формат одним и тем же кодом. На работе делаю полноценный офис в браузере, с соответстием моделей на сервере и клиенте, с оффлайн-редактированием и мёржем. Ещё много-много применений.
клиент и сервер — разные платформы с разными задачами.
Конечно, но в разных задачах бывают нужны одинаковые алгоритмы.
это вообще какая то екзотика.
Экзотика? Для googlebot очень даже требуется пререндеринг. Даже в вакансиях сейчас это спрашивают. Нет, уже не экзотика.
а еще все это может решить старый добрый PHP
Вы его на клиенте не выполните. Проблема код-шаринга не решена.
Для сайтов конечно не нужно, но веб это давно уже включает в себя не только простые бложики, но и полноценные приложения. Опять же, повторю, обсуждать необходимость в них — пожалуйста не надо.
dim_s
01.10.2016 20:20GWT был придуман еще до появления node.js, Java на сервере и на клиенте, есть еще Vaadin фреймворк с таким же подходом, там тоже Java на клиенте и на бэкенеде, так что идея эта не новая.
Antelle
01.10.2016 20:27+1Java на сервере и на клиенте
Была. Но сейчас уже можно сказать, что на клиенте её нет.
Я не утверждаю, что это новый подход. Это подход, который предположительно будет работать. Я о webassembly, если что, не о node.js. Идея использовать js везде, как я написал выше, мне не очень, но пока это единственный на сегодня рабочий способ код-шаринга. А так да, вы правы, попытки использовать общий язык начались уже давно, потому что это востребовано бизнесом.
neoxack
02.10.2016 12:12js — как раз быстрый язык, который работает везде.
Antelle
02.10.2016 12:23+1Не очень он быстрый, хочется быстрее, чтобы числодробилки писать можно было. Вот простой пример, сравните с native.
alaska332
02.10.2016 09:44+1200к херово написанных и бесполезных модулей в репозитории — врядли это является преимуществом.
Вообще, использовать все это дело надо очень осторожно и только топовые модули, коих обычно пару десятков.
xRay
03.10.2016 13:55+1А Node.js все так же однопоточный?
taujavarob
04.10.2016 18:46«Как было указано выше, Node.js однопоточный и использует всего одно ядро процессора. Может потребоваться реализовать конкурентность на многоядерном сервере, для этого команда разработчиков ядра Node уже занимается подготовкой специального кластерного модуля. Кроме того, вы без труда могли бы запустить несколько экземпляров сервера Node.js за обратным прокси с использованием nginx.»
Статья прошлого года:
https://habrahabr.ru/company/piter/blog/265649/
easyman
А вот JScript из ASP (не ASP.NET) не стал популярным, почему-то.
