Pull to refresh
45
0
Андрей Губанов @Finom

Веб разработчик

Send message
Это, кстати, единственный юз-кейс, когда мне приходилось подключать jQuery. Очень много инструментов требуют зависимости от jQuery либо из-за лени или отсутствия знаний разработчика, либо из-за того, что инструмент достаточно древний. Сейчас не знаю, как с этим дела, надеюсь, лучше.
Это не библиотека, а одна функция и её скачивать (подключать через script) не надо.
1. легче чем jquery?
Зависит от пдерживаемых браузеров.
2. удобней чем jquery?
Это холиварный вопрос. Для меня — да.
3. функциональней чем jquery?
Да.
Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней?
Да. В качестве параллели могу пивести PostCSS. В в нем нет ничего, нужно юзать плагины а свой вкус. В SASS есть всё. Но всё больше людей используют PostCSS (в том числе и я). Да и полифилы вряд ли можно назвать инструментами. Скорее, это — костыли для старых браузеров.
Вы забыли описать самое главное — какие преимущества?
Какие преимущества нативного DOM? Окей.
1. Максимальная скорость работы кода.
2. Полный контроль над работой DOM.
3. Отсутствие зависимостей.
4. Меньший размер результирующего файла.
5. Полифилы можно выпилить со временем, библиотеку — нет.
Я проигнорирую фразу «Откуда вы такие берётесь?» и постараюсь ответить.
Вы называете кроссбраузерными методы, работающие в Android-браузере и IE только через префиксы? Серьёзно?

Да, действительно. Вот вам решение:
Element.prototype.matches = Element.prototype.matches || Element.prototype.webkitMatchesSelector || Element.prototype.msMatchesSelector;


То есть обязательно.

Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.

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

Вы описываете проблемы, не предлагая никакого решения. А решение такое: подключать полифилы безусловно и не пользоваться polyfill.io, если страницу посещает много таких пользователей. Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.

Вы предлагаете вместо старой проверенной и надёжной jQuery, которая умеет почти всё, что вообще может придти в голову, использовать библиотеку с 4 методами и 3 (три) полифила для неё.

Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача. Если не нравится, то можно юзать querySelector[All]. Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек.

DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
Это большая библиотека (хорошая, кстати), таких очень много. bala.js селектит элементы на странице, не более того.
Так сильно сжать код, при этом сделав его читабельным — достаточно сложно. Я попробую расставить табы, спасибо за мысль.
Я не понимаю, как это касается Матрешки, там всё по-прежнему на месте.
Создание сервера сборки, к сожалению, штука очень трудозатратная. Если еще интересуетесь фреймворком, я могу предложить вот эту штуку. Вся функциональность, отвеающая за классы там отсутствует (хотя, много лишнего может быть для вас).
О ней я и говорил в посте, когда писал о двух переменных ($, $$). Если брать примеры с главной страницы, то всё это можно сделать средствами, которые я описал (анимация, fetch).
И совершенно сразу пропадает желание вручную писать

Для небольшого проекта такой код приемлем. Для большого — юзайте фреймворки, иначе получете макароны.

Если говорить о bala.js, то с Babel или без него (в случае поддержки только современных браузеров, например, при создании приложения под Electron), вы получете такой код:
for(let node of $('.xyz')) {
  node.insertAdjacentHTML('beforeend', '<xyz />');
}
Злой у вас комментарий какой-то.
Мне, как разработчику своего велосипеда фреймворка такое поведение тоже не ясно. Любой фреймворк, на мой взгляд, должен ставить цель расширить круг полезных инструментов, а не монополизировать рынок.
А что если, вместо БЭМ и модулей принять соглашение о том, что каждый виджет должен быть изолирован своим «главным» классом?

.awesome-module {
	.button {
		&.disabled {
			//...
		}
	}
}

.cool-module {
	.button {
		&.disabled {
			//...
		}
	}
}


Мне нравится идея изоляции CSS, но я не понимаю, зачем такие костыли.
На работу летать такой хочу.
Спасибо. Только не очевидно, как это юзать. Может, в айфрейме запускать тесты?
А ссылку можно?
Не вижу смысла копипастить. Матрешка — фреймворк с наследованием. Если у вас есть несколько общих черт нескольких виджетов, создайте общий класс.

Вьюху можно назвать «байндингами».
Я немного сомневаюсь в этом тесте. Рендеринг (или серверный пререндеринг) большого количества элементов вызывает тормоза страницы, которые решаются костылями, типа этого. Может, сделаете многократную перерисовку меньшего числа элементов?

Просто мысли в слух: в идеале хотелось бы получить альтернативу jsperf, который объективно замеряет скорость операций. В jsperf я разочеровался после этого теста. Консольный тест с jsperf расходится в 450 раз!
Спасибо, приятно слышать.

Information

Rating
Does not participate
Location
Одесса, Одесская обл., Украина
Date of birth
Registered
Activity