Comments 49
Как можно объяснить то, что JavaScript, в роли серверного языка, был столь быстро и широко принят сообществом разработчиков?
Кучей разработчиков, которых выпустили из фронт-енд загона? Меня всегда удивляло, как люди умудряются банально не замечать слона и делать вид, что основная причина популярности javascript не в том, что он ультимативно нужен для разработчки веб-сайтов.
Поддерживаю.
А может язык оказался настолько хорош, что после установления монополии в своей среде, начал захватывать новые области?
Может топ разработчики не такие и злые, не ставят нам 'ультиматум', а используют лучшее в своих системах?)
Но почему-то всегда в качестве встроенного скриптового движка в играх все выбирают lua, как так?
Иногда просто убивают комментарии в стиле «твой язык/стиль/по — фигня, потому что вот в этом конкретном случае лучше подходит другое».
Ладно бы еще игры были доминирующими программами или основой рынка, но нет.
Человек написал глупость в стиле «язык вышел в топ — поэтому и был принят сообществом». Причина и следствие. А спорить «что лучше» — это в другую веткую
Я не даю оценку языку, я говорю, что из-за того, что уже много людей знали JavaScript, а еще куча людей писали исключительно на нем, популярность NodeJS так резко возросла.
Банально потому, что JavaScript — это язык, который хоть как-то использовал почти каждый программист, а куча людей (фронтенеров) использовали только его.
Игнорируя этот факт и аппилируя к тому, что платформа крутая, потому что ее так тепло приняли нельзя именно по этой причине.
Если бы у JavaScript была какая-то альтернатива в качестве языка для фронтенд разработки еще можно было бы что-то говорить, но так вы просто проводите неверный мысленный эксперимент. JavaScript уже был условно самым известным языком.
Это как рассуждать про то, какой крутой английский, потому что им пользуется куча людей, игнорируя исторический контекст того, почему же он стал таким распространенным в мире.
Чем же он хорош? По моему это недоразумение, а не язык
А если думать чуть более глубоко, то Node.JS был принят сообществом разработчиков потому что он поддерживает современную спецификацию ECMAScript, к нему можно подключать различные модули, он может спокойно общаться по API с другими частями вашего BE. Тут лишь нужно проанализировать область в которой вам нужно что-то разработать и проанализировать, а подходит ли инструмент?
На счёт фронт-енд загона — тут отдельная тема, если вы считаете, что любой может писать на JS, то я вам скажу только одно, что и я могу написать кусок говнокода на C# за 5 минут, который будет работать. А чтобы писать красиво и аккуратно тут уже понадобится опыт и навыки.
Поскажите, пожалуйста, что такое "BE"?
На счёт фронт-енд загона — тут отдельная тема, если вы считаете, что любой может писать на JS, то я
Нет, это было к тому, что в целом до nodejs, javascript был узконаправленным языком, который использовался только в одном месте — фронтенд. А учить javascript + еще какой-то язык для того, что бы использовать его в других задачах довольно затратно по времени, вряд ли оплачивалось компаниями и потому мало кто из фронт-енд специалистов это делал.
Вот несколько популярных современных серверных JS-фреймворков:
И ни слова о ASP/JScript
2. Вы не поверите, но эта проблема есть везде. В PHP у вас процессы для apache или php-fpm, в python это у вас воркеры у вашего сервера, в java, c# и go — это пул потоков.
3. В python есть асинхронность и async/await (а раньше yeild / coroutine) и про callback hell там не слышали, потому что сразу было сделать нормально.
У вас какая-то каша.
NodeJS в целом работает только на одном ядре в один поток, у него проблемы с многопоточностью (условно). А благодаря async логике для него I/O как раз не является проблемой. Ну и да, кластер тоже есть.
И вообще, что это значит "никогда не угадаешь"? Как по вашему тредпулы работают? Они, чаще всего, тоже создают треды заранее и те просто висят и тупят.
несколько для I/O
Дайте пруф. Насколько помню, то libuv делает потоки, для асинхронной работы с файловой системой.
Тред пулы создают потоки на количество ядер процессора, и программа задействует ресурсы сервера максимально эффективно, без какой либо дополнительной настройки.
Так просто это не работает.
1) привести общее количество потоков к ядрам процессора не представляется возможным (расскажете как?) 2) из созданных потоков только один на процесс занимается JS, остальные I/O, и как же определить баланс между количеством потоков на JS и на I/O? Методом подбора!
- А как вы это делаете в других приложениях? Берете эмпирический 2 * количество ядер + 1 процесс и запускаете.
- Так просто это не работает. Если треды на IO не нужны — они и не работают, а только едят немного RAM. Потому что есть всякие sleep, wait, ожидания внешнего события и так далее.
Вообще, вы же понимаете, что у вас в ОС выполняется куча программ одновременно и в них куча потоков. Вот так просто приводить все с рандомному n или 2 * n + 1 немного так себе.
Скажите, а это правда всё имеет смысл? То, о чём вы говорите. Просто мне кажется, что попытки удержать число потоков равным числу ядер сродни попытке победить ветряную мельницу. Нужны какие-то уж очень тепличные условия, чтобы это было не так. Вынести БД за пределы node приложения, вынести nginx и подобные штуки за пределы, вынести всякие memcahed, redis и пр. за пределы, вообще всё вынести и стараться не дышать. И то не факт, что удалось всё учесть.
К тому же вы пишете — "простой сайт". Складывается ощущение, что у вас линейка дискретна: "простой сайт 1000 хитов в день" и "сложный сайт — триллионы хитов в день". Или я не прав? :)
P.S. я никогда не занимался hi-load, мне просто интересно.
Вообще то приводить количество потоков к количеству ядер это не так себе, а must have. Если рабочих потоков больше, то из за переключения контекста производительность падает совсем не линейно
Вы же знаете, что у вас в системе есть там, например, ntpd, systemd и еще куча всяких демонов? А потом еще может случится так, что вы на том же сервере запускаете бд, nginx и еще что-то.
Какой смысл приводить количество потоков в приложении к ядру (и кстати, например, в Java и JVM языках это невозможно сделать) если переключений контекста все равно не избежать.
Я не использую js, но вы просто несете очень странные идеи в массы.
Но ведь IO потоки тоже не будут ничего делать, они просто будут висеть до получения сигнала. Тогда в чем проблема?
И опять же таки, "но очевидно их нужно минимизировать" это не очевидно. Очевидно, что нужно оптимизировать приложение, если для вас это важно, но почему нужно минимизировать этот показатель и игнорировать остальные, мне решительно не понятно.
На практике минимизация переключений контекста, скорее всего, последние чем вы будете заниматься, сначала вас ждет увлекательный путь оптимизации взаимодействий с бд, потом самого кода, а вот потом уже выкручивание всяких таинственных ручек. И очень мало компаний и людей доходят до таинственных ручек, так как им банального этого не надо и проще еще пару серверов докупить.
Где это работает из коробки? В Java это не так и, мне кажется, в остальных языках тоже есть треды, которые нужны для рантайма.
Этого из коробки нет, потому что это никому не нужно.
Но ребята, кроме маркетинга есть что-то убедительное?
Вот проект Х, столько то клиентов(которые платят деньги), столько серверов, такие то параметры, столько то rps… и так далее.
Тогда продали бы, а пока кроме шумихи никакой информации.
Убедите меня, если кому не лень ))
На самом деле отличный инструмент для быстрой разработки небольших задач.
Для больших задач тоже пользуем. Не скажу, что сплошное счастье, но задача мигрировать проект с C# на nodeJS в планах на 2018.
Но реально убеждать — таки лень ;)
Вот не верю. Или там на C# спагетти-код вместо нормального, или узкие места, которые нода by design преодолевает.
Пока у нас больше вопросов чем ответов. Не все грабли прошли, а вот про грабли то статей как раз и не хватает.
У нас используется как внешнее АПИ, работает внутри с несколькими базами (эластик серч, дайнамо дб, редиска и тп). Нагрузка не супер большая, в среднем ~100rps на машину (50 на инстанс ноды), крутится на 2х двухядерных машинах на амазоне. Полет нормальный, с самой нодой проблем вообще не было, но и нагрузки не супер большие, но аптайм приложения довольно критичен для клиентов
До переписывания модуля с пхп 5.6 на ноду проект выдерживал 400-600k
пых упирается в оперативу 10гб 70% от полного объёма сервера.
Заменил на воду тогда 4 версия нагрузки ноль, сейчас уже 8.4.модуль обслуживает 7-10 млн в час. Нагрузка 20% ядра и 800 мб оперативный, вотакой опыт
Модульность Node позволяет создавать маленькие приложения, не сталкиваясь при этом с необходимостью поддержки огромной инфраструктуры, многие части которой в некоем конкретном случае окажутся незадействованными. При разработке Node-приложений программист выбирает именно то, что ему нужно, и, при необходимости, расширяет решение.
На самом деле, в этом вопросе Node ни в чем не выигрывает и не проигрывает остальным платформам (C#, Java, PHP, RoR...);
Сама же фраза «поддержка огромной инфраструктуры» – попытка показать, что у всех хуже, просто потому, что принято так считать, без каких-либо утверждений (ну вы же знаете, что там у них все сложно, да?).
А на самом деле, для все той же Node нужно разворачивать все те же LB, watchdog, etc. подымать базы данных, редисы, подымать инфраструктуру в докерах… – так чем же это легче, чем у остальных? =)
В противовес более традиционным подходам, жёстко регламентирующим те или иные архитектурные особенности систем, структуру, которая поддерживает серверную часть вашего приложения, создаёте именно вы.
Увы, тут вы лукавите больше всего.
Node очень жестко регламентирует архитектуру: «либо так, либо никак»…
И связано это с EventLoop – писать тяжелые обработчики попросту «запрещено» этой архитектурой.
Кроме того, JS — это язык, популярность которого за последние пять лет растёт быстрее, чем у других языков, при том, что C# и PHP теряют позиции.
Тут отлично подойдет старый пример с SQL. Не важно, какая платформа для бекенда – все они используют SQL, и вот из-за этого SQL становится более популярным, чем сами платформы.
JS популярен потому, что он используется в подавляющем большинстве фронтенд разработки и при этом абсолютно не важно, что на бекенде. Статистика – хорошо, но ее нужно правильно интерпретировать.
ps: Node – действительно крутая технология и за нею будущее в некоторой определенной области, но вот статьи такого плана, которые навешивают лапшу – это плохо. Данная статья – лишь пример как перетягивать одеяло и вызывать холивары.
Лучше стоит сконцентрироваться на том, чтобы делать из всего разнообразия фреймворков, языков и технологий – наилучшее решение из всех возможных.
Уважаемые читатели! Что вы думаете о серверном применении JavaScript и о Node.js?
Ну, JavaScript мне и на клиенте не нравится, тем более на сервере. Лучше уж, на ассемблере, потихоньку. :D
JavaScript это язык программирования. А Node это одна из платформ с этим языком. Не нужно их противопоставлять :) Слово "разница" тут не применимо.
И то и другое можно знать весьма поверхностно и делать успешные проекты. Не то, чтобы этот путь был правильным и рекомендуемым, но это так. JavaScript после выхода ES2015 стал довольно объёмным для изучения, при этом он обычно используется с таким огромным арсеналом утилит, что время на изучение и адаптацию может уйти весьма много. В то время как node это по сути его серверная обёртка с v8. Базовые вещи (вроде stream-ов) можно освоить очень быстро. А что-то более глубокое вам может никогда и не потребоваться. В общем при условии, что backend вам давно знаком, скажем по php, то зная JS в node и учить то толком нечего. Берёшь и пишешь, попутно лазая в документацию. А вот про JS такое сказать не могу, не зная языка, сразу запрыгнув в какую-нибудь контору, что пишет серьёзные реактивные SPA, времени на погружение и изучение может уйти оочень много.
Node.js и JavaScript для серверной разработки