Похоже, что вы просто придумали Webpack или Brunch, но менее навороченный в плане фич и возможностей. К тому же, не вполне понятно, зачем/причем тут вообще require.js в том или ином виде — SystemJS (плюс SystemJS Builder) и Webpack замечательно умеют работать с модулями самых разных форматов. Понятно, что там свои конфиги, но все равно неясна ниша этой разработки — немного похоже на brunch (но на базе gulp) и не предлагается ничего кардинально нового.
И совершенно непонятен тезис насчет
А как же Babel, ES6, Coffee, TypeScript? А никак. Сборка создавалась для использования в больших и средних проектах в продакшене. Если у вас университетская исследовательская работа или домашняя страничка, зачем вам вообще сборка? А если всё это в серьезном проекте, да в продакшене… Положим еще раз руку на сердце, вы просто изучаете новые технологии за счет работодателя.
Что бы это вообще значило? То, что все вышеперечисленное — игрушки для студенческих поделок?
Автор комментария как раз-таки подробно описал свою точку зрения и технические аспекты вместе с таким выводом. Вы же просто выдаете что-то как истину в первой инстанции, а на все запросы объяснить что-то чуть подробнее (люди реально хотят понять, что, да как, да почему) — вы говорите, что они ни хрена не понимают и сами идиоты (так это воспринимается). Отсюда и минусы, никакие истерики, о которых вы говорите ниже, ни при чем, дело даже не в обработке ошибок в Go, и даже не в самом Go.
Если filter тоже должен быть асинхронным — то сложнее, но если мы после .asyncMap работаем чисто с результатами промисов — то можно использовать синхронно все остальное.
var items = await list.asyncMap(fn1);
return items
.filter(fn2)
.reduce(fn3)
.some(fn4);
Ну, в точности, как синхронно, конечно, не будет. Но с «await*», который, как говорят ниже, убрали из спека и с Promise.all получаем вполне работающий синхронный .map, но оперировать все равно придется промисами — впрочем, это в любом случае. .asyncMap вполне несложно реализовать, использовав внутри .map и Promise.all — так что тут я особой монструозности то и не вижу. Единственное — всегда нужно держать в голове, что там происходит за кулисами.
Вот и мне интересно, что мы ожидаем получить из подобного рода конструкции, даже если бы она работала. Даже если ее переписать, чтобы она не использовала arrow-функцию и использовала async, что будет работать технически, то мы в итоге все равно получаем массив промисов, как если бы вообще не использовали await в коде выше.
Я понимаю, что товарищ faiwer говорил про «контекст», и ведь вроде как в стрелочных функциях тот же «this», что и за ее пределами, так почему бы не передавать и «async» — но это другое. Как по мне — несмотря на необходимость явно отмечать функции как «async» — код получается с виду очень даже синхронным (но на практике надо понимать, конечно, во что он разворачивается).
В этом плане я совершенно согласен с Домеником Деникола, что генераторы для «синхронности в асинхронном коде» — это больше хак и workaround, они изначально задумывались для других целей. И async/await — именно для управления асинхронным потоком исполнения в приложении, а генераторы останутся для того, для чего были задуманы изначально (итерация, удобные ко-рутины).
И в 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 для трансформации.
В итоге тоже пришел к этому. Немного больше boilerplate-а, но все это все равно становится либами/пакетами. С Sails есть свои косяки, хотя API хорош, на самом деле. Одним из последних камней преткновения в одном из проектов было использование в Sails-е Express 3.x, в то время как уже вовсю 4-й был в ходу.
Потом уходит само (ненужное здесь, по большому счету) понятие «контроллера» и это просто называется компонентом :)
И совершенно непонятен тезис насчет
Что бы это вообще значило? То, что все вышеперечисленное — игрушки для студенческих поделок?
Если filter тоже должен быть асинхронным — то сложнее, но если мы после .asyncMap работаем чисто с результатами промисов — то можно использовать синхронно все остальное.
в консоль выводятся объекты промисов, а в случае
результаты работы промисов.
Я понимаю, что товарищ faiwer говорил про «контекст», и ведь вроде как в стрелочных функциях тот же «this», что и за ее пределами, так почему бы не передавать и «async» — но это другое. Как по мне — несмотря на необходимость явно отмечать функции как «async» — код получается с виду очень даже синхронным (но на практике надо понимать, конечно, во что он разворачивается).
Однако, часто бывает удобен и 2-way-binding, но надо понимать, когда его лучше использовать (в Aurelia он хорошо сделан и лишен недостатков оного в Angular 1) — тут создатели разных фреймворков вроде как сошлись во мнении, что правильный 2-way-binding — это сахар над one-way-binding для отдельных случаев (именно такой подход используется в ng2 с его жуткими "([...])" скобками в шаблонах и похожий в Aurelia с его «адаптивными байндингами»).
И зачем нам тогда тут Angular? Он кроме view-логики тут ничего особенного и не дает.