Как ныне принято писать на js?

500 продуктов

их там 1000 -_-

Для простого добавления/обновления тебе шаблонизатор и не нужен. Так обновляй.

Описываю шаблоны я как jade и сразу их компилирую, для браузера шаблоны это уже js модули с обычными функциями. Когда надо обновить данные я НЕ ДЕЛАЮ ПОВТОРНЫЙ РЕНДЕРИНГ, хотя это тоже зависит от задачи. если надо просто что-то изменить, я просто поменяю содержимое ноды. На счет серверных практик наивное заблуждение, ведь MVC придуман именно для интерфейсов.

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

js модули

А что в прототипе у этих модулей?

у тебя нет необходимости в таких усложнениях. у меня она есть

Приведи пример, если не трудно.

Кстати технически я могу взять любой mvc фрэймворк, возможно из-за некторого времени работы с extjs у меня некое отторжение к этому всему. Но элементарного класса coffee с обсервером мне пока хватает для всех задач.. городить сложную абстракцию не вижу смысла.

Кстати да

НЕ ДЕЛАЮ ПОВТОРНЫЙ РЕНДЕРИНГ

Ну.. чудес не бывает, значит либо явно генерируются dom объекты (что вряд ли), либо идет сканировние (либо в момент создания, либо в момент обновления).

Функция обновления выглядит также красиво как

  update: (@product)->
    @title.nodeValue = @product.title
    @description.nodeValue = @product.description
    @image.satr 'src', @product.thumbUrl
    @bigImageLink.satr 'href', @product.imageUrl

