Автор почитал твой обновленный ответ. Компоненты - не правильное название, можно тут запомнить два слова (Блоки кода и объекты). Объекты ты вкладываешь один в друг-друга (Называется композиция), определяешь зависимости между ними 1 к 1, 1 ко многим. На основе фабрик, конструкторов (функций, классов) - строишь порождающие паттерны. Для создания архитектуры применяешь структурные паттерны, для взаимодействия отдельных частей приложения используешь поведенческие шаблоны. Алгоритмы пишешь внутри методов отдельных функций. Событиями создаешь процессы в системе. С помощью компоновки различных приложений и общения между ними с помощью http, tci/ip, sockets, ajax, json, rest, xml, soap - создаешь так-же в простом смысле (сложную программу). Например gmail.com
Да я об этом тоже подумал, но как на php подобное сделать? Наверняка есть поддержка сокетов и в php. Еще лучше если таймеры будут выполняются отдельным потоком. Не блокирующие сокеты тоже подойдут.
По поводу jQuery - его цель DOM дерево, остальное внутри кроме sizzle, приправка к обертке $. Строить с его помощью MVC не получится никак, получится лапша код. AngularJS - это уже набор базовых классов и целый API для разделения данных от представлений не так ли? Надо зайти на сайт и покурить маны, понять. А jquery - две строчки почитать в описании апи Ajax, append. Что проще написать? Один вызов Ajax с jquery и срендерить шаблон в div или определить контроллер модель, сервис для работы с Backend? Вроде как первое попроще, но Backbone с таким же способом рендеринга и применения будет опять-же проще чем AngularJS. А модульный Backbone + Marionette RIA с транслятором (TypeScript, Coffe, etc), requireJS, browserify, grunt, bower и кучей библиотек будет куда сложнее чем коробчное решение с Angular. Но Ангуляр так-же прошивается кучей примочек как и бэкбон. Так что тут спорить нет смысла, кому что проще пусть и выбирает. Keep it stupid and simple.
Backbone вам не понравился видимо потому что коробочных решений мало. Просто кусок базовых классов для творчества. AngularJS - расширение для HTML которое вводит DataBinding и внутренний скоуп в котором и химичите. Extjs - с ним вы вроде не спорили. А я высказался исходя из объективных оценок на разных источниках инета, исходя из данных порога вхождения в отдельную технологию. Если выбрать фреймворк - это уже архитектура, то я так понимаю сложных корпоративных приложений вы не писали. И нам неизвестны критерии того что хочет автор, просто сделать CRUD операции - будет наверное одинаково легко на любом фреймворке. Построить приложение уровня хорошего desktop IDE на клиенте - это уже другой разговор. Но к сожалению я не сталкивался с ограничениями AngularJS в построении серьезных приложений, но уверен, его популярность связана с простотой применения в контексте простеньких админок. Да и видел аналоги Photoshop на ангуляре и редакторы WebGL 3D моделей. Так-же удивился что и поверх WebGl & Canvas его используют для UI игр. Но мне это ничего не говорит, я понимаю, что объективные данные о том что в Backbone порог вхождения меньше чем в Angular - ерунда, большое приложение на Backbone Junior напишет, так что его надо будет переписывать. А на Angular философия уже построенная архитектура коробочных решений уже может его спасет от критики и невозможности сопровождения. Что касается Ember, Knockout - они все поближе к Backbone.
А Symphony - это вообще огород Backend, тогда посмотрите на другого монстра - Java Spring Framework или Playframework (Scala), NET C# - будет просто в сотни раз больше объема исходников. Можно еще обсудить сколько весит строк ядро линукса :)
Считаю, что если вы не согласны с моим выводом о том что проще или сложнее, можете просто пропустить мой ответ. А кто обратит внимание и захочет сам удостовериться погуглит и найдет нужные ему тезисы в зависимости от поставленной задачи.
Почему я так написал? С точки зрения чему быстрее научить нового сотрудника. Так как использовал и то и другое, но Angular поменьше, даже исходя из количества строк исходников (jquery - до 3к, angular - 10-15k, backbone + marionette = 3k, Extjs =70k). Так понятнее?
Я обычно записываю все кнопки в массив, перед тем, как поставить класс одному элементу, убираю класс у всех. Это если надо быстро сделать. Если не быстро, надо подумать :)
Dremkin: Рад, что вы солидарны со мной по поводу того что надо на что-то переходить :) Но эта идея не менее печальна, чем организационные вопросы. На проекте остался один я, теперь еще и людей приходится искать с пока что не определенными требованиями.
Про общий скролл я имел ввиду такой юзер кейс - Есть левая навпанель допустим меню, есть region-layout (north, west, east, south) - Внутри Header и Viewer (Главный блок который постоянно меняется). Туда обычно падает (Панель->еще внутри панелей 5-> в каждой может быть таб панель, кард лайаут и кучу всего что должно тянуть общего родителя Viewport вниз). Однако есть костыль ставим на Viewport - overflowY: 'auto', autoscroll: false. Вроде работает, но при этом не получается поставить на region-layout этот скролл, что бы допустим он был от хедера и до самого конца страницы. В общем эксперементировали много... Как только не делали, заказчик хочет поведение скролла как при верстке. Нас 3 человека фронтенда, один работал с Extjs 2 года, на мои вопросы как решить вопрос со скроллом размахивал руками. В итоге вместе с руководителем разработки ПО уволился после того как завалили дедлайн.
И получилось что нам Extjs дает интерфейс, а заказчику мы должны показывать другой интерфейс который больше похож на хорошую верстку с кучей отзывчивости вплане дизайна и юзабилити. Но при этом там просто миллион функционала. Для того что бы Extjs на этот уровень вывести мы просто сутками работали и заказчик опять все завилил :) Хотя мы понимаем что там jquery + bootstrap + тут грид от Extjs вроде должно получится, а тут неплохо AngularJs DataBinding на сверстанном куске сложного дизайнаНо руководитель наш запретил использовать сторонние библиотеки. В итоге его начальство уволило.
Причем у нас были интересные ситуации когда использовали Ext.ComponentManager.create(компонент) - нужно было место для отчетов, где данные рендерятся меньше 800мс. (Много цифр, канвас, свг). Сделали вначале вложенные компоненты с минимум в себе API от ExtComponent, что-бы эти элементы находить и проставлять значения в момент рендеринга (У брайзера занимало почти 2 секунды на 20 мини вьюх). В итоге как решили проблему, взяли написали большой XTEMPLATE и руками через document.getElementById снизили время рендеринга в 1000 раз. Ушло два для на оптимизацию, а по нашим срокам это смертельное время. И это только одно такое дырявое место в нашем приложении. Особенно запоминание состояний постоянно глючит и отрисывывается как-будто с багами. Плюс надо держать 960-1920 разрешение, а дизайнер частично при проектировании UI косячил и некоторые элементы просто не вмещаются в область видимости :) Я уже не говорю о том, что когда я пришел работать проект стилизовали с помощью овверайда LESS темы скомпиленной для Extjs. В общем 60% времени уходило на заправку дизайна. Функционал как раз с помощью Extjs писался великолепно, были проблемы с РЕСТОМ, асинхронными запросами, вложенными моделями, но в итоге костылем все зарешали.
К сожалению разработка началась раньше чем проектирование UI. Поэтому пришлось тяжко.
Я рассматривал вариант чтобы рендерить тот же бэкбон внутри Extjs и использовать Jquery в рамках бэкбона. Но наш руководитель зарубил все попытки сторонних либ. В итоге Генеральный директор его уволил :) и теперь про экст джс слышать ничего не хочет.
Нам в начале тоже было сложно представить. Опишу некоторые из проблем, общий скролл на страницу, вложенные в таблицах грид (Сложные касотмные компоненты) - найти ячейку в грид и вставить в нее что-то (целый ад), слишком сильная по дизайну и функционалу кастомизация TreeGrid, реализация сложных меню, элементов для подстветки выделения UI элементов. Ограничения по дизайну нужно учитывать компоненты Extjs либо писать свои. Я за 7 месяцев написал около 40 компонентов, мы очень сильно изменили представление дизайна в Extjs. Но в итоге в будущем предвидятся слишком сильные изменения от дизайна к дизайну, время на разработку слишком большое. Пришли к выводу что проще написать не на Extjs и время на смену дизайна и элементов функционала и UI будет меньше.
Модульная верстка хороший способ инкапсулировать логику в отдельные компоненты. В целом не стоит задачи делать миксины разных контролов внутри сборного компонента, но идея хорошая (Я про БЭМ).
По поводу поиска по ID (Как использовать идентификаторы, как у jquery $('#')) - с ангуляр JS я так понимаю это не нужно, так как директивы сами кладут все в общий скоуп.
Спасибо за раскрытие темы по поводу вложенности директив в друг-друга, я так понимаю будет удобно и для Backend разработчиков, взял кусок HTML и вставил, данные сами по REST загрузились - все работает.
Думаю что не стоит торопиться с выбором Backbone и действительно две недели потратить на AngularJS.
Опасения по поводу html атрибутов есть - могу привести аналогию с Backbone, пример рендеринг коллекции юзеров. При рендере для каждого назначается свой обработчик, например по клику открывает модальное окно (пробрасывая параметр user id). На него подписываются куча других UI элементов - какие нибудь уведомления и прочее. Не понимаю как происходит рендеринг всего этого в AngularJS. Если в Backbone логика отрисовки ложится на метод Render у View, то тут понятен процесс: Ручками вызываем рендеринг или подписываемся на изменения в модели и рендер сам происходит - шаблон превращается в стрингу (HTML с проставленными переменными). У другой VIEW вызываем переписанный метод Append, onAppend срабатывает удаление прошлой View, срабатывает метод ОнДестрой и отписывает нужные события. Вот как происходит подобное дело внутри AngularJS - к сожалению не знаю, но логика подсказывает что похожим образом.
Jade, Haml - интересное решение, использовал на прошлом проекте, когда привыкаешь смотря на код видно сразу только нужное :)
Browserify - смотрел, по синтаксису понравился больше чем requireJs. ES6 + traceur - не встречал подобное решение, спасибо рассмотрю. По поводу AngularJS - при рассмотрении фреймворка показалось, что разработка сильно упрется в атрибуты html, сложно представлял как разбить компоненты на шаблоны (например HandleBars). Как я понял создается отдельный div-wrapper, у него и контроллер и модель внутри, классы CSS для оформления, ID - для поиска. Сложно ли в данном случае делать множество вложенных в друг-друга view?