Comments 16
Мне не понятно зачем нужно было переносить переменные request и response в this. ИМХО удобнее передавать их через аргументы функции, как в express. И выносить поддержку co за пределы koa до появления async/await в v8, как-то преждевременно.
app.use(co.wrap(function *(ctx, next) {
// ctx.request
// ctx.response
yield next();
}));
Ну а если использование babel не приемлемо то можно обходиться генераторами или промисами, которые нативно работают уже сейчас.
Кроме того я хочу отметить что авторами Koa являються (более 70-ти) человек, часть которых учавствуют в разаработке Express, который значительно консерватавнее к новым возможностям JS.
Бабель-фуябель генерирует неоптимизируемый V8 код и это, очевидно, может заметно негативно сказаться на производительности. Пока в движок не будет добавлен синтаксис async/await, во фреймворке нет смысла (не свитая небольших проектов "для души").
Бабель-фуябель генерирует неоптимизируемый V8 код
O_o. Откуда дровишки? Почему V8, по вашему, не будет оптимизировать js код после babel-а? Чем он провинился? :)
Взгляните, что генерирует Babel. Если разобрать _asyncToGenerator, там есть неоптимизируемый try..catch. Но это полбеды, посмотрите, во что превращается безобидный код. Попробуйте разобраться, сколько лишнего всего происходит при использовании async/await: конвертация в генератор, вызов вот этой функции (изменение proto налету, ага), вызов вот этой (и всего, что в ней находится). Вы по-прежнему хотите это на сервере? Мы вроде-как наоборот стараемся ускорить приложения на ноде, ну да ладно.
там есть неоптимизируемый try..catch.
Посмотрел. А в чём проблема то? Там же всего пару строк. try-catch вынесен уровнем выше. Самое главное — оптимизации подлежит.
Попробуйте разобраться, сколько лишнего всего происходит при использовании async/await
Да вроде ничего особенного, учитывая контекст применения. Для высоконагруженных частей кодовой базы, может и не сгодится, но в остальных случаях — более чем. Следует понимать, что async-await в принципе не будет работать особенно то быстро, т.к. там всегда будет большой switch-case автомат и промисы. Это ведь в первую очередь удобство.
Я использую co и generator-ы (т.е. без babel). Выжимал по ab на простенькой веб-странице 1600 запросов в секунду (и это сквозь целую цепочку таких вот await-генераторов). Мне кажется такой производительности более чем достаточно для скриптового то языка. А позже и нативная реализация подойдёт. Правда я не думаю, что она будет заметно эффективнее.
А зачем такой громкий пафосный заголовок? К чему это? Ожидал увидеть какие-нибудь новые подходы или фишки. Не стоит так писать.
Вы знаете, мне кажется, сейчас каждый, кто начинает писать свой framework использует babel async-await или их имитацию через генераторы. Нет в этом никакого "фреймворка нового поколения". Если вы действительно считаете koa чем то выдающимся, то стоило именно об этом и написать. А так получилось что статья с ну прямо очень громким заголовком и описанием того, что мол есть babel и есть co, используйте. Я же по вашим примерам вижу в нём тот же самый express, который всегда не вызывал у меня ничего кроме недоумения.
app.use(convert(function *(next) {
const start = new Date(); // Это выполниться до того как будет отдан ответ на запрос
yield next;
const ms = new Date() - start; // Это выполниться после того
console.log(`${this.method} ${this.url} - ${ms}ms`); // как будет отдан ответ на запрос
}));
Если не нужен обработчик на upstreem-и или downstreem-е эту часть кода опускаем. Никаких колбеков. Где же тут express? Использование middleware? Так это у половины фреймворков такой стиль!
Мне не правится express и мне неприятно Ваше обобщение.
Koajs 2.0: новое поколение фреймворка нового поколения