Как стать автором
Обновить

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

Помимо работы, у меня есть несколько сайд-проектов, в которых я широко использую Deno

Всё-таки, для каких задач Deno подходит лучше, чем Node?

Если проект большой, планируется его поддерживать долгое время и развивать, то я бы сделал выбор в пользу node, так как под него есть решения практически для каждой задачи. Если проект сугубо утилитарный, то в качестве эксперимента вполне можно использовать Deno, будет гораздо проще и произвести изначальную настройку (в том числе и с помощью фреймворков экосистемы Deno) и настроить пайплайны билдов/деплоя.

Например, у меня есть свои сайд проекты, которые я пишу только под Deno. Проекты эти очень узкоспециализированы, я точно знаю что в них будет и чего нет. И Deno там отлично справляется. Мой проект - это веб скраппер + мобильное приложение (не на TS/JS, только Kotlin).

Другими словами я бы ставил вопрос всегда так: нужна стабильность и уверенность в том что будет решение под ваши запросы - однозначно node. Хочется экспериментов - deno.

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

Удивительно, что в 2022-м году кто-то еще рассматривает express как рабочий инструмент.

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

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

Ни моя статья, ни документация не призывает этого делать. Это просто демонстрация возможностей, не более. И приведено как наиболее простой пример.

Интересно узнать ваше мнение. Думаю, развёрнутый ответ будет полезнее для читающих. Чем плох Express в 2022 и что взять вместо него?

Я бы со своей колокольни сказал, что стоит так же рассмотреть Fastify и Nest. Но обратил бы внимание на приносимую техническую сложность, размер проекта и решаемую задачу.

Если нужно просто протянуть апишку, то возможность стоит посмотреть на tRPC.

API Fastify достаточно прост, под капотом не содержит тонны легаси и архаичный подход с цепочками миддлвар.

Вместо express, можно взять, например, частично совместимые Rayo или Polka:
Native
Requests/sec: 50867.22
Transfer/sec: 5.05MB

Polka
Requests/sec: 50475.67
Transfer/sec: 5.01MB

Rayo
Requests/sec: 49481.55
Transfer/sec: 4.91MB

Fastify
Requests/sec: 47476.75
Transfer/sec: 6.57MB

Koa
Requests/sec: 33909.82
Transfer/sec: 4.69MB

Express
Requests/sec: 20249.80
Transfer/sec: 4.02MB

Данильян, спасибо за статью и доклад на Яндекс!

В своем проекте Вы использовали Deno DOM WASM
. Скажите пожалуйста - какое ощущение у Вас сложилось по быстродействию этого пакета по сравнению с аналогичными библиотеками для Node ?

Действительно ли WASM в данном случае дает существенный прирост производительности ?

Рад что оказалось полезно:)
В последний раз я пользовался библиотекой cheerio для nodejs. На примерно одинаковом по объеме HTML кода (но не по сложности селекторов). Был это примерно 2018-2019 год. По ощущениям примерно то же самое, однако в своем нынешнем проекте я использую гораздо больше селекторов, они куда сложнее, а также хожу циклами по DOM элементам (в моем случае там по-другому к сожалению никак). Конкретных бенчмарков я не делал и производительность парсера на данный момент для меня не сильно важна, выкачиваю весь сайт примерно за 2 часа на типичном ПК разработчика (Ryzen 5500, 16gb RAM).
Говорить о существенном приросте я бы не стал. Однако если вам надо, к примеру, прожевывать HTML и выплевывать его по HTTP запросу, то возможно я бы порекомендовал именно Web Assembly и Deno, но опять же, это пальцем в небо, я могу только предполагать какие у Вас кейсы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий