а теперь давайте спросим, какой проект можно считать "сложным"

ноликом ошибся)) 1000 тож канает
Он наверное имел ввиду высоконагруженный, по крайней мере я так понял

Для примера можно рассмотреть список писем любой известной почтовой службы например mail.ru :)

А у вас там разве не пагинация?

А какие технологии используете?

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

Он вообще для этого не подходит, в нём нет ничего для этого (хотя если считать, что SPA - это приложеница уровня "календарь", то подходит). Я может скажу не популярное мнение, но ангуляр кусок говна, который стал популярным из-за мощнейшей раскрутки.

kobezzza,
Что скажешь по поводу эмбера и бэкбона? Хочу вот потыкать, но не знаю стоит ли

Кони какие-то абстрактные.

Прямо как чудо лопата.

<object width="420" height="315"><param name="movie" value="//www.youtube.com/v/OL9oad4VS70?hl=ru_RU&amp;version=3"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="//www.youtube.com/v/OL9oad4VS70?hl=ru_RU&amp;version=3" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>

Тоже кусок говна, я попробовал. Поначалу еще ничего, но без связки с разными приблудами - шлак. Деревья в нем выводить аццкий ад. А в связке полный финиш. Уж лучше тогда ангуляр :)

Мало всего прочего он навязывает REST, а мне не понятно, нафига так переусложнять. Какого он вообще лезет в мой сервер со своим REST?!

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

Ангуляр:D

l-liava-l,

без

Я использую самописный mv - модель+вью (класс, либу, функцию), а ля backbone, только без ненужного мусора. Собственно глядя на него и написал.

Подходит например для:
Слайдер просмотровщик (а ля ACDSee в браузере). Для очень больших приложений конечно может и не подойдет, но для маленьких и даже средних очень удобно.

cyber,
В случае огрооомных приложений нужно очент много заниматься проектированием и архитектурой приложения, желательно чтобы там небыло ничего лишнего. А ангуляр сам навязывает ее и шанс что она подойдет для твоего приложения мал. Еще некоторые вещи сделанные через жопу.
Поэтому от него стоит отказаться если он не подходит конкретно для твоего преокта.

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

А сорри забыл, я в связке еще использую загрузчик require+tpl

Хорошо, что скажите тогда о http://www.ractivejs.org/ ?

хм, понятно спс.

С ember не работал.

Ну а backbone - это микрокаркас, который сойдёт для базиса более продвинутого решения, а как самостоятельное решение - слишком низкоуровневое.

Если говорить об SPA, то когда я начинал свой проект (а он именно SPA), то я искал фреймворк который бы мог выступить как платформа, но увы ... пришлось писать велосипед ... 7 месяцев ... там реально очень много проблем, которые на мелких приложениях не заметны, вот к примеру: перед отображением на экране фреймворк просчитывает вес будующего представления, дробит задачу на "кванты" (подобно как это делает ОС для процессов) и поэтапно во много проходов строит отображение (т.е. переодически переключаясь то на одно, то а другое), при условии, что элементы UI ничего про это знать не должны. Т.е. строится дерево блоков, вычисляются вложенные блоки, потом в зависимости от разных параметров (например наивысший приоритет отдаётся тем, кто "возможно" отобразится на экране) после всех подготовок создаётся множество "легковесные потоки", т.е. модель потоков поверх setTimeout и setImmediate и всё это чтобы просто отобразить страничку, при этом повторюсь, что для разработки фреймворк должен быть простым и инкапсулировать в себе весь этот треш.

Потом свой сборщик мусора ... короче жесть :) И самое обидно, что до сих пор приходится тратить уйму времени на всякие доработки, написание тестов, документирование (т.к. кодовая база огромная и без этого никак).

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

Стоп, для "быстро слепить" ангуляр вполне подойдёт, но ты сказал, что он "идеально подходит для SPA", а это не так :)

золотые слова! :)

LMD пробовал? :)

Хотел написать статических страниц, а на писал одностраничных.
Ангуляр вполне подойдет для задачи :
К примеру нужно сделать портфолио на 3-4 страницы , с подгрузкой страниц через ajax

monolithed, ты часто рекомендовал http://www.ractivejs.org/ , есть ли у него какие то явные минусы ?
Просто думаю попробывать.

Если ты 7-мь месяцев писал, то сколько будут писать другие)
Кроме того, не у всех есть столько времени писать инструменты/велосипеды.

Также не следует забывать, что проект (ангуляр) развивается и не стоит на месте.
Например, мне удалось на себе это почувствовать :) В хорошем смысле слова. Добавляют "приятные мелочи", улучшают архитектуру.

Я юзал ангуляр в связке с canvas, svg, яндекс картами... Работает)
Для большинства приложений (CRUD) он подходит, т.к. позволяет писать мало кода, структурирует приложение (если придерживаться его концепции), делает код прозрачным, как мне кажется, за счет MV архитектуры, компонент, модулей и прочего.

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

Не, ну успел. У меня последние два месяца вылетели в трубу. Сейчас наверстываю. Обязательно попробую.

monolithed,
Хочу использовать es6-transpiler, а он подружиться с LMD? Их подружить возможно?

monolithed, а куда termi делся? у него там баги, а он не отвечает :(

but why?!

по идее, REST - это упрощение :)

а какие ты делаешь запросы, чтобы сделать CRUD для модели? как в Yii, через запросы вида "/%model%/create"?

он ведь mvc?
а ещё другие штуки, вроде Ruby on Rais, тоже вгоняют в рамки каркаса.

