company_banner

5 главных причин того, что JS-разработчики будут использовать Deno вместо Node

Автор оригинала: Dan Halperin
  • Перевод
Создатель Node.js Райан Даль выпустил новую платформу, которая рассчитана на решение многих проблем Node.js. Возможно, вашей первой реакцией на эту новость будет: «О, отлично, очередной JS-фреймворк? Его мне только и не хватало…». Я отреагировал на эту новость точно так же. А вот после того, как я немного вник в особенности Deno, я понял причины, по которым Deno можно назвать в точности тем, что серверным JavaScript-разработчикам нужно в 2020 году.



Сравним Deno и Node.js и рассмотрим 5 основных причин того, что хорошего способна дать разработчику эта платформа. В частности, речь идёт о том, что, благодаря Deno, в распоряжении того, кто раньше использовал Node.js, окажется более удобный и современный инструмент.

1. Современные возможности JavaScript: ES-модули


Node:

const moment = require("moment")

Deno:

import { moment } from "https://deno.land/x/moment/moment.ts"

Если вы, как и я, являетесь React-разработчиком, то вы уже давно заметили, что синтаксис импорта пакетов в Node.js отличается от того, к чему вы привыкли. Дело тут в том, что платформа Node.js была создана давно, в 2009 году. С тех пор в JavaScript появилось много нового. Многое в языке было улучшено.

В React (и в Deno) используется современный синтаксис импорта зависимостей вида import package from 'package'. В Node.js же применяется конструкция const package = require(«package»).

Использование синтаксиса ES-модулей даёт разработчику два серьёзных преимущества:

  1. Благодаря использованию ключевого слова import можно избирательно загружать из пакета лишь то, что нужно. Это помогает экономить память.
  2. При использовании ключевого слова require загрузка модулей выполняется синхронно. А механизм import загружает модули в асинхронном режиме, что улучшает производительность.

Если вы внимательно прочли вышеприведённые фрагменты кода, вы могли обратить внимание на то, что в Deno-примере пакет moment импортируется из URL. А это ведёт нас к следующему преимуществу Deno перед Node.

2. Децентрализованное хранилище пакетов


При использовании Deno разработчик больше не привязан к NPM. Вы правильно меня поняли: больше никакого package.json. Каждый пакет загружается с использованием URL.

В Node.js, для того чтобы использовать пакет, нужно сначала установить его из NPM:

npm i moment

Далее, необходимо дождаться завершения установки, а уже после этого подключать пакет в приложении:

const moment = require("moment")

Кроме того, каждый раз, когда кому-нибудь будет нужно запустить ваш Node.js-проект локально, понадобится устанавливать все зависимости этого проекта из NPM.

В среде Deno пакеты импортируются с использованием URL. В результате, если в вашем проекте нужна библиотека moment, вам достаточно импортировать её с использованием URL https://deno.land/x/moment/moment.ts. Выглядит это, как мы уже видели, так:

import { moment } from "https://deno.land/x/moment/moment.ts"

В деле работы с пакетами у Deno есть ещё одно огромное преимущество перед Node.js. Оно заключается в том, что каждый пакет, после установки, кэшируется на жёстком диске. Это означает, что установка пакета производится лишь один раз. Если в некий проект нужно импортировать зависимость, которая уже была импортирована в другой проект, соответствующий код не придётся загружать повторно.

3. В Deno встроена поддержка TypeScript


Для того чтобы писать на TypeScript под Node.js, придётся выполнить достаточно длительный процесс настройки рабочей среды. Нужно установить TypeScript, обновить package.json, обеспечить поддержку типов в модулях.

В Deno, для того чтобы обеспечить работоспособность TypeScript-кода, достаточно сохранить файл с таким кодом, использовав расширение .ts вместо .js. Компилятор TypeScript встроен в Deno.

4. Поддержка await за пределами асинхронных функций


Node:

const fakeData = async () => {
    const data = await fetch("https://jsonplaceholder.typicode.com/todos/1");
    const result = await data.json();
}

Deno:

const data = await fetch("https://jsonplaceholder.typicode.com/todos/1");
const result = await data.json();

В Node.js ключевое слово await может быть использовано лишь в функциях, объявленных с использованием ключевого слова async.

В Deno можно использовать await где угодно, организуя таким образом ожидание поступления каких-нибудь результатов. Помещать await-конструкции в async-функции необязательно.

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

5. Доступ к браузерным API (Window, Fetch)


Для того чтобы выполнять HTTP-запросы средствами JavaScript, можно использовать API Fetch. В Node.js нет доступа к браузерным API. Это, в нашем примере, приводит к невозможности обращения к Fetch с использованием лишь стандартного функционала платформы. Сначала нужно установить соответствующий пакет:

npm i node-fetch

Затем его надо импортировать в свой код:

const fetch = require("node-fetch")

После этого можно выполнять соответствующие вызовы.

А у Deno есть доступ к объекту window. Это значит, что для использования того же API Fetch достаточно просто сделать так:

fetch("https://something.com")

Это относится и к использованию других браузерных API. Для работы с ними не нужно устанавливать никаких дополнительных библиотек.

Если скомбинировать это с возможностью использования await за пределами асинхронных функций, становится понятным то, как и почему Deno-код может оказаться проще, чем Node.js-код.

Node:

const fetch = require("node-fetch")

const fakeData = async () => {
    const data = await fetch("https://jsonplaceholder.typicode.com/todos/1");
    const result = await data.json();
}

Deno:

const data = await fetch("https://jsonplaceholder.typicode.com/todos/1");
const result = await data.json();

Итоги: у Deno есть и другие преимущества перед Node


У Deno есть и множество других преимуществ перед Node.js. Например, Deno, в своём стандартном виде, безопаснее. В среде Deno можно выполнять Wasm-код, тут имеется множество встроенных библиотек.

Все те сильные стороны Deno, о которых шла речь в этой статье, взаимосвязаны. Все вместе они формируют ту среду, которую можно назвать более современной, чем Node.js, средой для разработки бэкенд-проектов. Я — React-разработчик, особенности Deno тесно переплетаются с моими потребностями. Теперь, создавая серверный код, я могу пользоваться ключевым словом import, могу где угодно ставить await. Я могу писать на TypeScript, ничего специально не настраивая, могу пользоваться Fetch, не устанавливая никаких дополнительных пакетов. Моя работа становится проще.

Станет ли Deno, в итоге, заменой Node? Возможно. Вероятно, это может занять несколько лет. Экосистема Node.js огромна, Deno понадобится время на то, чтобы вырасти до таких масштабов.

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

