zooks: вот серьезно, зачем вам compass? Миксины? Есть отдельно, без экстеншена. Префиксы? autoprefixer надежнее. Спрайты - есть отдельные плагины... разделение обязанностей с одного жирного решения на несколько поменьше галп уже в состоянии оптимизировать.
zooks: вывод - отказаться от compass и реализации на ruby. Ruby жутко медленный язык даже по сравнению с JS. Gulp тут ничего не ускорит так как в этом случае он просто запустит компас. то есть если у вас 6-7 секунд занимает компиляция, галп тут ничего не поделает.
zooks: только один стэп - нет, node-sass и так быстро все делает. А вот если у вас достаточно жирный стэк (sass -> autoprefixer -> csso -> всякие другие штуки) и очень много файлов (скажем у вас несколько файлов, типа main.scss, 404.scss, critical-path.scss, последний надо заинлайнить в тело страницы и т.д.) - то тут уже есть варианты. - но да. Вот со скриптами уже веселее - там можно загрузить в стрим сразу все файлы и только по изменению файлов релоадить только то что поменялось - минимум чтения с диска - максимум скорость.
Для инкрементной сборки все есть. Мне нравится browserSync.
под Grunt плагинов больше, но того что есть под gulp уже с головой хватает. Так что это не аргумент. По поводу "проще" - не сказал бы. Либо одинаково либо даже сложнее в некоторых моментах. А шустрота... чем сложнее сборка тем быстрее она будет происходить относительно реализации на гранте.
vt4a2h: денить на канонично и не канонично конечно не стоит, то вот стараться придерживаться общепринятых практик и не выдумывать свои кривые общепринятые практики все же стоит. Есть вполне себе простые для осознания принципы вроде тех же SOLID которые применимы почти к любому языку. И нарушать их просто так потому что так хочется - не ок. Ну или если уж и нарушать то без особых последствий что бы.
copal: можно, но при помощи еще одного класса реализовав композицию объектов. Это было бы правильнее. Все ооочень зависит от специфики конечно, но конкретно в вашем примере мне больше видится композиция. Иначе я бы выкинул Node и делал бы дерево тасков, без привязки непосредственно к какой-то структуре деревьев. Просто как ваша бизнес логика прописывает, мол у тасков могут быть подтаски и т.д. Сложный вопрос на самом деле.
По поводу примера с колесами и машинами - машина не может реализовать интерфейс колеса или двигателя... это ж не колесо, машина не умеет крутиться, это совершенно отдельная сущность с совершенно другими характеристиками и обязанностями. Да и вместо колес у нее могут быть гусеницы. То есть вышло бы так, что класс автомобиль зависит от реализации интерфейса "движитель" (не путать с двигателем). И реализацией было бы уже "колесо" или "гусеница" или какой-то класс, зависящий от гусениц или колес. Но никакого наследования. С двигателем так же - вы же можете в реальной машине заменить двигатель внутреннего сгорания на электро двигатель? Это две реализации разных интерфейсов.
LB777: ватчеры не имеют никакого отношения к элементам. Аналог ватчера - Object.observe. То есть это детектор изменений. На каждый чих ангуляр проверяет не поменялись ли данные, и если таких проверок много (или что существенно, это не простые проверки а полное сравнение объектов или еще чего посложнее) - приложение будет тормозить. Цифра 2000 возникла с потолка, в реальности все зависит от ватчеров которые вы запихали. Но в целом идея простая - если у вас возникла задача которая решается большим количеством ватчеров - вам стоит пересмотреть решение в пользу реактивного программирования.
copal: не то что бы обязывает, сам Angular2 написан на TS. Так что почти все что связано именно с Angular придется писать на TS. В частности директивы те же. Хотя насколько я помню будет предлагаться "многословный вариант" для любителей ванильного JS (всеравно все компилится в ES5).
В целом же, если вы изначально не завязываете код на фреймворк и придерживаетесь слабой связанности, проблем быть не должно. Да и я не вижу ничего плохого в TS.
den-bogdanov: модуль - это грубо говоря изолированный контейнер. Поскольку в JS нет инкапсуляци на уровне объектов (все публично) - сокрытие реализации делают внутри модулей. То что выплевывает модуль по сути публичный интерфейс. Это очень утрировано. Понятие модуля есть вообще много в каких языках.
Kir ---: я упоминал Object.create исключительно в контексте наследования. Прошу прощения если это не понятно из комментариев. И ссылку я привел как раз в этом же контексте.
