Comments 21
Бэкбон — это не фреймворк. Понимаю, что это следует сказать автору статьи, но зачем уж делать переводы таких статей?
Ох, как хорошо встретить человека который это понимает и уже отпостил за тебя :)
К слову:
Есть такой сайтик — backplug.io на котором есть куча плагинов в том числе включащих поддержку two-way биндинга. Бекбон распределенный инструмент, как и нод. Он из коробки не предоставляет вам больше чем несколько логических структур. Я не считаю недостатком, что у него нет структуры. Это плюс, причем большой. Во многих кейсах надо минимальная абстракция и полный котроль на ДОМом. Но хотя есть марионет, который даст вам то, что нужно в виде фреймворка.
Что косаемо тестирования и компонентов. Используете require и модули будут вам компонентами. С тестированием тоже проблем не наблюдается.
К слову:
Нет поддержки двусторонней связанности данных, то есть вам придётся писать много вспомогательного кода для обновления вида при изменениях модели, и для обновления модели при изменениях вида.
Есть такой сайтик — backplug.io на котором есть куча плагинов в том числе включащих поддержку two-way биндинга. Бекбон распределенный инструмент, как и нод. Он из коробки не предоставляет вам больше чем несколько логических структур. Я не считаю недостатком, что у него нет структуры. Это плюс, причем большой. Во многих кейсах надо минимальная абстракция и полный котроль на ДОМом. Но хотя есть марионет, который даст вам то, что нужно в виде фреймворка.
Что косаемо тестирования и компонентов. Используете require и модули будут вам компонентами. С тестированием тоже проблем не наблюдается.
По моему подобных статей на хабре с десяток, как-то не актуально уже такое видеть здесь в очередной раз…
React + Flux передают привет всем этим технологиям.
А причем здесь хаб jQuery?
JS – язык однопоточный
А как же Web Workers?
Проблема в том что Web Workers используется только в очень тормозных задачах — например отсортировать массив из 10к элементов в фоне что бы у человека не тормозил сам браузер. Так он очень редко используется в повседневных задачах — нет смысла гемороиться с многопоточностью пока хватает скорости работы, чего в большинстве случаев достаточно. Либо где-то что-то используется неоптимально.
Примеры — сложные вычисления в рекурсии, некоторые варианты с графикой(когда нужно много чего посчитать как можно быстрее) и т.п вещи.
Примеры — сложные вычисления в рекурсии, некоторые варианты с графикой(когда нужно много чего посчитать как можно быстрее) и т.п вещи.
А вы посмотрите на модель программирования, которая используется в Web Workers. Эти самые воркеры не способны использовать переменные из основного потока. Вся коммуникация основного потока строится по типу — отдали объект-параметры, получили объект результат в callback`е. Причем callback исполняется в основном потоке.
Благодаря такой модели, парадигма программирования на js не меняется. Не нужно вводить никаких примитивов синхронизации и прочих радостей, присущих многопоточным языкам.
Потому смело можно говорить, что js так и остался языком с одним потоком
Благодаря такой модели, парадигма программирования на js не меняется. Не нужно вводить никаких примитивов синхронизации и прочих радостей, присущих многопоточным языкам.
Потому смело можно говорить, что js так и остался языком с одним потоком
Backbone
1) Нет поддержки двусторонней связанности данных, то есть вам придётся писать много вспомогательного кода для обновления вида при изменениях модели, и для обновления модели при изменениях вида.
2) Виды в Backbone напрямую манипулируют DOM, поэтому их сложно тестировать и сложнее повторно использовать.
1) this.model.on('change', this.render, this); Вуаля — при изменении модели будет рендерится заново вьюха(при условии использования шаблонов), примерно с таким же успехом как и в Angular. С обратной связью(вью->модель) немного сложнее, но обычно это всё дело привязано к кнопке или действию. Под кнопку всёравно писать код что там что там ибо нужно сохранять на сервер в большинстве случаев. Действия могут обрабатываться по правилам и, соотвественно, можно не писать под каждое поле а обойтись универсальной функцией, где имя поля ввода будет действительно что-то значить.
2) Они не напрямую манипулируют DOM, они используют ссылку на кусок DOM'а, и их легко использовать повторно — достаточно сделать extend и внести минимальные правки(например изменить название загружаемого шаблона, у вас ведь он в свойствах вьюхи находиться?) + добавить/изменить/заекстендить ивенты. В итоге единожды написанный код у меня используется с минимальными правками в 2-3 представлениях.
И почему в жирнючие минуса Angular'а не внесли его отстойный вариант «улучшения» HTML? Такое чувство что опять вернулись во времена onclick прямо на элементах. Ужасно сложно дебажить логику которая скрыта за шаблонизатором.
Про недостатки Embera и его script. Ребятки а вы что, requireJS не используете? Он тоже «засоряет». Не вижу проблем.
Backbone предоставляет не минимум — Backbone предоставляет достаточное количество инструментов что бы построить с помощью них что угодно, включая свои инструменты. Если вам нужна скорость разработки — взгляните на фреймворки построенные на библиотеке Backbone — например Чаплин или Марионетку.
>> И почему в жирнючие минуса Angular'а не внесли его отстойный вариант «улучшения» HTML?
Потому что для кого-то это не минус?
Потому что для кого-то это не минус?
Ну не спорю, конечно для разработчиков времён onclick на элементах это может быть и не минусом, но остальной мир двинулся вперёд — и весь этот ng-мусор никакой полезной нагрузки для парсера и рендера DOM'а по HTML не несёт. По факту angular сделал браузер-в-браузере — сначала сам смотрит, потом браузеру отдаёт. Причём на любой чих и без альтенратив — он просто так работает. Вам не кажется этот способ — костыльным?
Оригинальная статья очень старая, и многие пункты вообще неприменимы сегодня.
Например, аддонов у Эмбера уже больше 1000, HTMLBars уже давно в релизе, а в бете его дальнейшее развитие — Glimmer. Наверняка по другим фреймворкам ситуация похожая.
Например, аддонов у Эмбера уже больше 1000, HTMLBars уже давно в релизе, а в бете его дальнейшее развитие — Glimmer. Наверняка по другим фреймворкам ситуация похожая.
как-то странно что Knockout не включили, он намного ближе к Angular чем остальные два.
Я просто оставлю это здесь:
www.meteor.com
www.meteor.com
Какого года статья? По Ember информация совершенно неактульная. Количество аддонов перевалило за тысячу, и Ember давно не добавляет script-элементы в DOM.
Некоторое время назад я сравнивал Ember с Angular и Backbone, описал личный опыт: habrahabr.ru/post/255769/#comment_8376441
Некоторое время назад я сравнивал Ember с Angular и Backbone, описал личный опыт: habrahabr.ru/post/255769/#comment_8376441
Единственная жесткая зависимость у Backbone это Underscore (в статье добавили jQuery/Zepto), в связи с чем он самый легковесный
Прочел, и сложилось впечатление — angular красавчик все остальное так себе, надоело. Надеялся что что то актуальное, полезное… но очередная статья восхваления.
Зы: Ожидал от статьи типа: Использовали в проекте все 3 фремворка/библиотеки — вот такие косяки, вот такие преимуществ…
Зы: Ожидал от статьи типа: Использовали в проекте все 3 фремворка/библиотеки — вот такие косяки, вот такие преимуществ…
Handlebars загрязняют DOM множеством тегов
Помоему не правильно либо переведено, либо сама статья написана корява. Создается впечатление, что handlebars генерирует кучу тегов script. Но это не так. Для имплементации темплейтов необходимы теги, в которых пишутся темплейты. Но это к слову не достаточное условие. Можно вполне себе прекомпилировать темплейты в полноценный javascript на этапе компиляции остального javascript'а. Все равно вероятнее всего кто-то использует coffescript, да даже просто конкатенация скриптов. А прекомпиленным темплейтам не нужно лишний раз компилиться в рантайме. Так что этот минус надуманный, а вот реальный минус, так это действительно гайды, отстающие от билдов. Но вообще всем советую даже ради интереса попробовать Эмбер, очень простой в освоении и красивый фреймворк.
Sign up to leave a comment.
AngularJS против Backbone.js против Ember.js