Всё очень просто. Предположим, на вашей странице очень много JS кода, который блокирует отрисовку. Хостится всё это дело не очень близко к пользователю, да ещё и канал у него не очень, так сказать, широкий. Пользователь открывает ваше веб-приложение, с грустью смотрит на белый (?) экран и значок загрузки, вздыхает, думает: «Да а нафига мне пользоваться таким непонятно работающим сервисом? Необработанные тормоза? Лежащий сервер?», ещё раз вздыхает и с высокой долью вероятностью отказывается от пользования вашими услугами.
Другой же вариант событий: пользователь открывает веб-сервис, где видит в меру надоедливый прелоадер (= сообщение о том, что мы работаем, да! щас будет счастье и радость), ждёт и получает необходимое ему.
Это нам с вами — как веб (и около) разработчикам — понятно, почему может быть белая страница с прелоадером. Это нам периодически не лень открыть дебаггер и «отладить» чужое приложение. Пользователям, привыкшим пользоваться продуктами из коробки это не свойственно — им хочется знать, что всё работает. Просто работает.
Всё это будет работать, пока у вас не начнутся сложные зависимости. А потом подбирать порядок файлов при склейке?
(Пока читал статью и набирал коммент, TheShock уже задал наводящий вопрос, да).
Каждый раз поднимается этот вопрос, но ведь уже давно понятно, что подобные хаки что с node-webkit, что с phonegap / appcelerator, sencha desktop, qtwebkit не подходят для тех вещей, где нужна производительность. Написать игрушку на webgl — круто, да, но только для себя самого. Такие «обёртки» подходят для «формочных офисных приложений». Когда нужно быстро, дёшево накидать — и чтоб работало.
Да нифига. У меня дома подобного типа лежит больше года — с рекламной акции каких-то сигарет досталась — так я ей достаточно часто что-нибудь разогреваю, чтобы подогнуть. До сих пор не кончилась =)
Там суть в следующем: все observables при инициализации выполняются (можете проверить это, добавив в них console.log, например), таким образом строится дерево зависимостей.
Это же свойство позволяет нам полезно модифицировать KnockoutJS так, чтобы сделать загрузку observables «ленивой»: сделать её таким образом, чтобы инициализация происходила не в момент инициализации вью-модели, а в момент первого обращения программиста к самой observable или к observable, от неё зависимой.
Я вам вполне верю, что для некоторых задач Angular лучше, и нигде с этим не спорю :)
Я не очень могу понять «Часто из того места, где меняется модель, я не могу знать, когда нужно менять отображение, а когда нет» и говорю о том, что это знание следует из применяемого фреймворка только и той архитектуры, которая накручена на всё это.
Реализация «события обновления» для такой структуры как массив — вообще вещь не очень очевидная, и для каждого фреймворка сугубо своя. В остальном же, я считаю, что, разрабатывая на каком-то фреймворке, нужно знать, как устроен механизм взаимодействия между разными его компонентами — это основа оптимизированного кода: не важно, knockoutjs у вас под рукой или angularjs.
К слову о дополнительных слоях. Да, действительно, это слишком усложняет. Но простой принцип «сначала сделай всё, а потом — отобрази» (не говорю о долгих операциях) обычно работает на ура.
> Если мы изменяем данные непрерывно или большими порциями сразу, то это вызовет очень много ненужных срабатываний, ведь конечная цель — всего лишь изменить отображение, которые так или иначе будет приведено к итоговому виду, и промежуточные состояния тут не нужны.
Тут дело в том, что нужно менять observable, отвечающий за соответствующее отображение только тогда, когда вам нужно поменять отображение. Если ваше приложение меняет данные отображения во время какой-то своей внутренней работы, то это значит, что с архитектурой что-то не то: например, вы просто пожадничали ещё один observable.
Ну что вы, в самом деле. Автор топика — не разработчик. На остальное ответ такой:
Ребята выбрали AJAX, оставив вам возможность реализовать через Comet.
Ну как… как и всё, что делается быстрее. Проводятся сравнительные анализы, и — вот результат.
Надуманный пример: что проще: удалить ноду и вставить новую или обращаться к ее innerHTML? А если 10 000 раз? Думаю, таких примеров можно придумать много. Остаётся их комбинировать и jsperf.com.
Ну и не забывайте, что мы с вами про JavaScript говорим — под капотом всё не так просто :)
Вот кстати было бы интересно посмотреть, как это реализовано у них внутри, и сравнить с нокаутом.
Как известно, браузер начинает давать немалые тормоза, если модель в knockout большая, а шаблон, который нужно отобразить содержит внушительное количество связей с observables. Может быть, товарищи в meteor смогли справиться с этой задачей?
Знаете, почему, например, под Unix системы какую-то «модель» можно реализовать очень многими способами? Потому что каждая часть самостоятельная, можно быстро заменить одну другой (в случае неотказоустачивойсти, например).
Насколько просто можно в данном фреймворке одну часть заменить другой?
Посмотрели в сторону angularjs, посмотрели количество отрытых багов и время, которые они там висят… и решили, что нет.
Хотя сам подход к организации кода и организации юнит-тестирования у них, несомненно, интересный.
Другой же вариант событий: пользователь открывает веб-сервис, где видит в меру надоедливый прелоадер (= сообщение о том, что мы работаем, да! щас будет счастье и радость), ждёт и получает необходимое ему.
Это нам с вами — как веб (и около) разработчикам — понятно, почему может быть белая страница с прелоадером. Это нам периодически не лень открыть дебаггер и «отладить» чужое приложение. Пользователям, привыкшим пользоваться продуктами из коробки это не свойственно — им хочется знать, что всё работает. Просто работает.
(Пока читал статью и набирал коммент, TheShock уже задал наводящий вопрос, да).
Я рыл, много рыл в этом направлении. Но кроме недоделок — портирования KO под nodejs — ничего дельного не нашёл.
Там суть в следующем: все observables при инициализации выполняются (можете проверить это, добавив в них console.log, например), таким образом строится дерево зависимостей.
Это же свойство позволяет нам полезно модифицировать KnockoutJS так, чтобы сделать загрузку observables «ленивой»: сделать её таким образом, чтобы инициализация происходила не в момент инициализации вью-модели, а в момент первого обращения программиста к самой observable или к observable, от неё зависимой.
Я не очень могу понять «Часто из того места, где меняется модель, я не могу знать, когда нужно менять отображение, а когда нет» и говорю о том, что это знание следует из применяемого фреймворка только и той архитектуры, которая накручена на всё это.
К слову о дополнительных слоях. Да, действительно, это слишком усложняет. Но простой принцип «сначала сделай всё, а потом — отобрази» (не говорю о долгих операциях) обычно работает на ура.
Тут дело в том, что нужно менять observable, отвечающий за соответствующее отображение только тогда, когда вам нужно поменять отображение. Если ваше приложение меняет данные отображения во время какой-то своей внутренней работы, то это значит, что с архитектурой что-то не то: например, вы просто пожадничали ещё один observable.
Ребята выбрали AJAX, оставив вам возможность реализовать через Comet.
Надуманный пример: что проще: удалить ноду и вставить новую или обращаться к ее innerHTML? А если 10 000 раз? Думаю, таких примеров можно придумать много. Остаётся их комбинировать и jsperf.com.
Ну и не забывайте, что мы с вами про JavaScript говорим — под капотом всё не так просто :)
Как известно, браузер начинает давать немалые тормоза, если модель в knockout большая, а шаблон, который нужно отобразить содержит внушительное количество связей с observables. Может быть, товарищи в meteor смогли справиться с этой задачей?
Насколько просто можно в данном фреймворке одну часть заменить другой?
Хотя сам подход к организации кода и организации юнит-тестирования у них, несомненно, интересный.