Так на чём в итоге делать SPA?
 

Хочу сделать SPA. Огромное количество фреймворков, глаза разбегаются, а выхлопу нема. Помогите пож определиться )

Если много вариантов, было бы круто развернуть что-то функционально-реактивное, вместе с React

Или просто бахнуть NG-APP и не париться? темы l-liava-l пугают)

что вообще на бекенд брать?

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

В моём понимании - это один index.html (поэтому и "одностраничное" приложение). все остальное переводится редиректом на index.html

да, собираюсь по кусочкам собирать. только нифига не понятно, какие кусочки брать) слишком их много

melky, Чем чаще пишу на ангуляре тем больше понимаю что он не подходит для такого.
Хотя там можно делать связку с react, даже модули есть уже написанные. И бахать все где не нужны обсерваблевымымвыемые элементы на реакте:)

А мне нравиться то, что я сейчас пилю.

html отдельно, разметка отдельно, поведение элементов отдельно, стили отдельно, модель отдельно. Самое то для SPA.
Сыровато и приходиться на лету править, но зато чувствуешь себя человеком. Главное правильно разделить задачи и не лезть костылями в чужую зону деятельности. И чем больше напишу, тем быстрее будет создаваться следующее, т.к. остаются полноценные рабочие элементы с гибкой настройкой.

Тоже поиграюсь, когда время появится.

Ну это как бы логично) Просто панелька с табами, которые асинхронно бегают или соц сеть - разные вещи, а соответственно разный подход, т.е. задача рождает архитектуру, а не наоборот.

Ну что для SPA главное? Роутер и шаблонизатор. Роутер в backbone приличный, шаблонизатор удобно такой, чтобы предварительно компилил шаблоны на сервере в яваскрипт функции, например snakeskin :)
Или так уже не модно?

Не делать SPA. Зачем оно?

Он хотя бы пусть документацию дочитает :)

последнее время меня преследует агрессивная реклама продуктов фирмы kobezzza :D

Или так)) Я пишу код, а времени мало) Все учу в процессе

Фак ты мне самооценку понизил

:D

Ну ладно fest jade :D

я не против :) Он нормальные вещи делает. Хуже было бы, если это была реклама UI :D

Смотри:
1. есть жуквери, на нем "писать легче", чем на чистом жс, поэтому легче наговнить. И многие сразу мнят себя гуру яваскрипта
2. есть ангуляр. На нем еще легче писать (границ еще меньше), чем на жуквери, следственно, наговнить еще проще. И большинство думает: "ща возьму ангуляр и сразу стану супер герой клиентской разработки. Все бабки мои, дедки и телки тоже. Не хочу ничего знать и думать тоже не хочу." Результат - говно на говне в говне :)

ещё разделение кода по модулям и управление их загрузкой, инициализацией и связями (сообщениями)
. наверное)
кстати ещё нужно не забыть про индексацию (я про чудо трюки индексации AJAX сайтов от YA, GOOG). но тут вроде все могут рендериться на сервере, верно?
мы в amix видели этот проект, нет?тож слыхал. думаю даже не начинать делать на нёмтребование заказчика и ... по мне, геморно использовать мощные фронтенд фреймворки вместе с многостраничной структурой. с одностраничным легче - всё в одну кучу бандлером намешал и пусть оно само там асинхронно лениво инициализируется, а ты себе знай код пиши))):lol: да ладно, чего уж )

lmd

хз наверное sitemap с ссылками на серверную версию в robots.txt указывают

видол. есть ещё свежий Webpack для ленивой сборки картинок и всего что угодно
вопрос в том, можно ли каждый FW отрисовать на сервере. если есть, но нет проблем)

fj на гите залита как рабочая недоальфа и без нормальных примеров и пояснений. Также там недописан деструктор и правильная работа с вложенными шаблонами при работе с методами элемента. Будет :)

Смысл такой.

Сначала добавляем шаблон html и методы работы с этим шаблоном (элемент b с текстом и данными пользователя)

