Ок. Прочесть то что чуть ниже никак?

очень распространенное заблуждение, либо у тебя задачи такие, подходящие

не согласен, у каждый из двух подходов удобен в соответствующей ситуации, а выдавать ошибки... не вижу в этом необходимости

насколько больше?

На одну проверку больше: один элемент, делаем это, больше — делаем то.Ну вот человек ошибся в селекторе, срипт выдал экзепшн "синтакс эррор" и фиг поймешь, в какой строке и к чему относится этот экзепшн. Так ему просто в консоли сообщать: с селектором трабл. Или другая ситуация: селектор вернул 0 элементов, человек применяет цепочку методов, но ничего не происходит. Что делать? Мне кажется вполне логичным написать в консоли, что элементов ноль, и что ничего происходить не должно.

Ну как же, когда мы пишем на чистом JS:

document.querySelector("#btn").className += "active";

то получим
фреймворк просто сокращает запись:

$("#btn").addClass("active");

почему мы не должны ждать такой же ошибки?

а вот, когда работаем с коллекцией, то отсутствие ошибок вполне логично:

var list = document.querySelectorAll(".btn"), i = list.length;
while (i--) {
    …
}

или

$(".btn").addClass("active")

тут программист берет в расчет, что элементов в коллекции может и не быть, и никакие действия не выполнятся, что на чистом JS, что с помощью jQuery.

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

function $(selector) {
    return new $Node(document.querySelector(selector));
}

function $$(selector) {
   return new $NodeList(document.querySelectorAll(selector));
}

function $Node(node) {
   this.node = node;
}

$Node.prototype = {
   addClass: …,
   …
   remove: …,
   …
   parent: …,
   …
};

function $NodeList(list) {
   this.list = list;
}

$NodeList.prototype = {
   first: …,
   …
   last: …,
   …
   each: …,
   …
};

никакого дублирования методов не нужно:

$$("selector").each("method", arguments)

и в коде будет наглядно:

$(selector).remove();
$$(selector).each("remove")

потому, что имхо это чуть разные вещи.
в случае с querySelector это лишь возврат функции которая может возвращать объекты разных типов(что в общем-то наверное не совсем правильно).
когда мы работаем с выборкой, то хочется единого АПИ в независимости есть в выборке элементы или нет(в конце концов это просто состояние объекта)
на практике позволяет в клиентском коде избегать ненужных if-в.

ЗЫ про style сенкс. не догадывался что есть такая особенность.

а вообще тс странный. и вступительная речь тоже.
мне например чтобы перевести своё детище на поддержку только "правильных" браузеров понадобиться ну час мб. jquery ну пускай день два.
Лично мне видится её главным недостатком(ну по крайней мере сейчас, когда я не спал сколько там... 22 часа) - сверх универсальность. Под конкретные задачи можно сделать лучше. Иногода это критично.
Посему к тсу - чтобы делать свой ворк/библиотеку нужен какой-то мотиватор, какая-то задача. Без этого быстро надоест.

float, чем не задача сделать либу быстрее, чем jQuery, но с совместимостью кода?

В общем эта тема превращается в срач, один предлагает поддерживать старые версии ИЕ и критикует сообщения прочитав только половину, другой говорит, что нужно создать отдельные методы для одиночиых элементов, по сути отдельную библиотеку, третий обзывает меня странным, при этом сказав, что за пару часов перепишет jQuery, сделав то же самое что и я. Остальным спасибо за помощь. Если что-то будет готово, сообщу. В срачах учавствовать не буду. На всякий случай, по совету melky запилю на гитхаб после нормальной реализации метода animate.

И что мне твое ниже даст?

пример:

<style>
div {
    width: 200px;
    height: 200px;
}
</style>
<div id="owner">
    <div id="child"></div>
</div>
 
<script>

function yourStyle( elem, prop ) {
    return elem.style[prop] ||
                    elem.ownerDocument.defaultView.getComputedStyle( elem, null ).getPropertyValue( prop );
}
 
function style( elem ) {
    if ( elem.ownerDocument && elem.ownerDocument.defaultView ) {
        return elem.ownerDocument.defaultView.getComputedStyle( elem, null );
    } else if ( elem.currentStyle ) {
        return elem.currentStyle;
    }
    return null;
}

var elem = document.getElementById('owner');

// проверяем твоей:
alert( [ yourStyle( elem, 'width' ), yourStyle( elem, 'height' ) ] );
// проверяем моей:
alert([ style( elem ).width , style( elem ).height ]);


// меняем ширину у элементов:
document.getElementById( 'owner' ).style.width = "auto";
document.getElementById( 'child' ).style.width = "300px";


// снова проверяем родителя:

// проверяем твоей:
alert( [ yourStyle( elem, 'width' ), yourStyle( elem, 'height' ) ] );
// проверяем моей:
alert([ style( elem ).width , style( elem ).height ]);


</script>

выводы о значительности каждый делает сам... учитывая то, что "один элемент, делаем это" - это частный случай "больше — делаем то"

опять абстрактные примеры? Обычно ты делаешь и проверяешь по ходу. И даже потом не сложно найти ошибку. Если сложно, тогда да, надо ее выдавать.

вопрос не в последовательности а в том, будет ли это заметной помощью

недостаток этого метода в том, что надо проверять существует ли объект: [jQuery] $('#id').addClass(...), [твой вариант] $('#id') && $('#id').addClass(...) ну или $$('#id').addClass(...), но тогда мы используем $$, несмотря на то, что нас интересует один элемент. Недостаток jQuery в том, что если надо получить доступ к этому одному элементу, надо писать $('#id')[0], вместо $('#id'). Может что-то забыл.

хуже, я бы сказал, что библиотеки должны получаться в результате решения задач, а не наоборот ;)

"Вы мне, пожалуйста, все тут давайте советы, но если они мне не понравяться, я вас слушать не буду, так что не обижайтесь..."