JavaScript встречает разработчиков асинхронностью можно сказать чуть ли не с порога. Начинается все с DOM-событий, ajax, таймерами и библиотечными методами, связанными с анимацией (например jQuery-методы fadeIn/fadeOut, slideUp/slideDown). В целом, это все не очень сложно и разобраться с асинхронностью на этом этапе не представляет проблем. Однако, как только мы переходим к написанию более или менее сложных приложений, в которых комбинируется все вышеуказанное, асинхронный поток может сильно затруднить понимание происходящего в коде. Цепочки асинхронных действий, например, анимация > ajax-запрос > инициализация -> анимация, создают достаточно сложную архитектуру, которая не подчиняется строгому направлению «снизу верх». В этой статье я намерен рассказать про свой опыт преодоления трудностей связанных с асинхронным JS.

Многие JavaScript-фреймворки предлагают свое представление о том, как должен выглядеть код. Более того, речь идет не просто о стиле, речь идет о способе написания сценариев. Это обусловлено практически абсолютной демократичностью JavaScript, да-да, именно таким является мультипарадигменный язык с С-подобным синтаксисом, прототипным наследованием, динамической типизацией и реализацией разнящейся от браузера к браузеру. Поэтому, когда речь идет о test-driven JavaScript я понимаю, что речь идет не просто об особом стиле программирования, но об особых технических принципах для особого фреймворка позволяющего тестировать JS приложения.

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

Внимание: длиннопост.

Часто, при создании достаточно сложных приложений на JavaScript наступает тот момент, когда становиться совершенно непонятно почему приложение перестало работать как надо, или наоборот вдруг заработало. Cвязей между элементами приложения становится так много, что уследить за ними даже с хорошими дебаггером очень трудно. И вот диллема: с одной стороны есть хорошо известная методика создания приложений на JS, столь привычная и глубоко описанная, что недостатков мы уже как бы и не замечаем. С другой стороны есть масса библиотек предлагающих нам перейти на другую сторону попробовать что-то новое. К таким библиотекам относиться и Bacon.js, предоставляя реализацию FRP на JavaScript.