Comments 25
JavaScript-код, выполняемый в среде Node.js, может быть в два раза быстрее, чем код, написанный на компилируемых языках, вроде C или Java, и на порядки быстрее интерпретируемых языков наподобие Python или Ruby

JS работает быстрее С?

stackoverflow.com/questions/17036059/why-does-javascript-appear-to-be-4-times-faster-than-c
benchmarksgame-team.pages.debian.net/benchmarksgame/faster/javascript.html

JavaScript значительно упрощает написание асинхронного и неблокирующего кода с использованием единственного потока, функций обратного вызова (коллбэков) и подхода к разработке, основанной на событиях.

Упрощать он начал после появления промисов, а значительно только после появления async/await которые (внезапно) уже есть в том же C#. А так добро пожаловать в ад колбеков.

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

Может быть событийного?

У Node.Js я бы выделил два преимущества.

Доступ к бекенду людям с JS бекграундом, что упрощает сетап команды. Изоморфность кода. Ну, может еще то, что из коробки Node.Js заставляет писать код в неблокирующем стиле. Остальное есть и на других платформах + многопоточность.

И да, я понимаю что это перевод, но ИМХО, не все переводы достаточно полезны.

Прошу прощения за несолько эмоциальный пост, сильно удивился.

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

Лучший пример демонстрации асинхронности на примерах событий, это загрузка данных, при которой загрузка не блокирует выполнение остальной программы. А с кнопкой пример ошибочен.
Пользуюсь пакетом pm2. В нем можно сколько душе угодно процессов наплодить. А заодно и рестарт всего добра при запуске системы или падении ноды )) Хотя больше, чем ядер (потоков) системы смысла нет, пока и двух хватает. Перед этим добром стоит прокси-балансировщик nginx.
Прошу прощения за несолько эмоциальный пост, сильно удивился.
Это не вы должны извиняться, а автор статьи за подобные опусы.

Тут скорее не некомпетентность, а использование грязных приемов для популяризации предмета.
Да, я смотрел оригинал, там работа проделана колоссальная. Такое ощущение что ее писало несколько человек и один из них копирайтер.
Еженедельно осуществляется 3 миллиарда загрузок из npm.

Это не удивительно, сегодня собирал небольшую презентацию вебпаком (babel / handlebars / sass).
Так в node_modules более 600 пакетов
Разворачиваешь проект с бэкэндом на джаве, а исходники плюс скомпилированное приложение все равно весят меньше чем node_modules -_-

Это не совсем корректное сравнение. Не все разработчики следят за тем что попадает в npm бандл. Залить тесты с ненужными файлами для некоторых не проблема. Также свой отпечаток накладывает и версионирование. Порой в одном проекте может оказаться несколько версий одной либы. Другие пихают огромный lodash в зависимости ради одной функции.


Если всё грамотно повыпиливать из node_modules, думаю что размер зависимостей будет сапостовим.

только что проверил
PS D:\work\test\npm> npm init
PS D:\work\test\npm> npm install babel-minify-webpack-plugin handlebars-loader node-sass webpack-cli -S

загрузил 295 пакетов.
Это даже не все утилиты, которые нужны для сборки.
У нас после каждого коммита / мерджа в главную ветку проект автоматически деплоится на тестовом сервере, а это несколько сотен npm запросов только во время одного такого тестового деплоймента, так что да, не удивительно. Целенаправленных скачиваний из этих 3 миллиардов загрузок, наверное, доли одного процента.
> Поддержка ES-модулей.

По-моему полноценную поддержку ES-модулей в node.js пока ещё так и не завезли.

Она есть, но не production ready. Там сейчас решается вопрос с обратной совместимость.

Писать и поддерживать серверную часть на JS — это нужно быть либо фанатом, либо упоротым.
Никто не заставляет использовать js напрямую. Тот же typescript позволяет избежать многих глупых и не очень ошибок (очепяток)
Приблуда, которая «делает» процесс «проще» и «понятнее».
Жду вторую часть и побольше примеров эксплуатации + видосики бы не помешали или сразу каналы)

"JavaScript-код, выполняемый в среде Node.js, может быть в два раза быстрее, чем код, написанный на компилируемых языках, вроде C или Java".


Если у человека руки растут из жопы, то можно и не такое написать на Си или Java. Но объективно — это не реально.


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

Может конечно для конечной PDF это и важно, но первая статья с нулевой полезностью, можно было на Википедию ссылку вставить.


И это если не особо придераться, так как спорных тезисов очень много.

Only those users with full accounts are able to leave comments. Log in, please.