Сайт+Rest API

Backbone.js в точности то, что тебе нужно. Ну или Ember.js, или Sproutcore (тут на вкус).

Вот, например, сделал сегодня на Ember.js с бэкэндом на Yii: http://resurtm.kz/yii-backbone-tasks/

Контроллер прост как три рубля: https://github.com/resurtm/yii-backbone-tasks/blob/master/protected/controlle... (обычный CRUD, толстый клиент, общается сервер и клиент через JSON).

1. Pure Ajax with hash rewriting

Это оно. А пользователи то не привыкли что у них страница не сразу одним махом грузится, а потом начинает части подгружать и еще spinner-ом троллит. Меня Github этим убивает. А прикинь весь вебсайт такой?

Это оно.

Не совсем оно. Якори — это лишь айсберг. Backbone.js привносит MV* подобную структуру (смесь MVP и MVC) на клиент и получается всё очень и очень красиво и структурировано, без спагетти-кода, который возникает, когда создаёшь приложения с очень толстым клиентом на pure low level jQuery. Разница огромная. :)

А пользователи то не привыкли что у них страница не сразу одним махом грузится, а потом начинает части подгружать и еще spinner-ом троллит. Меня Github этим убивает. А прикинь весь вебсайт такой?

Да, это недостаток. Хотя, к примеру, в GMail или в Twitter меня это абсолютно не напрягает.

s/это лишь айсберг/это лишь вершина айсберга/

3. JSON + XJST

Уточню ещё чуточку: это я к тому, что под понятием «pure Ajax with hash rewriting» может скрываться как абсолютно неприемлемое ни при каких условиях говно, так и конфетка первого класса (Backbone.js, Sproutcore приложения).

А он достаточно хорошо делает этот hash rewriting?

На сайте Backbone.js есть список real world приложений: http://backbonejs.org/#examples
Список внушительный, потестить самому и ощутить на вкус найдётся что. :)

А в чём проблема? `rails generate scaffold ...` как раз так делает. К примеру такие URI как /users, /users.json, /users.xml.

А в чём проблема? `rails generate scaffold ...` как раз так делает. К примеру такие URI как /users, /users.json, /users.xml.

Проблема в том, что ты, как backend разработчик не понимаешь, чего именно он хочет. А спрашивает он про способы, как писать правильно client side консьюмер сгенерированного серверного CRUD и какие хорошие методики для этого есть, а не то, как использовать генераторы из server side фреймворков.

«типа rest» url имеет к настоящему rest очень отдаленное отношение

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

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

сейчас смотрю на restlet, достаточно интерестно

Spoutcore не понравился, как-то слишком кардинально. )

Долго выбирал между Ember.js и Backbone.js остановился на бэкбоне. С документацией получше, не пытается быть рельсами на клиента и простой как три копейки. :)

у меня на текущем проекте так и сделано. От джавы только REST API, весь UI строится исключительно Ext JS

Ext JS

Это не для нищебродов, потому не подходит

хы, не знал, оказывается наш заказчик платит за него.

На работе у меня тоже ExtJS (точнее ExtGWT), но мне не нужен app, в большей мере информационный сайт. Но я просто ищу как его сделать поинтереснее

XSLT или любой другой подобный шаблонизатор, как сервер-сайд, так и клиент-сайд. Другое дело, что сайт, сделанный как тупо морда к ресурсам, будет ужасен для опльзователя - нужна еще одна прослойка кода между ресурсом и вью. Можешь глянуть на то, что мы делали в hh: https://github.com/hhru/frontik

Вот пример применения технологии: https://github.com/AndrewSumin/hephaestus

https://github.com/hhru/frontik

Оно на сервере собирает?

https://github.com/AndrewSumin/hephaestus

А тут на клиенте?

видел как-то демку на фиддле, бекбон и амбар рядом, сетка из каких-то крутящихся фигонь, амбар раз в 10 медленней отрабатывал. выбор очевиден.

На сервере и там и там. Хотя основная заморочка фронтика в асинхроности. Все это ты можешь написать сам безо всяких фронтиков

JS клиент в браузере ничем не отличается от других клиентов, тогда проблем не вижу.

А если нужен REST и обычный HTTP доступ с броузера, тогда должно быть две точки доступа, возможно с разными путями, где один с префиксом, например /posts/1 __rest__/posts/1