Deno ry jsconf

Deno

https://tinyclouds.org/jsconf2018.pdf

Критическая работа поддерживала Node с тех пор.
● npm (AKA «Исаак») отделил основную библиотеку Node и позволил распределить экосистему.
● N-API - это красиво оформленный API связывания
● Бен Нордхёйс и Берт Белдер построили библиотеку.
● Микал Роджерс организовал управление и сообщество.
● Fedor Indutny оказал огромное влияние на всю базу кода, особенно в крипто.


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

Ошибки никогда не бывают такими очевидными, как когда ты один
ответственность за них.

Возможно унифицированное использование обещаний в Node ускорило бы доставку
возможной стандартизации и асинхронности / ожидания.

Сожаление: безопасность
● V8 сам по себе является очень хорошей песочницей безопасности.
● Если бы я больше думал о том, как это можно поддерживать наверняка
приложения, Node мог бы иметь некоторые хорошие гарантии безопасности не
доступно на любом другом языке.
● Пример. Ваш линтер не должен получить полный доступ к вашему компьютеру и
сеть.

Сожаление: система сборки (GYP)
● Системы сборки очень сложны и очень важны.
● V8 (через Chrome) начал использовать GYP, и я переключил Node на буксире.
● Позже Chrome сбросил GYP для GN. Оставив Node единственным пользователем GYP.
● GYP не является уродливым внутренним интерфейсом - он открыт для всех, кто
пытаясь привязать к V8.
● Это ужасный опыт для пользователей. Это не JSON, Python адаптация JSON.
Продолжение использования GYP, вероятно, является крупнейшим отказом ядра Node.
● Вместо того, чтобы направлять пользователей для написания привязок C ++ к V8,
Я должен был предоставить основной интерфейс внешней функции (FFI).
● Многие люди вначале предлагали перейти на FFI (а именно, Cantrill)
и, к сожалению, я их проигнорировал.
● (И я крайне недоволен, что libuv принял автоинструменты.)

Сожаление: package.json
● Исаак из NPM изобрел package.json (по большей части).
● Но я санкционировал это, позволив Node's require () проверять файлы package.json
для "основного"
● В конечном итоге я включил NPM в дистрибутив Node, что сделало его
стандарт де-факто.
● К сожалению, существует централизованное (даже частное управление) хранилище
для модулей.
Разрешение package.json породило концепцию «модуля» как каталога
файлы.
Это не строго необходимая абстракция - и она не существует в сети.
В package.json добавлена всякая ненужная информация.
Лицензия? Repository? Описание?
Это стандартный шум.
Если при импорте использовались только относительные файлы и URL-адреса, путь определяет
версия. Нет необходимости перечислять зависимости.

Это значительно усложняет алгоритм разрешения модуля.
у продавца по умолчанию хорошие намерения, но на практике просто
$ NODE_PATH не исключил бы это.
Значительно отклоняется от семантики браузера.
Это моя вина, и мне очень жаль.
К сожалению, сейчас невозможно отменить

Сожаление: require("module") без расширения ".js"
* Излишне менее явный.
* Не так, как работает браузер JavaScript. Вы не можете опустить ".js" в теге скрипта src
приписывать.
* Загрузчик модулей должен запрашивать файловую систему в нескольких местах, пытаясь
угадайте, что задумал пользователь.

Regret: index.js

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


550/5000
Deno Goals: безопасность
● Используйте тот факт, что JavaScript является безопасной песочницей.
○ По умолчанию сценарий должен выполняться без каких-либо прав доступа для записи в сети или файловой системе.
○ Пользователи могут выбрать доступ с помощью флагов: --allow-net --allow-write
○ Это позволяет пользователям запускать ненадежные утилиты (например, линтер)
● Не допускайте привязки произвольных собственных функций к V8
○ Все системные вызовы выполняются путем передачи сообщений (сериализация protobuf).
○ Есть ровно две нативные функции: отправить и recv.
○ Это упрощает дизайн и упрощает аудит системы.

Нет попыток совместимости с существующими модулями Node.
● Импортирует только относительные или абсолютные URL. (См. Семантическое управление версиями)

Импорт должен обеспечить расширение.
● Удаленные URL-адреса извлекаются и кэшируются неограниченно при первой загрузке.
Только если указан флаг --reload, ресурс будет извлечен снова.
● Vendoring можно сделать, указав директорию кэша не по умолчанию

