Анонсирован (https://medium.com/@nodejs/the-node-js-project-introduc...) релиз Node.js 10.0.0 (https://nodejs.org), платформы для выполнения высокопроизводительных сетевых приложений на языке JavaScript. Node.js 10.0 относится к веткам с длительным сроком поддержки, но данный статус будет присвоен только в октябре, после проведения стабилизации. Обновления для LTS-веток выпускаются в течение 4 лет. Поддержка прошлой LTS-ветки Node.js 8.0 продлится до 2021 года, а позапрошлой LTS-ветки 6.0 до 2020 года. Поддержка промежуточной ветки Node.js 9.0 будет прекращена в июле 2018 года.Среди улучшений в Node.js 10.0:
- Обновление движка V8 до версии 6.6 (https://v8project.blogspot.com/). В новой версии отмечается оптимизация производительности асинхронных операций, функций promises/async, методов работы с массивами и строками (Array.prototype.*, String.prototype.indexOf ). Более чем в 10 раз увеличена производительность операции Array#reduce для массивов с большим числом пустот или значений с плавающей запятой. Производительность оператора instanceof возросла в 3.6 раза. Устранены некоторые узкие места с производительностью Function.prototype.bind. WeakMap и WeakSet. Сокращено потребления памяти в движке V8;
- Переход на использование OpenSSL 1.1.0, что позволило обеспечить поддержку потокового шифра ChaCha20 (http://cr.yp.to/chacha.html) и алгоритма аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html). В дальнейшем запланирован переход на ветку OpenSSL 1.1.1 для обеспечения поддержки TLS 1.3 (https://www.opennet.dev/opennews/art.shtml?num=48324) до осенней стабилизации Node.js 10;- Продолжен перевод проекта на новую систему обработки ошибок, в которой каждой проблеме присвоен свой уникальный код ошибки, что позволит организовать автоматизированный разбор проблем без привязки к тексту сообщения об ошибке и выпускать обновления текстов ошибок не дожидаясь следующего значительного релиза;
- Стабилизирован и переведён в категорию официально поддерживаемых новый API Node.js (N-API (https://nodejs.org/api/n-api.html)), который предоставляет средства для создания нативных дополнений к Node.js, не привязанных к JavaScript runtime и рассматриваемых как часть Node.js. N-API позволяет без перекомпиляции использовать существующее дополнение с новыми версиями Node.js и с разными JavaScript-движками (V8 и Chakra-Core);- Расширены средства диагностики и отладки. Добавлены новые события трассировки для точного измерения времени выполнения кода, позволяющие выявлять узкие места и провалы в производительности в пользовательском коде. В API также добавлена возможность включения и выключения трассировки во время выполнения программы;
- Добавлен экспериментальный API fs/promises, предоставляющий вариант функций "fs", реализованный при помощи механизма promise и демонстрирующий более высокую эффективность;
- Обеспечена поддержка новых возможностей языка JavaScript. Function.prototype.toString() теперь возвращает строку с кодом функции, полостью совпадающую с тем, как функция задана в исходных текстах (все отступы и даже комментарии сохраняются);
- Добавлены дополнительные изменения (https://github.com/v8/v8/wiki/Untrusted-code-mitigations) для противодействия атакам по сторонним каналам и добавлена защита от обращения к памяти вне границ области, отведённой для WebAssembly, а также доступной через массивы и строки JavaScript.
Одновременно объявлено (https://medium.com/npm-inc/announcing-npm-6-5d0b1799a905) о выходе пакетного менеджера NPM 6 (https://go.npm.me/npm6), в котором отмечено существенное увеличение производительности - некоторые операции стали выполняться до 17 раз быстрее. В 2-3 раза ускорено выполнение команды "npm ci". Добавлена возможность настройки webhook (уведомления об изменении пакетов) непосредственно из CLI. Реализовано автоматическое разрешение конфликтов с файлами блокировки (lockfile) и упрощено создание повторяемых сборок.
В репозитории организована проверка пакетов на наличие известных уязвимостей - при установке пакетов, содержащих неисправленные уязвимости, пользователю теперь выводится специальное предупреждение. Для проведения анализа на наличие уязвимостей в уже установленных пакетов и связанных с ними зависимостей добавлена новая команда "npm audit". Более наглядно предоставлена информация о целостности метаданных, что упрощает выявление вредоносных модификаций или повреждений в пакетах.
URL: https://medium.com/@nodejs/the-node-js-project-introduc...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48490
Молодцы! Уважаем!
Кто молодцы, кого уважаем и причем тут высокая производительность?
Тут как в действенных* шампунях против перхоти.* по сравнению со своей предыдущей разработкой.
Когда-то, году в 2006-ом, я друзьям и коллегам рассказывал о концепции "распределённой среды исполнения". Не без оснований - участвовал в одном интересном проекте.Предполагалось, что на серверной и клиентской сторонах применяется единая виртуальная машина, исполняющая байт-код приложений, которым совершенно без разницы где исполняться. При запуске приложения, на клиентской стороне выполняется процесс репликации кода. Сами приложения поделены на объекты, которые могут частично располагаться на сервере, а частично на клиенте, при этом свободно взаимодействовать друг с другом в едином адресном пространстве. Приложение может исполняться на сервере, но его оконный интерфейс отображается на клиенте, и это — только один из возможных вариантов.
Тогда эту концепцию просто не поняли...
Сейчас же наблюдается следующее: V8 становится единым ядром ВМ JS для обеих сторон. API расширяется и всё теснее сопрягается с функциями ОС. WebAssembly на подходе. Электрон и иже прочие с ним. Как говорится, "те же яйца, только в профиль". Сам бы не вспомнил, если б не программист из Сан-Франциско, который тогда эту концепцию слышал, но так же не воспринял всерьёз. Говорит, сейчас всё к этому идёт семимильными шагами. Очередной пример "созревания" идеи. До сих пор продолжается.
Если что, проект назывался "Deeptown.Org", и эта штука реально работала, демонстрируя все упомянутые качества и не только. Что с ним стало сейчас, я не в курсе, но такой объём рабочего кода бесследно пропасть не может.
Только Особенно в этом преуспели майнеры. Остальным нафиг не упало.
Там главная пользовательская killer-фича была в таких моментах: приложение не нужно было устанавливать, отслеживать зависимости, да и вопрос сопряжения решался сам собой: они работали в единой среде. Нужно было лишь разрешение пользователя на доступ. Нынче что-то подобное имеется в Андроиде и ВЕБ-тулкитах типа Google Docs.Один фиг всё идёт к подобному. Вся репликация, JIT-компиляция и прочие процессы оптимизации запуска могут происходить на фоне уже запущенного по сети ПО. Пользователь даже не будет знать, что что-то устанавливается к нему в браузер. Просто следующий раз запустится быстрее.
> Пользователь даже не будет знать, что что-то устанавливается к нему в
> браузер. Просто следующий раз запустится быстрее.Спасибо, не надо. А то программистов начнут калечить и убивать прямо на улицах.
>> Пользователь даже не будет знать, что что-то устанавливается к нему в
>> браузер. Просто следующий раз запустится быстрее.
> Спасибо, не надо. А то программистов начнут калечить и убивать прямо на
> улицах.Тогда это не выглядело настолько критичным. Достаточно вспомнить, что тогда и Java-апплеты ещё не запрещали. К тому же, вся "каша" внутри клиента не имела доступа к файлам хостовой ОС. Только по прямым запросам через диалоговое окно или в специальный каталог локальной ФС.
Напомню: это всё — дело прошлого. Сейчас я всего лишь предаюсь воспоминаниям. Что стало с этим кодом — без понятия.
Вам бы перед этим посмотреть хотя бы на концепцию OpenOffice (подозреваю, что тогда ещё StarOffice). UNO делает всё, что Вам нужно.
Ради таких коментариев в том числе и хожу на данный ресурс :)
> Ради таких коментариев в том числе и хожу на данный ресурс :)Дык, сейчас это — дело прошлого. Оно ни на что не влияет, если только двое авторов этого дела из Новосиба не договорились с какой-то конторой. Тогда систему хотела скупить одна весьма влиятельная организация, но они не договорились. А может это только внешне так выглядело.
Ничто не ново под Луной.
Клиентская сторона не может полностью доверенной.
> Клиентская сторона не может полностью доверенной.Так она и не была полностью доверенной для локальной ОС. Там даже взаимодействие объектов определялось по их UID через политику прав доступа. Нечто, сильно похожее на дерево ФС Linux, только действующее в адресном пространстве распределённой системы, где адрес — хеш. Локально же поддерживалась своя файловая система, где для каждого UID был свой слой абстракции. Файлы не пересекались, если только сам пользователь не даст на это добро.
Вообще, эта штука изначально рассчитывалась как исполнительная среда виртуальной реальности. Авторы подошли к вопросу с этой стороны, отправив все вопросы со "средствами погружения" в долгий ящик, да и вообще не заморачиваясь на этот счёт.
Если уж на то пошло, то там вообще не было понятия запуска приложения. Висящие в пространстве объекты реагировали на события запросов, генеря инстанции интерфейса и профили для каждого пользователя. Можно было лишь запустить локально бинарник на исполнение с единственной целью — создать в среде необходимые для функционирования ПО объекты.
Вот этим и предлагалось пользоваться. Пример: есть строка поиска, в ней вводится слово "калькулятор", а среди результатов - ссылка на приложение. По клику на ней открывалось окно калькулятора. Примерно то же, на что сейчас похожи ВЕБ-приложения, только в 2006 году.
> Вот этим и предлагалось пользоваться. Пример: есть строка поиска, в ней вводится
> слово "калькулятор", а среди результатов - ссылка на приложение. По клику
> на ней открывалось окно калькулятора. Примерно то же, на что сейчас
> похожи ВЕБ-приложения, только в 2006 году.https://en.wikipedia.org/wiki/Spotlight_%28software...
А вообще это называют incremental search и оно древнее, как сами компьютеры. Реализации и цели использования могут разниться.
Хорошо бы инноваторам перед изобретением всего нового знакомиться с уже созданными вещами. :)
ЗЫ
> Хорошо бы инноваторам перед изобретением всего нового знакомиться с уже созданными вещами.
> :)Ну, что ж теперь-то судить? Сейчас проекта в открытом виде не существует.
> А вообще это называют incremental search и оно древнее, как сами компьютеры.
> Реализации и цели использования могут разниться.За ссылки спасибо!
не льсти себе, там и виртуальная машина не очень единая, и разница для стороны, на которой запущен код, очень даже есть, и репликацией ты называешь простое скачивание по хттп, да ещё и с левого cdn, сами приложения так прекрасно поделены на объекты, что яндекс крадёт у тебя движения мышью и введённые данные со страницы банка, где ты там усмотрел ЕДИНОЕ адресное пространство у клиента и сервера — вообще непонятно. В общем, намешал бреда и назвал себя прозорливым алтфаком. Фу.
Вероятно, парни работали над повторным изобретением идеи мейнфрейма. :)
> Вероятно, парни работали над повторным изобретением идеи мейнфрейма. :)Кстати, на мейнфрейм оглядка была, да. Но цели были слегка иные. Вряд ли у мейнфрейма в программном стеке ПО предполагался т.н. "сервер доступа", отвечающий за маршрутизацию трафика и уж тем более амплитуд звуковых волн. Да-да, там была такая штука, она смешивала амплитуды, исходя из позиции "аватара" в 3D-пространстве. Отрабатывался даже "эффект Доплера".
Я ещё раз повторю — эта штука позиционировалась как механизм виртуальной реальности. Задачи ВЕБ-а брать на себя даже не собирались. По ВЕБ-у предполагалась трансляция вывода от браузерного движка в 3D-сцену.
В мейнфрейме может быть, условно говоря, «всё» (что угодно). Мейнфрейм, концептуально и архитектурно, это уже и есть, по сути, «виртуализатор» — этакая абстрактная компьютерная среда, посредством которой реализована «виртуальная реальность», внутри которой в «виртуальных компьютерах» одновременно могут жить разные ОС, программы в которых даже знать не будут, что это всё вокруг них «ненастоящее».
> не льсти себе, там и виртуальная машина не очень единая, и разница
> для стороны, на которой запущен код, очень даже есть, и репликацией
> ты называешь простое скачивание по хттп, да ещё и с левого
> cdn, сами приложения так прекрасно поделены на объекты, что яндекс крадёт
> у тебя движения мышью и введённые данные со страницы банка, где
> ты там усмотрел ЕДИНОЕ адресное пространство у клиента и сервера —
> вообще непонятно. В общем, намешал бреда и назвал себя прозорливым алтфаком.
> Фу.Эх, любителей выдавать своё мнение за истину на Опене и Лоре развелось тучами. Даже не знаю, откуда вы все такие берётесь?
1) Хоть где-то сказано, что идея моя? Я даже проект назвал. Авторы идеи — два программиста из Новосибирска. Я лишь принимал участие в нём. Но рассказывать — рассказывал. Так при чём тут "прозорливость"?
2) Что было там, мне, наверное, лучше известно, чем тебе. Я с этой штукой имел непосредственное знакомство на уровне кода и тех.доков;
3) Не было никакого CDN. Протокол HTTP не применялся вообще. Вместо него использовался собственный протокол DTTP (DeepTown Transport Protocol), способный работать как поверх стека TCP/IP, так и без него, выполняя даже функции Ethernet;
4) Единое адресное пространство было у проекта Deeptown.Org, а не у современных ВЕБ-приложений. Ты чем вообще читаешь??? Было лишь косвенное сравнение одного с другим.
> Предполагалось, что на серверной и клиентской сторонах применяется единая виртуальная машина, исполняющая байт-код приложений, которым совершенно без разницы где исполняться.Это вам в IBM с такими идеями надо было. Правда они уже давно их реализовали.
>> Предполагалось, что на серверной и клиентской сторонах применяется единая виртуальная машина, исполняющая байт-код приложений, которым совершенно без разницы где исполняться.
> Это вам в IBM с такими идеями надо было. Правда они уже
> давно их реализовали.Идея не моя, а двух программеров из Новосибирска. Вполне возможно, что что-то реализовали. Только цели там другие ставились.
Гугл хотел скупить, но автор проекта не захотел продавать, хотя встречался с ними. Тогда Гугл ещё располагался в Москве в т.н. "розовом здании" с небольшим садом в ограде. Позже куда-то съехали.
>Гугл хотел скупить, но автор проекта не захотел продавать, хотя встречался с ними. Тогда Гугл ещё располагался в Москве в т.н. "розовом здании" с небольшим садом в ограде. Позже куда-то съехали.Сестра, два клозапина этому наполеону.
> Сестра, два клозапина этому наполеону.Не хочешь, не верь. Тебя кто заставляет, что ли? И клозапин свой забери обратно.
Я рассказываю, что видел, а кто как на это отреагирует — ни горячо, ни холодно.
>Тогда Гугл ещё располагался в Москве в т.н. "розовом здании" с небольшим садом в ограде.Ору)))
Ори дальше.
Судя по датам, как раз совпадает с первой версией GWT. Там как раз этот подход и реализован. Хочешь код на клиенте выполняешь, хочешь на сервере. :)
> Судя по датам, как раз совпадает с первой версией GWT. Там как
> раз этот подход и реализован. Хочешь код на клиенте выполняешь, хочешь
> на сервере. :)Наблюдение интересное, но чтобы разработать подобное, нужен был хотя бы год на разработку архитектуры и написание кода. Думаю, оно было независимо друг от друга.
У Deeptown.Org была своя ВМ "GIDE", свой язык программирования K++, рассчитанный на неё. Кстати, там лямда-функции представлялись как объекты данных. Хотя точнее было бы сказать объекты моделей данных, содержавших в себе исполняемый код. Можно было передать эту функция как значение между объектами из состава разного ПО.
Кстати, нечто местами похожее проглядывается в концепции среды исполнения Phantom OS. Там вообще ФС в привычном понимании нет. Файл — есть объект, в свойстве которого хранится содержимое обычного файла. В этом проекты схожи.
>[оверквотинг удален]
> среды исполнения". Не без оснований - участвовал в одном интересном проекте.
> Предполагалось, что на серверной и клиентской сторонах применяется единая виртуальная
> машина, исполняющая байт-код приложений, которым совершенно без разницы где исполняться.
> При запуске приложения, на клиентской стороне выполняется процесс репликации кода. Сами
> приложения поделены на объекты, которые могут частично располагаться на сервере, а
> частично на клиенте, при этом свободно взаимодействовать друг с другом в
> едином адресном пространстве. Приложение может исполняться на сервере, но его оконный
> интерфейс отображается на клиенте, и это — только один из возможных
> вариантов.
> Тогда эту концепцию просто не поняли...Так эта JEE ;)
> Так эта JEE ;)Тоже много общего. Но там был свой сетевой протокол, аудиоподсистема, механика 3D-пространства с тремя представлениями объектов: 1) Графическое; 2) Физическое; 3) Механическое.
В общем, цели стояли разные. Для вывода графики оно использовало на тот момент движок Ogre3D.
> виртуальная машина, исполняющая байт-код приложений, которым совершенно без разницы где исполнятьсяЕмнип, Джо Андерсон сотоварищи из Эрикссон уже написали такое, только оно не в браузере крутится.
> Емнип, Джо Андерсон сотоварищи из Эрикссон уже написали такое, только оно не
> в браузере крутится.Конкретно то решение было написано на C и C++, представляло собой связку ядра и модулей, определяющих функционал ноды (сервер, клиент, клиент+сервер, транслятор и т.д.). Браузер там и близко не применялся.
>Приложение может исполняться на сервере, но его оконный интерфейс отображается на клиентеВау, они изобрели X11
>>Приложение может исполняться на сервере, но его оконный интерфейс отображается на клиенте
> Вау, они изобрели X11Влом уже морально распинаться... Особенно перед такими "яслями", выдёргивающими фразу из контекста.
В кратце объясню, но скорее для других:
В среде "висит" набор объектов, содержащих как данные, так и исполняемый байт-код. Все под одним UID, а потому имеют друг к другу доступ. Это — и есть ПО. Запрос извне к публичной фабричной функции генерит объед под UID пользователя, который обратился. Этот объект уже тянет на исполнение всё остальное необходимое. У клиента в конфигурации есть доступ к графическому серверу, а на сервере нет. Тем более под этим UID. Потому создаётся реплика всех объектов-участников графической оболочки ПО. Т.е., на стороне клиента работает "графическая" часть приложения, а на стороне сервера — общая для всех пользователей.
И никакого X11 там и в помине не было! Там не передавылись вызовы отрисовки примитивов. Само ПО, образно говоря, "проростало" в пространство клиента своей графической частью.
Когда уже сделают node как зависимость для приложений.. чтоб они не тащили браузер с собой, а только подтягивали
Если я правильно тебя понял, то ты путаешь Electron с Node.js. В Ноде нет никакого браузера, там только движок V8.
Нода - фактически просто скриптовый язык, который можно использовать в разных случаях жизни, хоть сисадминство, хоть сервера (в принципе, как и остальные подобные языки).
В ноде мне не нравится, что npm-пакеты при установке с опцией "-g" по умолчанию требуют прав суперпользователя.
Учитывая, что база npm - это та еще помойка, хотелось бы, чтобы пакеты ставились в папку пользователя.
Да, это можно настроить, но почему так сделано - непонятно.
> В ноде мне не нравится, что npm-пакеты при установке с опцией "-g"
> по умолчанию требуют прав суперпользователя.
> Учитывая, что база npm - это та еще помойка, хотелось бы, чтобы
> пакеты ставились в папку пользователя.
> Да, это можно настроить, но почему так сделано - непонятно.предложи получше способ установки пакета в систему, не используя специальных привелегий?
> предложи получше способ установки пакета в систему, не используя специальных привелегий?"--prefix dirname" ?
Это у вас теперь называется "в систему"? Лучше бы ты про докер сказал.
> предложи получше способ установки пакета в систему, не используя специальных привелегий?echo 'prefix = ~/.node' >> ~/.npmrc
После этого npm i -g будет ставить в ~/.node
попробуй без опции -g (--global) ставить
> попробуй без опции -g (--global) ставитьНет, вы не поняли. В вашем случае пакет с зависимостями установится в ./node_modules, и запускать его надо будет через $ node ./node_modules/some_npm/bin/some_npm. А хочется, чтобы он установился куда-нибудь в ~/.global_node_modules и его можно было запускать прямо по имени из терминала.
https://github.com/nodeschool/discussions/wiki/Installing-gl...)
Вот сейча читаю, там предлагают сделать
3. Another option: take ownership of /usr/local
sudo chown -R $USER /usr/local
Смешно, конечно.Есть еще Option 2: возможность устанавливать npm-пакеты "глобально" в домашнюю папку, Там нужно PATH обновить, какую-то настройку npm-a, и все, в принципе работает. Никаких рутовских прав не нужно. Непонятно, почему до сих пор такое поведение не являеся поведением по умолчанию
https://github.com/nodeschool/discussions/wiki/In
stalling-global-node-modules-(Linux-and-Mac)Извините, кажется, опеннет обрезает ссылки
После включения в современные версии npm команды npx, надобность в глобальных пакетах вообще отпала. Не могу представить себе ни одной причины, по которой еще нужно использовать глобальные пакеты.
> После включения в современные версии npm команды npx, надобность в глобальных пакетах
> вообще отпала. Не могу представить себе ни одной причины, по
> которой еще нужно использовать глобальные пакеты.Ну да, ну да. В документации черным по еблому
INSTALL
npm install -g npx
> Не могу представить себе ни одной причины, по
> которой еще нужно использовать глобальные пакеты.Для уязвимостей самое то.
Так надо Node ставить из NVM, а не репозитория, тогда и global пакеты будет храниться в юзерспейсе, как и сама Node.
NPM 6 войдет в состав Node только к версии 10.1, не раньше.
В июне выйдет обновление с V8 6.7 (насчет 6.8 команда не уверена, что имеет смысл тратить время на починку ABI V8 к версии 6.6).
эта та байда с псевдо асинхронным callback hell про которую ее создатель сказал что ее нужно похоронить и писать на golang?
"Вспомнити", ты ли это?
> эта та байда с псевдо асинхронным callback hell про которую ее создатель
> сказал что ее нужно похоронить и писать на golang?Можно ссылку?
https://www.mappingthejourney.com/single-post/2017/08/31/epi.../
годно
>"каждой проблеме присвоен свой уникальный код ошибки"это просто мега LOL
Релиз выходит за полгода до начала стабилизации???
Да, целых полгода на полировку и стабилизацию. А что в этом плохого?
Рискну предположить, что аноним выше говорит, что это не релиз, а бета (или альфа) раз он еще не готов. Но видимо, в мире js заведено по-другому, чтобы веб-(животные, любящие бананы и лазить по деревьям) не боялись "полировать" и стабилизировать.
https://github.com/nodejs/Release#release-scheduleВот план релизов ноды. Перед тем как оскорблять людей, ознакомьтесь в следующий раз.
> https://github.com/nodejs/Release#release-schedule
> Вот план релизов ноды. Перед тем как оскорблять людей, ознакомьтесь в следующий
> раз.Ты Илюша не путай, никого я не оскорблял. Если ты в веб-макаках видишь что-то плохое, то это твои личные проблемы.