Pull to refresh

Comments 22

Не нужно, всё-таки, переводить дословно singleton и helper. Эти термины давно и успешно транслитерировались.
Поправил, спасибо.
стоит использовать Ember, который сразу предлагает производительность и низкий порог вхождения для разработчика

Чего-чего? Я недавно начал изучать Ember (сам пишу на рельсах) и это просто ад для новичка. С каких пор роуты рендерят темлейты и возвращают модели? Нафига вьюхи и где разница между ними, компонентами и темплейтами? А теперь еще контроллеры захотели убрать. Что за каша, зачем так усложнять? Я и так долго думаю в какие части этого эмбера засунуть нужный кусок кода и откуда что доступно. Простые вещи превращаются в часы планирования. Может быть со временем привыкнешь (как и ко всему) и не будешь думать куда что написать, но говорить что эмбер имеет легкий порок вхождения — это эребор.
> С каких пор роуты рендерят темлейты

Не могли бы вы подробнее остановиться на этом моменте? Это ведь довольно распространенная практика что за путём регистрируется лишь шаблон.
Спасибо за ссылки, но что плохого в том что «роуты рендерят темлейты»?
Это отличается от MVC, где за это отвечают контроллеры. Многим это не нравится, так как предлагается другой подход, причем контроллеры вообще хотят убрать из Ember заменив на компоненты.
Подробнее тут — Контроллеры
Ничего подобного, отличие лишь в том что входной точкой является шаблон. А шаблон может состоять лишь с одного компонента, например
<Users/>
. Далее вызывается контроллер «Users» и далее по старой, или вашими словами — привычной, схеме. Такое поведения на порядок лучше, чем прямой вызов контроллера «Users», так как шаблон разрешает создавать композицию из контроллеров и много прочих классных штук.
так как шаблон разрешает создавать композицию из контроллеров

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

> для маршрута может быть только один соответствующий контроллер
Это если только жестко привязываться к «Роут-Контроллер» архитектуре, но достаточно ввести между ними шаблон и уже можно комбинировать. И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.
И именно такой подход набирает популярность, так как он сочетает в себе и «Роут-Контроллер» вариант, и композицию.

Потом уходит само (ненужное здесь, по большому счету) понятие «контроллера» и это просто называется компонентом :)
Ну как же, контроллер и компонент это разные вещи. Компонентом называют законченную единицу интерфейса/приложения — и он как раз состоит из контроллера, или шаблона, или только модели, также может другие ресурсы и компоненты включать в себя. Вообщем компоновать все это вещи можно как угодно. Здесь «компонент» был назван в контексте HMVC.
Дурная практика, на самом деле. Состояние в урле — это такое же состояние, как и состояние в локальном хранилище и состояние на сервере. В идеале работа со всеми этими состояниями должна быть единообразной. Более того, зачастую то какую страничку показать зависит сразу от нескольких типов состояний (конфиг пользователя с сервера, урл с переопределениями, локальное хранилище с теми данными, что не хотелось бы держать в урле).
Вовсе нет. Шаблон в данном случае как middleware между роутом и контроллером, смотрите пример выше про Users. А всё вами описанное можно реализовать или «по-старинке» или же через композицию. Последнее намного удобнее.
Я не про шаблоны в данном случае, а про роуты. Состояние UI зависит не только и не столько от URL. Яркий пример — позиция проигрывания видео на вытрубе. Сохраняется в локальное хранилище, но может быть перегружена через URL.
Вы меня запутали) Изначально обсуждалась тема, что плохого в том, что «роуты рендерят шаблоны». А если говорить лишь о URL, то разумеется не всегда возможно, или вернее сказать, не всегда целесообразно, хранить состояние приложения в путях.
Я к тому, что роуты — это довольно опциональные штуки и странно на них завязывать ядро фреймворка. Всё же это задача контроллера (пусть и в варианте сервиса или метода компонента) посмотреть в различные состояния и решить что и как рендерить.
В сочетании с паттерном DDAU и механизмом визуализации Glimmer разработчики Ember изначально имеют в своем распоряжении и производительность и эффективность.
Надеюсь они сотворили там чудо, ибо первая версия в два раза медленнее даже ангуляра: nin-jin.github.io/todomvc/benchmark
Кто бы написал ToDoMVC на Ember2?
В Ember 2 производительность хорошо подтянули.
Свежее сравнение Ember 1, Ember 2, React и IDOM можно посмотреть в этом обзоре (En).
Судя по графикам, еле-еле догнали React, который тоже не особо блещет производительностью. Впрочем, от модели виртуального дома лучшего наверно уже не добиться.
Есть предложения, как сделать быстрей? Jin быстрее React?
Да, отказаться от виртуального дома в пользу прямого точечного изменения реального. В тесте выше раза в два быстрее, angular light и vue вообще в 3.
Only those users with full accounts are able to leave comments. Log in, please.