addElement({ b: {
  tpl:'<b name='{data.name}'>{text}</b>',
  methods: {
  remove: function(){},
  setText: function(){},
  getText: function(){},
}});

а когда строим приложение привязываем к нему события:

b = gui({
type: 'b',
name: 'BoldTextElement',
parent: 'root', //куда крепим, можно не указывать прикрепит в body,
text: 'Василий Болд!'
data: [{name:'bold-element'}],
events: {
  click: function(){
  var text = gui.method(b, 'getText'); //тут надо бы придумать что-то чтобы обойтись без переменной b, а метод уже знал с чем работает
  console.log(text)
  }
},
dataEvents: {//добавляем слушатель на вложенный элемент, если есть, здесь это не нужно, только для примера
  click: function(){
    this указывает на вложенный элемент пользователя
  }
},
modelEvents: {//создаем событие модели, если нужно, события модели можно создавать и позже
  myEvent: function(){}
}

})

Есть еще модель и методы работы с ней.

Шаблонизатор позволяет создавать по сути любые элементы любой сложности и вложенности. В нем есть только foreach, но в других я смысла пока не вижу.

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

Прочитал доки бегло, понял концепцию. и начал писать код, столкнулся с проблемой, пошел посмотрел.

Жуквери это не библиотека для написания говнокода, это библиотека базового уровня, на ней не пишут приложения. Именно поэтому, если на ней писать приложения, то получается говнокод.

Для того, чтобы писать SAP нужны совершенно другие возможности. Нужен настраиваемый конструктор интерфейса с примочками (модель, конструкторы, деструкторы виджетов ...)

Кстати ты про jquery или про jquery + jqueryui? Я на jqueryui не писал, но выглядит не очень.

одного React'а хватит на всё про всё ?

Зависит от задачи :)

На личном опыте разработки крупных SPA (~ 2 года) могу сказать, что самое сложно и важно там - это сборщик мусора и планировщик задач и потоков.

Data-binding приятная, но не обязательная часть. А вообще там супер много нюансов и очень сильно зависит от задачи.

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

:D

Резюмируя: Если проект укладывается в 1 мастер-пейдж, то реализовать SPA не сложно, а если нет и вам очень надо, то... приготовьтесь к попо-боли и велосипедам :)

нет. Видимо, ты не читал про реакт :)

первое (сборщик мусора) я уже уяснил на себе)))
расскажи про второе
также интересны нюансы (можно перечислить хотя бы некоторые)

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

Собственно проблема: когда инициализируются несколько виджетов одновременно, то повышается вероятность "фриза" вкладки или браузера, а когда у нас пользователь перешёл на новую страницу, то шанс фриза на 500 и более мс очень велик (конечно, если у вас не совсем простая страница). Фриз на более чем 100 мс уже чувствуется и раздражает.

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

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

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

Между "проверкой места" должен быть таймаут, т.е. действия не должны идти сразу же, иначе мы зафризем вкладку. У меня стоит 25мс таймаут, вполне норм работает. Подчёркиваю нужен именно таймаут, т.е. никакой setImmediate или requestAnimationFrame не подойдёт, т.к. этот таймаут нужен чтобы отдать поток на другие задачи (поймать фокус мышки, обработать клик и т.д.), т.е. чтобы юзер не дожидаясь общей загрузки уже работал с интерфейсом. Когда мы пишем простое приложение, то за нас это делает браузер, но в SPA всё сложнее.

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

Усложняем задачу: очень часто для того, чтобы отрисовать новую страницу - мы должны грохнуть старую, а только потом рисовать новую и если это делать последовательно, то фриза не миновать. Опять та же стратегия с планировщиком, только теперь удаляем виджеты, но в тоже время там где уже можно начинаем инициализировать новые виджеты.

