Все правильно я преподношу. Это надстройка над JS которая позволяет в рамках очень больших проектов (А angular это очень большой проект сам по себе) улучшить управление сложностью, получить статический анализ и т.д.
Для людей которые боятся TypeScript в Angular2 (а их немало, люди просто не знают что это такое) следует как раз таки указать, что если убрать информацию о типах, то это все тот же EcmaScript (тобиш JS). И это основной поинт. Со временем возможно они начнут прописывать типы и т.д. Но на некоторых проектов это ненужный оверхэд.
И да, то что вы описали это плохой пример смешивания концепций а не "JS плохой".
а я вот не думаю что уже есть смысл учить первый ангуляр. Во всяком случае документация к первому ангуляру будет вредной для перехода на вторую версию.
k-2: а у меня сложилось впечатление что вы не те уроки смотрели или же масшабы ваших задач не совсем укалываются в те задачи для которых нужен angular.
js + jquery - это круто и можно все сделать на нем (особенно если заюзать MVVM библиотеки, тогда и jquery не нужен), но только это не всем дано. Подавляющее большинство разработчиков зажатое в рамки цикла разработки на выходе будут получать кусок неподдерживаемого треша и неподдерживаемой лапши.
angular это обычный инструмент, и что бы с ним работать эффективно его надо знать. Ну и да, для маленьких проектов это оверхэд.
copal: ну и опять же никто не мешает вводить поправки самому, не тупо лепить 1000 милисекунд постоянно добавляя доп время, а скажем смотреть когда нам надо вызвать функцию в следующий раз и тогда задержки будут еще меньше.
copal: о какой синхронизации и с каким сервером вы говорите?
В JS все дико просто. setTimeout - это просто возможность положить вызов чего-либо в очередь. Это не штуки вроде прерываний и т.д. То есть если мы выставим setTimeout(fn, 0) и потом влепим бесконечный цикл, наш таймаут никогда не вызовется так как он следующий на выполнение в очереди, а нынешний кусок потока выполнения не собирается заканчивать выполняться.
copal: предположим что мы выставляем таймер каждые 1000 милисекунд. То есть за 10 минут у нас будет 600 таймеров.
Предположим что в промежутке у нас таки что-то происходит, идет перерисовка DOM элементов, мы скролим страницу и т.д. То есть мы тратим процессорное время на всю эту ерунду. Это смещает наш таймер. Где-то больше где-то меньше, ну и не забываем о логике между срабатыванием таймера и установкой нового. То есть у нас есть целая куча различных вещей которые жрут CPU, есть очередь событий которые надо обработать (event loop), и наш теймер просто помещается куда-то в эту очередь.
В итоге это нормально что между срабатываниями кусочков кода из event loop происходит разброс в ~30 милисекунд в зависимости от производительности браузера (на мобильниках все будет совсем плохо).
Алексей Максимов: и? у вас есть текущее время, у вас есть время события. По таймеру мы только обновляем значение, но мы не полагаемся на таймер. Мы просто вычисляем значение по изменению.
Денис Рыбин: вы стучитесь на несуществующий хост. Ну то есть вы делаете вызов amOnPage а дальше надо смотреть настройки и куда оно на самом деле шлет запрос.
copal: ну вы сами захотели изоморфности. Для изоморфности у вас все компоненты и так должны быть stateless а меняться должно состояние которое в них прокидывается. В этом ключе вам ничего переучивать не надо, просто не формируете состояние больше чем нужно, генерите первый снэпшет дома и отправляем все на клиент.
capscom: не особо. Смотря как делать, у меня все эти данные (что чувак может) зашиты в JWT токен. Прятать кнопки что бы не давать чуваку что-то делать - наука не хитрая. Пишем директивку для этого или вообще на уровне загрузчика темплейтов все делаем.