А вы уже попробовали Deno?

RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Комментарии 143

    +29
    В среде Deno пакеты импортируются с использованием URL.

    Главная причина того, что JS-разработчики НЕ будут использовать Deno. Вот психанёт разработчик условного leftpad и удалит сайт/репозиторий — и всё, нету вашего URL.


    Ну или все будут импортировать с какого-нибудь npmjs.com или того же deno.land и в итоге по сути ничего не поменяется.

      –11

      Вот психанёт разработчик условного leftpad и удалит сайт/репозиторий, а у вас в вашей репе лежит форк этого пакета.

        +9

        Дак и npm сохраняет кэш. Но из npm теперь нельзя удалить

          +17

          Я задолбаюсь форкать все 2073 пакета, которые прописаны в зависимостях одного из моих небольших проектов.

            +2

            Не надо ничего форкать, любой прокси решает эту проблему. Такой "прокси" могут даже встроить в сам Deno, и тогда он даже не будет иметь ничего общего с перехватом сетевых вызовов.


            URL — это точно такая же виртуальная сущность, которая может указывать куда угодно. То, что пока его не отвязали — это просто свидетельство, что проблемы никакой нет. Слишком мало людей ещё пользуются Deno, есть проблемы важней.


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

              +2

              URL в качестве виртуальной сущности окончательно теряет всякий смысл

                0

                Вы б рассказали, почему, что ли

                  +1

                  Потому что в итоге получается тот же самый Node, в котором импорты тоже можно сделать с такими же виртуальными сущностями. Только будет хуже чем в Node, потому что через несколько итераций легаси придётся поддерживать совместимость с длинными неуклюжими URL из Deno v1.0

                    +3

                    Дальше строго имхо, Райану свечку не держал.


                    Весь прикол в том, что Deno хорош для быстрого прототипирования.


                    Так-то, в C# и Java инструменты пофичастее будут, чем JS. И программы быстрей, стабильней, держат большую нагрузку. Но кто захочет связываться с жирными сложными чудовищами, если есть чудесный JS, где веб-сервер пишется в одну строчку в пустом файле? Весь поинт в этой невыразимой лёгкости использования, по сравнению с монстрами из Старого Мира


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


                    У человека есть мгновенная проблема — и он её решает методом копипасты с GitHub. Есть приложения, в которых нет почти ни одной своей строчки, это целиком готовые модули (возможно, свои с других проектов), копипаста с GitHub и StackOverflow и клей.


                    Поэтому важно, чтобы основной юзкейс использования (быстро навернуть готового кода откуда-то из произвольного места в интернете) был доступен за 0 секунд без включения мозга.


                    Вот у тебя есть какой-то другой проект, вчера ты его кодил. Ты хочешь, чтобы один из модулей, которые ты там наговнокодил, перекочевал в то, что ты пишешь прямо сейчас. Что для этого нужно сделать? Запушить старый говнокод в произвольное место на гитхабе в любом виде, какой тебе больше нравится, и прописать путь до него в import, всё


                    А вот все остальные кейсы, вроде поддержки срача из модулей через пять лет разработки — это уже всё дело десятое и инструменты для этого могут использоваться куда сложнее, или даже быть непрятными и уродливыми.


                    Пример уродливого, но рабочего решения — это файл-роутер, в котором можно сказать: "пакет по этому URL отвалился, будем использовать вместо него пакет по другому URL". Всё, починиль.


                    Один фиг, в нашем мире throawayware, скорей всего никакой код пять лет не проживёт, зависимости изменятся сто пятьсот раз совершенно не по причине того, что они сломались в репозитории, и беспокойство совершенно преждевременное :)

                      +1
                      Весь прикол в том, что Deno хорош для быстрого прототипирования.

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

                      У человека есть мгновенная проблема — и он её решает методом копипасты с GitHub. Есть приложения, в которых нет почти ни одной своей строчки, это целиком готовые модули (возможно, свои с других проектов), копипаста с GitHub и StackOverflow и клей.

                      Ох уже эти времена старого php… Только код брался, если правильно всё помню, из комментариев к официальной документации.

                      Вы думаете, что в js таки решил проблему, что код не пишется дважды?

                      Если уж надо тяп ляп, то заливать на github явно сложно, долго. Проще код копипастнуть у себя же на машине.
                        0

                        Если код продолжает изменяться — нет

                    +2
                    Потому что это становится идентификатором пакета (наименованием) при этом имеет неудобный длинный формат URL.

                    Потому что это вносит зависимость исходного кода (языка фактически) от HTTP стандарта. Это просто кричит о неправильной абстракции.
                    0
                    Ой, а если при этом вспомнить ещё и xmlns… Плавали, знаем…
              +3

              Меня больше беспокоит, одна библиотека будет импортировать leftpad с npmjs.com, другая с deno.lend, третья со своего сайта, в результате в проекте будет 3 копии одной библиотеки. А писать полный адрес каждый раз при импорте — то ещё развлечение.

                0

                У меня есть большое подозрение, что механизм кэширования умеет проверять хэш.

              +25

              Выглядит как нескучные обои:


              1. ECMAScript modules are the official standard format to package JavaScript code for reuse. Modules are defined using a variety of import and export statements.
              2. Как сказал предыдущий комментатор: внешние зависимости на проде — это нескучно!
              3. ts-node
              4. Experimental top-level await
              5. Давайте вместо Node и Deno сделаем новый проект с встроенным leftpad — Endooo!
                +2
                При использовании Deno разработчик больше не привязан к NPM.

                И где же здесь удобство?! Если у пакета сотни зависимостей — все прописывать в import?!


                В Deno можно использовать await где угодно, организуя таким образом ожидание поступления каких-нибудь результатов. Помещать await-конструкции в async-функции необязательно.

                А вот это очень полезно!

                  +7
                  А вот это очень полезно!
                  Уже есть в экспериментальном режиме в node.js
                  +15
                  Все хорошо, но черно-белый логотип мне напоминает вот это:
                  image
                    +3

                    "Когда в первый раз увидел JS после своего любимого <название языка>"

                      +1
                      у меня наоборот, так было когда понадобилось по мелочи подпилить бэкенд питоновский
                    +8
                    1.
                    nodejs.org/api/esm.html
                    Может подождать полгода вместо перехода?
                    4.
                    nodejs.org/api/esm.html#esm_experimental_top_level_await
                    Думаю те же полгода
                    5.
                    А зачем на сервере window?
                    Fetch еще понятно, остальные не особо
                      +1
                      Может подождать полгода вместо перехода?

                      За эти полгода в Deno появится ещё куча фичей.


                      Кажется, сейчас суть в том, что Deno идёт по переднему краю платформы и там есть и всегда будет всё то, что в node добавлять нельзя хотя бы потому, что будут ныть любители легаси. Не в смысле легаси "ой, апи поменялось в новой ноде", а легаси фундаментальных подходов к использованию


                      А зачем на сервере window?

                      Чтобы вы могли скопипастить кусок кода, изначально написанного для работы в браузере, и использовать и там и там без изменений. Например, раньше какой-то рендеринг или вычисление делалось на клиенте, и вы решили перетащить его на сервер.

                        +4
                        А зачем на сервере window?

                        Для этого есть спецификации. И в спеках описан globalThis для написания кода как раз для разных движков. Печально, что у deno своё видение стандартов.


                        За эти полгода в Deno появится ещё куча фичей. <...> легаси фундаментальных подходов к использованию

                        Можно примеры? Я просто не очень за deno слежу. У ноды накопился свой багаж легаси за 10 лет, есть своя политика удаления старья. Через пару лет, когда у deno будет свой легаси, пыл поубавится.

                          +2
                          Через пару лет, когда у deno будет свой легаси, пыл поубавится.

                          Тогда будет самое время придумать какой-нибудь edon.

                            –1
                            И в спеках описан globalThis для написания кода как раз для разных движков.

                            в спеках-то он описан, но что делать с тонной программистов и их кода, которое ни про какие такие спеки не знает и продолжает использовать window. Если window есть, то всё это отлично работает


                            Можно примеры?

                            Легко. Приходим в Node и говорим, что JS файлы больше не обрабатываются, только TypeScript, кто не согласен — выметайтесь. Крик поднимется до небес.


                            пыл поубавится.

                            или не поубавится, потому что Deno — это площадка для экспериментов, и кто не согласен адаптироваться под новшества — идут на выход

                              +1
                              Deno — это площадка для экспериментов
                              В таком случае ни один вменяемый разработчик не будет на нём строить свой production, и удел Deno — быть песочницей.
                            +1
                            или не появится за эти пол года, пока еще не понятно
                              0
                              раньше какой-то рендеринг или вычисление делалось на клиенте

                              дернул сервис с chromeless да и все быстро отрендерилось как надо. Нафига это включать в ядро? Оно далеко не всем надо на беке. Выглядит сомнительно.
                              +3
                              мне кажется закончится тем же, чем и история с io.js
                                0

                                Ну например (если речь про fetch) вы собираете запрос на другое АПИ, а у него свои правила, и приходится и в get параметры и в multipart/form-data, а тогда наличие URLSearchParams и FormData сильно упрощают работу. Конечно, для многих глобальных методов есть npm-пакеты, но многие не реализованы полностью.

                                  0
                                  window — для ssr, наверно
                                    0
                                    для ssr нужен document, а не window :)
                                    Хотя конечно, можно возразить, что в мире js обьектов — одно часть другого
                                  +19
                                  Заголовок:
                                  5 главных причин того, что JS-разработчики будут использовать Deno вместо Node
                                  статья:
                                  Станет ли Deno, в итоге, заменой Node? Возможно.
                                  Вывод: заголовок кликбейтный.
                                    +2
                                    А механизм import загружает модули в асинхронном режиме...

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

                                      0
                                      По старому доброму принципу, название увы не знаю. Один раз вбил какое-то слово ручками — дальше подставляй сколько хочешь.
                                      +12

                                      Выглядит как какая то религия. Свидетели deno теперь каждый день будут нам доказывать, что deno удобнее nodejs? Ну сколько можно, в самом деле

                                        0
                                        Один раз в сто лет появляется статья

                                        Хабр: " теперь каждый день будут нам доказывать!!!"
                                          0

                                          Ну не надо, недавно была подобная статья.

                                          +2

                                          Скорее как пропаганда Svelte. Что в общем, недалеко от религии.

                                            +1
                                            Причём здесь Svelt и почему именно он, a не те же React/Vue/Angular, у которых пропаганда в разы мощнее?
                                              +3

                                              Не знаю, меня никто не склоняет (в виде статей) срочно переходить на React/Vue/Angular, но очень яростно это делают в статьях о Svelte без особых на то причин/киллер-фич. По крайней мере на Хабре.
                                              Да, о тройке больше статей, но не агитационных.

                                                +2

                                                Сколько статей про Svelte не читал, ни разу не видел, что "нужно срочно переходить на Svelte". И вообще я не очень понимаю, как можно склонить перейти на Svelt в статье? Рука с пистолетом из монитора вылезает что ли? =)


                                                Да, о тройке больше статей, но не агитационных.

                                                Серьёзно? Стоит написать в поисковике: "{ framework1 } vs { framework2 }" или "why { framework1 } is better than { framework2 }" (framework1 и framework2 — любой из "тройки"), так сразу море статей найдётся. А что же творилось на релизах первых версий… И ладно статьи, так ещё и куча конференций, на которых хотя бы кто-то один из "тройки", но будет обязательно.

                                            +2

                                            Надо совместить deno со svetle

                                              +1

                                              С той поделкой, которую автор пихает в любую жопу без спроса, $mol. Как раз будут два сапога пара — ненужный рантайм и никудышний фреймворк.

                                                +2
                                                Да-да! $mol и deno, лучший фронтенд стек 3030 года
                                              0
                                              Ага. Можно ещё deno и node в твоём предложении местами поменять и будет ровно так же справедливо. И продолжаться это будет минимум до тех пор, пока люди так же однобоко будут мыслить.
                                              +3

                                              Был я на докладе автора проекта. С его уст — это не замена node, пока еще все под вопросом. Он хочет решить ряд проблем которые лежат в основе node, но не стоит халиварить на тему node vs deno. Это по пока еще разные вещи.

                                                +3
                                                Да, действительно давно пора добавить все эти вещи (ну разве что кроме импорта с линка, совсем не вижу плюсов) в ноду, но только ради этих фич, я не буду переходить, с проверенной в кровавых боях технологии, на темную лошадку. И я надеюсь, что польза для меня от этого проекта будет именно в том, что эти и другие интересные фичи в ноде появятся еще при нашей жизни, потому что конкуренция это хорошо.
                                                  +1
                                                  Ts-node супер-мега-тормозной по сравнению node, натравленного на скомпилированные js-файлы. Время перезапуска даже для небольшого 100-тысячнт-строчного проекта просаживается раз этак в 3-5, что во время разработки очень актуально. А как в deno с этим?
                                                    +2

                                                    ts-node нужен для разработки, а не для реальной эксплуатации.

                                                      0

                                                      Ну так в комментарии выше как раз про разработку и говорится. Во время активного дебага, например, скорость сборки критична.

                                                      +2
                                                      Вы обратили внимание на момент, который почти все разработчики чувствуют, но мало кто рефлексирует: чем меньше по времени итерация «написал — запустил — посмотрел как работает или не работает», тем быстрее, легче и удобнее идет процесс разработки. REPL должен работать быстро. И у nodejs для этого есть сначала nodemon, а когда его начинает не хватать, есть более продвинутые механизмы (сброс кэшей модулей). И это настолько ускоряет и улучшает процесс разработки (по сравнению с многоминутными деплоями war-контейнеров, или многочасовыми компиляциями проектов на C++), что это можно сравнить только с той радостью, когда разработчики 15 лет назад начали пользоваться svn (git был написан уже после) и радовались, что «создание ветки — теперь очень дешевая и быстрая операция».
                                                        0

                                                        Никто в Java не деплоит уже многоминутные war-контейнеры. JavaEE официально сдохла, вместо неё JakartaEE, которая только набирает силу, и в Jakarta относятся к "многоминутным war" крайне отрицательно.


                                                        JVM умеет подсасывать изменения на лету, приложение не нужно перезапускать. Если писать в определённом стиле и с использованием Spring, процесс ещё более приятный, чем на Ноде, потому что после подгрузки нового кода у тебя не теряется shared mutable global state.


                                                        В смысле, я не спорю с идеей fast loop, а исключительно с тем, что вы тут обосрали Java и C++. Или мне только показалось, что это был наезд? Если так, сорри. (Хотя у C++ всё ещё плохо, но начиная со стандарта 2020 года там появились модули, и всё стало сильно лучше)

                                                          0
                                                          Извините, пожалуйста, если это выглядит как «обосрал». Я ничего такого не имел в виду, и пытался быть максимально корректным.

                                                          Если же по существу, то я в курсе, что в Java есть механизм hot swap (тот, который в Идее навешен на Ctrl-F10), и очень рад этому факту. А особенно круто, что можно в отладчике дропнуть фрейм, и придти уже в обновленный код. И таким образом значительной части «многоминутных деплоев» можно избежать. Но, насколько я понимаю, существуют ограничения JVM для этого подхода: нельзя менять сигнатуру методов или удалять их. Если вы, как эксперт по Java, подсветите этот момент (или, может быть, даже подскажете, как их можно обойти), буду признателен.
                                                            +1

                                                            Абстрактно говоря, в API JVM есть интерфейсы и для изменения сигнатур методов.
                                                            Просто в самой распространённой JVM (HotSpot) по этим интерфейсам находится
                                                            throw new UnsupportedOperationException();


                                                            Есть другие реализации JVM (как правило, платные), где есть полноценная поддержка смены сигнатур методов (так как метод полностью определяется через сигнатуру, поддержка смены сигнатур это синоним поддержки добавления/удаления). Потому для ускорения цикла ставят на машины разработчиков эти альтернативные JVM, а в бой всё идёт на HotSpot.

                                                              0
                                                              Спасибо! Уже после того, как ответил на коммент, я нагуглил dcevm.github.io — как раз одна из таких JVM, которая умеет добавление / удаление методов. ИМХО это просто очень сильно упрощает разработку (хотя некоторые разработчики говорят, что им и дефолтного hot swap хватает). Последний релиз там под Java 11, и как-будто бы совсем свежий (май этого года), что радует, потому что проект не заброшен.
                                                                0

                                                                Ну вот я из таких, которым вполне хватает обычного hotswap. Приблизительно 95% моих потребностей закрываются именно им.
                                                                А вот поддержка только Java 11 у dcevm это непросто. Дело в том, что Java 11 — это сентябрь 2018-го, а актуальная версия нынче 14.

                                                      +4

                                                      package-lock.json и прокси npm c кэшированием и проверками — это залог успешных билдов и ребилдов в ci/cd у ноды, а в дено это червь подсунутый в очередной зависимости только для продакшенфлоу билдера или рандомные ошибки сборки, потому что часть интернета опять полегла?
                                                      Спасибо, дайте два :)

                                                        +1
                                                        кликбейт, спам и обман
                                                          +3
                                                          import { moment } from "https://deno.land/x/moment/moment.ts"
                                                          

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

                                                          А хардкодить все версии зависимостей во всех файлах проекта, ну такое. Если у меня этот moment используется в 10 файлах в большом проекте, то в какой-то момент у меня неминуемо будет 10 разных версий moment.

                                                          У npm есть недостатки, конечно, но это знакомые, понятные недостатки.
                                                            +1

                                                            Синтаксис URL:


                                                            https://deno.land/x/MODULE_NAME@BRANCH/SCRIPT.ts


                                                            Можно сделать бранчи по версиям, можно сделать бранч "stable", всё что угодно.
                                                            Строка импорта — это обычная строка, можно подсунуть туда имя нужного бранча интерполяцией, а само название бранча вписать в сеттинги.


                                                            И конечно, можно импортировать не с deno.land, а со своего собственного GitHub или CDN, на котором лежит истинно верный форк библиотеки. Возможно с вашими истинно верными патчами:


                                                            import { helloDeno } from "https://raw.githubusercontent.com/AbmSourav/deno-std/master/index.ts";
                                                            helloDeno()
                                                              +4

                                                              А как потом во всем проекте обновить версию зависимости?

                                                                0

                                                                Как-нибудь так?


                                                                const moment = await import(`https://deno.land/x/moment@${Settings.Depenencies.MOMENT_VERSION}/moment.ts`)

                                                                Или например, можно сделать свою репу на гитхабе, запушить туда Moment и ссылаться на этут репу. При необходимости изменить версию во всём проекте — идёшь на Гитхаб и заливаешь по этому адресу другую версию. Всё.


                                                                Вообще, Deno же развивается полным ходом. Туда можно припилить всё, что угодно.

                                                                  +3
                                                                  вы вот это все серьезно сейчас? Знаете какой следующий вопрос будет?
                                                                    0

                                                                    нет, не знаю, расскажите

                                                                      +1
                                                                      ну например как теперь сделать `list outdated`
                                                                        0

                                                                        Ну, по моему это легко решится. Как только придёт необходимость появятся утилиты аля "deno-outdated" которые будут смотреть по всем файлам и выдадут список устаревших зависимостей для каждого модуля.

                                                                          +1
                                                                          Как говорится, «флаг вам в руки и барабан на шею» )
                                                                    +2

                                                                    Скорее будет использоваться файл deps.ts с реэкспортом:


                                                                    export { moment } from `<URL>`;

                                                                    И тут мы возвращаемся к файлам, где объявлены все зависимости.


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

                                                                      +3

                                                                      А ничего, что вот этим Settings.Depenencies.MOMENT_VERSION вы фактически заново переизобрели package.json?

                                                                      0

                                                                      В принципе, можно создать файл dependency.ts и писать в нём:


                                                                      export * as http from "https://deno.land/std@0.54.0/http/mod.ts";

                                                                      В таком случае версию пакета придётся писать только в одном файле и обновить можно будет в нём же

                                                                        +8

                                                                        Можно еще сделать статический файл, в котором указать эти версии, а загрузчик с учетом версионирования встроить в рантайм. Назвать это как-то типа dependency.json, или я не знаю, package.json.

                                                                          +1
                                                                          Не мешайте пионерам изобретать велосипед ))
                                                                            –1

                                                                            Напомнило фэнтези "Идущие в Ночь". Там у главной героини был боевой костюм типа скафандра, который расстегивался только у плечей, и снимать его было очень неудобно. Когда этот костюм выдавали, она поинтересовалась: "как же в нём срать" и получила ответ: "всё зависит от того, что ты чаще делаешь — дерешься или срёшь".


                                                                            Вот и тут так. Всё зависит от того, что ты чаще делаешь — копипастишь какие-то URL с гитхаба на самую свежую версию либы, или с умом выбираешь стабильные версии.

                                                                              +1

                                                                              С умом выбираешь стабильные версии раз и навсегда, и дублируешь их 100500 раз в каждом файлике?


                                                                              DRY это не про deno?


                                                                              Развитие продукта это не про deno?


                                                                              Детерминированные билды это не про deno?

                                                                                –3

                                                                                Я-то откуда знаю, что там про Deno, у меня имя не Райан Дал ;)


                                                                                Выше есть сниппет кода — складываете истинно правильные версии в какой-то глобальный стор, потом используете плейсхолдеры с версиями при каждом импорте. Кстати, этот метод используется в Maven в Java — это такая платформа, где люди десятилетиями могут поддерживать совместимость кода, и за детерминированные сборки собачку родную убьют. Плейсхолдеры эти юзаются и в декларативных конфигах типа package.json (даже так — в основном в них и юзаются). Поэтому это было то, что первое пришло в голову — такое знакомое старое решение.


                                                                                Я раньше программировал на Java и наелся всего этого дрожания над легаси, которое 20 лет работает без единого изменения. Лично мне гораздо удобней, чтобы у мнея было средство быстрого прототипирования, в котором о проблемах долгосрочной поддержки кода задумываться просто не нужно. Развалится — починим. Таков Путь.


                                                                                То что я заметил в мире JS — разваливается обычно совершенно не от мифических ужасов с летфпадом, от которых тут все в шоке. А от того, что ты обновился на свежую не-LTS версию Ноды, которая вышла на прошлой неделе, а твои библиотеки ещё не обновились. Вот тут да, проблема.

                                                                              –1

                                                                              Именно так) однако у вас всё ещё остаётся возможность использовать разные источники для пакетов ибо "децентрализованное хранилище пакетов". Конечно же в придачу и все вытекающие проблемы, вроде одного и того же пакета, что тянется разными зависимостями с разных урлов и т.д.

                                                                                +1

                                                                                Вы правда считаете, что npm может ставить пакеты только из какого-то одного места, а не откуда угодно, включая кастомные npm-репозитории, git, локальную файловую систему, ssh, локальные tar.gz-архивы и удаленные tar.gz-архивы + бесконечное количество мест, добавляемых плагинами? Для многих путей, откуда npm может пакет поставить, даже URL нет, только URI от силы.


                                                                                О какой централизации npm идет речь?

                                                                            +1
                                                                            Думаю это нежизнеспособно по практическим причинам управления зависимостями. Не зря придумали менеджеры пакетов и package_lock.json
                                                                              +1
                                                                              Можно сделать бранчи по версиям, можно сделать бранч «stable», всё что угодно. Строка импорта — это обычная строка, можно подсунуть туда имя нужного бранча интерполяцией, а само название бранча вписать в сеттинги.

                                                                              Принципиально ли это отличается от Git URLs as Dependencies в npm?
                                                                              +1

                                                                              Вы, конечно правы. Но как мне видится идея в том, что у вас не весь ваш проект зависит от moment, а каждый отдельный модуль/файл зависит от moment конкретной версии. Я вижу в этом возможность очень легко переводить обновление зависимостей в проекте по частям.

                                                                                0

                                                                                И еще легче ловить крайне стремные баги, вызванные несовместимостью внутренних структур того же moment, которые не являются частью публичного API surface, при передаче их между разными файлами проекта. Ведь это так забавно — иметь в половине проекта объекты одной версии, а в другой половине объекты другой версии, с неопределенным поведением при их взаимодействии.


                                                                                Или ограничим API каждого модуля строго JSONами?

                                                                                  0

                                                                                  Сильно типизированными DTO. Не уверен, что это шутка.

                                                                                    +1

                                                                                    "ну да, ну да, пошел я нахер".

                                                                                    +1

                                                                                    Как мне кажется, это уже вопрос архитектуры. Если есть два независимых модуля, то один не должен ломаться при изменении реализации второго. Главное чтобы возвращаемые структуры были идентичными. А если два "модуля" сильно связаны между собой, тогда здравый смысл подсказывает, что они должны использовать общую версию зависимостей.

                                                                                      0
                                                                                      Главное чтобы возвращаемые структуры были идентичными.

                                                                                      Вот это как раз никто и никому не обязан. В версии 1 будут одни приватные поля, в версии 2 другие. Так как приватные поля не являются частью публичного АПИ, авторы их могут менять даже в минорных версиях по своему усмотрению. Будет ли работать новый код со старыми полями? Будет ли работать старый код с новыми полями? Ответ очевиден всем, кроме апологетов deno.

                                                                                        0
                                                                                        С es-приватными полями будет работать, тк нельзя через один инстанс читать приватные поля другого инстанса того же класса.
                                                                                +3
                                                                                «В Deno можно использовать await где угодно, организуя таким образом ожидание поступления каких-нибудь результатов» – top level await это немного не это. Вы совсем не разобрались что это за функция, и пользы от не много, просто маленький сахар в новом ES.
                                                                                  –2

                                                                                  Ничего себе маленький сахарок.


                                                                                  Сейчас вот такое невозможно:


                                                                                  await Promise.resolve(console.log(''));
                                                                                  // → SyntaxError: await is only valid in async function

                                                                                  И приходится писать так:


                                                                                  (async function() {
                                                                                    await Promise.resolve(console.log(''));
                                                                                    // → 
                                                                                  }());

                                                                                  При этом, например, если ты пишешь какой-то скрипт для командной строки на JS, то у тебя половина кода состоит из async-await-ов, потому что весь код скрипта исключительно синхронный, выполняется в один поток, и с таким подходом 30% кода — это слова "async" и "await".

                                                                                    +1
                                                                                    так top-level-await – позволяет не оборачивать await только в корне модуля (вне каких либо функций), в любой функции это уже не прокатит, ни о каких 30% кода даже близко речи нет. Ознакомьтесь пожалуйста внимательнее v8.dev/features/top-level-await
                                                                                      0
                                                                                      прям киллер фича, без iife- как без такой жить :) Сейчас как бы все логично, await вне асинхронной функции не имеет смысла.
                                                                                        0

                                                                                        Ещё как имеет, потому что все библиотеки имеют эвэйтовое API. Они не знают, что ты собираешься их использовать в одном треде.

                                                                                          0
                                                                                          Ну они имеют промисифицированное апи. И с ним await в синхронной функции работать в принципе никак не может, тогда ее нужно будет подменить неявно на асинхронную и эта неявность может поломать код, который писался как синхронный, но вдруг при дописывании await его куски внезапно стали работать в разных итерациях цикла событий, поломав логику с process.nextTick и т.д. Еще и потенциальные потери в производительности на анализе кода и модификации внутренних структур. И все ради того чтобы не явно не обернуть асинхронный участок кода в iife. Какое то хипстерское решение, в надежде перетянуть одеяло, не более.
                                                                                          Они не знают, что ты собираешься их использовать в одном треде.

                                                                                          Не знаю при чем тут треды… там тред один, не считая внутренних.

                                                                                            0
                                                                                            , тогда ее нужно будет подменить неявно на асинхронную

                                                                                            под "скриптом" я имею в виду то, для чего раньше использовали bash — всякая работа с файлами и запуском программ из командной строки. Или например, какие-то роботы, которые скрейпят чужие сайты в headless браузере. Или анализ данных и построение графиков в экселевском файле.


                                                                                            там у тебя нет асинхронности вообще. Каждую следующую строчку можно делать только если все предыдущие уже завершились. Как в баше и питоне, которые всё это и призвано заменить


                                                                                            ну и сейчас ты просто руками делаешь (async function() { }()), и дальше там скобочках происходит вообще весь текст скрипта. Туда же можно впилить верхнеуровневый try-catch. Получается прям аналог функции main из C++.


                                                                                            и дальше у тебя примерно каждая строчка в твоей программе начинается с await. Каждая. Ибо "промисифицированное апи" имеет каждая собака. Даже твой собственный код имеет такое апи, потому что ты писал его в предыдущем проекте для сервера, и там всё насквозь асинхронное.

                                                                                              0

                                                                                              Одно не понимаю. И что мешает сделать одну большую async функцию и вызывать её в таком скрипте? Зачем top level-то?

                                                                                                +1

                                                                                                Очень утомляет каждый раз писать


                                                                                                (async () => {
                                                                                                  await fs.readFile();
                                                                                                })().catch(error => {
                                                                                                  console.error(error);
                                                                                                  process.exit(1);
                                                                                                });

                                                                                                В этой ситуации очень часто забывают про catch, а это важно.


                                                                                                С top-level await эти обертки становятся не нужны и работать намного проще.

                                                                                                  0

                                                                                                  Ну так это только если это ваш полный скрипт. Обычно он несколько больше, и ты один раз сделал верхнюю асинк функцию, а дальше спокойно внутри эвейтами обмазываешься.

                                                                                                    +1

                                                                                                    В том и загвоздка, что это придется делать в каждом файле.


                                                                                                    В случае приложения, сделать это в одном app.js не проблема, а вот делать это в каждом build-скрипте утомляет и легко ошибиться.

                                                                                                      0

                                                                                                      Поэтому и нужен не только top-level async, а everyting async. Это можно навертеть самостоятельно, конечно, есть же бабель и другие JS трансформаторы. Но это уже некий недостижимый уровнь для ситуации, когда тебе нужно наебашить тридцать скриптов за вечер — нет времени думать, делать надо.

                                                                                      +1
                                                                                      2. Если в NodeJS уверен, что все лежит в node_modules и оно будет работать, то как тут?) (к тому же в NodeJS установить пакет можно так же по URL)

                                                                                      Все остальное в статье для меня вообще не актуально)

                                                                                      Единственное, в чем есть какой-то плюс в Deno (и о чем не написано в статье), так это явное указание, куда у него есть доступ в файловой системе.
                                                                                        +2
                                                                                        deno собирает весь проект в один большой бинарник, упаковывая все зависимости, поэтому если у вас есть бинарник — все будет работать. Это кмк главный его плюс а автор упустил этот момент.
                                                                                        +1
                                                                                        Если deno будет на 20-30% быстрее то еще можно подумать о переходе, а так он ненужен и его место на свалке.
                                                                                          +1
                                                                                          Придумали бы ECMAPromisesScript уже́, все эти асинки и авайты только глаза режут.
                                                                                          Чё бы не писáть
                                                                                          const {users} = fetch(URL).json();

                                                                                            0

                                                                                            Потому, что иногда имеет смысл ожидать результат позже


                                                                                            // Start downloading data in advance
                                                                                            const promise = fetch('/user')
                                                                                            
                                                                                            // Do something very difficult and time consuming
                                                                                            heavy()
                                                                                            
                                                                                            // Waiting for the data download to finish
                                                                                            const {user} = await promise

                                                                                            Или не ожидать результат вовсе


                                                                                            fetch('/signal') // No await
                                                                                            heavy()
                                                                                              –1
                                                                                              Ну и зачем здесь await? И зачем вообще вводить переменную под fetch()? Я указываю, что хочу users, после heavy() здесь или в другом месте через глобальную переменную (прости господи).

                                                                                              Дальше холиварненько по теме промисов, но всё же.

                                                                                              Вызов функции fetch интерпретатор расценивает как явное применение асинхронности. А последующее await для передачи значения в переменную выглядит подобно разыменованию указателя.
                                                                                              В случаях, когда важен именно статус исполнения, пусть будет стоять promise.
                                                                                              const {users} = fetch('/users');
                                                                                              
                                                                                              // просто некая конструкция для получения именно промиса по какой-то переменной
                                                                                              let {status} = promise users;
                                                                                              //или то же самое но в форме привычной объективации переменной в конкретный тип
                                                                                              let {status} = Promise(users);
                                                                                              
                                                                                            0

                                                                                            Какая глупость написана.


                                                                                            Современные возможности JavaScript: ES-модули

                                                                                            используются дольше, чем существует deno.


                                                                                            Децентрализованное хранилище пакетов

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


                                                                                            наверное, скачивание пакета и запись его в кэш у deno как-то особенно быстрее, чем скачивание пакета и запись его в кэш у npm.


                                                                                            В Deno встроена поддержка TypeScript

                                                                                            в Node встроена поддержка любой версии Typescript, Flow, Hegel или еще неизобретенного тайпчекера с произвольными настройками.


                                                                                            Поддержка await за пределами асинхронных функций

                                                                                            Welcome to Node.js v12.16.2.
                                                                                            Type ".help" for more information.
                                                                                            > async function foo() { return "hello" }
                                                                                            undefined
                                                                                            > await foo()
                                                                                            'hello'
                                                                                            > 

                                                                                            Не говоря уже о том, что этой фиче сто лет в обед.


                                                                                            Доступ к браузерным API (Window, Fetch)

                                                                                            Ну конечно, ведь в ноде совершенно нет fetch, и никак не решен этот чудовищный недостаток. А вот зачем в ноде был бы нужен целиком DOM? Подозреваю, что авторы deno не осилили убрать из хромиума всю DOM-обвязку, поэтому сделали вид, что это фича.


                                                                                            Например, Deno, в своём стандартном виде, безопаснее.

                                                                                            Нет, конечно же.


                                                                                            В среде Deno можно выполнять Wasm-код,

                                                                                            Правда? https://nodejs.org/api/wasi.html


                                                                                            тут имеется множество встроенных библиотек.

                                                                                            Ну а у ноды стандартная библиотека пустая совершенно.




                                                                                            Пять с плюсом отличных причин не использовать deno. Очередная поделка, призванная собрать все костыли и грабли заново. Надеюсь на скорое удаление репозитория deno как очевидно неудачного эксперимента.

                                                                                              0

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

                                                                                                0

                                                                                                Ах да, интереса ради проверил. В node 10.0.0, выпущенной 2 года назад, 1 мая 2018, поддержка top level await уже есть. Deno появился 13 мая 2018, и так за два года и не стал нужен хоть кому-то.

                                                                                                  –1

                                                                                                  Судя по тексту, вы похоже не в курсе, что автор у node и deno один и тот же.

                                                                                                    +1

                                                                                                    А каким образом это влияет на написанное? Глупость написал не автор deno, а автор этого поста. И то, что у автора ноды получилось в первый раз сделать что-то хорошее, не дает гарантий того, что у него это получится во второй раз. Вот, deno тому ярким примером — хуже только php.

                                                                                                      +1
                                                                                                      Я сделал комментарий исходя из вот этого:
                                                                                                      Подозреваю, что авторы deno не осилили убрать из хромиума всю DOM-обвязку, поэтому сделали вид, что это фича.
                                                                                                      (кстати, при чем тут хромиум вообще?)

                                                                                                      Заголовок у статьи конечно кликбейтный, но все-равно ваш комментарий звучит так, будто deno сейчас кто-то сильно пиарит как «убийцу» nodе.
                                                                                                      По сути это эксперимент, посмотреть на реакцию js сообщества.
                                                                                                      К ноде многие уже просто сильно привыкли, на начальных этапах тоже очень много вопросов возникало.
                                                                                                  +1
                                                                                                  к примеру мне необходимо перенести проект (локальный сервис) на сервер без интернета. как он будет подтягивать библиотеки из репозитория?
                                                                                                    0

                                                                                                    Точно так же как и в случае с node: скачать все зависимости локально и закинуть на сервер папку с кэшем.

                                                                                                      0

                                                                                                      Только вот явно это не сделать, не так ли? Потому что импорт может произойти где угодно, включая вызов await import(generateSomeUrl()). А это значит, что нужно запустить где-то deno-поделку, дать поработать, собрать кэш, перебросить на сервер без интернета. Что исключает сборку артефактов на том же CI.


                                                                                                      Мой нынешний проект работает как раз на airgapped серверах, где деплой выглядит следующим образом — специальный человек с флешкой проходит через сканирование сетчатки, после чего в пустой комнате с ноутбуком, подключенным к внутренней сети, сливает rpm-пакет на нужный сервер, забирает логи и уходит. Как собирать этот rpm, если "дать поделке поработать локально" не выйдет из-за того, что часть систем, к которым нужно подключаться, доступны только изнутри банка?


                                                                                                      Правильно, никак.

                                                                                                        –1
                                                                                                        Отдельная утилита, которая будет собирать запросы импорта от Дено-поделки и складывать в журнал для флешки. Затем человек-сетчатка сходит во внешнюю сеть, где другая утилита исполнит запросы импорта и сформирует кеш, для флешки. Повторять до полного удовлетворения Дено-поделки.
                                                                                                          0

                                                                                                          Так, как бы, и встроенными инструкциями такое возможно
                                                                                                          https://deno.land/manual/linking_to_external_code/integrity_checking


                                                                                                          Создаст список всех зависимостей:


                                                                                                          deno cache --lock=lock.json --lock-write src/entry.ts

                                                                                                          Скачает все зависимости и проверит каждую по хэшу


                                                                                                          deno cache -r --lock=lock.json src/entry.ts

                                                                                                          Но проблема с динамическими импортами действительно есть.

                                                                                                    0

                                                                                                    Поправьте если я заблуждаюсь, но в 14 версии ноды есть поддержка es модулей (без загрузки по url)

                                                                                                      +1
                                                                                                      1. Современные возможности JavaScript: ES-модули

                                                                                                      Указываем в package.json
                                                                                                      {
                                                                                                        "type": "module"
                                                                                                      }


                                                                                                      И спокойно пишем
                                                                                                      import fs from 'fs'
                                                                                                      import myModule from './myModule.js'


                                                                                                        0
                                                                                                        В среде Deno пакеты импортируются с использованием URL.

                                                                                                        Это что получается, надо во всех модулчх проекта импортировать на URL, а при переходе на новую версию искать все включения и каждый раз в куче файлов обновлять URL зависимости? А что делать, если у проекта несколько зависимостей, которые зависят от разных версий одной и той же библиотеке?

                                                                                                          0

                                                                                                          Мне видится в этом больше преимущество. Как я понимаю в этом и весь прикол, что у вас нет списка зависимостей на весь проект. А каждый ваш модуль/файл имеет собственный набор зависимостей. И вы можете спокойно изменять зависимости в одном модуле не боясь сломать все остальные.


                                                                                                          Вот представьте ситуацию:
                                                                                                          Вам пришла задача, сделать какую-то фичу. Для вас это не проблема, вы нашли библиотеку "А" и хотите её использовать. Но вот проблема — в проекте уже применяется библиотека "А" причем версии "0.0.1" в старом многолетнем legacy. Имея такую систему как у Deno, вы об этом вообще можете не думать. Старый модуль будет использовать свою версию, а вы можете использовать свою.

                                                                                                            0
                                                                                                            Решения для монореп есть и еще одно встроят в нпм в новых мажорных версиях
                                                                                                              0

                                                                                                              Разве они позволяют разным модулям (не разным приложениям/пакетам) иметь разные версии одной зависимости? Только если выносить модули в пакеты отдельные. А в JS/TS сейчас модулем является практически любой файл с кодом.

                                                                                                                0
                                                                                                                >Разве они позволяют разным модулям (не разным приложениям/пакетам) иметь разные версии одной зависимости
                                                                                                                нет, а зачем оно надо? на уровне пакетов должно быть достаточно
                                                                                                                  –1

                                                                                                                  Ну вот надо мне создать новый модуль для системы, вижу что есть в мире библиотека, которая мне поможет, причём особенно помогут новые фичи последней стабмльной версии. В идеальном мире я просто беру её для своего модуля и не парюсь. В реальном она уже может использоваться в проекте и версия будет, скорее всего, не последняя. У меня дилемма — использовать имеющуюся версию, дублируя в своём модуле код, который есть в последней (копипаст или велосипед — не суть), или обновить зависимость во всём проекте с большим риском вызвать кучу ошибок. Ну ещё вариант — оформить мой модуль как пакет, получив все "прелести" разработки в нескольких местах. Все варианты приводят к дополнительной работе и в фазах разработки и тестирования, и, главное в фазе поддержки и, даже, вывода из эксплуатации.

                                                                                                                    +1
                                                                                                                    Принимать решение, потому что его быстрее делать как-то неправильно, это же не хотфикс в проде. Ну, мб мне конечно везет с работой, так как обычно такое не требовали.
                                                                                                          +1
                                                                                                          Импорт модулей по ссылке — прямая дорога в ад, такое в продакш пускать нельзя
                                                                                                            –1
                                                                                                            Deno: import { moment } from «deno.land/x/moment/moment.ts»
                                                                                                            Проекты работающие на js без интернета: УУУУУуууу кайф, спасибо Node что живой!
                                                                                                              0

                                                                                                              А как бы вы поступилии в случае с Node?

                                                                                                                –1

                                                                                                                Обычно заранее колеса выкачивают, но не в момент исполнения

                                                                                                              0
                                                                                                              Какая то фигня, не увидел сколько то значимых причин переходить на это…
                                                                                                              но куча потенциальных проблем на лицо!
                                                                                                                0

                                                                                                                Для нативных аддонов Deno ещё хуже чем NodeJS. В ноде можно обращения от нативного модуля к обёртке над v8 сократить, а в Deno все данные через обёртку обязаны проходить.
                                                                                                                Для серверных задач из-за этого минуса просто бесполезен за пределами тестовых поделок. Не думаю что этот пункт "ради безопасности" изменится в Deno.


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


                                                                                                                Синтаксический сахар меня мало интересует. Может быть кому-то он и нужен.

                                                                                                                  +1
                                                                                                                  Deno это попытка автора node перепрыгнуть самого себя. У него талант выбирать и совмещать казалось бы несовместимые между собой технологии для получения бомбического результата. Во всяком случае, один раз это ему сделать удалось.

                                                                                                                  Deno не является решением для продакшена и в этом смысле он не конкурент для node. Это proof of concept. По сути, маркетинг проекта больше направлен на то, чтобы найти энтузиастов и единомышленников для исследования возможностей предложенной архитектуры.
                                                                                                                    0
                                                                                                                    Очевидно, что автору просто TS нравится больше, чем js. Он написал себе «node.js с ts» и пытается придумать какие-нибудь ещё отличительные черты, которые кто-нибудь может посчитать преимуществом.
                                                                                                                    Слишком много внимания и громких заявлений ни о чём
                                                                                                                      +1

                                                                                                                      Он сначала написал себе node.js, а потом уже node.js с ts

                                                                                                                        0
                                                                                                                        Потом напишет node.js с 1С. И вроде понятно, что это — история на любителя, но «5 причин того, что JS-разработчики будут использовать node1C вместо node» будут появляться и вызывать такие же бурные обсуждения :)
                                                                                                                          +1

                                                                                                                          Так и сама node.js — история на любителя. "5 причин того, что бєкенд-разработчики будут использовать node,js вместо их любимых PHP/Python/Ruby/Java/C#/C++/..." куда более бурные обсуждения вызывали :)


                                                                                                                          А автор уже показал свою способность делать то, что востребовано очень многими. Вот недавно при смене проекта, узнал, что большинство вакансий "Фуллстэк разработчик" (без указания чегото-то типа PHP или Java) теперь подразумевают JS/TS на фронте и бэке — это буквально за год картина на рынке изменилась.

                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        0
                                                                                                                        Сильно зависит от кода. Deno это отдельный рантайм со специфичным API. Разница того же порядка как между node и браузером. Народ пытается запилить адаптеры для совместимости с разными частями инфраструктуры node, но это все пока на очень ранней стадии.
                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        0
                                                                                                                        Когда вижу статью про какую-то новую технологию, первым делом захожу в коменты посмотреть мнение экспертов, а потом уже читаю статью
                                                                                                                          –1
                                                                                                                          И для этого великолепия пришлось делать новую платформу…

                                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                          Самое читаемое