Ещё усложняем задачу: есть такие виджеты, которые в момент инициализации много чего считают и могут самостоятельно зафризить поток. Следовательно выносим что можно в Worker, но Worker - это тяжёлая штука, а не легковесный поток, как например в Rust или Erlang и там есть лимит на создание (точно не помню, вроде не больше 10), т.е. для работы с потоками опять делаем планировщик.

Вот такие дела :)

Лучше задавай вопросы, ибо про всё тут писать я устану :) На вскидку часов 10 устной лекции можно только про одни нюансы сделать :)

Зачем компилить шаблоны на сервере?

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

Gozar, ты не понял. Я имел ввиду, что не нужно тащить на клиент транслятор синтаксиса шаблонов, а заранее на этапе сборки или ещё как транслировать шаблон в JS, чтобы не делать это на клиенте.

https://github.com/kobezzza/Snakeski...%D0%B8%D 1%8F

http://screencast.com/t/iU7AgM6jvjaj

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

Возможно я не прав и в будущем если я построю ну просто огромное приложение, с тысячами сложных элементов, с вложенностью до 10 уровня тормоза будут заметны, но я вывел за 3 года использования SPA, что компьютеры становятся мощнее.

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

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

Комментарии на странице каждый день парсят регами по 10 тыщ человек, никто не жалуется!

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

Мне думается оптимизация заранее - зло.

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

Gozar, если тебе это не критично, то ок - это нормально. Но в моём случае:

1) Тащить 12к строк транслятора, которые не нужны, не айс;
2) Не удобно юзать, а так простой вызов функций;
3) Сейчас у меня 300+ шаблонов, рендерятся 1-1.5 сек, базовый модуль ~300 мс, т.е. это реально тормоза для live-режима;
4) Не понятен профит рендеринга на клиенте, т.к. всё автоматизировано и я даже не замечаю, как у меня пересобираются шаблоны :)

так бы и сказал сразу, я же не знаю как у тебя приложение строится.

Не замечал. Как на твоем шаблонезаторе строить приложение, я вот понять не могу.

Ну я тоже не замечаю, наверное профит в этом, ну и в том, что транслятор у меня строк на 100 :)

Мое представление о SPA выражается в следующем:

Самое сложное это построение интерфейса, большая часть которого статична и не требует постоянного рендеринга. Чаще всего добавляются или удаляются дочерние элементы. Бывает и такое, что создаются удаляются сложные элементы. Однако компьютеры многозадачны, люди нет, поэтому работают обычно с какой-либо частью приложения и не рендерят элементы пачками.

Если элементы рендерятся пачками и постоянно, то возможно стоит изменить принцип работы на создание дочерних элементов, а не рендерить элемент с нуля.

При таком подходе тормоза обычно наблюдаются только во время работы с сервером.

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

Возможно мы говорим о разном. Ты подходишь к шаблонам, как к шаблонам. Когда я говорю о шаблонах я говорю о новом html элементе. Именно как о элементе, поэтому я не могу и не хочу разорвать связь при создании элемента из шаблона. У меня вложенные элементы строятся из того же шаблона, поэтому я не могу его заранее компилировать.

ну а что, всё остальное просто в Plain-объекты завернул и норм) шутка это всё, не подумай)
я под влиянием статьи Why you might not need MVC with React.js

укладывается в один мастер пейдж. и есть требование по поводу SPA. мне не отвертеться, йо)

пара па пам, да это же реактивное программирование!

имхо, можно засовывать в setImmediate. это труднее с точки зрения реализации, но легче по ресурсам, чем Worker

На генераторах и setImmediate можно сделать примитивную реализацию легковесных потоков, но... мне лень (т.к. это очень утомительно делать вручную), поэтому юзаю воркеры :)

{template Button.prototype.tpl(params) extends Widget.prototype.tpl}
    ...
{/}

В JS вызов как простых функций, т.к. это уже и есть простые функции.

this.tpl(...)

Как закончу версию 4-ре, то запишу пару видеоуроков, чтобы было понятнее. А вообще сама концепция взята из Google Closure Templates и Django Templates.