Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
Логично. Но пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели, а самое плохое — испытание на малом кол-ве файлов показательным не особо будет, так что прогнозировать, как оно заработает на большом проекте довольно трудно. Поэтому нужен чужой опыт.
Я не совсем согласен насчет «устаревшей» технологии, не так все плохо… Плюс он спокойно расширяется через модули и прикрутить туда компиляцию es6 никакого труда не составляет. А бонусы от компиляции в рантайме при этом остаются.
Я переформулирую вопрос — какие webpack предоставляет возможности для быстрой компиляции в режиме «изменил-сохранил-посмотрел в браузере», насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
А насколько у webpack хорошо с компиляцией в рантайме? Я вот поставил requirejs с jsx плагином и могу все на живую компилировать, никаких watcher'ов и т.п., webpack же, насколько я понимаю, заставит меня через свой сервер ходить для этого.
Механика процесса как раз понятна и вопросов не вызывает. Дело в другом. Допустим я открыл видео, поделал что-то со страницей, потыкал в ссылки и т.д., и по привычке нажимаю пробел и результат — известно какой. И главное, раз уж надо в плеер ткнуть мышкой для фокуса, то тогда уже проще и на паузу мышкой же нажимать.
.finally() можно заменить конструкцией .then().catch().then() и не выбрасывать exception заново в catch(), тогда будет считаться, что блок отлова ошибок ошибку поймал, обработал и вернул выполнение в нормальное русло.
По стандарту каждый блок .then() или .catch() выдает наружу новый promose, соотв. если в .catch() не перепрокинуть ошибку
.catch(function(e){
// do something
throw e;
})
и вернуть некий результат или другой primise, то будет считаться, что нормальный ход выполнения восстановлен.
Никто конечно не мешает вытащить функции разрешения наружу. Но это как раз и является лично для меня раздражающим фактором в конструкции Q.defer(), т.к. в случае с Revealing Constructor Pattern (т.е. как реализован Promise), разрешение возможно только внутри, что в большинстве случаев является необходимым и достаточным. Затрудняюсь придумать сценарий, когда Promise создается в одном месте, а резолвится в другом.
А в дебаг режиме не нужно ничего компилировать, оно и так работает как RequireJS.
Если Вы про google closure compiler, то да, а вот фишки Flow, в которых задействовано в т.ч. расширение синтаксиса, без пре-компиляции не взлетят. Так что я сугубо за подход через аннотации в комментариях.
Что касается проектов с мегабайтами исходников — для таких только бандлы функциональности, загружаемые по мере надобности, и, безусловно, прекомпиляция, но так то ж для продакшена. Там можно многое, чего не желательно иметь в дев режиме. И наоборот…
Я лично именно за такой вариант, когда при применении RequireJS (ну или Cajon, если CommonJS синтаксис ближе) есть и модульность и нет необходимости что-то компилировать перед запуском, а парсинг JSDoc обеспечивает более-менее вменяемое автодополнение при написании и подсветку потенциально опасных мест. На мой взгляд, компилировать язык, который без этого прекрасно обходится — есть безусловное зло. Только при создании билда на продакшен, там это оправдано.
Сейчас IntelliJ продукты (WebStorm, IDEA и т.д.) прекрасно справляются с большинством ситуаций при наличии хорошо написанного JSDoc.
Надеюсь это направление со временем не отомрет и JS не придет к тому, что любой чих надо будет перекомпилировать…
Сравнение с typescript немного некорректно. Его придется компилировать, а парни из Flow утверждают, что все пашет само прямо на живую. Что несомненно лучше. Единственное, на мой взгляд, лучше бы они JSDoc начали парсить, чем вводить какие-то навороты по синтаксису, а то и правда TS получается.
Я недавно делал проект на TypeScript, где sourcemap тоже есть, однако нормально дебажить все равно неудобно, т.к. что-то где-то все равно не так названо может быть, либо не на ту строку брейкпоинт встает. Короче говоря, помогает, конечно, но с оговорками. Большими такими оговорками.
Приглядитесь, в моем коде ошибки промисов не потеряются, а в Вашем — они никак не будут обработаны. А так разница мала, да. Насчет уровней вложенности, готов поспорить, что их можно было бы вывернуть из вложенности в обычную цепочку, если правильно модифицировать результат Promise'ов.
События для другого. Promise одноразовый по определению, события — сущность многоразовая. Не стоит мешать две разные концепции, их следует использовать строго там, где это дает наибольший профит.
Логично. Но пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели, а самое плохое — испытание на малом кол-ве файлов показательным не особо будет, так что прогнозировать, как оно заработает на большом проекте довольно трудно. Поэтому нужен чужой опыт.
Я переформулирую вопрос — какие webpack предоставляет возможности для быстрой компиляции в режиме «изменил-сохранил-посмотрел в браузере», насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
По стандарту каждый блок .then() или .catch() выдает наружу новый promose, соотв. если в .catch() не перепрокинуть ошибку
и вернуть некий результат или другой primise, то будет считаться, что нормальный ход выполнения восстановлен.
Если Вы про google closure compiler, то да, а вот фишки Flow, в которых задействовано в т.ч. расширение синтаксиса, без пре-компиляции не взлетят. Так что я сугубо за подход через аннотации в комментариях.
Что касается проектов с мегабайтами исходников — для таких только бандлы функциональности, загружаемые по мере надобности, и, безусловно, прекомпиляция, но так то ж для продакшена. Там можно многое, чего не желательно иметь в дев режиме. И наоборот…
Сейчас IntelliJ продукты (WebStorm, IDEA и т.д.) прекрасно справляются с большинством ситуаций при наличии хорошо написанного JSDoc.
Надеюсь это направление со временем не отомрет и JS не придет к тому, что любой чих надо будет перекомпилировать…
В копилку — база полифиллов polyfills.io
Сильно сомневаюсь, что кто-то будет этим заниматься. Один из плюсов RequireJS — что она всеядна и через shim и прочее туда можно запихать что угодно.