Comments 38
Вот только касательно примера, для пользователя вообще ничего не изменится, т. к. пока база не ответит http ответ пользователь не придет.
Со стороны пользователя да.
Но при этом мы можем иметь меньше запущенных процессов для обработки того же количества запросов.
А также нету блокировок (если вдруг не наделали их :) )
экономия на спичках. При жирм возникает проблема если запросы длинные с обработкой серьезных данных. Тогда либо ответ тормозит либо надо регшать вопросы когла распараьлеливать а когда нет. и смысл этого всего?
не вполне так.
Если приложению есть чем заняться кроме как обработать результат запроса, то пользователь получит ответ быстрее, в силу того что время ожидания ответа будет эффективно использовано.
сайты — штука интерактивная — приложению редко есть чем занятся кроме отвечать пользователю. А с фоновой работой прекрасно справляется крон.
Главному рисунку полтора года :)

>Однако требования повышались, исходный код разрастался на глазах, нагрузка возрастала и привычные инструменты перестали справляться.

Повышались не то что требования.
Просто некоторые задачи удобней решать на асинхронном 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 и не использует его браузерность.
Примерный диалог:
Новичек: Где получать информацию о веб-программировании?
me: Читайте хабр.
Программист: В массе стадо студентов, ламерья. Сейчас из двух десяток заметок — одна стоит внимания. Лучше читать профильные форумы, а хабр в качестве желтой прессы во время кофе с бутербродом.
me: Кстати да. Еще очень самоуверенного.
Комментаторов конечно подобрали завязанных на js. Что еще они могли сказать :)
Нода стала хорошо обновляться, но экосистема по сравнению с фронтом не развивается, все пишут на экспрессе и тулзах, которые еще TJ написал. Все идет к тому, что нода становится придатком фронта в виде дев серверов и билд утилит. Большие проекты пишутся лапшой и костылями, серьезные люди в язык не идут, потому что есть более интересные альтернативы, как результат отсутствие хороших практик в комьюнити и понимания куда двигаться. Это было хорошо видно на Node Intercative Europ 2016: почти полное отсутствие именно Node.js повестки кроме поддержки новых стандартов. Увеличение числа вакансий опять же по сравнению с фронтом мизерное, скорее просто как плюс для фронта.
Здрасьте. Как это не развивается? А Koa, а Hapi? А миллион фреймворков и плагинов к ним для написания микросервисов? А готовые решения вроде Horizon или Deepstream? Вы чего?
Я думаю речь идет о фреймворках уровня Yii, Symfony, Lavarel из мира PHP. Чтобы было коммьюнити, чтобы была какая-то предсказуемость и поддержка, проверенность временем, чтобы в конце концов был какой-то деревянный стандарт уровня PSR. Из PHP 4 за несколько лет сделали язык enterprise уровня со всеми прилагаемыми плюшками, из javascript пока нет.
В этом комьюнити больше популярны SPA-приложения, которые дергают API по xhr или вебсокетам.
Koa и Hapi этот же экспресс, только с сахаром или сбоку, они не решают проблему написания больших приложений, чем являются те же микросервисы. А BaaS существует для всего, нода тут не при чем
Да полно есть решений для создания микросервисов. Один Loopback от IBM чего стоит.
Интерпрайз чтобы веб серверы делать? Нет, спасибо. Дело же не в наборе фич, которые можно и так руками прикрутить, а в эволюции решений на основе языка. Посмотрите сколько было создано подходов для работы с UI на клиенте и сколько на сервере для работы с данными. А язык прекрасно подходит для экспериментов и заимствования из других мультипарадигменностью. Слава богу TypeScript появился за 5 лет.
В плане микросервисов язык Go выглядит на мой взгляд более убедительно, так что в этом плане у Node.js шансы не больше чем у других языков. Будущее конечно же есть, т.к. у node.js в мире фронтенда нет альтернативы, а вот в мире бэкенда у Node.js есть большое количество конкурентов, так что я не вижу большого будущего у node в этом направлении. Полиморфные приложение нужны единицам, они усложняют код, сложны для понимания, стоимость поддержи увеличивается, да и бизнесу сложно объяснить — зачем это все нужно.
На стороне front-end я знаком с Angular, back-end пишу на asp.net MVC. Есть ли какой-либо резон в освоении node.js? Где можно найти примеры кода хороших, реальных проектов (а то везде этот hello-world..)?
а то везде этот hello-world..

Поддержу вас. Сам из .NET, сейчас ищу хороший пример испоьзования Redux, по сути ничего путного кроме counter и todo list не могу найти.

Посмотрите на ghost это блог-платформа. Для примера хорошо подходит, правда написана с использованием коллбэков, а не промисов, но это не критично для понимания.

Неочень перспективы с тех пор как гугл популяризировал CSP. Горутинами озвученные задачи решать намного проще чем калбэками. Даже промисы с генераторами не остановят падение
Перспектива появится, когда NodeJS, наконец, отвяжут от тормозного V8 и пересадят на гиперзвуковой Chakra… Ну, или прослойку запилят, чтобы движок можно было выбрать.

V8 / Chakra и тп вторичные вещи по моему мнение. Для большой кодовой базы, большой команды, и написания бизнес логики важны более общие вещи, например строгая типизация, поэтому я за вариант — перспектива появится когда использование чистого JS станет "плохой практикой" (по крайней мере на бэкенде), а обычным делом будет все писать на TypeScript (или чем-то похожем к тому времени).

