Comments 42
Кажется, что я правильно разбил их и поэтому доступны только три основных режима
Зачем изобретать велосипед, если есть bootstrap grid system, ставшая стандартом де-факто? Да и называть экраны меньше 980px мобильными телефонами — не верно (тот же iPad 1024×768 ).
Сейчас вообще ничего нельзя сказать с уверенностью просто потому что экраны постоянно становятся больше и больше.
iPad же все же не мобильный телефон.
Мне не нравятся media-queries. Не люблю SASS и LESS, к примеру. А эта штука позволяет моментально и автоматически подцепить нужную CSS-схему. А для коррекции всего-то необходимо отконфижить один из CSS файлов.
Bootstrap для того функционала который я задумывал потянет за собой и jQuery в том числе, а она нынче весит непозволительно много.
Мне же удалось уложиться в какие-то 32кб кода с комментариям в последней версии.
Я не стал поддерживать старые IE с учетом того, что таких пользователей остается единицы и благодаря этому удалось сделать фреймворк минимального веса.
iPad же все же не мобильный телефон.
Мне не нравятся media-queries. Не люблю SASS и LESS, к примеру. А эта штука позволяет моментально и автоматически подцепить нужную CSS-схему. А для коррекции всего-то необходимо отконфижить один из CSS файлов.
Bootstrap для того функционала который я задумывал потянет за собой и jQuery в том числе, а она нынче весит непозволительно много.
Мне же удалось уложиться в какие-то 32кб кода с комментариям в последней версии.
Я не стал поддерживать старые IE с учетом того, что таких пользователей остается единицы и благодаря этому удалось сделать фреймворк минимального веса.
iPad же все же не мобильный телефон.
У меня маленький телефон 1920*1080 ;)
Вы с этой либой опоздали лет минимум на 10.
И даже десять лет назад никто не пользовался бы либой, где команды отдаются строками:
$.dom('.prost div', "del");
$.dom('h1','tog');
Зачем?!
Чтобы было неудобнее?
Чтобы не работало автодополнение?
Чтобы был нечитаемый стектрейс?
Чтобы легче было допустить ошибку?
Почему не самые обычные методы, как 10 лет назад в JQuery?
$.dom('h1').toggle()
>> Почему не самые обычные методы, как 10 лет назад в JQuery?
Постеснялся боянить. Ладно, убедили
Постеснялся боянить. Ладно, убедили
Я однажды упаровшись написал такое: https://github.com/RubaXa/jquery.zen#zen-school ;]
var _append = {
'+': 'append',
'+>': 'appendTo',
'+!': 'prependTo',
'+^': 'insertBefore'
};
Да уж :) Слава богу я до такого пока не дошел. Хорошо! Будет сделано красивое jQuery-style API в версии 2. И, я надеюсь, я все таки не хуже какого нибудь Bootstrap. Ибо обладаю немалым опытом верстки и могу сделать небольшой grid system(но только без БЕМ и LESS — не люблю много тегов и повторения при перестройке).
>> Зачем изобретать велосипед, если есть bootstrap grid system, ставшая стандартом де-факто? Да и называть экраны меньше 980px мобильными телефонами — не верно (тот же iPad 1024×768 ).
Все таки подумав сделал по другому. Теперь схем 5:
1) меньше 480 — мобильные телефоны
2) от 480 до 768 — планшеты
3) от 768 до 960 — планшеты в портретном режиме
4) от 960 до 1280 — десктопная схема минимум
5) больше 1280 — десктопная схема максимум.
Все таки подумав сделал по другому. Теперь схем 5:
1) меньше 480 — мобильные телефоны
2) от 480 до 768 — планшеты
3) от 768 до 960 — планшеты в портретном режиме
4) от 960 до 1280 — десктопная схема минимум
5) больше 1280 — десктопная схема максимум.
Про API это вы о чем именно? Я делал обертки ванильного API только для сложных действий. Например для анимации.
Могу сделать также как у jQuery($(sel).().()), но делать много действий с одними и теми же элементами получается в основном у новичков jQuery. А для каких-то дополнительных функций, если они нужны, я предусмотрел callbacks.
Что бы вы изменили в этом API?
Могу сделать также как у jQuery($(sel).().()), но делать много действий с одними и теми же элементами получается в основном у новичков jQuery. А для каких-то дополнительных функций, если они нужны, я предусмотрел callbacks.
Что бы вы изменили в этом API?
Если вы хотите чтобы библиотекой начали пользоваться, то рекомендую выложить её в NPM и Bower.
Больше походе на невнятный набор хелперов, а размер совсем не микро.
Кроме этого, уже есть Zepto, который умеет намного больше, а главное лучше.
Не знал про Zepto. Есть к чему стремиться, но я не ставил себе цель сделать клон jQuery, как это сделано у Zepto.
Стремиться? Какую нишу вы хотите занять?
Например Zepto поставили цель сделать удобное API для работы DOM, событиями, анимацией, ajax, touch-устройствами и маленький размер. Удобный API для перечисленного — это jQuery-style, как не крути.
Или вот микро библиотека Voyeur пытается предложить альтернативный взгляд, спорный, но всё же альтернативный.
У вас же просто набор методов объединенных единым namespace, который с лихвой покрывают возможности Zepto имеющего тесты, доку и коммьюнити.
Так что взгляните на всё это и подумайте, что же вы хотите, велосипед ради велосипеда (не осуждаю, это нормально, но только для себя в рамках образования) или альтернативный вариант/свежий взгляд?
>> Стремиться? Какую нишу вы хотите занять?
Осуждаете…
>> У вас же просто набор методов объединенных единым namespace, который с лихвой покрывают возможности Zepto имеющего тесты, доку и коммьюнити.
Чтобы никто не схватил и не начал потом жаловаться на сильные изменения я прислушиваюсь ко всем на стадии beta. С чего-то надо начинать.
Да без проблем. Во второй версии я сделаю такие же нунчаки как у jQuery, если уж другое кажется смешным.
Осуждаете…
>> У вас же просто набор методов объединенных единым namespace, который с лихвой покрывают возможности Zepto имеющего тесты, доку и коммьюнити.
Чтобы никто не схватил и не начал потом жаловаться на сильные изменения я прислушиваюсь ко всем на стадии beta. С чего-то надо начинать.
Да без проблем. Во второй версии я сделаю такие же нунчаки как у jQuery, если уж другое кажется смешным.
> Zepto имеющего тесты, доку и коммьюнити
Сделал первый релиз версии 1.5.3(https://github.com/xShiftx/javascript-framework/releases протестировал все что мог) документация на английском написана.
Дело осталось за коммьюнити так как идеи для модулей у меня закончились.
Буду ждать предложений и просьб о реализации, если мой фреймворк начнет хоть как-то использоваться.
Сделал первый релиз версии 1.5.3(https://github.com/xShiftx/javascript-framework/releases протестировал все что мог) документация на английском написана.
Дело осталось за коммьюнити так как идеи для модулей у меня закончились.
Буду ждать предложений и просьб о реализации, если мой фреймворк начнет хоть как-то использоваться.
протестировал все что мог
Эээ… okay ;]
я руками проверяю. какие еще тесты могут быть нужны?
примеры кода есть в документации в Readme.MD…
примеры кода есть в документации в Readme.MD…
У меня регресси только на эффектах анимации. Пришлось почти с нуля разбираться и писать формулы поштучно тестируя эти самые регрессии. Все относительно правильно.
Или вы у меня в коде где-то еще их нашли?
Или вы у меня в коде где-то еще их нашли?
Я вам объясню. Хороший фреймворк — это такой фреймворк, который постоянно развивается, быстро реагирует на запросы и при этом новые версии не ломают старый функционал неожиданными багами.
Допустим, мы вам поверим, что ваш фреймворк в данном виде идеально вручную протестирован. Но все множество вариантов его использования стремится к бесконечности и с каждой версией вы перепроверяете только небольшую область, которую, как вы предполагаете, является найболее чувствительной к багам.
К сожалению, из-за усталости от одного и того же каждый раз эта область будет сокращаться. Но даже, допустим, она не будет сокращаться, это не так важно.
Любой код имеет такую особенность, что в нем возможны баги. И часто в самых неожиданных местах. Иногда баги появляются не там, где вы ожидали. Например, вы правили где-то часть, которая отвечает за ДОМ, а оно повлияло на анимацию в одном определенном редком случае. Это и называется регрессией — когда изменения в коде заставили функционал, который ранее работал корректно сейчас работать некорректно. Регрессии практически очень сложно проверять руками, ибо для этого необходимо делать полное тестирование всего функционала (тем более в JS, уж я то знаю) в любой комбинации.
А вот автоматические юнит-тесты дают пользователям вашего фреймворка гарантию, что хотя бы то, что ими покрыто работает так, как в них описано.
Более того, допустим, вы — программист, посланный нам самой вселенной как благословление и никогда не допускаете ошибок, к сожалению ваше время ограничено и для прекрасного развития вашего фреймворка обязательно участие других программистов, а они, к сожалению, допускают баги.
Потому фреймворк, не покрытый тестами от и до имеет мало шанса на выживание и интерес широкой публики.
Допустим, мы вам поверим, что ваш фреймворк в данном виде идеально вручную протестирован. Но все множество вариантов его использования стремится к бесконечности и с каждой версией вы перепроверяете только небольшую область, которую, как вы предполагаете, является найболее чувствительной к багам.
К сожалению, из-за усталости от одного и того же каждый раз эта область будет сокращаться. Но даже, допустим, она не будет сокращаться, это не так важно.
Любой код имеет такую особенность, что в нем возможны баги. И часто в самых неожиданных местах. Иногда баги появляются не там, где вы ожидали. Например, вы правили где-то часть, которая отвечает за ДОМ, а оно повлияло на анимацию в одном определенном редком случае. Это и называется регрессией — когда изменения в коде заставили функционал, который ранее работал корректно сейчас работать некорректно. Регрессии практически очень сложно проверять руками, ибо для этого необходимо делать полное тестирование всего функционала (тем более в JS, уж я то знаю) в любой комбинации.
А вот автоматические юнит-тесты дают пользователям вашего фреймворка гарантию, что хотя бы то, что ими покрыто работает так, как в них описано.
Более того, допустим, вы — программист, посланный нам самой вселенной как благословление и никогда не допускаете ошибок, к сожалению ваше время ограничено и для прекрасного развития вашего фреймворка обязательно участие других программистов, а они, к сожалению, допускают баги.
Потому фреймворк, не покрытый тестами от и до имеет мало шанса на выживание и интерес широкой публики.
А чем эта библиотека лучше jQuery?
Не утверждаю, что написал лучше или хуже, но вот например jQuery не умеет так:
А evolution так умеет:
Обратите внимание на разные easing и разное время анимации для каждого из CSS свойств.
(:
$('div').animate({'border-radius':'20px 50px 200px 10px'},1000)
А evolution так умеет:
$.dom("#mainContents","animate",['border-radius:25px 10px 15px 5px:1000:circ','opacity:1:2000']);
Обратите внимание на разные easing и разное время анимации для каждого из CSS свойств.
(:
Правильнее, только если вы в 2016 году не тянете за собой IE<10 которые их не поддерживают.
Так сейчас у всех используются современные браузеры и даже если речь об IE, то и у них в качестве движка по умолчанию все обновляется до Edge(речь не идет о тех, кто отключил обновление системы умышленно — они продивинутые и у них навряд ли нет того же Chrome).
Я пользователей Windows XP уже своей целевой аудиторией не считаю, да и те пользуются или Opera или Chrome, что равнозначно из-за webkit.
В общем их единицы единичные.
Нужен ли этот fallback?
Я пользователей Windows XP уже своей целевой аудиторией не считаю, да и те пользуются или Opera или Chrome, что равнозначно из-за webkit.
В общем их единицы единичные.
Нужен ли этот fallback?
Писать этот бардак в inline или переключать тысячу классов? Можно и так, но мне было удобнее через JS.
Со временем, кстати, планирую добавить и поддержку CSS-animations(rotate, translate, skew и т.д.)
Со временем, кстати, планирую добавить и поддержку CSS-animations(rotate, translate, skew и т.д.)
Sign up to leave a comment.
Front-end JavaScript framework Evolution beta