CAMOKPYT: Вы что думаете порог входа в один большой Angular/Ember/etc. меньше чем в пару небольших либ? Вот как раз наоборот - либы вы добавляете по мере необходимости и достаточно быстро можете получить готовый продукт. А вот если вы новичок в большом фреймворке - до релиза долго идти. Если одна из маленьких либ устареет так что её нельзя использовать - она меняется на другую. Тот же React никак не привязан ни к Flux, ни к Redux - в самом крайнем случае можно свой велик для части системы запилить. А что будет если перестанут поддерживать большой фреймворк? Придётся перепиливать весь проект с нуля. Или вот у Angular 1 были большие проблемы с производительностью - aviasales ручками там внутри правили под свои нужды - это проще чем править / заменить маленькую либу? Или тупо не будут успевать фичи за вашими хотелками добавлять? Это повсеместно.
Я вижу такие варианты:
1. можно сгенерить код подобным выше образом, потом сделать toString, передать на клиент - сделать eval
2. можно просто генерить с помощью шаблонизатора из строки: 'var myFun = function(){, }', передавать на клиент - делать eval
или генерировать код в шаблонизаторе и выполнять new Function
var func = new Function('console.log(1)');
console.log(func());
Тогда так:
for (var prop in settings){
if(settings.hasOwnProperty(prop)){
if(prop === 'messages'){
var value = settings[prop] === 'on' ? true : false;
window._Global[prop] = value;
}
if(prop === 'video'){
var value = settings[prop] === 'on' ? true : false;
window._Global[prop] = value;
}
...
}
Пробегаем по каждому свойству в settings и добавляем свойство в window._Global с обработкой на основе него.
littleguga: Перепишите без jQuery что-нибудь мифическое типа этого: $('.my-element').find('.first').addClass('yellow').show().append('Yay!').val('Trum-tum-tum'). Сколько строк получилось? И так ведь почти в любом месте где используется jQuery - одну строку менять на несколько. (Хреновый пример, но суть отражает) В любом случае рано или поздно встанет вопрос о том чтобы писать обёртку над JS для частых операций. И зачем это нужно, когда можно использовать готовое протестированное решение?
По-поводу Zepto - API, как я понимаю, не 100% совместимо с jQuery - есть риск что сторонняя библиотека требующая jQuery (которых обычно несколько в проектах) не сработается с ней. Зачем париться и придумывать себе новые баги? А вот на этапе оптимизации, или в мобильной версии сайта, можно попробовать прикрутить.
Janiba: Про отдельно не продаётся - я имею ввиду Apple - Cinema Display не обновили. Если ссылки на мониторы с этой же матрицей кинете - буду благодарен.
Под MacPro 13 подразумевался Macbook Pro 13 - моя опечатка, но если бы Вы читали тот комментарий на который я ответил - Вы бы поняли.
4K и 5K - разные разрешения и требования к ним разные.
Он конечно сократит некоторую часть кода (причём не ту что сократит jQuery), но суть моего комментария это не меняет - не фиг писать с нуля велосипеды (если это не этап обучения) и оптимизировать там где не надо, если есть готовые удобные пути.
На iMac 27 монитор 5К - отдельно такой не продаётся. И даже если найдёте не от Apple - далеко не факт что MacPro 13 его потянет - так что осторожнее с такими советами.
littleguga: Расширению не нужно грузиться за 2 секунды, как сайту - оно имеет право устанавливаться как программа в первый раз, так что экономить на спичках - не лучшая идея. Плюс jQuery существенно менее многословный чем JavaScript - этого более чем достаточно для его использования, если хотите писать хорошо поддерживаемый код.
natoster: Так а что такое 100К? Для разработчика плавно переходящего из джуниора в мидла - это 2 месяца работы. Сайт в Вашем т.з. не смотрел, но если это не вёрстка натянутая на вордпресс, а что-то посложнее - на меньший срок рассчитывать не следует.