имхо, запала mvc должно хватить на 99% проектов - не зря паттерн так популярен

это из-за его тормознутости?

Я поясню: много кто говорит, что Angular создан с прицелом на SPA, это даже в википедии и на их сайте написано, но складывается такое ощущение, что SPA в их понятии - это календарь или панель с табиками, а не веб-сайт. Думается мне, что они пишут его не под задачу, а по принципу "о прикольная фича, давайте сделаем".

Говоря, что Angular гавно - я имею ввиду, что он гавно для SPA, если вы мне не верите, то значит вы просто никогда не писали SPA :)

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

REST - это усложнение. Он влияет на архитектуру программы сервера.

POST более чем достаточно.

Через POST строишь приложение так как тебе нужно, делишь на блоки так как нужно, а не на PUT,DELETE ...
Хочешь сделать REST? Добавляешь в POST переменную rest - и вот тебе передача состояния, если так уж присралось. Только я ломаю себе голову уже год, со времени пробы бэкбоне и до меня не допирает в чем преимущество?

Вот пример: Есть приложение с 10 разными несвязанными блоками(которые выполняют несвязанные задачи).
делаем запрос:
block=comment&action=get
block=comment&action=delete&id=3

На сервере сразу передаем управление в нужный block и далее обрабатываем в нем. Вот зачем мне тут REST? Он есть в action и при необходимости я могу его ограничить POST, GET, PUT, DELETE, но нафига?

А в REST я сначала должен обработать сам REST, а только потом думать о том в какой block это пойдет. Как-то мне это кажется все кривым.

Я могу предположить, что существует монструозноогромное приложение, где REST будет оправдан, но честно говоря представить его не могу.

Стоп, REST - это как раз супер простая схема, когда у нас запрос передаёт некоторый абстрактный набор данных без передачи состояния и знания архитектуры сервера, а сервер уже сам решает что с этим делать, а какой протокол для транспорта используется - это дело десятое. Т.е. Gozar ты мне кажется напутал в терминах :)

Это и есть REST :) И мне сложно представить что-то проще чем REST :)

***

Альтернативой REST является подход когда используя сложный транспортный протокол можно вызывать удалённые процедуры на сервере и работать с ними, такой подход используется, например, в full-stack фреймворке Meteor.

Можно конечно создать прослойку на клиенте и прослойку на сервере, которые будут собирать и разбирать REST, но зачем? Почему я должен думать о том как данные передаются в приложении. Я что писатель протокола http? Я же не Рой Филдинг для которого возможно это было важно, мне вообще до лампочки как передаются данные, лишь бы доходили в целости. Я хочу думать о абстракции, о масштабируемости, о архитектуре, а не накладывать искусственные ограничения, а потом трахать себе ими мозг.

POST более чем достаточно. melky, Придумаешь где не достаточно, напиши.

Gozar, прочитай мой посты выше :)

POST - это способ отправки данных, а REST - это паттерн, т.е. кислое и длинное

Хз, Backbone использует REST и в нем все делится POST, GET, PUT, DELETE. Свое представление о REST я основывал на Backbone представлении. Если я не прав, ну что ж бывает.

ага, прочел, лень править пост :)

Ну дык реализаций множество. Я например использую передачу JSON и юзаю GET для получения данных, а POST для изменения.

Главный постулат REST, что нет передачи состояния и мы оперируем простым и очевидным протоколом для работы, при этом сервер ничего не знает про клиента и наоборот. А какой протокол мы используем и какой транспорт - это уже на наше усмотрение.

Что это значит? что такое состояние?

Ну имеется ввиду, что нет значения откуда был послан запрос и состояние того, кто посылал, т.е. например если мы соединимся по сокету с сервером, то сервер будет иметь этот объект "сессии" и может как-то выделять запросы конкретных клиентов.

В REST же мы тупо передаём данные и на основе переданных данных уже работаем.

ЗЫ: вот яркий пример НЕ REST - SOAP

А можно яркий пример при построении SPA? А то этот яркий пример как абстрактный конь. :)

Про состояния я не понимаю. База должна синхронизироваться с клиентом и ясен пень она ничего не знает о клиенте, да и собственно о сервере она тоже ничего не знает. Запросы к ней прилетают через прослойку(php). php тоже ничего не знает о клиенте. да и клиент о php.

А причём тут SPA? :) Может я вопрос не понял, поясни.

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

Когда ты соединяешься, например, по WebSokets, то клиент связан с вполне конкретной удалённой машинкой и эту информацию можно использовать в логике приложения (т.е. ты можешь например взять и отправить клиенту сообщение) и следовательно сложнее масштабировать, т.к. нужен дополнительно синхронизирующий кластер.

***

Синхронизация БД - это вообще из другой песни.

Ответил выше.

Хз уже как разжевать, вот абстрактный пример:

REST

Привет Сервер, дай картинку! - ОК, держи - Пока!

не REST (причём с передачей состояния)

Привет сервер, дай картинку! - Ок, держи ...

Слушай клиент, тут тебе письмо пришло и вот, зацени эту милую картинку с котиками -
О спасибо сервер, продолжай держать меня в курсе...

kobezzza,
Спасибо дошло, чат(кот.держит соединение) - не REST. Теперь до меня дошло, что backbone еще большее говно, которое лезет туда, куда его не просили. И все эти их высокопарные слова про REST бессмысленный набор слов.

Ну или надо сразу брать готовую серверную часть для работы с backbone, писать свою мне не понравилось на основе их методологии.