Цель: компилятор TypeScript, встроенный в исполняемый файл.
● TS абсолютно красивая.
○ Наконец-то появился практический опционально типизированный язык.
○ Позволяет коду беспрепятственно развиваться от быстрых взломов до больших, хорошо структурированных машин.
● Deno подключается к компилятору TS, чтобы выполнить разрешение модуля и увеличить его
кэширование сборочных артефактов.
● Не модифицированные файлы TS не должны перекомпилироваться.
● Обычный JS тоже должен работать (но это тривиально, так как TS - это расширенный набор JS)
● Следует использовать снимки V8 для быстрого запуска (еще не в прототипе)

deno.gitbook.md

https://denolib.gitbook.io/guide/codebase-basics/infrastructure

1. Внешний интерфейс TypeScript Здесь реализованы общедоступные интерфейсы, API и большинство важных функциональных возможностей, которые напрямую не требуют системных вызовов. Сгенерированный автоматически документ API TypeScript доступен в данный момент по адресу https://deno.land/typedoc (который может быть изменен в будущем). TypeScript / JavaScript рассматривается как «непривилегированная сторона», которая по умолчанию не имеет доступа к файловой системе или сети (поскольку они работают в V8, которая является средой «песочницы»). Это возможно только благодаря передаче сообщений в бэкэнд Rust, который является «привилегированным». Поэтому многие API-интерфейсы Deno (особенно вызовы файловой системы) реализованы на стороне TypeScript как чисто создающие буферы для данных, отправляющие их в бэкэнд Rust через средние привязки libdeno и ожидающие (синхронно или асинхронно) отправки результата назад.

