Comments 55
Переводчик от Бога
Это про что?
Тонкий hint на большой amount непереведенных words, которые вы посчитали нужным не переводить по тем или иным reasons.
Я живу и работаю в Канаде. Я просто не знаю как эти слова произносятся в современном русском. Например view в контексте MVC я просто не знаю как озвучить по русски. Буду признателен если кто-то предложит непротивречивый термин.
Официально — вид (модель-вид-контроллер). Неформально, среди разработчиков — вьюха.
Неформально, среди разработчиков — вьюха.Главное в переводах без вьюх.
Читателей такие словечки ставят в тупик на ура. И никакой словарь не поможет. Уж лучше view.
Чаще «представление», чем «вид» (если нет желания запутать читателя разными видами).
Не нужно придумывать. Официально — представление. А вид — это из окна.
представление, же, а вовсе не вид
Мультитран, на мой взгляд, один из лучших переводчиков английских терминов на русский.
Например view в контексте MVCmodel-view-controller
Критикуя — предлагай.
url hash — ???
single page web application — ???
url hash — ???
single page web application — ???
Я не берусь судить и мне, собственно, все понятно. Просто многим это не нравится, и они могут посчитать как неуважение. Это один из вечных срачей на хабре, и получить минусы за хорошую статью из-за такой ерунды — это тоже не хорошо.
url hash — веб-ссылка на гашиш
single page web application — одностраничное веб-приложение
url hash — веб-ссылка на гашиш
single page web application — одностраничное веб-приложение
Поаккуратнее с гашишем: нас того… и закрыть могут.
По вопросу перевода: уж лучше оставлять оригинальные написания на латинице, чем уродливо транслитерировать.
По вопросу перевода: уж лучше оставлять оригинальные написания на латинице, чем уродливо транслитерировать.
UFO just landed and posted this here
Если по поводу хэша еще можно усомниться, то термин «одностраничное веб-приложение» довольно звучен и не коряв (имхо). Хотя опять же, «хэш-ссылка» лично для меня звучит тоже нормально.Если есть нормальный перевод или устоявшаяся транслитерация — конечно надо использовать их.
В остальных же случаях лучше оригинал, нежели «робастный скэлэйбл интерпрайз солюшн».
Хэш-ссылка — как человек, испорченный математикой, думал, что это хэш-функция, применённая к длинному урлу. Ну, типа, hel.lo/w0rLD123. И, только дочитав до href="#имя-секции", понял.
Не француз, конечно, с их калькой le mot diese в пику заимствованию hashtag, но хотелось бы что-то более благозвучное и, одновременно, понятное по-русски найти этой штуковине «hash url»
Не француз, конечно, с их калькой le mot diese в пику заимствованию hashtag, но хотелось бы что-то более благозвучное и, одновременно, понятное по-русски найти этой штуковине «hash url»
хэш урла
одностраничные web приложения (ваш К.О.)
одностраничные web приложения (ваш К.О.)
хэш — dic.academic.ru/dic.nsf/dic_culinary/2344/%D1%85%D1%8D%D1%88
урла — dic.academic.ru/dic.nsf/efremova/280613/
:)
Captain, I'd better use «url hash» instead.
урла — dic.academic.ru/dic.nsf/efremova/280613/
:)
Captain, I'd better use «url hash» instead.
Ну сами подумайте:
Как минимум несогласованность текста, грамматика (скорее опечатки причем), куча терминов, которым можно найти достойный перевод (я понимаю что вы живете в Канаде, но все же это создает вполне нормальное впечатление о корявом переводе). Как-минимум перечитали бы разок перед публикацией.
Но яыно ошибочно считать
распробовал single page web applications
этот вот url hash должен быть показан в этом view
Т.е. активация такого гиперлинка должна
Как минимум несогласованность текста, грамматика (скорее опечатки причем), куча терминов, которым можно найти достойный перевод (я понимаю что вы живете в Канаде, но все же это создает вполне нормальное впечатление о корявом переводе). Как-минимум перечитали бы разок перед публикацией.
А как быть с индексированием? Я так понимаю в вашем случае шаблоны всеравно являются статичными, и просто подтягиваются с сервера. Мол индексироваться ваша страница не будет (либо нужно на сервере реализовывать механизм снапшотов). Не проще было бы каким grunt-ом скомпилировать все шаблоны в один html сразу. И по части js это реализуется довольно просто.
Если это приложение с логином (как правило) то зачем там индексирование?
Для поисковиков нужно делать правильный about текст который статически включается в index.htm
Или я не понял вопроса.
Для поисковиков нужно делать правильный about текст который статически включается в index.htm
Или я не понял вопроса.
Например, так
help.yandex.ru/webmaster/robot-workings/ajax-indexing.xml
Применено, например, здесь. Весь сайт такой, «динамический»…
www.rozenbaum.ru/#!/songs/i/0472
help.yandex.ru/webmaster/robot-workings/ajax-indexing.xml
Применено, например, здесь. Весь сайт такой, «динамический»…
www.rozenbaum.ru/#!/songs/i/0472
я знаю про ajax-crawling, но в конкретно этой реализации это не предусмотрено. Если речь идет о такой небольшой странице, проще распихать все в одну страницу и просто показывать только частями. Если уже хоть сколько нибудь сложнее все, то тогда нужно дублировать рендринг снашотов на сервере и отдавать их ботам.
csmile, недавно на HN встретил пост, где автор тоже создал микрофреймворк для одностраничных приложений: moot.it/riotjs/ Может будет полезно подчерпнуть его идеи.
Ага, спасибо.
Замечательна MVCёвинка, и махонька така :)
А MVC… моделью можно считать данные на сервере, в базе данных например. Контроллер — частично в business logic layer (сервер), частично на клиенте. Т.е. то что работает на клиенте есть чистый view и его логика. Почему народ пытается MVCями обозвать скажем angularjs я не понимаю.
А вообще мне как прагматику лично более симпатичен Twitter Flight хотя это и не framework в общем смысле. И кстати Twitter Flight реально работает на twitter сайте. Скажем AngularJS в google продуктах не замечен.
Замечательна MVCёвинка, и махонька така :)
А MVC… моделью можно считать данные на сервере, в базе данных например. Контроллер — частично в business logic layer (сервер), частично на клиенте. Т.е. то что работает на клиенте есть чистый view и его логика. Почему народ пытается MVCями обозвать скажем angularjs я не понимаю.
А вообще мне как прагматику лично более симпатичен Twitter Flight хотя это и не framework в общем смысле. И кстати Twitter Flight реально работает на twitter сайте. Скажем AngularJS в google продуктах не замечен.
AngularJS используется, как минимум, в одном сервисе Google — DoubleClick.
И это скорее контр-пример ибо UI там вообще никакой да и продукт какой-то уж совсем левый, половина ссылок здесь не работает толком.
Очень соблазнительно считать данные в базе моделью, но это заблуждение. Модель должна включать в себя логику обработки данных в единой точке, не размазывая и не дублирая ее по контроллерам. Хотя, конечно, данные в базе можно считать моделью, если доступ к ним идет через апи, «зашитое» в процедуры без прямого доступа к данным.
Как angularjs и прочие оказываются MVC? Тут наверно стоит упомянуть концепцию HMVC, которая, имхо, значительно лучше подходит для описания слоев логики приложения, чем попытка вместить их все в прокрустово ложе MVC.
Как angularjs и прочие оказываются MVC? Тут наверно стоит упомянуть концепцию HMVC, которая, имхо, значительно лучше подходит для описания слоев логики приложения, чем попытка вместить их все в прокрустово ложе MVC.
Упс. Не туда комментарий.
Я так понял главная причина изобретение собственного велосипеда заключается в том что не хочется подгружать чего-то типа AngularJS, Ember и прочих Knockouts.
AngularJS 80k и для простых задач jquery вообще не нужен.
JQuery 1.7 = 92k и плюс еще Zepto.
На счет "создает значительную run-time нагрузку", не уверен что ваше решение создаст ее меньше. Такая нагрузка бывает когда не правильно инструмент используешь, а не сама по себе возникает при использовании чего-то типа AngularJS, Ember и прочих Knockouts.
AngularJS 80k и для простых задач jquery вообще не нужен.
JQuery 1.7 = 92k и плюс еще Zepto.
На счет "создает значительную run-time нагрузку", не уверен что ваше решение создаст ее меньше. Такая нагрузка бывает когда не правильно инструмент используешь, а не сама по себе возникает при использовании чего-то типа AngularJS, Ember и прочих Knockouts.
jQuery 1.10 весит где-то 30-40Кб. Для правки. zepto весит меньше то толку от него не много. Насколько я помню работает он медленнее jQuery и там где он используется можно обойтись и vanilaJS. А есть еще jqMobi
бесполезный бенчмарк
бесполезный бенчмарк
Про dirty checking в angularjs и проблемы со списками можно прочитать здесь: habrahabr.ru/post/200670/
Data binding в angularjs требует создания отдельной функции-observer для *каждого* объекта в модели.
Чем более «развесиста» и глубже модель — тем более медленно это всё работает ибо базовые алгоритмы имеют вычислительную сложность
При всем при том для базовых операций типа «отобразить список» в 99% случаях совершенно не нужен живой data binding.
Т.е. в этих самых 99% мы платим за то что не используем вообще. В мобильных приложениях плата это расход батареи и пр.
Мое решение оптимально в том числе в смысле расходов — ты платишь только за то что реально используешь.
Data binding в angularjs требует создания отдельной функции-observer для *каждого* объекта в модели.
Чем более «развесиста» и глубже модель — тем более медленно это всё работает ибо базовые алгоритмы имеют вычислительную сложность
O(n*m). Где n — количество элементов данных в модели (объектов и их свойств) и m — количество обозревателей. При всем при том для базовых операций типа «отобразить список» в 99% случаях совершенно не нужен живой data binding.
Т.е. в этих самых 99% мы платим за то что не используем вообще. В мобильных приложениях плата это расход батареи и пр.
Мое решение оптимально в том числе в смысле расходов — ты платишь только за то что реально используешь.
Object.observer все еще является эксперементальной фичей и по умолчанию отключен в хромах. Как только это изменится, angular сразу перейдет на использование оной, что даст прирост производительности при работе со списками в 20-40 раз. Во всяком случае они упоминали это на одной из последних конференций. Пока же достаточно не писать конструкции вида $scope.watch('myFatModel', callback, true), и особых проблем с производительностью вы не заметите. Да, это сложнее, но не намного. Для мобильных приложений хватает и без angular, любые анимации или банальное выполнение чего-то в фоне во время анимаций тормозит сильнее, нежели периодически запускающиеся $digest циклы.
В любом случае по другому нормально заимплементить датабиндинг не особо то и выйдет. Через геттеры/сеттеры тоже есть свои ограничения.
В любом случае по другому нормально заимплементить датабиндинг не особо то и выйдет. Через геттеры/сеттеры тоже есть свои ограничения.
Даже при наличчи Object.observer в той форме что он предложен не поможет сделать AngularJS легче.
Для того чтобы заменить $watch функциональность нужно пройтись по всем узлам модели (objects & arrays) и навесить на них по отдельной callback функции с помощью Object.observer.
Для отображения списка с помощью ng-repeat нужно на каждую data item повесить свой scope что превращает задачу отображения списка в праздник для сборщика мусора.
Data binding в принципе может быть полезной вещью в каких-то случаях, просто как он тотально навязан в Angular (либо data binding — либо никак) мне откровенно не нравится.
Кстати я сделал свой неинтрузивный вариант data binding в Sciter в стиле AngularJS. Так как в Sciter есть namespaces, Object.add/removeObserver и декораторы функций то код действительно получается чистым.
Для того чтобы заменить $watch функциональность нужно пройтись по всем узлам модели (objects & arrays) и навесить на них по отдельной callback функции с помощью Object.observer.
Для отображения списка с помощью ng-repeat нужно на каждую data item повесить свой scope что превращает задачу отображения списка в праздник для сборщика мусора.
Data binding в принципе может быть полезной вещью в каких-то случаях, просто как он тотально навязан в Angular (либо data binding — либо никак) мне откровенно не нравится.
Кстати я сделал свой неинтрузивный вариант data binding в Sciter в стиле AngularJS. Так как в Sciter есть namespaces, Object.add/removeObserver и декораторы функций то код действительно получается чистым.
На данные навешиваются обсерверы изменений только один раз. Если вам не нужно отслеживать изменения во всей модели (а обычно это не нужно) то все достаточно быстро работает. Во всяком случае у меня еще не было таких проблем с производительностью, что пришлось бы отказаться от ngRepeat, а если и будут, мне проще для конкретного случая написать свою директиву.
Как-тоу Вас все сформулировано, что сходу и не поймешь — Вы хорошо знаете как работает $watch, ngRepeat? Сам ngRepeat создаст только один watchCollection для самого списка/словаря. А далее — сколько в темплейте у Вас будет {{}} столько и будет весьма примитивных watch-ей. Не нужен живой датабиндинг — используйте неживой :-) (ссылку на статью сами и привели)
Имеем модель вида
отображаемую на некий repeatable в UI.
Для того чтобы binding работал нужен примерно следующий код
итого три closures. Это на простой массив объектов-то…
И вот сказ про то как человек бился с ng-repeat.
Воистину, выбираем героический фреймворк чтобы потом героически его бороть.
var list = [
{ id:1 },
{ id:2 }
];
отображаемую на некий repeatable в UI.
Для того чтобы binding работал нужен примерно следующий код
Object.observe( list, function() { ... } ); // list add/remove items observer
Object.observe( list[0], function() { ... } ); // list[0] object property change observer
Object.observe( list[1], function() { ... } ); // list[1] object observer
итого три closures. Это на простой массив объектов-то…
И вот сказ про то как человек бился с ng-repeat.
Воистину, выбираем героический фреймворк чтобы потом героически его бороть.
Вы абсолютно уверены, что это будут реализовывать именно так? Отслеживать тотально все? А зачем?
Опять же зачем? Выбирайте инструмент под задачу. Если Вам постоянно надо его «бороть», то зачем Вы или кто-то другой его выбрали?
Воистину, выбираем героический фреймворк чтобы потом героически его бороть.
Опять же зачем? Выбирайте инструмент под задачу. Если Вам постоянно надо его «бороть», то зачем Вы или кто-то другой его выбрали?
Вы абсолютно уверены, что это будут реализовывать именно так? Отслеживать тотально все?
Да, уверен.
Скажем вот список
var list = [ { val:1 }, { val:2 }, { val:3 } ];
Нужно представить live-bound cумму всех полей val в этом списке. Кроме как повесить по observer 'у на каждый элемент ничего не получится. В DOM дереве можно сгенерирвать bubbling событие ибо есть parent/child связь. И поймать это событие на root контейнере. В JS же объектах такого в принципе быть не может — только brute force — каждому объекту по observer.
Извините, сразу не было времени посмотреть статью. Правильно ли я понял, что в этой статье человеку все нравится, но он столкнулся с одной проблемой, которую успешно решил. Это называется «героически бороть»? Хм, у нас, видимо, разное представление о масштабах проектов и масштабах «борьбы».
Кстати, ему первое решение не подошло, скорее всего потому, что watchCollection появилось только в 1.1.4.
Кстати, ему первое решение не подошло, скорее всего потому, что watchCollection появилось только в 1.1.4.
Но явно ошибочно считать что single page web application не сделать без чего-то типа AngularJS, Ember и прочих Knockouts.
А есть ведь вообще микроскопический (в килобайтах) Backbone, который сам по себе никакой нагрузки не создаёт (вся отрисовка на усмотрение разработчика и т.д.), зато приложение будет хорошо структурированным, а не набором спагетти-коллбэков.
Так что можно-то оно конечно можно. Только зачем?
Про какие крнкретно «спагетти-коллбэки» идет речь?
Про те, которые появятся в процессе расширения функциональности.
Да не нужны там никакие callbacks.
Достаточно вставить в код приведенный в моей статье что-то типа этого:
и пусть кому надо подписываются на эти события. Делов то. Это называется loosely coupled (слабо связанные?) системы.
Еще раз: смотрим на Twitter Flight, он прагматично правильный.
Достаточно вставить в код приведенный в моей статье что-то типа этого:
currentPage.trigger("page:close", currentPageName);
newPage.trigger("page:open", newPageName);
и пусть кому надо подписываются на эти события. Делов то. Это называется loosely coupled (слабо связанные?) системы.
Еще раз: смотрим на Twitter Flight, он прагматично правильный.
То есть надо добавить никак не описанную в статье систему подписок, так?
А потом, например, окажется, что нужно передавать параметр в url. И? Переписывать половину приложения? Чем это прагматичнее варианта «использовать готовое решение на 6.5 килобайт», я никак не пойму? Кстати, тут вполне можно обойтись одним Backbone без jQuery (а подписки вы ведь именно из него хотели заюзать?) и сэкономить на разнице 75(!) килобайт.
А потом, например, окажется, что нужно передавать параметр в url. И? Переписывать половину приложения? Чем это прагматичнее варианта «использовать готовое решение на 6.5 килобайт», я никак не пойму? Кстати, тут вполне можно обойтись одним Backbone без jQuery (а подписки вы ведь именно из него хотели заюзать?) и сэкономить на разнице 75(!) килобайт.
Пардон, там нужен Underscore, так что разница будет 70kB
Система подписок описана в jQuery и в каждой статье про pub/sub pattern
Система подписок также является основой Twitter Flight.
Система подписок также является основой Twitter Flight.
Важным вопросом для AJAX сайтов является поисковая доступность, чтобы не городить костыли и Graceful Degradation.
Вах! Спасибо! Обожаю короткие и элегантные решения. Пошел делать member-эрию на SPA.
Хорошо бы исходники демки — загрузить и поиграться, чем из статьи вырезать и компоновать…
Вот выложил на GitHub это дело. Там же фиксы и доработки
Sign up to leave a comment.
Пишем single-page web application framework в 60 строках кода