Владимир Т.

Нет, естественно надо указать только то, что будешь внедрять непосредственно в сам компонент. А можно даже не указывать ничего, если сервис ты регистрируешь глобально в функции bootstrap.

Вообще логика такая: все сервисы, которые внедряются, должны каким-то образом быть зарегистрированы. Те сервисы, которые ты зарегистрировал глобально в функции bootstrap будут доступны глобально во всех компонентах. Их необязательно описывать в поле providers. Если сервисы не регистрируются глобально, то нужно регистрировать в компоненте. Причём сервисы будут доступны и в дочерних компонентах.
Вообще, у каждого компонента свой инжектор зависимостей. Таким образом, для каждого компонента можно настроить провайдеры сервисов по-своему. Если сервис не зарегистрирован у компонента, то его ищут вверх по иерархии компонентов.

читайте книжки, развивайтесь. Крутые тех диры иногда обитают во всяких гиттерах. А еще - учитесь задавать вопросы и ищите на них ответы. Вопросы в духе "откуда взялся active record", или откуда взялись объекты и зачем они нужны если есть функции и тд. Порой в поисках ответов на эти вопросы можно много чего узнать и понять.

Как можно начать использовать в таком проекте commonJS-модули и es2015?

Используйте сразу es2015 модули может?

В целом проблемы нет, просто нужно будет сначала слинковать все файлы между собой. Ну либо сделать пока один файлик в котором все файлы будут подключены и его использовать как точку входа для сборки. Ну а потом уже делать постепенно нормально.

p.s. я бы рекомендовал все же webpack вместо browserify, сейчас в последнем смысла особо нет.

browserify сам обернет ваш код в IIFE и даст возможность использовать commonjs
насчет es2015 - babel и babelify transform для browserify

Не нарушаю ли я таким образом подход angular-way?

Вы таким образом нарушаете подход MVC. Команды модели может отдавать только контроллер. На дворе 2015-ый год, скоро выйдут angular1.5 и angular2, пора отвыкать от наследия angular1.0 и 1.1

1) никаких $scope в контроллерах (читать про controllerAs). По сути единственное место где можно использовать $scope - link директивы (которых при возможности тоже лучше не юзать). Соответственно такие приятные глазу вещи как $scope.$watch тоже лучше используйте только в link

2) никаких отдельных контроллеров, контроллеры могут быть только у директивы (исключения - тупые контроллеры которые должны замэпить данные из параметров стэйта на директиву, то есть пробросить в атрибуты). Избегать использования module.controller. В целом почитайте про компоненты в контексте angular

3) избегайте использования в приложении начистую angular API. Все то что со знаком $ (например $http, $sce, etc) должно юзаться в обертке (сервисы-репозитории, фильтры, отдельные мини-сервисы...). Таким образом мы максимально отделяем приложение от фреймворка, и делаем поддержку кода проще (например если вы захотите обновить зависимости, вам не придется переписывать пол приложения из-за каких-то изменений в API, ну и сторонние библиотеки тоже рекомендую заворачивать в обертки-фасады, пряча их от приложения. Опять же по той же причине, с ангуляром ждать сюрпризов редко приходится но вот сторонние библиотеки...).

4) передавайте данные явно, то есть никаких ивентов, в сервисы (вашу модель) данные должны попадать по прямому вызову метода из контроллера. Тогда дебаг приложение и тестирование оного (вы же когда-нибудь начнете тестить приложения?) не будут вызывать боли. Да и поддержка кода существенно упростится. Исключение опять же - когда ивенты эмитятся и обрабатываются где-то в сервисах, например когда вы используете web-sockets. Тут как бы все с этим хорошо.

Полезные материалы по теме:

busypeoples.github.io/post/thinking-in-components-...
teropa.info/blog/2014/10/24/how-ive-improved-my-an...

p.s. Это все лишь рекомендации на случай если вы делаете не прототип на коленке а реаьлное приложение. Даже если в ближайшем будущем все это практиковать вам будет не реально (приложение пилится уже давно и переписывать его никто не будет), учтите на будущее.

