Самое горячее событие в кругу переднего плана в эти дни — новый проект ry (Райана Даля) deno, и многие ИТ-новости и СМИ использовали название: «Next Generation Node.js». Я прочитал исходный код deno на этих выходных и специально написал эту статью. Длинное текстовое предупреждение (5000 слов, 11 картинок).
0. Зачем разрабатывать Deno?
Вот график, который я сделал на прошлой неделе, чтобы дать краткую историю JavaScript. Просто изменил его, чтобы добавить примечание о времени выпуска Node.js и Deno. Node.js и Deno были разработаны Райаном Далем в 2009 и 2018 годах соответственно на основе новейшей фронтенд-технологии года.Небраузерная среда выполнения JavaScript.
Райан Даль разработал deno не потому, что «просто для удовольствия», нине заменять узел. Объясните медленно ниже.
1. В настоящее время deno — это просто демоверсия
В последние два дня я нашел время, чтобы прочитать исходный код deno (к счастью, он находится в начальной стадии, исходный код очень мал, и его легко понять), и, кстати, я прочитал все вопросы и прс. Я не знаю, как «из официального представления его можно рассматривать как Node следующего поколения».
Поскольку это новая работа отца Node.js, Node.js, естественно, неотделим от обсуждения. Автор прямо ответил:
The main difference is that Node works and Deno does not work : )
Большая разница в том, что Node работает, а Deno нет :)
В настоящее время Deno — это просто демоверсия, даже не бинарный дистрибутив. К счастью, компилировать из исходников проще (если вы не в Windows).
На высоком уровне Deno обеспечивает максимально простую привязку V8 к системным API. Зачем использовать Golang вместо C++, потому что по сравнению с Node Golang позволяет намЛегче добавлять новые функции, такие как http2 и т. д.
Насчет того, почему вы не выбираете Rust, автор не ответил.
Давайте сравним производительность запуска двух. Выполнить отдельно:
console.log('Hello world')
Я уже писал статью:Новый план для Node.js: в 8 раз более быстрый запуск с моментальным снимком V8, то если использовать--without-snapshot
Как насчет компиляции Node.js с параметрами?
Есть еще большая разница, в конце концов, deno нужно загрузить компилятор TypeScript. Ведь это демо-версия, и я надеюсь ее оптимизировать в будущем.
Еще одна идея для повышения производительности — использовать LLVM в качестве внутреннего компилятора для компиляции кода TypeScript в WebAssembly, а затем запускать его в V8 или даже компилировать исходный код непосредственно в двоичный код для запуска. Райан Даль сказал, что deno нужен только один компилятор, и это TS. Но поскольку deno совместим с браузерами, WebAssembly также должен поддерживаться.
Deno может кэшировать результаты компиляции ts (~/.deno/cache
), поэтому в настоящее время основное внимание уделяется скорости запуска и начальной скорости компиляции.
Или скомпилируйте его перед выпуском, чтобы deno не соответствовал первоначальному замыслу разработки. Deno - это среда выполнения ts, поэтому должна быть возможность запускать код ts напрямую.Если ts заранее скомпилирован в js, то deno вернется к среде выполнения js.
2. Стоит ли новичкам изучать Node.js или Deno?
Ответ Райана Даля на этот вопрос лаконичный и аккуратный:
Use Node. Deno is a prototype / experiment.
Используйте узел. Deno — это всего лишь прототип или экспериментальный продукт.
Как видно из введения, целью Deno является совместимость не с Node, а с браузерами.
Поэтому Deno не заменит Node.js или Node.js следующего поколения, а также не откажется от npm для восстановления экосистемы Node. Текущая цель deno — охватить экосистему браузера.
Должен сказать, что это великая цель. Райан Даль разработал Node.js, а сообщество создало всю экосистему npm. я ответила в другомjustjavac: Что такое nodejs в глазах чистой фронтенд-разработки?Написано, что «Node.js — один из важных столпов фронтенд-инжиниринга».
Хотя Райан Даль покинул Node.js и перешел в сообщество Golang, Райан Даль вернулся, представляя Golang сообществу JavaScript, разрабатывая Deno и охватывая экосистему браузера. 👍
Давайте посмотрим на цели deno для веб-API:
- High level
- Консоль √
- File/FileList/FileReader/Blob
- XMLHttpRequest
- WebSocket
- Middle level
- AudioContext/AudioBuffer
- Canvas
Он даже будет включать поддержку webGL, графического процессора и т. д.
3. Архитектура Дено
Парса Гадими рисует ДеноДиаграмма архитектуры:
Нижний слой разработан авторомv8worker2, а цикл событий основан на модели pub/sub. О v8worker вы можете взглянуть на этот PPT:docs.Google.com/present Вопрос А…
Что меня больше всего интересует, так это то, что deno использует protobuf, а не Mojo. Поскольку цель состоит в том, чтобы быть совместимым с браузерами, а не использоватьMojo, но чтобы пересобрать колесо на протобуфе, видно, что Райан Даль - настоящий "брат по колесу". Если вы хотите быть совместимым с экосистемой браузера, выбор Mojo — это кратчайший путь, а если целью является высокопроизводительный сервер, вам следует выбрать несериализованную библиотеку с нулевым копированием. protobuf не подходит для deno с любой точки зрения. Но как видно из вопроса, Райан Даль никогда раньше не слышал о Mojo, но после прочтения mojo все же чувствует, что выбор protobuf правильный.
Mojo — это механизм IPC нового поколения, разработанный Google для замены старого IPC Chrome. Последняя версия Chrome в настоящее время — 67, и Google планирует заменить все старые IPC на mojo в версии 75 в 2019 году.
Идеи Mojo действительно похожи на protobuf, ведь все они принадлежат Google. Старая система IPC была реализована на основе именованных каналов (IPC::Channel) между двумя процессами (потоками). Этот конвейер представляет собой очередь, и сообщения IPC между процессами доставляются в порядке «первым пришел — первым обслужен», поэтому различные сообщения IPC имеют зависимости последовательности. Напротив, Mojo создает отдельный конвейер сообщений для каждого интерфейса, гарантируя, что IPC разных интерфейсов независимы. И стоимость создания отдельного конвейера сообщений для интерфейса не дорогая, выделяется только небольшой объем кучи памяти.
Архитектурный дизайн Mojo:
Мы можем взглянуть на архитектурные изменения с момента появления Mojo в Chrome.
До:
Позже:
Это похоже на микросервис?
Те, кто знаком с Java Spring, могут ясно видеть это.Инверсия зависимости. Первоначально Blink был движком нижнего уровня браузера, но через Mojo Blink стал промежуточным модулем. Недавно популярный Flutter также основан на архитектуре Mojo.
4. TypeScript VS JavaScript
Введение в deno — безопасную среду выполнения TypeScript. Но когда мы посмотрим на исходный код, мы обнаружим, что deno интегрирован в компилятор TypeScript, а файл вводаry/deno: main.go
// It's up to library users to call
// deno.Eval("deno_main.js", "denoMain()")
func Eval(filename string, code string) {
err := worker.Load(filename, code)
exitOnError(err)
} // It's up to library users to call
// deno.Eval("deno_main.js", "denoMain()")
func Eval(filename string, code string) {
err := worker.Load(filename, code)
exitOnError(err)
}
Файл deno_main.js, работающий с V8. Это JavaScript вместо TypeScript.
В предыдущем анализе мы знали, что это повлияет на начальную скорость запуска deno. А как насчет скорости выполнения? Теоретически, поскольку TypeScript является статически типизированным языком, скомпилированный код JavaScript будет выполняться быстрее. Ранее я упоминал в статье «Внешние программисты должны немного знать о V8», что V8 влияет на повышение производительности JavaScript.Type feedback.
Когда V8 выполняет функцию, он выполняет JIT-компиляцию на основе фактических параметров, переданных функцией (обратите внимание, что это фактический параметр, а не формальный параметр, поскольку формальный параметр JavaScript не имеет типа):
Но когда позже функция будет вызвана с другим типом, V8 выполнит операцию **Deopt**.
(Удалить ранее оптимизированные результаты, называемые «деоптимизацией»)
Но если мы используем TypeScript, все параметры аннотируются по типам, что предотвращает операции деоптимизации, выполняемые внутри движка V8.
5. Перспективы и предположения о производительности deno
Хотя TypeScript может избежать операции деоптимизации движка V8, V8 выполняет результат после компиляции ts. Из байт-кода или машинного кода видно, что V8 по-прежнему генерирует код для проверки типа. Перед вызовом каждой функции V8 тип фактического параметра проверяется. То есть, хотя TypeScript гарантирует тип параметра функции, после компиляции в JavaScript V8 не может определить тип параметра функции и может только гарантировать тип параметра, проверяя его перед каждым вызовом.
Во-вторых, когда V8 сталкивается с определением функции, он не знает тип параметра, и только после вызова функции V8 может судить о типе функции, а затем выполнять типизированную компиляцию функции в реальном времени. Здесь есть еще одно противоречие, typescript уже знает тип формального параметра, когда функция определена, а V8 оптимизирует только в соответствии с типом фактического параметра при вызове функции.
Поэтому с текущей архитектурой deno еще много проблем, ведь это всего лишь демо. Есть еще много направлений для оптимизации в будущем.
V8 — это среда выполнения JavaScript, и если deno определяется как «безопасная среда выполнения TypeScript», по крайней мере, в текущей архитектуре, это приводит к огромным потерям в производительности. Но пока нет среды выполнения TypeScript, и лучше всего поставить перед V8 компилятор TypeScript.
Последовательность выполнения следующая:
Хотя я не использовал TypeScript в проекте, в основном сторонние библиотеки, которые я пишу в проекте, предоставляют файл d.ts. В настоящее время наибольшее использование TypeScript по-прежнему отражается в процессе разработки и обслуживания.
Один из способов, о котором мы думаем, — это разветвить исходный код V8, а затем интегрировать в него процесс компиляции. TypeScript также нуждается в AST в процессе компиляции в JavaScript, а затем генерирует код js. Когда V8 выполняет код js, он анализирует другой AST и генерирует промежуточный код (ByteCode) на основе AST. Производительность во время выполнения улучшилась бы, если бы TypeScript мог напрямую генерировать соответствующий байт-код.
Но Райан Даль, вероятно, не будет этого делать. Но не обязательно, ведь сообщество скомпилировало подмножество TypeScript в WebAssembly.
Раньше JScript и VBScript от Microsoft проигрывали в конкуренции с JavaScript, а сейчас TypeScript набирает обороты. Хотя совместимость со спецификацией ES ограничивает разработку TypeScript, ожидается, что Microsoft может предоставить среду выполнения TS или добавить поддержку среды выполнения TS в механизме Chakra.
6. Резюме
В любом случае, deno — очень хороший проект, но не «следующее поколение Node.js».
PS: вчера Райан Даль сделал "Design Mistakes in Node«Речь, в настоящее время только PPT, нет видео Youtube. А 8 лет назад, в 2009 году, Райан Даль также выступил с докладом на конференции JS Conf, на которой родился Node.js.