Тест сделали не правильно — это в основном «Dom-Based Template Engine» — поэтому используйте renderDom. А renderHtml там только для тестов и прочего. Вот ссылка — jsperf — в Хроме маск быстрее, в других возможно нет. НО, в данном тесте вы сравнивается полноценный дом рендерер/шаблонизатор и маленькую функцию, от которой собственно в проекте смысла не много. А если найдете или напишете более быстрый шаблонный движок — будет здорово, и я буду рад почитать об этом здесь.
Интересный и очень критичный комментарий. На самом деле как раз работа с ДОМ очень дорогая. Анимация — так это сейчас через transitions и animations делается — а это отдельный поток + gpu. События сами по себе ничего не нагружают — важно, что вы в этих событиях делаете, и работа с ДОМом здесь не на последнем месте. По поводу вашых плюсов (вернее минусов :) )
сео — не интересует, во первых много делаем приложений даже не под браузеры, а это мобильные и десктопные приложения, а то что для веба — в основном корпоративные инструменты. И даже то что для паблика, то это решается — делаю не я, но никто не «ругал».
незнакомый разработчик — подобных проблем не было, всем все понятно, а если не понятно, то нужен ли такой сторонний разработчик? Здесь все достаточно просто.
Ускорить процесс. Это какраз кардинально ускоряет процесс разработки. (Нативный zen coding :), a из за произвольных тэгов, этой разметки становится ещё меньше)
Виджеты. Правильно — поэтому есть событие DOMInsert — слушаем, инициализируемся
И хочу вас огорчить ни handlebars, ни тем более ваше решение не достаточно производительны.
Да, но это может быть не только html, a любой макет(разметка) — xml, xaml, mask. В первом комментарииGorthauer87 упомянул qml, но признаюсь, хоть qt очень мощный фрэймворк сделали, ихняя разметка это нечто — css в перемешку с кодом(функции, события), но это субъективно.
Вернувшись к маск разметки, так она удобная тем, что с помощью произвольных тегов, мы скрываем некоторую реализацию, вместо
Да, у вас интересный подход к построению ДОМ. Но вы лишаетесь такой замечательной вещи, как разметка — хотя это дело вкуса конечно. Мне, например, она очень помогает, как понять так и построить структуру приложения/компоненты. А пост/препроцессоры всего лишь паттерны такие — но тут действительно можно, что то интересное развить из этого.
Да, maskjs там тоже используется, как и много других вещей. В ие9 починил. Было пару причин почему не работало — но к шаблонизатору это не относилось — мои недочеты. Признаюсь конечно, что сайт в ие9 выглядит очень уж коряво, но это проблемы верстки и прочего.
Много вам по этому поводу не скажу, так как этим я не занимаюсь. Оптимизация происходит наверное, как во всех остальных, обычных SaaS приложениях. Помню, что можно в robots.txt указать ссылку на sitemap index с перечнем sitemap-ов для нужных категорий, ну а там
Спасибо, хорошее замечание, но insertAdjacentHTML не во много раз быстрее, особенно если мы вставляем хтмл в пустую ноду. Все равно требуется время на парсинг и построение дерева. Добавил новый тест: jsperf:2. И вообще смысл был, не показать, что вот — я сделал нечто — и оно быстрее браузера ;) Конечно же решение немного медленное — но максимально приближено к возможностям браузера, и пока что одно из самых быстрых решений «доселе» мне известных.
А что вас смущает? Синтаксис? Ведь, что касается функционала кастомных контролов, так там важна только одна функция «render». Шаблонизатор относительно простой. И к тому же, не подумайте, я никого не заставляю этим пользоватся — просто рассказал, что и почему использую сам.
Ясно, получается arguments[i] дорогой только в случае IndexOutOfRange, спасибо. Добавил testcase с fake аргументами и скорость сравнялась.
Согласен что можно было инициализацию функции вывести в setup function теста, но так как инициализация соблюдена для всех тестов, то это не проблема, ведь не сама скорость теста важна, а их соотношение.
Может код и оптимизируется, но такому тесту я был, мягко сказано, удивлён. @jsperf. Обратите внимание на 3ий тест, где по отношению ко 2ому уменьшен доступ к arguments[i] и код становится быстрее в 2 раза(в хроме), а в лисе даже в 3 раза. И счет идёт на миллионы операций, так что «в 2 раза» это существенно быстрее. Или я где-то просчитался в тесте?
Согласен, поэтому я тоже оставил возможность генерировать string из построенного дерева. Хотя основной задачей все же является генерация UI, a в html, это зачастую DOM. Поэтому на это и ориентируюсь.
А вы знаете, я тоже так думал, но оказалось всё намного проще. За длительное время я ни разу не сталкивался с подобной проблемой. За основу синтаксиса и «энергии дао» взял ZenCoding стиль. Таким образом, привычные javascript вставки в шаблоне нарушают целостность «энергии шаблона». Простыми словами: Макет должен оставаться макетом. Но что бы не терять мощь шаблонизатора, javascript-ную логику вынес в кастомные тэги. И собственно, шаблон из которого нельзя построить json дерево, является не правильным шаблоном, имхо. Если вы приведёте противоположный пример, буду благодарен. (Кстати я было уже вклинился в ваш диалог ниже) И добавлю, что даже если такой подход и имеет свои недостатки, так они компенсируются лучшей производительностью.
Я вот к примеру использую рэндеринг шаблона прямо в DocumentFragment, время немного увеличивается, зато с лихвой компенсируется во время вставки в DOM, поэтому получается «быстрее чем у других».
Важно (покрайней мере мне), что бы зависимости не лежали списком в отдельных файлах, и тем более не в одном, как у инструментов выше ( это получается, если я хочу подключить доплнительный модуль, я должен указать путь к ниму, и вспомнить его зависимости, что бы тоже указать в файле для сборки. А этих зависимостей может быть много, и не только скрипты, но и хтмл, и стили). Если я хочу подключить один javascript файл, он сам должен подключить, всё что ему надо. Если он подключил другой javascript, тот в свою очередь, подключает свои зависимости, ну и т.д. Тут как раз самое важно — контекст подключение ресурсов — он должен быть в управлении самих скриптов. Вот мы и получили систему подключения ресурсов, она может работать и без сборки. По скорости не уступает разным AMD системам, и если честно, если приложение не большое, я даже редко и собираю. А вот если побольше, тут и вступает сборщик ресурсов. Собсвенно он просто склеивает ресурсы — скрипты, стили, шаблоны, ленивые скрипты(что не мало важно в большых приложениях) — но берет он это все от системы подключения ресурсов. Ну вот наверное это все по конкатенация скриптов.
Сложно? Ничего сложного, заинклудили ресурсы — готово. Можна даже не собирать все в кучу, все будет прекрасно подгружатся, задумались о релизе — собрали. С поддержкой ие вам точно не скажу. Это все дело хорошо протестировано на wебкитах, так как сам я разрабатываю хтмл5 приложения для десктопов и мобилных с wебкит-контэйнером.
Скрипты и прочие ресурсы подгружаются асинхронно, так что ничего не замирает. А jam использует reuirejs? или я нето нашел?
grunt уж совсем банальный — дали ему список скриптов — он собрал. A вот brunch похоже хорош, больше возможностей, но тот же принцип — собираю все что в папке по алфавиту. Или тот же конфиг файл, как у грант. Но во многих случаях и этого достаточно. Спасибо, что поделились.
Визуализировать худший сценарий в стрессовых ситуациях — не самый лучший выход. Чревато заблаговременно сдаться. «Обозначай цели, делай в каждый конкретный момент всё, как можно лучше, и будь, что будет». А так статья очень хорошая — надеюсь кому-то поможет.
И хочу вас огорчить ни handlebars, ни тем более ваше решение не достаточно производительны.
Вернувшись к маск разметки, так она удобная тем, что с помощью произвольных тегов, мы скрываем некоторую реализацию, вместо
можем иметь
Таким образом реализацию диалогового окна мы скрыли за компонент, таким образом макет у нас становится более прозрачным.
Такие ссылки генерируются программно, значит и данный «html» может тоже быть преобразован и отдаваться поисковикам.
arguments[i]дорогой только в случаеIndexOutOfRange, спасибо. Добавил testcase с fake аргументами и скорость сравнялась.Согласен что можно было инициализацию функции вывести в setup function теста, но так как инициализация соблюдена для всех тестов, то это не проблема, ведь не сама скорость теста важна, а их соотношение.
arguments[i]и код становится быстрее в 2 раза(в хроме), а в лисе даже в 3 раза. И счет идёт на миллионы операций, так что «в 2 раза» это существенно быстрее. Или я где-то просчитался в тесте?В виду этих пунктов, я отказался от подобных (isArray, isFunction) функций. Хотя могу где-то ошибаться.
Скрипты и прочие ресурсы подгружаются асинхронно, так что ничего не замирает. А jam использует reuirejs? или я нето нашел?