Комментарии 24
AngularJS весит где-то мегабайт
Версия 1.2.0 RC2 весит ~89кб, это совсем не так много. Да и гугловский CDN намного улучшает ситуацию.
Ясное дело, что в ангуляре синтаксис сумасшедший (касательно директив), но это только вопрос привычки. Да и в проекте, где потребовались директивы, скорее всего, потребуется и остальной функционал AngularJS.
Симпатично. Скролл, правда, не айс — не для перетягивания мышкой, надо поправить. Но функционал приятный.
НЛО прилетело и опубликовало эту надпись здесь
Да, с размером — наврал, извиняюсь, возможно, перепутал с какой-то другой библиотекой по памяти. Уже убрал.
Но я ни в коем случае не хочу конкурировать с ангуляром, corner — это маленькая библиотека для вынесения всего того, что не связано с основным потоком работы приложения из него.
Касательно синтаксиса — я ни в коем случае не критикую angularJS, я сам сделал на нем не один проект, вопрос в другом: он работает на durtyChecking-е. Да, он обещает перейти на Object.observe, но директив это не коснется, так как они в любом случае пересчитываются только при каждом ре-рендере шаблона.
Более близкую аналогию с технологической точки зрения на самом деле можно привести с Polymer и принципом web Components, где с кастомными элементами можно ассоциировать определенный код, отсылку к директивам ангуляра я сделал скорее потому что это куда понятнее для объяснения. Ну и, конечно, потому что разработка началась благодаря ангуляру — после трех проектов на нем было очень сложно строить статику, а подключать такую-архитектуру на сайт, который не оперирует никакими данными, ощущалось немного глупо.
Но я ни в коем случае не хочу конкурировать с ангуляром, corner — это маленькая библиотека для вынесения всего того, что не связано с основным потоком работы приложения из него.
Касательно синтаксиса — я ни в коем случае не критикую angularJS, я сам сделал на нем не один проект, вопрос в другом: он работает на durtyChecking-е. Да, он обещает перейти на Object.observe, но директив это не коснется, так как они в любом случае пересчитываются только при каждом ре-рендере шаблона.
Более близкую аналогию с технологической точки зрения на самом деле можно привести с Polymer и принципом web Components, где с кастомными элементами можно ассоциировать определенный код, отсылку к директивам ангуляра я сделал скорее потому что это куда понятнее для объяснения. Ну и, конечно, потому что разработка началась благодаря ангуляру — после трех проектов на нем было очень сложно строить статику, а подключать такую-архитектуру на сайт, который не оперирует никакими данными, ощущалось немного глупо.
<del>
1) angularjs весит меньше jQuery (ввели в заблуждение… давненько не смотрел на вес jQuery)
2) так как в angularjs есть jqLite подключение jQuery остается на ваш выбор
3) data-binding?
4) Dependency Injection?
последние 2 пункта так же экономят массу времени, и без них это как-то скучно… По сути все что есть в ангуларе сейчас — это как раз таки директивы и все что нужно для того что бы они работали (даже контроллеры подключаются через директивы).
Все дополнительные фичи аля ngRoute и т.п. вынесено в отдельные модули.
2) так как в angularjs есть jqLite подключение jQuery остается на ваш выбор
3) data-binding?
4) Dependency Injection?
последние 2 пункта так же экономят массу времени, и без них это как-то скучно… По сути все что есть в ангуларе сейчас — это как раз таки директивы и все что нужно для того что бы они работали (даже контроллеры подключаются через директивы).
Все дополнительные фичи аля ngRoute и т.п. вынесено в отдельные модули.
нужно будет залезть в панель веб-разработки и вручную поменять значение repeat у любого из клонированных элементов
Поменял у одного из элементов с «repeat=5» на «repeat=7», в итоге остался один элемент. Так и задумано?
Да, более того — в Corner используется полифилл для mutationObserver от полимера, и я сам пытаюсь отслеживать изменения обеих проектов.
brick указан зря — это комплект элементов на базе x-tags, в действительности существует всего 2 реализации web Components.
Я периодически использую в качестве эксперимента(например, там, где однозначно не будет поддерживаться ie) Polymer, однако он сам по себе несколько монструозен и тяжеловесен. В любом случае даже x-tags более тяжеловесное решение, в которое входят полифиллы для HTML imports, Custom Elements, входит достаточно больше количество кода, которое позволяет обсчитывать жизненный цикл компонента.
Если лезть глубже — то директивы Corner-а это что-то среднее между директивами ангуляра и компонентами.
С одной стороны — они навешиваются на элемент (не создают новый элемент, а базируются на старых), их может быть несколько, они могут появляться в любой момент жизненного цикла элемента и так же исчезать. С другой — их события действительно похожи на те, которые используются в web Components — решениях: создание, исчезновение, изменение атрибута.
В пользу директив говорит простота при почти том же функционале, в пользу веб-компонентов — переносимость(вы ведь в курсе, что и полимер, и x-tags способны использовать компоненты друг друга?). Однако далеко не в пользу компонентов говорит то, что они опираются на:
-WeakMap полифилл, при этом они используют решение, которое в в пользу скорости(прирост в сравнении с «правильной» реализацией огромный, в некоторых случаях — в сотни и тысячи раз в силу того что сложность официального решения O(n), сложность их — O(1)) несколько не соответствует стандарту и способно в некоторых случаях банально падать.
-MutationObserver полифилл, не способный отлавливать удаление атрибута(все остальное на самом деле полностью соответствует стандарту)
-HTML imports полифилл, который в силу своей природы выполняет синхронный XHR-запрос, что крайне негативно сказывается на времени загрузки страницы, и поэтому я бы рекомендовал использовать его только в разработке
-Shadow DOM полифилл. Его я не использовал, поэтому не могу по своему опыту ничего сказать, но то, что я видел в исходниках, наводит меня на мысль на то, что опять же быстродействие ощутимо проседает.
Полимер в действительности это огромный прыжок в будущее, и я нисколько не умаляю его роли, более того — я все собираюсь с духом написать про него большую и интересную статью, но все же… даже сами разработчики не рекомендуют использовать его в продакшне.
В любом случае, компоненты не позволяют расширять текущие элементы. А в случае же с Сorner-ом можно спокойно написать что-нибудь вроде
и потом спокойно делать в SCSS примерно такой запрос
brick указан зря — это комплект элементов на базе x-tags, в действительности существует всего 2 реализации web Components.
Я периодически использую в качестве эксперимента(например, там, где однозначно не будет поддерживаться ie) Polymer, однако он сам по себе несколько монструозен и тяжеловесен. В любом случае даже x-tags более тяжеловесное решение, в которое входят полифиллы для HTML imports, Custom Elements, входит достаточно больше количество кода, которое позволяет обсчитывать жизненный цикл компонента.
Если лезть глубже — то директивы Corner-а это что-то среднее между директивами ангуляра и компонентами.
С одной стороны — они навешиваются на элемент (не создают новый элемент, а базируются на старых), их может быть несколько, они могут появляться в любой момент жизненного цикла элемента и так же исчезать. С другой — их события действительно похожи на те, которые используются в web Components — решениях: создание, исчезновение, изменение атрибута.
В пользу директив говорит простота при почти том же функционале, в пользу веб-компонентов — переносимость(вы ведь в курсе, что и полимер, и x-tags способны использовать компоненты друг друга?). Однако далеко не в пользу компонентов говорит то, что они опираются на:
-WeakMap полифилл, при этом они используют решение, которое в в пользу скорости(прирост в сравнении с «правильной» реализацией огромный, в некоторых случаях — в сотни и тысячи раз в силу того что сложность официального решения O(n), сложность их — O(1)) несколько не соответствует стандарту и способно в некоторых случаях банально падать.
-MutationObserver полифилл, не способный отлавливать удаление атрибута(все остальное на самом деле полностью соответствует стандарту)
-HTML imports полифилл, который в силу своей природы выполняет синхронный XHR-запрос, что крайне негативно сказывается на времени загрузки страницы, и поэтому я бы рекомендовал использовать его только в разработке
-Shadow DOM полифилл. Его я не использовал, поэтому не могу по своему опыту ничего сказать, но то, что я видел в исходниках, наводит меня на мысль на то, что опять же быстродействие ощутимо проседает.
Полимер в действительности это огромный прыжок в будущее, и я нисколько не умаляю его роли, более того — я все собираюсь с духом написать про него большую и интересную статью, но все же… даже сами разработчики не рекомендуют использовать его в продакшне.
В любом случае, компоненты не позволяют расширять текущие элементы. А в случае же с Сorner-ом можно спокойно написать что-нибудь вроде
directive('input', function(node){
$(node).keyup(function(){
$(node).attr('value', $(node).val());
})
});
и потом спокойно делать в SCSS примерно такой запрос
input {
&:active, &:focus, &:not([value=""]) {
& + .label {
display: none;
}
}
if ($(‘.element-carousel').length>0) {$('.element-carousel').initCarousel()}
if ($('.element-scrollbox').length>0) {$('.element-scrollbox').initScrollbox()}
Очень странный подход. Мне кажется надо было начинать с разбора этого кода, а потом уже про директивы.
Вполне стандартная ситуация, ничего странного.
Как по мне, в jQuery плагинах обязательно должна быть такого рода проверка внутри тех самых initCarousel и initScrollbox. Но мы с вами ведь знаем, что так бывает не всегда. Поэтому такой код можно часто встретить в проектах.
Как по мне, в jQuery плагинах обязательно должна быть такого рода проверка внутри тех самых initCarousel и initScrollbox. Но мы с вами ведь знаем, что так бывает не всегда. Поэтому такой код можно часто встретить в проектах.
обычно внутри плагинов код примерно такой:
а это значит что проверка на количество элементов не нужна. Если не найдено ничего — то и пофигу.
Опять же можно сделать еще такое:
$('[data-plug]').plug();
как это сделано в том же twitter bootstrap.
$.fn.foo = function () {
return this.each(function () {
// bootstrap stuff...
});
};
а это значит что проверка на количество элементов не нужна. Если не найдено ничего — то и пофигу.
Опять же можно сделать еще такое:
$('[data-plug]').plug();
как это сделано в том же twitter bootstrap.
try {value = eval( '{' + value + '}' )}
OMG! JSON.parse забыли?
Статья базируется на пастулате, что
Но нет решения этого плохого кода, с использованием Corner.js
Звучит как «Курение это плохо, а вот как мы решаем вопрос с алкоголем и наркоманией.»
Не понятно, почему вот это
Я не понял, чем хорош Corner.js. Чем решение на jQuery хуже или лучше.
Общий this — вообще нарушение основ языка, когда в jQuery это решается через .proxy, а в coffiscript через '=>'. Можно сказать что true = false, выдать за фишку библиотеки и ждать счастливого дебага.
function pageChange(){
if ($(‘.element-carousel').length>0) {$('.element-carousel').initCarousel()}
if ($('.element-scrollbox').length>0) {$('.element-scrollbox').initScrollbox()}
Но нет решения этого плохого кода, с использованием Corner.js
Звучит как «Курение это плохо, а вот как мы решаем вопрос с алкоголем и наркоманией.»
Не понятно, почему вот это
directive('input', function(node){
$(node).keyup(function(){
$(node).attr('value', $(node).val());
})
});$('input').keyup(function(){
$(this).attr('value', $(this).val());
});Я не понял, чем хорош Corner.js. Чем решение на jQuery хуже или лучше.
Общий this — вообще нарушение основ языка, когда в jQuery это решается через .proxy, а в coffiscript через '=>'. Можно сказать что true = false, выдать за фишку библиотеки и ждать счастливого дебага.
Видимо, я плохой автор, раз не смог объяснить.
Это работает не как jQuery. Это не альтернатива jQuery. Этот код работает через MutationObserver, который вызывает колбэки на каждое изменение DOM-дерева. И каждый раз, когда целевой элемент добавляется, отрабатывает целевой колбэк.
Я не представляю, как на jQuery можно красиво и быстро реализовать что-то подобное:
При том что внутри одних шаблонов легко и непринужденно могут оказаться другие, иногда — даже не один раз.
А вообще статья базируется на постулате о том, что ПРЕДПОЛАГАТЬ появление новых элементов и вызывать инициализацию элементов по смене вьюхи или чего угодно еще это плохо.
Как угодно еще — это, например(реальный код, который я видел):
При этом человек не первый день в вебе, далеко не первый, много запущенных и работающих сайтов.
То есть человек реально делает предположение, что через .5 секунды после смены текущего анкора вызовется смена вьюхи(которая делается тоже асинхронно в силу того что слушает то же самое событие), которая успеет обновить дом-дерево.
Что страшнее всего — сами вьюхи подгружаются через $.get.
В действительности же все скроллбоксы — сущности автономные, и держать их внутри основного кода — смысла нет. Соответственно — Corner это возможность вынести абсолютно весь код, который не относится к mainflow, в отдельные изолированные блоки.
А вот это
будет работать только с теми элементами, которые в данный момент есть на странице. Если вы добавите еще один />, то он уже не будет обрабатываться.
Хотя да, без Corner заработал бы такой код. Не стану спорить.
Относительно общего this.
Если бы я предложил синтаксис
вам было бы комфрортнее принять общий this? Потому что jQuery предлагает именно такой синтаксис. Я просто пришел к тому, что цепочка вызовов, в каждом из которых this ссылается на ноду — не так удобна для декларирования, чем общая конфигурация сразу же.
Это работает не как jQuery. Это не альтернатива jQuery. Этот код работает через MutationObserver, который вызывает колбэки на каждое изменение DOM-дерева. И каждый раз, когда целевой элемент добавляется, отрабатывает целевой колбэк.
Я не представляю, как на jQuery можно красиво и быстро реализовать что-то подобное:
directive('include', {alter: function (node, path) {
$.get(path, function(responseText){
node.innerHTML = responseText
})
}});
При том что внутри одних шаблонов легко и непринужденно могут оказаться другие, иногда — даже не один раз.
А вообще статья базируется на постулате о том, что ПРЕДПОЛАГАТЬ появление новых элементов и вызывать инициализацию элементов по смене вьюхи или чего угодно еще это плохо.
Как угодно еще — это, например(реальный код, который я видел):
$(document).on('hashchange', function(){
setTimeout(function(){
$('.scroller').each(function(){
initScroller($(this))
})
}, 500)
})
При этом человек не первый день в вебе, далеко не первый, много запущенных и работающих сайтов.
То есть человек реально делает предположение, что через .5 секунды после смены текущего анкора вызовется смена вьюхи(которая делается тоже асинхронно в силу того что слушает то же самое событие), которая успеет обновить дом-дерево.
Что страшнее всего — сами вьюхи подгружаются через $.get.
В действительности же все скроллбоксы — сущности автономные, и держать их внутри основного кода — смысла нет. Соответственно — Corner это возможность вынести абсолютно весь код, который не относится к mainflow, в отдельные изолированные блоки.
А вот это
$('input').keyup
будет работать только с теми элементами, которые в данный момент есть на странице. Если вы добавите еще один />, то он уже не будет обрабатываться.
Хотя да, без Corner заработал бы такой код. Не стану спорить.
$('body').on('keyup', 'input', function(){
$(this).attr('value', $(this).val());
});
Относительно общего this.
Если бы я предложил синтаксис
directive('test')
.onload(function(node){this.name = node.innerHTML})
.onunload(function(){alert(this.name)})
вам было бы комфрортнее принять общий this? Потому что jQuery предлагает именно такой синтаксис. Я просто пришел к тому, что цепочка вызовов, в каждом из которых this ссылается на ноду — не так удобна для декларирования, чем общая конфигурация сразу же.
Будет ли это работать с jQuery? Общий this только внутри directive?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CornerJS, или директивы «как в AngularJS», только лучше