не вижу ни малейшей выгоды использхования одного языка на сервере и клиенте. Сервер и клиент полностью. отличается и платформой в целом, и технологиями и задачами которые они выполняют.
Посему один язык как раз нелогичен.
Да и програмист, знающий один язык все равно никому не нужен — но обучении тоже не сэкономишь.
Думаю нода займет свою определенную нишу для кторой она и создавалась — обеспечить быструю отдачу мелких данных. Типа сообщений в соцсетях. Но таких приложений не так много среди всего множства веб приложений.
Аналогичная ситуация с уже проходящей модой на nosql БД. Повыпендривались и поняли что на биг дата (а нарастающее количество инфы все приведет к бигдата) нереляционным решениям в ближайшем будущем делать нечего (кроме разумеется всяких кеширований)

Один язык очень даже логичен и востребован. Например:


  • проверить какие-то данные достаточно сложным методом, при этом каждый раз не гонять это на сервер, потому что хочется быстрый фидбек
  • иметь сложную модель, но чтобы внесение изменений в схему не требовало поддержки в двух местах
  • написать модуль для использования на сервере, но приготовиться к тому, что его можно будет легко вынести на клиент, или наоборот
  • выполнить клиентский код на сервере, например, если пришёл клиент, который это не умеет (например, google bot)

Вот только нода мне не очень нравится, сейчас это можно решить на C++, скомпилировав код в emscripten. Хотелось бы что-то менее низкоуровневое, надеюсь, что в скором будущем с приходом webassembly у нас таки будет быстрый язык, который будет работать везде.

проверить какие-то данные достаточно сложным методом, при этом каждый раз не гонять это на сервер, потому что хочется быстрый фидбек

если данные можно не гонять на сервер то какая разница какой там язык
иметь сложную модель, но чтобы внесение изменений в схему не требовало поддержки в двух местах

а на фига вообще на клиенте какие то модели? Следовать еще одной не более чем модной фишке использованию яваскриптовых фреймворков вас никто не заставляет.
написать модуль для использования на сервере, но приготовиться к тому, что его можно будет легко вынести на клиент, или наоборот

клиент и сервер — разные платформы с разными задачами. как вы себе представляете такой модуль? Типа проверка даты на валидность?
выполнить клиентский код на сервере

это вообще какая то екзотика.

попросту говоря ваши аргументы притянуты за уши.

Вот только нода мне не очень нравится, сейчас это можно решить на C++, скомпилировав код в emscripten.

а еще все это может решить старый добрый PHP. Особенно когда там будет сделан JIT компилятор.
Впрочем для подавляющего большинства сайтов это нафиг не нужно, учитывая что железо нынче дешевле труда программиста.
Просто каждый новичок мнит себя Цукербергом и думает что на его сайт будут ходить по милиону в день.
Посему еще раз — проблемы которые вы описали яйца выеденного не стоят.

если данные можно не гонять на сервер то какая разница какой там язык

Но проверить на сервере потом тоже нужно. А как?


а на фига вообще на клиенте какие то модели?

Давайте здесь не будем обсуждать, а нужна ли в браузере сложная логика и примем как данное, что нужна. Если не нужна, то и обсуждать тут нечего, всё и так ясно. У меня вот менеджер паролей в браузере, когда будет сервер, я захочу читать формат одним и тем же кодом. На работе делаю полноценный офис в браузере, с соответстием моделей на сервере и клиенте, с оффлайн-редактированием и мёржем. Ещё много-много применений.


клиент и сервер — разные платформы с разными задачами.

Конечно, но в разных задачах бывают нужны одинаковые алгоритмы.


это вообще какая то екзотика.

Экзотика? Для googlebot очень даже требуется пререндеринг. Даже в вакансиях сейчас это спрашивают. Нет, уже не экзотика.


а еще все это может решить старый добрый PHP

Вы его на клиенте не выполните. Проблема код-шаринга не решена.
Для сайтов конечно не нужно, но веб это давно уже включает в себя не только простые бложики, но и полноценные приложения. Опять же, повторю, обсуждать необходимость в них — пожалуйста не надо.

GWT был придуман еще до появления node.js, Java на сервере и на клиенте, есть еще Vaadin фреймворк с таким же подходом, там тоже Java на клиенте и на бэкенеде, так что идея эта не новая.
Java на сервере и на клиенте

Была. Но сейчас уже можно сказать, что на клиенте её нет.
Я не утверждаю, что это новый подход. Это подход, который предположительно будет работать. Я о webassembly, если что, не о node.js. Идея использовать js везде, как я написал выше, мне не очень, но пока это единственный на сегодня рабочий способ код-шаринга. А так да, вы правы, попытки использовать общий язык начались уже давно, потому что это востребовано бизнесом.

200к херово написанных и бесполезных модулей в репозитории — врядли это является преимуществом.
Вообще, использовать все это дело надо очень осторожно и только топовые модули, коих обычно пару десятков.
«Как было указано выше, Node.js однопоточный и использует всего одно ядро процессора. Может потребоваться реализовать конкурентность на многоядерном сервере, для этого команда разработчиков ядра Node уже занимается подготовкой специального кластерного модуля. Кроме того, вы без труда могли бы запустить несколько экземпляров сервера Node.js за обратным прокси с использованием nginx.»

Статья прошлого года:
https://habrahabr.ru/company/piter/blog/265649/
Уже больше 6 лет занимаюсь разработками как backend так и frontend. Для некоторых решений на серверной части node будет оптимальным решением (сам использую), НО если мы очень хорошо знаете javascript потому что из большого набора модулей мы нечего не получите (это я про примеры, готовые решения). На практике сайты, которые полностью использую node поддерживать проблематично. Это я имею только свой опыт. Может кто-то использует node для других целей или он гуру в JS и node ему ножен только для запуска js без браузера)
Only those users with full accounts are able to leave comments. Log in, please.