# Мотивация

## Простота

Всем нам нравятся простые инструменты. Сложность убивает. Она делает наши жизни сложнее, а кривую обучения — более отвесной. Программисту необходимо знать, как вещи работают. Иначе они чувствуют себя неуверенно. Если мы работаем со сложной системой, появляется огромный разрыв между «я этим пользуюсь» и «я знаю, как это работает».
Именно по этой причине мы в некоторых своих проектах на ряду с  [React]() и [Angular]() выбираем в качестве инструмента([Backbone.js](http://backbonejs.org/)), который вносит минимальные требования и ограничения при написании кода, по сравнению с другими известными фреймворками.

Ведь под разные требования необходимо использовать разные инструменты.

И основным критерием явояеться то, что по сути **Backbone.js** можно назвать библиотекой а не фреймверком. Как написали в одном коментарии "Backbone.js не решает за меня как мне писать моё приложение".

## Template

Еще одной причиной выбора **Backbone.js** являеться работа с шаблонами. Мы часто пользуемся шаблонами. И делаем мы это из-за необходимости разделять данные и разметку HTML. Вы можете возразить и упомянуть JSX, как HTML подобный синтаксис, компилируемый в JavaScript. Где разметка и код находятся в одном файле. Основным приемуществом которого являеться возможность непосредственной *javascript* и верстки, что, например, позволяет вставлять ссылки на функции, компоненты и переменные прямо в шаблоне функции `render`.

Но это не единственный способ, есть к примеру **.ejs** шаблоны которые позволяют встраивать исполняемый *javascript* непосредственно в шаблоны. А так как любой шаблон по факту являеться функцией то выполнение этой функции в контексте вашего `view` автоматически даст возможность упомянутой выше интеграции. Но кроме этого, разделение данные и логики отдельно от верски, являеться необходисомтью, так же как и разделение css от html(оформления и представления), потому что это являеться разделением представления логики и самого представления. Другое дело, что мы не хотим иметь дело с загрузкой строк в HTML или с передачей данных в специальные функции, или же мы хотим быть избавлены от непосредственной работы с DOM. И это одна из причин по котором мы хотим улучшения **Backbone.js**.

## Dependency management

Но возвращаясь к разделению шаблона и логики представления: Управление зависимостями — важная задача в процессе разработки. Обычно мы зависим от внешних функций, модулей или библиотек. Фактически, мы всё время создаём зависимости. Мы не пишем всё в одном методе. Мы разносим задачи приложения в различные функции, а затем их соединяем. В идеале мы хотим инкапсулировать логику в модули, которые ведут себя как чёрные ящики. Они знают только те детали, которые касаются их работы, и больше ничего. И в случае разделения темплейта и логики представления это тоже  - управление зависимостями.

Другой тип управления зависимостями это инъекция различного типа кода, тех же `view` шаблоны. Например так как это сделано с инъекцией компонент в шаблоны ReactJS, это удобно и этого не хватает в **Backbone.js**, и поэтому нам тоже захотелось это исправить.

Но вернемся от того что не хватает в **Backbone.js**, к тому почему мы его выбрали:

## Открытое API  

Большая часть фреймворков предоставляют API к своей базовой функциональности. Но при помощи этих API можно добраться только к тем частям, которые поставщики посчитали нужными для нас. И вот тут может понадобиться хакерство. Мы же хотим использовать **Backbone.js** еще по одной причине: так как они имеет минимальный объем, полностью документированного, исходного кода, что исключает появление любого типа "магии". 

Кроме того он достаточно известен, зрел и существует просто огромное количество стороннего кода, поддерживающих **Backbone.js**, и примеров как рекомендуеться использовать его в различных ситуациях.

## Other reasons

Кроме указанных ранее причин, существуют еще достаточно:

* в нем есть всего 4 стандартных абстракции, которые понятны всем - Models, View, Collections and Events
* "не лезет в мой html" - есть возможность использовать любую 3-d party library, для любой задачи
* огромное комьюнити - есть расширения на все случаи жизни
* идеален для JSON и REST
* малый размер - 7.6kb (Packed and gzipped). Некоторые указывают на зависимости **Backbone.js** от других библиотек, но давайте будем честными - много ли вы встречали web проектов, которые не используют сторонние библиотеки в том числе и **jQuery**
* There's More Than One Way To Do It - да это спорный момент, но мы никогда не утверждали что наше решение идеально, и мы его используем во всех проектах.

## What is missing ?

Не стоит забывать об недостатках **Backbone.js** и именно их мы попытались решить:

* необходимость непосредственной работы с DOM: Мы пытаемся решить данную проблему, но нет RAD.js не запрещает вам непосредственно работать DOM, это было бы противоречием с основной идеей: "не ограничивать разработчика в используемых инструментах". Мы убираем ее необходимось, но оставляем ее возможность
* производительность: стандартный движок шаблонов в **Backbone.js** не выдерживает никакого сравнения в быстродействии обновления DOM  с последними *javascript* фреймверками. Поэтому в качестве движка обновления DOM в RAD.js был применен [incremental-dom от Google](http://google.github.io/incremental-dom/#about), об быстродействии которого вы можете судить по [независимым тестам](https://auth0.com/blog/2016/01/11/updated-and-improved-more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/). 
* `nested views` работа с ними достаточно затруднена в **Backbone.js** и этого реально не хватает

## Основная цель

Решить проблемы с недостатками в уже знакомом и удобном инструменте, дать возможность использования в современных условиях.
