Не понял о чем точно идет речь. Какие действия произвёл пользователь, как перемещался по страницам и какие запросы в каком порядке в этом предполагаемом случае отправлены?
ага видел в видео на сайте. я только не понял это режим (из которого надо выйти повторным нажатием) или квазирежим(из которого выходишь, когда перестаёщь зажимать) (что лучше) raskin-interface.narod.ru/interface/chapter3.htm#s3.2
Я имел ввиду какое-то отдельное устройство для обычных компьютеров (где меньше ограничений) для специалистов, гиков, и может быть даже для тех у кого RSI и остро стоит проблема набора текста lionet.livejournal.com/71005.html. Такое гармоничное гибридное устройство позволяющее и крайне эффективно набирать текст, и использовать как мышь
Хочу такую клавиатуру не только для мобильного, но даже больше для обычного компа. Надеюсь ввод всяких программистких скобок и прочих символов будет не сильно неудобней чем текстовые символы. Уверен, что на таком устройстве и правильной раскладке скорость ввода текста может быть кардинально больше.
Кстати для игр тоже крутая вещи. Скрестить бы со steam контролллером и отказаться от мыши! (тачпады для больших пальцев)
«Этот подход отлично работает с юзерами на медленном канале»
Этот подход отлично работает с юзерами на медленном канале, с юзерами сервисов с медленными серверами, с юзерами сервисов использующих api других сервисов, у которых есть throttling. Этот подход превосходно работает с быстрыми серверами, мгновенно выполняющими запросы так, что страница наполняется данными прямо во время короткой анимации переходов между экранами. (можно поправить css в сису, увеличив время, и увидеть, что именно так всё и происходит))
"«прыгающие» блоки (на seesu в том числе) очень раздражают"
В seesu нет прыгающих блоков — "… фиксированное расположение, высота и ширина визуальных блоков ..."
«Если канал большой, то почти моментально загружающиеся… »
Возможно вы просто пропустили вторую часть, но я там пишу про то, что вконтакте, например, запрещает присылать больше одного запроса в секунду, discogs запрещает загружать больше одной картинки в секунду. Чтобы отобразить полностью страницу нужно отправить больше одного запроса.
Таким образом какой бы широкий канал у вас не был — ждать вам всё равно придётся и если не пользоваться этими правилами, то ждать придётся всегда и долго.
«Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!»
Очевидно, что большой канал вас всё-таки не спасает.
Смысл подхода в том, что не нужно ждать пока выполнятся все запросы, наполняющие страницу — можно мгновенно перейти на другую страницу. После перехода данные для выбранной страницы будут загружены в первую очередь.
Почему же под вебкит? Тут, кажется, все оптимизации касаются всех браузеров. К примеру приложение достаточно хорошо себя чувствует в устаревающей опере 12
В том примере скроллинг не нативный; шаг скроллинга не пиксел, а целая строка, что точно не плюс. «не совсем правда», «есть способы с этим бороться» — не хотелось бы заниматься борьбой с фреймворком и постоянно решать одну и туже проблему (даже если решение известно, хотя то, что по ссылке точно не решение)
Чтобы понять как должно быть организовано реально разделение на MVC нужно представить как использовать angularjs в системе, где ядро приложения (с моделями) находится в отдельной области видимости от представления (где вьюхи) и они могут общаться между собой чем-нибудь вроде window.postMessage, вьюха может быть полностью уничтожена, и иногда её нужно полностью воссоздать заново. Представить как использовать angularjs в системах, которые построенный на этом принципе, таких как www.appcelerator.com/titanium/. Нужно понять как во view будет передаваться структура/взаимосвязи моделей, их состояний, как будут передаваться оперативные обновления состояний, структуры во вьюхи, и как будет поставляться обратная связь из вьюх в модели.
Система шаблонизации и датабайндинг в angularjs — единственные вещи, которые интересны в нём.
Пока никому не предлагаю использовать свой «велосипед». Действительно трудно найти преимущества, когда я о них не рассказываю :)
С другой стороны непонято — о каких именно «более-менее сложившихся фреймворках» идёт речь в контексте рендеринга? О каких фрейморках с выдающейся системой рендеринга вы знаете? Я знаю только шаблонизацию angularjs и шаблонизацию facebook react (это не mvc фрейморк), но facebook react опубликован 25 мая 2013 github.com/facebook/react/tree/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4, а я начал внедрять декларативную шаблонизацию в стиле angularjs примерно в феврале 2013 (при этом у меня уже было до этого атомарное изменении DOM) и к концу апреля 2013 у меня была работающее в декларативном стиле решение, покрывающее большинство вещей, требующихся мне. И с тех пор я в той части занимался в основном оптимизациями. Какой выбор был тогда у меня и какой сейчас?
Для меня плюсы заключаются в том, что у меня реальное разделение на MVC в отличии от angularjs, и нет проблем с производительностью при работе со списками.
Angularjs, построен так, что просто отрендерить большой список и изменить какое-нибудь поле у одного из элементов выливается в геморой с производительностью (он пойдёт по всему списку смотреть не изменилось ли чего у кого, заново выполняя функции на моделях, которые являются источником информации состояний. $digest… вот это всё)
О том, что при клонировании нодов свойства объектов (являющихся интерфейсом к dom node) не клонируются я писал. Если нам очень надо клонировать свойство, то это надо делать либо как я описал выше, либо через setAttribute().
Во вторых зачем клонировать эти свойства из шаблона, если мы их меняем их и пользуемся в экземпляре?
Я готов написать свою часть которая будет отвечать оговорённым требования шаблонизации по результату и возможностям, вроде
1) какая-то большая структура
2) нужно будет получить 100 экземпляров
3) при передаче новых данных в экземпляр соотствествующие части будут автоматически обновлены
Можно договориться об этих требованиях и кому интересно — предоставят реализации для тестирования. Ну и соответственно потом замерять скорость получения первого экземляра, скорость получения последующих, скорость применения изменений.
Клонирование корневого нода структуры было медленней, чем result_node.innerHTML = '.....' или медленней чем
var div = document.createEment('div');
var pp = document.createEment('p');
div.appendChild(pp)?
Т.е. такое поэлементное воссоздание даже для большой структуры
Не понял о каких трудностях связанных с клонированием (учитывая что этот код не нужно каждый раз писать) идёт речь. Я, наверно, плохо описал как именно используется шаблонизация, уделив больше внимания собственно реализации. О каких проблемах идет речь?
raskin-interface.narod.ru/interface/chapter3.htm#s3.2
Я имел ввиду какое-то отдельное устройство для обычных компьютеров (где меньше ограничений) для специалистов, гиков, и может быть даже для тех у кого RSI и остро стоит проблема набора текста lionet.livejournal.com/71005.html. Такое гармоничное гибридное устройство позволяющее и крайне эффективно набирать текст, и использовать как мышь
Кстати для игр тоже крутая вещи. Скрестить бы со steam контролллером и отказаться от мыши! (тачпады для больших пальцев)
Этот подход отлично работает с юзерами на медленном канале, с юзерами сервисов с медленными серверами, с юзерами сервисов использующих api других сервисов, у которых есть throttling. Этот подход превосходно работает с быстрыми серверами, мгновенно выполняющими запросы так, что страница наполняется данными прямо во время короткой анимации переходов между экранами. (можно поправить css в сису, увеличив время, и увидеть, что именно так всё и происходит))
"«прыгающие» блоки (на seesu в том числе) очень раздражают"
В seesu нет прыгающих блоков — "… фиксированное расположение, высота и ширина визуальных блоков ..."
«Если канал большой, то почти моментально загружающиеся… »
Возможно вы просто пропустили вторую часть, но я там пишу про то, что вконтакте, например, запрещает присылать больше одного запроса в секунду, discogs запрещает загружать больше одной картинки в секунду. Чтобы отобразить полностью страницу нужно отправить больше одного запроса.
Таким образом какой бы широкий канал у вас не был — ждать вам всё равно придётся и если не пользоваться этими правилами, то ждать придётся всегда и долго.
«Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!»
Очевидно, что большой канал вас всё-таки не спасает.
Смысл подхода в том, что не нужно ждать пока выполнятся все запросы, наполняющие страницу — можно мгновенно перейти на другую страницу. После перехода данные для выбранной страницы будут загружены в первую очередь.
habr.habrastorage.org/post_images/44e/74a/813/44e74a813a70bdc1da54885d31d26100.png
интерфейсы, сделанные подобным образом, действительно вызывают крайне неприятные ощущения.
В статье я рассказываю как сделать хорошо
интересно было бы узнать почему идеи Джефа Раскина не позволяют создавать удобные унтерфейсы, или в чем приложение противоречит его идеям
Например, тут chrome.google.com/webstore/detail/seesu-music/nhonlochieibnkmfpombklkgjpkeckhi когда popup закрывается его document удаляется, и при новом открытии приходится работать с новым документом
Чтобы понять как должно быть организовано реально разделение на MVC нужно представить как использовать angularjs в системе, где ядро приложения (с моделями) находится в отдельной области видимости от представления (где вьюхи) и они могут общаться между собой чем-нибудь вроде window.postMessage, вьюха может быть полностью уничтожена, и иногда её нужно полностью воссоздать заново. Представить как использовать angularjs в системах, которые построенный на этом принципе, таких как www.appcelerator.com/titanium/. Нужно понять как во view будет передаваться структура/взаимосвязи моделей, их состояний, как будут передаваться оперативные обновления состояний, структуры во вьюхи, и как будет поставляться обратная связь из вьюх в модели.
Система шаблонизации и датабайндинг в angularjs — единственные вещи, которые интересны в нём.
Пока никому не предлагаю использовать свой «велосипед». Действительно трудно найти преимущества, когда я о них не рассказываю :)
С другой стороны непонято — о каких именно «более-менее сложившихся фреймворках» идёт речь в контексте рендеринга? О каких фрейморках с выдающейся системой рендеринга вы знаете? Я знаю только шаблонизацию angularjs и шаблонизацию facebook react (это не mvc фрейморк), но facebook react опубликован 25 мая 2013 github.com/facebook/react/tree/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4, а я начал внедрять декларативную шаблонизацию в стиле angularjs примерно в феврале 2013 (при этом у меня уже было до этого атомарное изменении DOM) и к концу апреля 2013 у меня была работающее в декларативном стиле решение, покрывающее большинство вещей, требующихся мне. И с тех пор я в той части занимался в основном оптимизациями. Какой выбор был тогда у меня и какой сейчас?
Для меня плюсы заключаются в том, что у меня реальное разделение на MVC в отличии от angularjs, и нет проблем с производительностью при работе со списками.
Angularjs, построен так, что просто отрендерить большой список и изменить какое-нибудь поле у одного из элементов выливается в геморой с производительностью (он пойдёт по всему списку смотреть не изменилось ли чего у кого, заново выполняя функции на моделях, которые являются источником информации состояний. $digest… вот это всё)
О том, что при клонировании нодов свойства объектов (являющихся интерфейсом к dom node) не клонируются я писал. Если нам очень надо клонировать свойство, то это надо делать либо как я описал выше, либо через setAttribute().
Во вторых зачем клонировать эти свойства из шаблона, если мы их меняем их и пользуемся в экземпляре?
Где-то есть на jsperf.com код?
Я готов написать свою часть которая будет отвечать оговорённым требования шаблонизации по результату и возможностям, вроде
1) какая-то большая структура
2) нужно будет получить 100 экземпляров
3) при передаче новых данных в экземпляр соотствествующие части будут автоматически обновлены
Можно договориться об этих требованиях и кому интересно — предоставят реализации для тестирования. Ну и соответственно потом замерять скорость получения первого экземляра, скорость получения последующих, скорость применения изменений.
var div = document.createEment('div');
var pp = document.createEment('p');
div.appendChild(pp)?
Т.е. такое поэлементное воссоздание даже для большой структуры
будет быстрее чем клонирование каким-нибудь таким кодом?