Осторожно Холивар! JavaScript vs Библиотеки

[vflash]

Андрей Параничев,
при таком раскладе "00000000000000000" тоже не число, и ' 00012343' тоже. мне вообще то не понравился регексп, который непойми где определен и стоит ли его там использовать ради зашиты от дураков.

нативный isNaN() расчитан на работу с числами.


библиотеки нужны. и было-бы хорошо если на javascript.ru имелась бы приличная коллекция самых востребованных вещей.


.

[Андрей Параничев]

vflash,
Нативный isNaN() не строгий. Для внутренних нужд jQuery необходим строгий isNaN(), отсюда и регулярка. И это не от дураков скорее, эта проверка ведь срабатывает при парсинге свойств стилей тех же самых, в т.ч. возвращаемых браузером.

.each() удобен для обходя коллекций DOM элементов, получаемых через jQuery. А приведенный код, ну это просто для красоты так сделано, можно было до сделать все "напрямую", или использовать стандартный цикл, конечно, я не знаю, почему конкретно в этом месте сделали так.

[vflash]

Андрей Параничев,
each удобен но медлен. в IE8 вызов функции относительно медленная операция. да и в js вообше вызов функции это создание области видимости, arguments и еше всякого там. для быстрого кодинга это удобно а для библиотеки могли бы и постараться без него.

по поводу размера 233кб исходника, нехило так для маленькой библиотеки )

[x-yuri]

Андрей Параничев, а мое сообщение ты не заметил? В общем-то меня в первую очередь интересует, как ты решаешь этот вопрос:

Банальный пример, есть две страницы: gallery.html и comments.html, подключается один скрипт. Ну вы понимаете, роутинга нет, нужно что-то придумывать самому. Проблемы тут, по сути, нет, написать самому просто.

по поводу jquery у тебя впечатления скорее всего другие. И...

Для мобильного интернета нужны мобильные версии сайтов, если речь не про 3G.

а если 3G?

p.s. наткнулся на вот такую статью (только не надо судить сразу по заголовку). И вот здесь еще краткий взгляд на историю javascript неплохо получился (A brief (and partially fabricated) history of JavaScript)

[Андрей Параничев]

vflash,

по поводу размера 233кб исходника, нехило так для маленькой библиотеки )

PRODUCTION (31KB, Minified and Gzipped)

в IE8 вызов функции относительно медленная операция.

Мда. Надеюсь медленная настолько, что можно пренебречь.

x-yuri
Я как-то так примерно делаю. Не слишком лаконично, зато удобно поддерживать код в будущем. Собственно текущий вид я определяю обычно или на основе url, что не самое удобное решение, либо на основе id у элемента body, который проставляется серверной частью.

Если 3G, то смысл вообще что-то оптимизировать? Скорости 3G достаточно, чтобы есть файлы целиком и даже смотреть видео на youtube в 720р.

[vflash]

Андрей Параничев,
а когдато была всего ~18 и без Minified .

Мда. Надеюсь медленная настолько, что можно пренебречь.

в квери addClass переписали на циклы не по прихоти же. в событиях вроде когдато видел засилье each, а если событие весит на mousemove то эти копейки хорошо почувствуются.

когда-то про js тоже говорили что ему ненужно быть быстрым.

[x-yuri]

Я как-то так примерно делаю. Не слишком лаконично, зато удобно поддерживать код в будущем. Собственно текущий вид я определяю обычно или на основе url, что не самое удобное решение, либо на основе id у элемента body, который проставляется серверной частью.

насколько я понял, первая проблема, которую он решает - организация кода. Но почему не пойти дальше? Вторая... Пример в статье - абстрактный. Можно какой-нибудь конкретный пример привести?

p.s. пользуясь случаем, хочу передать при... ну просто вы тут все... или почти все... другими словами, тестируете ли вы свой код? (это не предложение развивать здесь эту тему, если что)

[DreamTheater]

Библиотеки уменьшают время разработки больших приложений, но при этом разработчик не может на 100% понимать как это работает и какие еще алгоритмы отрабатывают внутри библиотеки, что иногда может привести к совершенно непредсказуемым багам. При программинге на чистом JS разработчик всегда знает что и где он писал (если он один, конечно), и чистый JS, как правило, работает намного быстрее библиотек, хотя тут уже все зависит от коэффициента кривизны рук девелопера. Ну и не забываем о том что библиотеки несут в себе избыточный код для обеспечения поддержки старых браузеров и функционал который никак не задействован в продукте.

[Gozar]

К тому же средние скорости из статистики же взяты, а не с потолка. Только недавно на хабре была статья про это.

Взяты они из такой же абстрактной статистики как и большая часть статистики. Шум на хабре не влияет на статистику в отрасли в которой хабр не участвует.
Разговор ни о чём получается.

PHP тоже подобием jquery когда-то был

По сути:
Когда качество приложения ставится на первое место выбираются те инструменты которые нужны для разработки. Иногда выбирается отсутствие jquery в основном коде и подключение её в готовый продукт, в котором нет ни одной строчки на ней и любой другой библиотеке.