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

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

Перевод статьи «Building robust web apps with React: Part 1, in-browser prototypes», Matt Hinchliffe

От переводчика: это первая статья из цикла «Building robust web apps with React».
Переводы:

• Построение надежных веб-приложений на React: Часть 1, браузерные прототипы
• Построение надежных веб-приложений на React: Часть 2, оптимизация с Browserify
• Построение надежных веб-приложений на React: Часть 3, тестирование с Jasmine
• Построение надежных веб-приложений на React: Часть 4, серверная генерация

Когда я смотрю на то, как устроены браузеры и протоколы, на которых работает веб, мне становится как-то тревожно. Есть столько всего, что может и, обычно, идет не так, что становится удивительно, как хоть что-то из того, что мы пишем, вообще работает. Надежность «вопреки всему» происходит от отказоустойчивости и обратной совместимости, которые укоренились в ключевые части веб-стека. Браузер всегда сделает все возможное, чтобы отобразить, что-то полезное, будь-то парсинг плохо написанного документа, в котором невозможно получить зависимости, или, который на 10 лет устарел.


404PageFound содержит до сих пор работающие сайты, созданные еще в 1993 году.

Работая над одним большим проектом, мы с напарником задумались над тем, чтобы автоматизировать процесс сбора спрайтов на проекте.
До этого спрайты собирались ручками или с помощью онлайн сервисов, что отнимало достаточно времени.
Проект уже собирался Gulp'ом и было принято решение найти адаптированный под него сборщик спрайтов.

Одним солнечным весенним утром, мне пришла в голову замечательная идея — заняться изучением популярной библиотеки RequireJS. Я уже давно читал много хорошего и о простоте использования и о преимуществах, которые она оказывает при использовании в проектах. Поэтому и подумать не мог, что подключение RequireJS к модульному проекту на Backbone может вызвать столько проблем. Я потратил два дня на то, что должно занять не более часа. А если у разработчика нет этих двух дней? Вот и решил поделиться с другими своим опытом, чтобы сэкономить время и нервы.

Привет Хабра!

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

Многие веб-разработчики не любят писать тесты, и я не исключение. Но тесты уменьшают количество багов и если ваше приложение становится все больше и больше, от тестов вам не уйти. К тому же в мелких компаниях я часто встречал джуниоров, которые вообще предпочитают писать код в текстовых редакторах (это увеличивает количество ошибок, т.к. редакторы не проверяют код). Как же начать потихоньку использовать тесты без боли и страданий?! Выход есть — подключить автотесты.

Суть поста на картинке слева. Это то, чего мне раньше не хватало в повседневной работе. Хотелось иметь инструмент, которым можно очень просто потыкать в код и сделать общее заключение о его живучести и пригодности.