Carbon.JS JavaScript framework

[Cr@ZyBoY]

Я не понял, что конкретно вам не понравилось, ткните пожалуйста пальцем. В моём понимании оформление и поведение - это разделение HTML-кода и скриптов, но причём тут css, который употребляется внутри отдельно взятой функции?

[tenshi]

> А зачем мне отделять оформление от поведения?
чтобы поправить цвета мог кто угодно, а не только тот, кто это написал

[PeaceCoder]

но причём тут css, который употребляется внутри отдельно взятой функции?

Они имеют ввиду что используя метод который я описал, тебе не надо будет менять скрипты, а просто поменять параметры в классах => ненужные убать, нужные переправить/оставить. Идея кстати хорошая. обязательно реализую, т.к. очень сильно открываются просторы анимации.

[Cr@ZyBoY]

Ок, тогда тоже запишу себе в ToDo.

[Riim]

на мой выбор такого типа циклов повлияла вот эта статья

статья почти правильная, но вот поняли вы ее видимо не совсем правильно, вот эта фраза:

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

про кэширование сказано, но вот ни слова нет о том, в каких ситуациях это кэширование даст прирост производительности. Например, такой код:

obj.prop;
obj.prop;
obj.prop;
obj.prop;

здесь свойство считывается 4 раза, на считывание свойства уходит какое-то время, пусть это время будет X. Всего получается 4X. На перезапись переменной тоже уходит какое-то время, это время в зависимости от браузера может быть больше или меньше X, но не намного и если посмотреть сколько людей пользуются тем или иным браузером, то в среднем можно считать, что на считывание свойства и на перезапись переменной время затрачивается в точности одинаковое. Теперь кэшируем значение:

var t = obj.prop;
t;
t;
t;
t;

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


UPD: не понимаю как без самых основ по оптимизации кода можно браться писать движки для выборки по css-селекторам.

[Cr@ZyBoY]

Riim,
ну, не в большинстве, конечно, но учту в следующий раз.

не понимаю как без самых основ по оптимизации кода можно браться писать движки для выборки по css-селекторам

Меня почему-то совесть не мучает, если учесть, что мой движок быстрее чем Sizzle, base2, DOMAssistant, Prototype, MooTools, Dojo и Peppy.

[Dmitry A. Soshnikov]

Cr@ZyBoY, работа проделана немалая (и по самому фреймворку, и по оформлению сайта, и по PR-у на сайте; главное, чтобы PR соответствовал тому, что есть на самом деле). Как минимум, если фреймворк не станет популярным - Вы набрались опыта. А так - продвигайте, мотивируйте, собирайте комьюнити, возможно, кто-то заинтересуется всерьёз и будет использовать.

Но это будет нелегко, даже несмотря на то, что движок селекторов у Вас быстрее: у монстров типа jQuery и т.д. совершенно другие ресурсы (деньги и т.д.) вбуханы в PR и продвижение.

Успехов

[Cr@ZyBoY]

Спасибо, стараемся Да, денег я, конечно, не вкладываю в пиар, да и молод я ещё... А так уже есть планы по использованию Карбона в движке форума ExBB, вроде на этой неделе собирались устроить конференцию в скайпе, будем обсуждать в том числе и интеграцию моей библиотеки

[PeaceCoder]

вместо четырех считываний свойств (4X) теперь одно считывание и одна перезапись (2X), т. е. производительность улучшилась примерно в два раза

Только Вы забыли что если кешировать простое число или строку то запись в кешированную переменную бессмысленна.

На счет движков селекторов.
В документе 1360 элементов, включая такой HTML

<span id='id1' class='SPAN'>
  <i></i>
  <span id='id3'>
    <i>
      <span>
        <div>
          <b>
            <a class='SPAN1 ppp'>1</a>
          </b>
          <a id='id4'>2</a>
        </div>
      </span>
    </i>
    <span id='id2'>
      <div>
        <b>
          <a id='id3'>3</a>
        </b>
        <a id='id5'>4</a>
      </div>
    </span>
  </span>
</span>

Принудительно во всех движках отключен кеш и возможность querySelectorAll
На запрос (должен выдавать 2 элемента SPAN#id3,A#id3)

#id1 #id3

Такие результаты:
jQ: 0.1576мс, результат: SPAN#id3 (неверно)
Peppy: 0.1869мс, результат: SPAN#id3 (неверно)
DOMAssistant: 1.86мс, результат: SPAN#id3, A#id3 (верно)
CarbonJS: 0.075мс, результат: SPAN#id3 (неверно)

На запрос (должен выдать 2 элемента A#id4,A#id5)

* SPAN I + SPAN DIV B + *

Такие результаты:
jQ: 6.83мс, результат: A#id5 (неверно)
Peppy: 70мс, результат: A#id4,A#id5 (верно)
DOMAssistant: 10.571мс, результат: A#id4,A#id5 (верно)
CarbonJS: 12.84мс, результат: A#id4,A#id5 (верно)

Так что есть над чем подумать, а ктото кричит (по инету слухи) Peppy самая быстрая. Да она самая медленная без кеша и нативных методов.

[Cr@ZyBoY]

PeaceCoder,
попридержите коней. Откуда у вас в html-коде взялось 2 элемента с одним id? Это прямое нарушение стандарта.
По поводу селектора "* SPAN I + SPAN DIV B + *" - вы же не каждый день такую мешанину ищите. На более простых селекторах, которые встречаются чаще всего, Карбон выигрывает.