Comments 47
А я вот хочу, чтобы допилил web qml, там и синтаксис приятный и работать оно теоретически может очень быстро.
UFO just landed and posted this here
Спасибо не надо. Лучше уж запилить новый фреймворк без привязки к MS.
К слову, Microsoft представили CSS3 Grid Layout. Вкусно :)
Есть ещё FlexBox Module, который уже худо-бедно поддерживается в браузерах. Я с ним вчера побаловался — лучами счастья изошёлся.
Есть ещё FlexBox Module, который уже худо-бедно поддерживается в браузерах. Я с ним вчера побаловался — лучами счастья изошёлся.
Толку от IE? Надо чтобы это стало стандартом на всех браузерах.
а так красота, да)
а так красота, да)
Это будет ActiveX N2 по своему влиянию на веб. Помнится, благодаря первому появилось сумасшедшее количество вебинтерфейсов, которые не могли работать нигде, кроме IE, причем строго определенных версий.
Есть хорошая библиотека от гугла, использующая такой подход — AngularJS.
UFO just landed and posted this here
Без обид, но в IE 8 не работает. Пускай ещё пару лет полежит.
Вы пишете про то, что свойство «innerHTML» работает медленно, а как насчет более быстрого и, в большинстве случаев, более правильного метода «insertAdjacentHTML», который, если не ошибаюсь, уже все браузеры поддерживают?
Спасибо, хорошее замечание, но insertAdjacentHTML не во много раз быстрее, особенно если мы вставляем хтмл в пустую ноду. Все равно требуется время на парсинг и построение дерева. Добавил новый тест: jsperf:2. И вообще смысл был, не показать, что вот — я сделал нечто — и оно быстрее браузера ;) Конечно же решение немного медленное — но максимально приближено к возможностям браузера, и пока что одно из самых быстрых решений «доселе» мне известных.
а как насчет SEO? Как индексируются ссылки? И, например, google отображает страницу в кэше или вообще отказывается от индексирования сайта?
Много вам по этому поводу не скажу, так как этим я не занимаюсь. Оптимизация происходит наверное, как во всех остальных, обычных SaaS приложениях. Помню, что можно в robots.txt указать ссылку на sitemap index с перечнем sitemap-ов для нужных категорий, ну а там
Такие ссылки генерируются программно, значит и данный «html» может тоже быть преобразован и отдаваться поисковикам.
<urlset xmlns="...">
<url>
<loc>url</loc>
<lastmod>date</lastmod>
</url>
Такие ссылки генерируются программно, значит и данный «html» может тоже быть преобразован и отдаваться поисковикам.
Круто, уже много лет назад отказался от HTML, правда не дошли руки написать свой шаблонизатор, так что написал классический дом строитель который позволяет быстро и удобно создавать ноды в JS, тем самым избавившись от привязки JS к существующему дому, сделав его провайдером view приложения.
Выглядит примерно так:
Больше всего понравилась ваша идея с пост/препроцессорами. Правда думаю было бы круче как-то их доработать, добавить чуточку магии :)
Выглядит примерно так:
node.root = Node('div', {'class' : 'menu'},
Node('div', {'class' : 'left'},
node.form = Node('form', {'class' : 'form'},
Node('h1', 'Authorize'),
Node('div',
node.email = Node('input', {'type' : 'text', 'value' : 'test@gmail.com'})
),
Node('div',
node.password = Node('input', {'type' : 'password', 'value' : '123'})
),
Node('div',
node.submit = Node('div', {'class' : 'button left'}, 'Authorize'),
node.cancel = Node('div', {'class' : 'button'}, 'Cancel')
)
)
),
Node('div', {'class' : 'right'},
Node('div', {'class' : 'inner'},
Node('h1', 'New User'),
Node('p', {'innerHTML' : 'Haven\'t registered yet?<br/>Please become a our subscriber.'})
)
)
)
node.form.addEventListener('submit', function(){
//some actions
}, false);
document.body.appendChild(node.root);Больше всего понравилась ваша идея с пост/препроцессорами. Правда думаю было бы круче как-то их доработать, добавить чуточку магии :)
У вас какой то шаг назад, выглядит крайне неудобным и многословным, имхо.
P.S. А как на это поисковики реагируют, адекватно?
P.S. А как на это поисковики реагируют, адекватно?
выглядит крайне неудобным и многословным
Сохраняет вложенную структуру HTML для лучшего понимания, в принципе ее редактировать может даже кодер, при этом по размерам меньше HTML кода. Элементы генерируется во view компоненте приложения независимо от дома, что позволяет сделать пре-обработку дома до того как он появится в дом структуре. К тому-же такой подход полностью убирает необходимость использовать дом селекторы, т.к. все нужные ноды уже в есть в скопе приложения.
А благодаря такой чудесной особенности ООП как полиморфизм, возможно создавать целые семейства view компонентов с возможностью их прозрачной подмены в рантайме. Причем благодаря такому подходу можно полностью редизайнить приложение, т.к. JS не привязан ни к структуре DOM, ни к id/class/tagname. Все преимущества на лицо.
Естественно дом строитель уступает по гибкости шаблонизаторам как в этой статье.
P.S. А как на это поисковики реагируют, адекватно?
Честно говоря, никогда не занимался сайтами. Делаю в основном приложения и веб сервисы, там SEO вообще не стоит как задача.
Вы правильно рассуждаете. Но вы в самом начале пути. Мы начинали с чего-то подобного. Но как здесь заметили в таком виде не очень удобно описывать шаблоны, к тому же теряется наглядность. Лучше оставить описание шаблона в виде html/xhtml формате с дополнениями. Конечно, для этого придется реализовывать свой парсер и т.п. но оно того стоит. Да и ссылки удобно хранить не только на элементы, но и на текстовые узлы, атрибуты и комментарии.
В общем посмотрите на реализацию шаблонов в basis.js (надеюсь все же будет скоро статья на хабре) — это то куда мы пришли.
Если кратко, то получается так
Хотя шаблоны мы храним каждый в отдельном файле, а в коде пишем только на этапе прототипирования. В шаблон так же добавляется подключение css стилей. Напрямую мы не заполняем шаблон, это делает соответствующий компонент. Шаблоны могут динамически менять исходный код. Например:
Заменит уже созданные фрагменты на новые. И многое другое…
Сейчас проблема с документацией/статьями, что в ближайшее время постараемся исправить.
В общем посмотрите на реализацию шаблонов в basis.js (надеюсь все же будет скоро статья на хабре) — это то куда мы пришли.
Если кратко, то получается так
var myTemplate = new basis.template.html.Template(
'<div class="menu">' +
'<div class="left">' +
'<form{form} class="form">' +
'<input{email} type="text" value="{emailValue}">' +
....
'</div>'
);
var domMap = myTemplate.createInstance();
// domMap.element -> <div class="menu">
// domMap.form -> <form class="form">
// и т.д.
domMap.set('emailValue', 'some@email.ru');
Хотя шаблоны мы храним каждый в отдельном файле, а в коде пишем только на этапе прототипирования. В шаблон так же добавляется подключение css стилей. Напрямую мы не заполняем шаблон, это делает соответствующий компонент. Шаблоны могут динамически менять исходный код. Например:
myTemplate.setSource('<div>new source</div>');
Заменит уже созданные фрагменты на новые. И многое другое…
Сейчас проблема с документацией/статьями, что в ближайшее время постараемся исправить.
Чем это удобнее HTML?
Все преимущества и удобства есть в моем ответе выше.
Недостатком можно назвать то что для правки существующего шаблона, кодеру нужно будет провести пятиминутный ликбез. Так-же для конвертации html -> JSBuilder для больших шаблонов, у нас на проекте был написан небольшой скрипт в 50 строк.
Недостатком можно назвать то что для правки существующего шаблона, кодеру нужно будет провести пятиминутный ликбез. Так-же для конвертации html -> JSBuilder для больших шаблонов, у нас на проекте был написан небольшой скрипт в 50 строк.
Да, у вас интересный подход к построению ДОМ. Но вы лишаетесь такой замечательной вещи, как разметка — хотя это дело вкуса конечно. Мне, например, она очень помогает, как понять так и построить структуру приложения/компоненты. А пост/препроцессоры всего лишь паттерны такие — но тут действительно можно, что то интересное развить из этого.
Подход интересный, и в принципе себя уже неоднократно оправдал, на довольно крупных сервисах. Но, как я уже говорил выше, он уступает полноценным JS шаблонизаторам.
А под разметкой вы подразумеваете HTML код?
А под разметкой вы подразумеваете HTML код?
Да, но это может быть не только html, a любой макет(разметка) — xml, xaml, mask. В первом комментарии Gorthauer87 упомянул qml, но признаюсь, хоть qt очень мощный фрэймворк сделали, ихняя разметка это нечто — css в перемешку с кодом(функции, события), но это субъективно.
Вернувшись к маск разметки, так она удобная тем, что с помощью произвольных тегов, мы скрываем некоторую реализацию, вместо
можем иметь
Таким образом реализацию диалогового окна мы скрыли за компонент, таким образом макет у нас становится более прозрачным.
Вернувшись к маск разметки, так она удобная тем, что с помощью произвольных тегов, мы скрываем некоторую реализацию, вместо
<div class='overlay'><div class='container'><div class='dialog'>hello</div></div></div>
можем иметь
dialog > 'hello'
Таким образом реализацию диалогового окна мы скрыли за компонент, таким образом макет у нас становится более прозрачным.
Великолепно.
>> Более подробно о самой библиотеке и примеры можете посмотреть здесь — libjs/Mask
В IE (даже в 9м) сайт по указанной ссылке не отображается (разве что только фон).
Судя по коду он тоже написан на MaskJS? Почему так?
В IE (даже в 9м) сайт по указанной ссылке не отображается (разве что только фон).
Судя по коду он тоже написан на MaskJS? Почему так?
UFO just landed and posted this here
Мне кажется данное решение создает больше проблем, чем решает.
Даже если мы получаем прирост производительности при вставке в DOM, это ведь не критичное местов в js. Ведь основная проблема производительности, в коде, который выполняется с частым интервалом (анимации, события).
А используя такую штуку мы получаем букет проблем:
+ сео
+ незнакомому разработчику трудно понять код
+ нельзя ускорить процесс написания кода (autocomplete, zen coding)
+ многие виджеты не могут работать правильно с блоками, пока они не вставлены в dom и не имеют width/height/display
Собственно сразу же вопрос, если мы получаем больше проблем, чем выгоды, как вам удается использовать данное решение в своих проектах и при этом не матерится? Не лучше ли использовать шаблонизатор типа handlebars.js, либо более производительное решение:
Даже если мы получаем прирост производительности при вставке в DOM, это ведь не критичное местов в js. Ведь основная проблема производительности, в коде, который выполняется с частым интервалом (анимации, события).
А используя такую штуку мы получаем букет проблем:
+ сео
+ незнакомому разработчику трудно понять код
+ нельзя ускорить процесс написания кода (autocomplete, zen coding)
+ многие виджеты не могут работать правильно с блоками, пока они не вставлены в dom и не имеют width/height/display
Собственно сразу же вопрос, если мы получаем больше проблем, чем выгоды, как вам удается использовать данное решение в своих проектах и при этом не матерится? Не лучше ли использовать шаблонизатор типа handlebars.js, либо более производительное решение:
function renderWidget(params) {
return '<div class="test">'+ params.content +'</div>'
}
Интересный и очень критичный комментарий. На самом деле как раз работа с ДОМ очень дорогая. Анимация — так это сейчас через transitions и animations делается — а это отдельный поток + gpu. События сами по себе ничего не нагружают — важно, что вы в этих событиях делаете, и работа с ДОМом здесь не на последнем месте. По поводу вашых плюсов (вернее минусов :) )
И хочу вас огорчить ни handlebars, ни тем более ваше решение не достаточно производительны.
- сео — не интересует, во первых много делаем приложений даже не под браузеры, а это мобильные и десктопные приложения, а то что для веба — в основном корпоративные инструменты. И даже то что для паблика, то это решается — делаю не я, но никто не «ругал».
- незнакомый разработчик — подобных проблем не было, всем все понятно, а если не понятно, то нужен ли такой сторонний разработчик? Здесь все достаточно просто.
- Ускорить процесс. Это какраз кардинально ускоряет процесс разработки. (Нативный zen coding :), a из за произвольных тэгов, этой разметки становится ещё меньше)
- Виджеты. Правильно — поэтому есть событие DOMInsert — слушаем, инициализируемся
И хочу вас огорчить ни handlebars, ни тем более ваше решение не достаточно производительны.
Я сделал сравнение вставки обычного string шаблона и вашего
Правильно ли я сделал тест?
Правильно ли я сделал тест?
Тест сделали не правильно — это в основном «Dom-Based Template Engine» — поэтому используйте renderDom. А renderHtml там только для тестов и прочего. Вот ссылка — jsperf — в Хроме маск быстрее, в других возможно нет. НО, в данном тесте вы сравнивается полноценный дом рендерер/шаблонизатор и маленькую функцию, от которой собственно в проекте смысла не много. А если найдете или напишете более быстрый шаблонный движок — будет здорово, и я буду рад почитать об этом здесь.
Я обновил url выше, теперь renderHTML работает через documentFragment (конвертацию я быстро нашел на stackoverflow и не уверен что это самый производительный вариант).
Даже в такой реализации производительность выше. В этот раз хоть правильно тест сделал?)
Даже в такой реализации производительность выше. В этот раз хоть правильно тест сделал?)
Handlebars comparison — а теперь сравните на фоне вами рекомендованного handlebars.js. Повторюсь, что конечно, маленькая функция с одной конкатацией стрингов будет быстрее шаблонного движка. И если такой маленькой функции вам хватает для проектов, ну тогда я рад за вас.
Я согласен, что по сравнению с другими шаблонизаторами, производительность вашего отличная, но такой синтаксис меня очень смущает, в нем легко сделать ошибку и трудно ее найти. Даже в вашем тесте jsperf.com/maskjs-vs-json есть ошибка, mask.renderDom возвращает лишь часть dom объекта.
Ведь шаблоны в первую очередь делаются для уппрощения их редактирования, а если очень важная производительность можно использовать js без шаблонов. Или как вариант, попробовать Dart.
Ведь шаблоны в первую очередь делаются для уппрощения их редактирования, а если очень важная производительность можно использовать js без шаблонов. Или как вариант, попробовать Dart.
Вы наверное ссылкой ошиблись, так как .renderDom там совсем не используется, а .compile, и на первый взгляд без ошибок там. А в синтаксисе, конечно же можно допустить ошибку, но не менее легче чем в обычном html, или javascript-e. В редакторе выбрав подсветку как в javascript, сразу видно литералы/блоки. И должен признать, что парсер преднамеренно сделан без кучи проверок на валидность синтаксиса, хотя сделать это не сложно. Но мне это не надо — абстракции компонент и синтаксис позволяют держать шаблоны маленькими и наглядными, где ошибку пропустить уже довольно сложно становится.
В первую очередь шаблоны нужны, что бы «оживить» html связав его с данными. А в данном случае, я предлагаю дополнительно компонентно-ориентированный макет.
> js без шаблонов — что бы построить более менее сложное приложение(а не просто страницу), одной функцией(продемонстрированной вами выше) не обойтись — в результате получаем далеко не более быстрое решение.
> Неужели Dart будет быстрее, можете провести тест?
В первую очередь шаблоны нужны, что бы «оживить» html связав его с данными. А в данном случае, я предлагаю дополнительно компонентно-ориентированный макет.
> js без шаблонов — что бы построить более менее сложное приложение(а не просто страницу), одной функцией(продемонстрированной вами выше) не обойтись — в результате получаем далеко не более быстрое решение.
> Неужели Dart будет быстрее, можете провести тест?
О, добрый день. Я наткнулся на ваш шаблонизатор 3 недели назад.
Я не буду писать, чем ваш шаблонизатор хуже или лучше других. Их много и у всех свои свойства. Сейчас вообще становиться модно в каждой крупной компании иметь свой собственный.
То, что ваш шаблонизатор шустрый отрицать не буду, но когда я увидел у вас «is even faster than native JSON.parse», у меня закрались большие сомнения в вашей правоте.
И как оказалось, просто ваш тест не является чесным, так как JSON представление шаблона, использованное вами для сравнения, содержит 40% «лишнего».
И чтобы не быть голословным, я написал новый тест, где JSON шаблон предствален более рацилонально. И, как и ожидалось, ваш mark в нем проигрывает JSON.parse — jsperf.com/maskjs-vs-json/2
Более того мы можем отказаться от валидации JSON, используемой в JSON.parse для обеспечения безопасности, и использовать eval. Тогда мы получим ровно два раза большую скорость парсинга.
Так что ваш тест сыграл с вами вами злую шутку.
И да, фразу «is even faster than native JSON.parse» наверное лучше убрать :)
Я не буду писать, чем ваш шаблонизатор хуже или лучше других. Их много и у всех свои свойства. Сейчас вообще становиться модно в каждой крупной компании иметь свой собственный.
То, что ваш шаблонизатор шустрый отрицать не буду, но когда я увидел у вас «is even faster than native JSON.parse», у меня закрались большие сомнения в вашей правоте.
И как оказалось, просто ваш тест не является чесным, так как JSON представление шаблона, использованное вами для сравнения, содержит 40% «лишнего».
И чтобы не быть голословным, я написал новый тест, где JSON шаблон предствален более рацилонально. И, как и ожидалось, ваш mark в нем проигрывает JSON.parse — jsperf.com/maskjs-vs-json/2
Более того мы можем отказаться от валидации JSON, используемой в JSON.parse для обеспечения безопасности, и использовать eval. Тогда мы получим ровно два раза большую скорость парсинга.
Так что ваш тест сыграл с вами вами злую шутку.
И да, фразу «is even faster than native JSON.parse» наверное лучше убрать :)
О, так это вы создали 2-ой тест — очень грамотный подход, особенно array nested tree object. А вот тест как раз ваш не честный, так как на выходе мы получаем разные json. Я же взял тот json, который на выходе по данному шаблону выдает mask.compile, и сравнил с парсингом оного через JSON.parse — кажется довольно честно. Согласен, что от «40%» лишнего надо бы избавится, правда потом мы будем размножать проверки на подобии node.attr != null?. В любом случае, этот тест просто показывает, что компиляция происходит довольно быстро, и много мы не выиграем, если будем компилировать шаблоны перед дэплоем. А это, по крайней мере, мне очень важно — иметь чистые шаблоны в релизе.
Моя конфигурация JSON, это то что я по быстрому получил заменив ваш JSON при помощи нескольких RE в текстовом редакторе. Не более того. Касательно структруры я не задумывался — поэтому прошу без претензий.
Моя цель была — уменьшить длину строки. В какие структуры там внутри это превращается это дело второе.
Моя цель была — уменьшить длину строки. В какие структуры там внутри это превращается это дело второе.
Хм, мне кажется вы сочли, что мой ответ с сарказмом — вовсе нет. Действительно — array nested tree в javascript хороший паттерн.
А вот то, в какую структуру это все превращается довольно важно — ведь с ней потом работать «дом-билдеру» и компонентам, поэтому уменьшать строки, тем самым изменяя структуру на выходе, не вариант.
А вот то, в какую структуру это все превращается довольно важно — ведь с ней потом работать «дом-билдеру» и компонентам, поэтому уменьшать строки, тем самым изменяя структуру на выходе, не вариант.
Есть подозрение, что в силу меньшей вложенности и замены обращения к полям хэша, на обращения к полям массива, ваш «дом-билдер» переписанный под предложенную мной структуру справлялся бы быстрее.
Да, я об этом подумал как только увидел. Обязательно попробую с этим вариантом, тут просто больше будет семантических проблем с произвольными компонентами. Ведь намного удобнее работать, когда создав обработчик компоненты, вы получите атрибуты в .attr, a детей в .nodes — чем [1], [2]. Но над этом я ещё подумаю. Спасибо вам.
И по-поводу eval — в данном тесте мы «эвалим» один и тот же шаблон — это то же не честно, так как v8 и wjs кэшируют результат — webkit (fixed)
Jade синтаксис в случае с шаблонизатором на мой взгляд удобнее и немногословнее всего. Думаю что отказ от html разметки лежит в этом направлении.
Sign up to leave a comment.
Преимущества произвольных тегов, или как я отказался от HTML разметки