в целом то как что делать решать только вам. Вам же потом с этим кодом работать. Ну или о людях после вас подумайте. В целом то что вы делаете - это называется писать логику в шаблонах.

var timer = Date.now(),
    img = new Image();

						img.onerror = errback;
						img.onload= callback;
						img.src = '/static/img.png';

function errback (err) {
    console.log((Date.now() - timer) + " ms", err);
}

function callback () {
    console.log((Date.now() - timer) + " ms"); // или использовать console.time, для простой отладки в консоли
    document.getElementsByTagName('body')[0].appendChild(img); // можно было вставить сразу в DOM, не дожидаясь загрузки
}

Тестирование JavaScript

Controller As желательно всегда, а уж инджектить или нет в контроллер $scope зависит от того, нужно ли вам:
- подписываться на события
- ватчеры в контроллерах

Случай когда вы именно хотите из контроллера задать что-то что должно наследоваться во всех скоупах я нарочно опускаю ибо так делать не стоит. Если уж хотите, это можно сделать в run модуля через $rootScope. Но не из контроллера, они по возможности должны быть изолированными и не должны зависить от иерархии.

Если вам удается обходиться без этого и все это берут на себя директивы и сервисы - славно, значит верной дорогой идете... скорее всего.

Единственое что... почему вы пишите SomeController as vm... По идее вы должны писать там алиас контроллера что бы было понятно у кого методы дергаются. Понятно в смысле не ангуляру а вам.

А чего не добавить общий class к элементам и изменять параметры этого класса?

Будет и короче код, а если у тебя на странице будет 100 таких элементов? так же писать будешь?

Зачем присваивать в $rootScope объект сервиса - не знаю. Вероятно, какой-то глобальный хелпер.
Присваивание в self - чтобы в коллбэках не потерять контекст.

Сила в том что все знают JS. Кто может писать на PHP/Ruby/Python? Те кто пишут на PHP/Ruby/Python соответственно (и скажем по 10%-15% от количества каждых кто может писать хотя бы на двух из трех языков. Кто может писать на JS? Все фронтэндеры + добрых каких 60%-70% от всех этих php/ruby/python/java/c# разработчиков...

Что это дает? ОГРОМНЕЙШЕЕ комьюнити... большая часть быдло конечно но засчет огромнейшего количества разработчиков инструментарий начал просто очень быстро развиваться. Кому нужен инструмент написанный на Ruby если его можно написать на JS и его сможет поддерживать на порядок больше людей?

Вопрос производительности по началу стоял как основная фишка языка. Все кричали наконец-то, V8 на сервере, асинхронность! Самый быстрый интерпритируемый язык на планете и все такое. Но на деле все чуть сложнее. JS реально быстрый. По сравнению с тем же Ruby он в разы быстрее! Но по большому счету на это адекватным людям плевать с высокой колокольни, так как js нифига не асиинхронный. JS работает в один поток. Причем в этом же потоке работает и сборщик мусора. Если он начнет все чистить - все замрет. Обычно это не сильно большая проблема но как-то забавно. Асинхронное в JS только работа с IO которая на плюсах/си реализована...

Революционности так же нету. JS на сервере не новая идея и практиковался еще лет за 5 до. Просто это была очень удачная реализация да ктому же если бы не V8 то так же все было бы не так круто.

Что до сравнения с PHP и т.д. - это инструменты для разных сфер. PHP - разработка web-сайтов. node.js - демоны, инструменты разработки, шины данных, доставка данных и т.д. Для всего остального PHP подходит больше. Есть правда пара интересных проектов главная цель которой устранить дублирование кода на сервере и на клиенте.... но подходят эти наработки пока только для очень простых проектов (хотя все относительно).

Если вас прям плющит от нового, быстрого, современного, с клевым дизайном и тоже где повлиял гугл - golang.