Станислав Романов

Я использовал.

Как он видет с клиентом?
Какой % юзекров он охватывает (поддержка) ?

IE10+ caniuse websockets

Как быть с теми у кого он отключен, не доступен, и вообще нету поддержки ?

Я делал так, у меня фронтэнд на Ember.js, если сокеты поддерживаются, включается адаптер который тянет API через сокет, если нет - стандартным RESTful.

На бэкенде пишите так архитектуру чтобы контроллеры отдавали только массив готовых данных, а middleware уже подготавливали ответ в нужный формат в зависимости от того, кто инициализировал запрос, RESTful или websocket.

Такой подход минимизирует дублирующий код.

Какие проблемы могут возникнуть при работе с ним ?

У нас с PHP были проблемы. Один pid не имеет доступа к другому pid. Соответственно чтобы процессы могли общаться с друг другом нужно было поднимать еще один внутренний сокет на сервере. PHP :)

Отсюда:

Вид и компонент довольно похожи друг на друга (по правде сказать вид это родительский класс компонента). Вид и компонент оба имеют свой собственный шаблон. За видом и компонентом находится свой собственный объект. Разница заключается в двух ключевых моментах. Во первых обработка событий — компонент сам обрабатывает именные события а вид просто напросто отдает их родительскому шаблону который в свою очередь отдает их контроллеру. Во вторых окружение — компонент полностью изолирован и может работать только с объектами которые вы ему отдадите; вид в свою очередь имеет доступ ко всем объектам доступным родительскому шаблону. С точки зрения контекста родительского шаблона вид имеет доступ к модели и контроллеру но имеет свой собственный вид. Компонент более изолированный и не имеет доступ ни к чему.

> Ещё поразили последние приписки типа "короче с версией 2 теперь используйте в 90% компоненты и не парьтесь", встаёт вопрос а вид тогда на что теперь?

Ну я не думаю что прям вот так откажутся от контроллеров и видов, так что в 10% тоже можно не парится.

Да ну, какой Angular. Ember.js хорош, но под него желательно заточенный бэкенд работающий по jsonapi.org. Если у вас с этим проблем не будет, берите его.

> EmberJS больше нравится из-за MVC более явного. Но почему такой большой - 300kb.
Уже давно не аргумент, у меня один файл фронтэнда = ember.js + ember-data + все зависимости + ~10 различных плагинов (валидация, авторизация, momentjs и тд.) + предкомпелированные шаблоны всего сайта, весят около 1 мб, но сервер отдает gzip, который пожат раза в 3 и выходит не страшно.

Начать можно с Backbone, но чистый он уже так широко не используется, в любом случае придется изучить что-то серьезней, так что Marionette тоже хороший выбор.

Привет.
https://github.com/mgenev/nodember ? На discuss.emberjs.com время от времени появляются вопросы какой backend для Ember лучше. Чаще всего фавориты ROR || Sinatra, Django Rest Framework, Sails.js.

PHP никто не упоминал, но думаю Laravel 4-5 хорошо подойдут. Symfony 2 точно нет.

Все дело в том что ember-data организовывает REST API по принципам описанным в jsonapi.org и вроде как нет смысла эти принципы переопределять, там все довольно продумано и гармонично. На сайте есть раздел со списком библиотек поддерживающих jsonapi.

Мои ИМХО что будущее крупных веб-приложений все же за websokets, а не за http, поэтому я потихоньку посматриваю в сторону GO, но про него сказать ничего не могу.

Update: 07.03.2015

Нашел sanestack.com, Ember.js + Sails.js

Используйте SQLite. Картинки и текст можно хранить + система транзакций на случай падения приложения + если нужно можно зашифровать данные.