2. C ++ libdeno Middle-end libdeno - это тонкий слой между интерфейсом TypeScript и бэкэндом Rust, служащий для взаимодействия с V8 и предоставления только необходимых привязок. Это реализовано с C / C ++. libdeno предоставляет API-интерфейсы передачи сообщений Send и Receive сторонам TypeScript и Rust. Он также используется для запуска платформ / изоляторов V8 и создания / загрузки снимка V8 (большой двоичный объект данных, который представляет информацию о сериализированной куче. Подробности см. В https://v8.dev/blog/custom-startup-snapshots). Стоит отметить, что снимок для Deno также содержит полный компилятор TypeScript. Это позволяет значительно сократить время запуска компилятора.

3. Rust Backend В настоящее время серверная часть, или «привилегированная сторона», которая имеет доступ к файловой системе, сети и среде, реализована в Rust. Для тех, кто не знаком с этим языком, Rust - это язык системного программирования, разработанный Mozilla, с акцентом на безопасность памяти и параллелизма. Он также используется в таких проектах, как Servo. Бэкэнд Rust перенесен из Go, который послужил для создания оригинального прототипа Deno, представленного в июне 2018 года. Причины перехода связаны с опасениями по поводу двойного GC. Подробнее читайте в этой теме.

V8 V8 - это движок JavaScript / WebAssembly от Google. Написанный на C ++, он также используется в частности в Google Chrome и Node.js. V8 не поддерживает TypeScript. Вместо этого весь код TypeScript, который вы запускаете в Deno, компилируется в JavaScript с помощью компилятора снимков TS, а сгенерированные файлы хранятся в папке .deno. Если пользователь не обновит код, после начальной компиляции будут запускаться только кэшированные файлы JS.

FlatBuffers Flatbuffers - это эффективная кроссплатформенная библиотека сериализации, разработанная Google. Flatbuffers позволяет передавать сообщения и получать к ним доступ на разных языках без необходимости разбора и распаковки. В случае Deno FlatBuffers используется для обеспечения внутрипроцессного обмена сообщениями между привилегированной и непривилегированной сторонами. Многие общедоступные API-интерфейсы Deno внутренне создают буферы, которые содержат сериализованные данные на внешнем интерфейсе TypeScript, и делают эти буфера доступными для Rust, чтобы конец Rust мог обработать запрос. После завершения или планирования запросов конец Rust аналогичным образом создает буферы для сериализованных результатов и отправляет их обратно в TypeScript, который десериализует их, используя файлы, сгенерированные компилятором FlatBuffers. По сравнению с Node, который создает много привязок V8 для каждого привилегированного вызова, Deno с FlatBuffers нужно только выставлять методы отправки и получения сообщений на TypeScript и Rust. Это значительно упрощает добавление нового вызова и исключает прямое взаимодействие с V8. Flatbuffers введен для замены протокольных буферов в прототипе Go, чтобы избежать накладных расходов. Смотрите эту ветку для получения дополнительной информации.

Tokio Tokio - это асинхронная среда исполнения для Rust. Он используется для создания и обработки событий. Это позволяет Deno порождать задачи во внутреннем пуле потоков и получать уведомления для обработки вывода после завершения задачи. Tokio опирается на Rust Future, конструкцию, похожую на обещания JavaScript.

deno_bkjs.md

https://tinyclouds.org/deno_bkjs.pdf

• deno распространяется как один исполняемый файл (и так будет всегда).
• Для запуска любой программы deno не требуется никакого дополнительного программного обеспечения.
• deno использует только «ES-модули», а не require ().
• deno может выполнять TypeScript из коробки.
• deno дает гарантии безопасности, поэтому вы можете безбоязненно выполнять код.
• deno можно встраивать как ящик для ржавчины
• deno совместим с браузером

All imports are either relative or via URLs.

import { red } from "https://deno.land/x/std@v0.2.6/colors/mod.ts";
console.log(red("Hello world!"));

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

Он работает точно так же, как URL-адреса в браузере JS. ● Требуется расширение имени файла. ● index.js больше не имеет особого значения. ● Нет "bare imports" like import * as react from "react"

Флаги CLI безопасности

--allow-net — access the network --allow-write — write to disk --allow-env — read from env vars --allow-run — run subprocesses

Or -A to allow all.

Deno как ОС

...

first-look-at-deno.md

https://43081j.com/2019/01/first-look-at-deno

Тем не менее, Node в настоящее время очень старается играть с новыми API и особенно с ES-модулями. Вот где приходит deno, поскольку он стремится реализовывать вещи так же, как это делают браузеры.

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

Deno - это просто еще одна среда выполнения для языка, который мы уже знаем, поэтому ваш код будет почти таким же, как в браузере (без учета стандартных различий в библиотеках).

import { listen, copy } from "deno";

(async () => {
  const addr = "0.0.0.0:8080";
  const listener = listen("tcp", addr);
  console.log("listening on", addr);
  while (true) {
    const conn = await listener.accept();
    copy(conn, conn);
  }
})();

RUN

deno foo.ts
deno requests network access to "listen". Grant? [yN] y
listening on 0.0.0.0:8080

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

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

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

Одна из больших проблем с Node сейчас заключается в том, что они находятся в трудном положении, пытаясь оставаться совместимыми со своей собственной модульной системой (require) и той, которая определена в спецификации (import).

Здесь отлично подходит Deno, ему нет дела до старой системы модулей Node, не соответствующей спецификации, и он реализует только то, что есть в спецификации, ES Modules:

// Deno & Browsers
import {Foo, Bar} from './my-module.js';

// Node (CommonJS)
const {Foo, Bar} = require('./my-module.js');

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

Пакетные замки, манифесты и пр.

Я думаю, что в deno чего-то не хватает - это концепция манифеста и, возможно, файла блокировки.

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

Полагаю, это обходит необходимость в файле блокировки, но кажется немного нетрадиционным, когда я делаю свои зависимости…

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

Но что, если кто-то изменит тег git, или ветку, или URL просто исчезнет? Некэшированная сборка будет иметь много проблем, или зависимость может быть неосознанно изменена.

Что касается манифеста, deno рекомендует создать файл package.ts или какой-нибудь такой файл:

// package.ts
export {Foo, Bar} from 'https://foo.bar/branch/some-package.ts';

// mod.ts
import {Foo, Bar} from './package.ts';

The standard library…

Вот где deno действительно становится очевидным проектом ранних стадий, для которого требуется много TLC, прежде чем он станет чем-то большим, чем эксперимент.

У меня есть несколько проблем:

• Нет четкого процесса в отношении того, что включено (кто решает, какие модули вводить или что они предоставляют?)
• Некоторые модули кажутся поспешными (модуль datetime является хорошим примером, анализ которого выполняется с помощью набора условий).
• В некоторых модулях отсутствуют тесты.
• Не все модули следовать той же структуре, соглашениям и т. д.

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

По сравнению с браузерами

То, что deno пытается просто реализовать те же спецификации, что и браузеры, должно означать, что весь код переносим (по крайней мере, после переноса TypeScript).

Это кажется правдой, но все еще есть некоторые незначительные проблемы.

Например, deno требует расширения для всех импортов, но языковая служба TypeScript (которую используют такие редакторы, как VSCode) в настоящее время не нравится и жалуется.

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

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

Подводя итог, я думаю, что deno - это здорово, и это важный шаг вперед. То, что Node не осмеливается сделать (серьезное изменение для них), deno может и сделал.

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