И почему же мы все не кидаемся вовсю использовать шаблонизацию на стороне клиента?
Если приложение все равно делает HTTP запрос (а это неизбежно задержки!) для получения JSON данных, почему бы не загрузить уже готовое HTML представление, сгенерированное на сервере (или взятое из кэша)? Из моей практики размер чисто шаблона редко когда превышает размер данных, а значит выигрыш в трафике тоже отсутствует?
>>Может быть, стоит оставить некоторое (небольшое) количество отладочного кода на «боевом» сервере
Интересно, а куда будут сохраняться статистические данные по производительности? Ведь код client-side.
>>Другие JavaScript-движки (WebKit, SpiderMonkey) уже оптимизированы, чтобы использовать realloc + memcpy во всех возможных случаях объединения строк.
Ждем IE8? :)
>>Придерживайтесь простых шаблонов. Стоить пересмотреть ваши регулярные выражения, если они выглядит примерно так... [очень-очень длинное регулярное выражение, не встречающееся в природе]
улыбнуло :)
Очень полезные советы, узнал для себя много нового, и понял, почему код YUI выглядит местами так странно - все дело в оптимизации. Автор - большой умница!
«Мы не знаем насколько впечатляющими будут применения платформы», заявил Кузин.
Очень радует, что OpenSource находит свое место и в робототехнике, и очень интересно,
насколько успешным окажется этот проект.
имхо, сюжет спорный, но интересный, а профессионализма все-таки пока не хватает
кстати, в этом топике завелся домовой, который минусует нелестные комментарии.
домовой, одумайся! критика ОЧЕНь и ОЧЕНЬ полезна, особенно для начинающих!
Вообще все новое и неизученное обладает двумя чертами:
* потенциальной опасностью из-за плохой изученности
* магнетизмом по той же причине
Было б здорово менять те или иные свойства и добиваться огромных по важности результатов, но
ИМХО просто неизбежны ошибки. Человек не может не ошибаться, даже если он ученый и обладает мегапупернавороченным оборудованием для исследований и экспериментов.
Пока что природа "прощает" ученым их эксперименты, и это радует. Кто не рискует, тот не пьет шампанского :-)
Если приложение все равно делает HTTP запрос (а это неизбежно задержки!) для получения JSON данных, почему бы не загрузить уже готовое HTML представление, сгенерированное на сервере (или взятое из кэша)? Из моей практики размер чисто шаблона редко когда превышает размер данных, а значит выигрыш в трафике тоже отсутствует?
и сообщения, что сервис загружен не увидишь.
я за здравый смысл в разработке, а не слепую веру в догмы о производительности...
Товарищ, будь джентельменом! ;-)
Интересно, а куда будут сохраняться статистические данные по производительности? Ведь код client-side.
>>Другие JavaScript-движки (WebKit, SpiderMonkey) уже оптимизированы, чтобы использовать realloc + memcpy во всех возможных случаях объединения строк.
Ждем IE8? :)
>>Придерживайтесь простых шаблонов. Стоить пересмотреть ваши регулярные выражения, если они выглядит примерно так... [очень-очень длинное регулярное выражение, не встречающееся в природе]
улыбнуло :)
Очень полезные советы, узнал для себя много нового, и понял, почему код YUI выглядит местами так странно - все дело в оптимизации. Автор - большой умница!
Очень радует, что OpenSource находит свое место и в робототехнике, и очень интересно,
насколько успешным окажется этот проект.
кстати, в этом топике завелся домовой, который минусует нелестные комментарии.
домовой, одумайся! критика ОЧЕНь и ОЧЕНЬ полезна, особенно для начинающих!
* потенциальной опасностью из-за плохой изученности
* магнетизмом по той же причине
Было б здорово менять те или иные свойства и добиваться огромных по важности результатов, но
ИМХО просто неизбежны ошибки. Человек не может не ошибаться, даже если он ученый и обладает мегапупернавороченным оборудованием для исследований и экспериментов.
Пока что природа "прощает" ученым их эксперименты, и это радует. Кто не рискует, тот не пьет шампанского :-)
а) стоит, потому что поломался (где пассажиры?)
б) едет в парк