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

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

При проектировании 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 можно сделать примитивную реализацию легковесных потоков, но... мне лень (т.к. это очень утомительно делать вручную), поэтому юзаю воркеры :)