я даже не работал с ext и уже отторгаюсь (от ext'а, в смысле)

необходимость — сложное риа приложение, когда сервер это чистый рест, все остальное делает клиент

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

все зависит от ситуации и того что я решу использовать

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

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

можно использовать тот же обсервер, простой или сложный, махину вроде нокаута, почему бы и нет

я же не говорю тебе «держи все в строке» или «не делай запросов по дереву» или «не обновляй дерево», я говорю что для каждой задачи свое решение, и когда элемент комплексный легче выплюнуть его как строку, но это то что касается его формирования, в остальном манипуляция идет, конечно, с домом

ты бы посмотрел бекбон и что он предлагает, это же не монстро, это 1,5к строк С КОММЕНТАРИЯМИ

и его афтар кофе писал, кажется

как я люблю когда начинают считать спички
происходит траверсинг по дереву

-_-

я же не говорю тебе

Я тоже ничего не говорю, я вообще спрашиваю, чего ты завелся.

можно использовать тот же обсервер, простой или сложный, махину вроде нокаута, почему бы и нет

Ну вот легкий dsl для генерации dom объектов, более быстрый чем любой шаблонизатор, разве не отличный вариант (я не предлагаю им пользоваться, а просто спрашиваю мнение).

а тебе больше всего в бекбоне что нравится (может какая-то конструкция, прототип)?

ну смотри, дсл это круто, пока не начинаются изменения

если это верстка, проще держать все в шаблонах

и я не завелся, спрашивай пожалуйста, такой у меня стиль ответов

в бекбоне, уж и не знаю, то что там все просто, понятно и по делу

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

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

ну jade это ж тоже dsl

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

Но технически можно сделать чтобы автоматом искался какой-нибудь ProductControl, где бы все это делалось (включая метод update), а в Product бы остался только dsl (это если обязательно надо разделить по файлам).

Я бы смотрел knockout и angular. Разметку делаю на Jade + Stylus.

Сейчас все катится в повышенную модульность. В качестве самой упоротой крайности можно посмотреть яндексовский БЕМ.

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

это все дело предпочтений, жейд это html без жт лт, не более (ну, конечно, не считая того что это шаблонизатор, лол)

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

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

Могу сказать, что мне в нем НЕ нравится. Он слишком сильно заточен на модели от бизнес-логики (серверные данные). А в интерфейсе обычно упор на свистелки и view-models. И по факту получается, что самую трудозатратную часть бекбон не делает. Возможно, лет пять назад он был прорывом, но сейчас есть более эффективные подходы, IMHO.

Я тут давеча крыл кнокаут. Дык вот, я был не прав. После переписывания фонтеллы с бекбона на кнокаут, код стал намного проще.

А я его именно для идей и советовал изучить. Чтобы потом не лажануться при написании своего. С теоретической частью там все пучком. Просто имплементация с bem-tools пока бесконечно далека от народа.

оки, гляну.

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

А такой вопрос, неужели не хочется быть поближе к оригинальному js api, а не использовать медлительных посредников?

ынтыпрайзу надо быстрее и чтобы везде работало

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

просто используя свой бойлерплейт я пишу и отлаживаю все в хроме и с 99% вероятностью все заработает в остальных местах, даже на девятом ослике

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

пока не разбираешься в основе, высокое лучше не трогать

с другой стороны, зачем ползать по полу если можно лазать по канату

с другой стороны, зачем ползать по полу если можно лазать по канату

Ах, если бы так. Если поразмышлять (а мне внезапно предоставилась возможность), то все не так уж радужно.

Самое тупое: время выполнения. Опять же, элементарный бенч на выборку

select by id
jquery  7ms
js      0ms

select by class
jquery 98ms
js     2ms

select by tag
jquery 114ms
js     1ms

var t, times = 1000

console.log('select by id')

console.log('jquery')
t = (new Date).getTime()
for( var i=0; i<times; i++ ){
  $('#a')
}
console.log( (new Date).getTime() - t + 'ms' )

console.log('js')
var t = (new Date).getTime()
for( var i=0; i<times; i++ ){
  document.getElementById('a')
}
console.log( (new Date).getTime() - t + 'ms' )

console.log('select by class')

console.log('jquery')
t = (new Date).getTime()
for( var i=0; i<times; i++ ){
  $('.a')
}
console.log( (new Date).getTime() - t + 'ms' )

console.log('js')
var t = (new Date).getTime()
for( var i=0; i<times; i++ ){
  document.getElementsByClassName('a')
}
console.log( (new Date).getTime() - t + 'ms' )

console.log('select by tag')

console.log('jquery')
t = (new Date).getTime()
for( var i=0; i<times; i++ ){
  $('a')
}
console.log( (new Date).getTime() - t + 'ms' )

console.log('js')
var t = (new Date).getTime()
for( var i=0; i<times; i++ ){
  document.getElementsByTagName('a')
}
console.log( (new Date).getTime() - t + 'ms' )

C одной стороны 1000 итераций вроде много, с другой, не так уж. Главное - разница цифр. Время маленькой выборки будет в ~10..20 раз дольше (зависит от типа запроса, из-за регулярных выражений обработке входных данных), а для выборки большого количества объектов, время будет тем больше, чем больше величина выборки (тут уже генерация объектов jquery).

Скорость может и приемлема для _небольших приложений_, но я не вижу профита..

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

То что для биндингов и делегирования используется один метод, вовсе не означает, что границы стерты.. это просто определяется через параметры метода, и снова через регулярные выражения, которые в jquery срабатывают на каждый чих. Вот это Как ныне принято писать на js? (комментарий) будет работать быстро, хотя и не уверен, что быстрее, чем событие прерывающее дальнейшее всплытие, но то, что делает jquery - работает медленно, и отмечались тормоза связанные с делегированием (т.е. слишком медленно).

используя свой бойлерплейт я пишу и отлаживаю все в хроме и с 99% вероятностью все заработает в остальных местах

js основных браузеров достаточно схож (уже) и так.

Посмотри на бенчи еще раз, очевидно, что jquery замедляет работу веб-приложений в десятки, а то и в сотни раз (это плохо). Помнож это на тормоза от jade (кстати может подкинешь шаблончик для бенчей), я думаю они ~ 2..5 раз медленнее обычной домогенерации. И получаем, что такая методика работы (текстовый шаблон + jquery) замедляет веб-приложение в 100..1000 раз (это тоже плохо). Да, они в основном работают «фастэнаф», но это ограничивает их сложность (т.е. уже не сделаешь гуглмапс).

Далее код, я так и не понял, куда ты складываешь навешивание биндингов и методы обновления фрагмента? Т.е. нет ситуации, как с ORM в руби, когда объект содержит все методы для работы с собой. Нет и самого понятия дом-объект. Кстати да, сейчас понял, что я перенимаю именно эту модель, только у меня бд - это дом-дерево..

И в заключении.. jade это хорошо, но дсл на чистом js, или coffee - лучше, т.к. ближе к программистам и быстрее.

пс, а верстальщики чтоли у тебя работают прямо на jade?