Pull to refresh
87
0

User

Send message
Конечно, не 10, а лет 15 лет назад, но похоже мудаком я был еще тем :)
И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.

Потом уходит само (ненужное здесь, по большому счету) понятие «контроллера» и это просто называется компонентом :)
Похоже, что вы просто придумали Webpack или Brunch, но менее навороченный в плане фич и возможностей. К тому же, не вполне понятно, зачем/причем тут вообще require.js в том или ином виде — SystemJS (плюс SystemJS Builder) и Webpack замечательно умеют работать с модулями самых разных форматов. Понятно, что там свои конфиги, но все равно неясна ниша этой разработки — немного похоже на brunch (но на базе gulp) и не предлагается ничего кардинально нового.

И совершенно непонятен тезис насчет
А как же Babel, ES6, Coffee, TypeScript? А никак. Сборка создавалась для использования в больших и средних проектах в продакшене. Если у вас университетская исследовательская работа или домашняя страничка, зачем вам вообще сборка? А если всё это в серьезном проекте, да в продакшене… Положим еще раз руку на сердце, вы просто изучаете новые технологии за счет работодателя.

Что бы это вообще значило? То, что все вышеперечисленное — игрушки для студенческих поделок?
Автор комментария как раз-таки подробно описал свою точку зрения и технические аспекты вместе с таким выводом. Вы же просто выдаете что-то как истину в первой инстанции, а на все запросы объяснить что-то чуть подробнее (люди реально хотят понять, что, да как, да почему) — вы говорите, что они ни хрена не понимают и сами идиоты (так это воспринимается). Отсюда и минусы, никакие истерики, о которых вы говорите ниже, ни при чем, дело даже не в обработке ошибок в Go, и даже не в самом Go.
Все верно, декораторы — это ES7. Статические свойства в объявлении класса — тоже ES7.
Чем-то жертвовать придется :)

Если filter тоже должен быть асинхронным — то сложнее, но если мы после .asyncMap работаем чисто с результатами промисов — то можно использовать синхронно все остальное.

var items = await list.asyncMap(fn1);
return items
       .filter(fn2)
       .reduce(fn3)
       .some(fn4);
А есть где-то информация почему так? Все-таки Promise.all — это дополнительный шум в коде. Как-то я упустил этот момент с удалением «await*».
Ну, в точности, как синхронно, конечно, не будет. Но с «await*», который, как говорят ниже, убрали из спека и с Promise.all получаем вполне работающий синхронный .map, но оперировать все равно придется промисами — впрочем, это в любом случае. .asyncMap вполне несложно реализовать, использовав внутри .map и Promise.all — так что тут я особой монструозности то и не вижу. Единственное — всегда нужно держать в голове, что там происходит за кулисами.
Ну, тут как ни пиши, результат работы самой async функции будет промисом, а .map() — синхронный. В случае

async function test(list) {
  var result = list.map(async function (el) {
    return await someAsyncMethod(el);
  });
  console.log(result);
  return result;
}

в консоль выводятся объекты промисов, а в случае
async function test(list) {
  var result = await* list.map(el => someAsyncMethod(el));
  console.log(result);
  return result;
}

результаты работы промисов.
Как по мне — вполне нормально можно сделать и с async/await:

async function test(list) {
  return await* list.map(el => someAsyncMethod(el));
}

Вот и мне интересно, что мы ожидаем получить из подобного рода конструкции, даже если бы она работала. Даже если ее переписать, чтобы она не использовала arrow-функцию и использовала async, что будет работать технически, то мы в итоге все равно получаем массив промисов, как если бы вообще не использовали await в коде выше.

Я понимаю, что товарищ faiwer говорил про «контекст», и ведь вроде как в стрелочных функциях тот же «this», что и за ее пределами, так почему бы не передавать и «async» — но это другое. Как по мне — несмотря на необходимость явно отмечать функции как «async» — код получается с виду очень даже синхронным (но на практике надо понимать, конечно, во что он разворачивается).
А зачем писать свою реализацию .map() и прочих? Что мы хотим получить на выходе вот этой функции из примера?

async function test(list) {
  return list.map(el => await someAsyncMethod(el));
}

В этом плане я совершенно согласен с Домеником Деникола, что генераторы для «синхронности в асинхронном коде» — это больше хак и workaround, они изначально задумывались для других целей. И async/await — именно для управления асинхронным потоком исполнения в приложении, а генераторы останутся для того, для чего были задуманы изначально (итерация, удобные ко-рутины).

image
Так они недавно (в сентябре) еще и перешли в статус Stage 3 (Candidate).
И в Angular 2, и в Ember 2 тоже (и там, и там — плотно советуясь с командой React), и на Angular 1 тоже в итоге для больших приложений получается удобнее писать (субъективно), когда есть явная передача данных «туда» и «обратно».

Однако, часто бывает удобен и 2-way-binding, но надо понимать, когда его лучше использовать (в Aurelia он хорошо сделан и лишен недостатков оного в Angular 1) — тут создатели разных фреймворков вроде как сошлись во мнении, что правильный 2-way-binding — это сахар над one-way-binding для отдельных случаев (именно такой подход используется в ng2 с его жуткими "([...])" скобками в шаблонах и похожий в Aurelia с его «адаптивными байндингами»).
Добавлю, что Babel не только понимает JSX, но и сама команда React'а даже отказалась от своих наработок и рекомендует использовать Babel для трансформации.
Практически для всех платформ :)
package main

import "fmt"

func main() {
	fmt.Println("Hello, World!")
}
XSLT не устарел, просто в общем случае для SPA он слишком громоздок и те же задачи сегодня решаются массой более элегантных способов.

но с модулем XSLT, view логику Angular можно вообще отдать XSLT
И зачем нам тогда тут Angular? Он кроме view-логики тут ничего особенного и не дает.
Это было бы здорово. Ибо Sails как таковой — нравится в целом, но давно не используется именно по вышеупомянутым причинам.
В итоге тоже пришел к этому. Немного больше boilerplate-а, но все это все равно становится либами/пакетами. С Sails есть свои косяки, хотя API хорош, на самом деле. Одним из последних камней преткновения в одном из проектов было использование в Sails-е Express 3.x, в то время как уже вовсю 4-й был в ходу.

Information

Rating
Does not participate
Date of birth
Registered
Activity