Комментарии 68
Было бы неплохо подкрепить примером, я например не встречал подобных фреймворков на своей практике(но это конечно же не значит что их совсем нет).
Хватить вешать одну и ту же лапшу про велосипед! Ваши «известные фреймворки» делались на такой же человеческой коленке.
Да, но они уже прошли период, когда их никто не использует, кроме автора. Большое коммюнити и постоянное развитие — большой плюс.
Вы размерами-то не меряйтесь. Большое коммьюнити может быть маленьким по отдаче. А постоянное развитие может быть следствием постоянных исправлений.
Под развитием я понимаю в первую очередь добавление нового и улучшение старого.
Исправление ошибок — это тоже хорошо, если их количество уменьшается.
Большое коммьюнити может быть маленьким по отдаче.
Вероятность того, что большое коммюнити будет отдавать больше, гораздо выше. Больше пользователей, больше заинтересованных людей, больше отдача.
Исправление ошибок — это тоже хорошо, если их количество уменьшается.
Большое коммьюнити может быть маленьким по отдаче.
Вероятность того, что большое коммюнити будет отдавать больше, гораздо выше. Больше пользователей, больше заинтересованных людей, больше отдача.
Но потом получили широкое распространение, имеют обширное комьюнити, документацию, постоянно развиваются (и цель развития фреймворка — сам фреймворк).
Все когда-то начиналось делаца на коленке. Но не факт, что ваш очередной велосипед собраный посредством «ну, вот надо бы сделать так, что бы потом… в будущем неприходилось переписывать и дописывать», с утерянной документацией и знанием кода только двух-трех человек сможет вырасти в действительно фреймворк, которым захотят пользоватся другие люди, потому что он удобен и не только вам, для ваших проектов, потому что вы так привыкли.
Все когда-то начиналось делаца на коленке. Но не факт, что ваш очередной велосипед собраный посредством «ну, вот надо бы сделать так, что бы потом… в будущем неприходилось переписывать и дописывать», с утерянной документацией и знанием кода только двух-трех человек сможет вырасти в действительно фреймворк, которым захотят пользоватся другие люди, потому что он удобен и не только вам, для ваших проектов, потому что вы так привыкли.
не будьте пессимистом ;)
Я буду оптимистом!
Я верю в разработчиков, которые пишут документацию.
Я верю в разработчиков, которые не делают ошибок.
Я верю в разработчиков, которых всегда можно спросить о функции, которую они делали 3 года назад вот в том модуле.
Я верю в разработчиков, которые работают бесплатно.
Какие-то роботы получаются. :)
Я верю в разработчиков, которые пишут документацию.
Я верю в разработчиков, которые не делают ошибок.
Я верю в разработчиков, которых всегда можно спросить о функции, которую они делали 3 года назад вот в том модуле.
Я верю в разработчиков, которые работают бесплатно.
Какие-то роботы получаются. :)
А если то, что придумал Джон совсем не говно? И если не только Петя его использует. И если я могу использовать то, что придумал Джон, гораздо эффективнее и мне это обойдется дешевле?
Мы говорим о разных вещах
Прорыв делается гением в гараже. Или специалистом в исследовательском центре. При чем ему на эти исследования дали денег.
Если же мы говорим о работе, за которую платят, есть четкие требования, вполне четкие сроки и деньги. Если вы будете делать заново вещи, которые не нужно делать заново, вы не уложитесь в эти сроки и деньги. Клиент уйдет к другому исполнителю. Прорывы в таких условиях делаются очень редко.
Прорыв делается гением в гараже. Или специалистом в исследовательском центре. При чем ему на эти исследования дали денег.
Если же мы говорим о работе, за которую платят, есть четкие требования, вполне четкие сроки и деньги. Если вы будете делать заново вещи, которые не нужно делать заново, вы не уложитесь в эти сроки и деньги. Клиент уйдет к другому исполнителю. Прорывы в таких условиях делаются очень редко.
В идеале, решение о целесообразности применения тех, или иных библиотек, должен принимать человек компетентный, который сможет взвесить все «за» и «против». Архитектор, например.
привет — я из тех, кто лучше загрузит фреймворк в 50 кб, чем напишу то что вы написали
такое допустимо только в макетах вёрстки, как и инлайн-стили
вы уверены, что хотите об этом поговорить?
такое допустимо только в макетах вёрстки, как и инлайн-стили
вы уверены, что хотите об этом поговорить?
1. потому что во всех проектах, где я участвовал и где так делали с самого начала — они все доходили до той точки, когда проще было переписать все с нуля, чем что-то менять
2. лень, нецелесообразность
и почитайте топик про разбитые окна
любой мало-мальски опытный разработчик это понимает
2. лень, нецелесообразность
и почитайте топик про разбитые окна
любой мало-мальски опытный разработчик это понимает
>> Или Вы тоже относитесь к людям, изучающим jQuery вместо Javascript?
до изучения jQuery я успел написать два своих JS-фреймворка
ну, что я могу теперь сказать — на ошибках учатся, как-то так ;)
>> Я думаю, не стоит оценивать уровень незнакомого разработчика, сравнивая его с собой.
вы очень хотите увидеть то чего нет — или покажите мне, где я кого-то с кем-то сравнивал
>> Вы обрекаете проект на медленную смерть в случае смерти фреймворка.
эти басни, про «фреймворкокапец» и вообше «чего-угодно-капец» я слышу регулярно во всех областях IT — только вот почему-то объекты предсказаний таких нострадамусов всё никак не дохнут и не дохнут
до изучения jQuery я успел написать два своих JS-фреймворка
ну, что я могу теперь сказать — на ошибках учатся, как-то так ;)
>> Я думаю, не стоит оценивать уровень незнакомого разработчика, сравнивая его с собой.
вы очень хотите увидеть то чего нет — или покажите мне, где я кого-то с кем-то сравнивал
>> Вы обрекаете проект на медленную смерть в случае смерти фреймворка.
эти басни, про «фреймворкокапец» и вообше «чего-угодно-капец» я слышу регулярно во всех областях IT — только вот почему-то объекты предсказаний таких нострадамусов всё никак не дохнут и не дохнут
>> Сформулируйте ответ более четко, пожалуйста.
вы не понимаете, чего просите — я не могу вот так взять и кристаллизовать experience в слова; если бы мог — писал бы книги :)
>> Фреймворкокапец более вероятен, чем загаживание проекта
ну какой, простихоспади, фреймворкокапец, загаживания проекта, документация… тред начался с примера инлайн-кода и обсуждения, подключать ли jQuery (кстати, 14 килобайт, а не 50) из-за этого
я не собираюсь здесь обсуждать судьбы проектов настолько больших, долгоживущих и самостоятельных, что годы будут проходить, фреймворки создаваться и разрушаться — а проекты эти будут стоять
вы создаёте TEH DRAMA на ровном месте
вы не понимаете, чего просите — я не могу вот так взять и кристаллизовать experience в слова; если бы мог — писал бы книги :)
>> Фреймворкокапец более вероятен, чем загаживание проекта
ну какой, простихоспади, фреймворкокапец, загаживания проекта, документация… тред начался с примера инлайн-кода и обсуждения, подключать ли jQuery (кстати, 14 килобайт, а не 50) из-за этого
я не собираюсь здесь обсуждать судьбы проектов настолько больших, долгоживущих и самостоятельных, что годы будут проходить, фреймворки создаваться и разрушаться — а проекты эти будут стоять
вы создаёте TEH DRAMA на ровном месте
когда страница весит 100 килобайт, то ± 14 кб меня мало волнуют
я не фанатик какой
а вообще, спасибо за понимание, и вам всего доброго :)
я не фанатик какой
а вообще, спасибо за понимание, и вам всего доброго :)
> Вы готовы увеличить размер страницы на 14 кБ ради собственного удобства вопреки удобству пользователя
Конструкциями, подобными этим — document.getElementById('something').style.color='#ffffff', Вы увеличите размер страницы на 140 Кб.
Пример не очень удачный. Вы хотели сказать, что можно сделать легче и лучше «общепризнанных и популярных» фреймворков (и это, естественно, так!), но привели пример не подходящий для контраргумента.
Конструкциями, подобными этим — document.getElementById('something').style.color='#ffffff', Вы увеличите размер страницы на 140 Кб.
Пример не очень удачный. Вы хотели сказать, что можно сделать легче и лучше «общепризнанных и популярных» фреймворков (и это, естественно, так!), но привели пример не подходящий для контраргумента.
> и это, естественно, так!
Не докажешь ты никому свою «естественность», и восклицательные знаки не помогут. Оборона не пошатнётся — велосипеды будут уже придуманы, контрпримеры будут неубедительными (чтоб убедить, или садись и пиши популярную либу в ответку, или не вякай вообще), и всегда покажут тебе пальцем на микрогуглояндексы, «которые это используют», а там не дураки сидят, значит что?..., дурак — ты. Они ж не фанатики какие. Понимать надо. ;)
Не докажешь ты никому свою «естественность», и восклицательные знаки не помогут. Оборона не пошатнётся — велосипеды будут уже придуманы, контрпримеры будут неубедительными (чтоб убедить, или садись и пиши популярную либу в ответку, или не вякай вообще), и всегда покажут тебе пальцем на микрогуглояндексы, «которые это используют», а там не дураки сидят, значит что?..., дурак — ты. Они ж не фанатики какие. Понимать надо. ;)
Ну, сто раз уже говорили про это. К тому же, человек сам признаётся, что «наука» его мало интересует в эти моменты, у него цель другая — в кротчайшие сроки получить деньги от заказчика.
@all:
Кому интересно, можете почитать одну из дискуссий на эту тему — javascript.ru/forum/offtopic/2813-storonnie-biblioteki-byt-ili-ne-byt.html
@all:
Кому интересно, можете почитать одну из дискуссий на эту тему — javascript.ru/forum/offtopic/2813-storonnie-biblioteki-byt-ili-ne-byt.html
У тебя это «наука», у кого-то «фанатизм»..., а на поверку — всё это отмазки от ответственной самостоятельной профессиональной работы. Вот где зло-то. ;)
> а на поверку — всё это отмазки от ответственной самостоятельной профессиональной работы
У меня нет таких отмазок (да и вообще отмазок). Не понял, что ты имел в виду. А «наука» было сказано на это (что, поясняю, значило: «не хочется углубляться в изучение, когда можно быстро срубить бабло»):
> Прорыв делается гением в гараже. Или специалистом в исследовательском центре… Если же мы говорим о работе, за которую платят, есть четкие требования, вполне четкие сроки и деньги.
У меня нет таких отмазок (да и вообще отмазок). Не понял, что ты имел в виду. А «наука» было сказано на это (что, поясняю, значило: «не хочется углубляться в изучение, когда можно быстро срубить бабло»):
> Прорыв делается гением в гараже. Или специалистом в исследовательском центре… Если же мы говорим о работе, за которую платят, есть четкие требования, вполне четкие сроки и деньги.
Не у тебя отмазки, а терминология, которая обычную ответственную компетентную профессиональную работу программиста называет наукой, фанатизмом, велосипедом и т.д. Зато безответственный копипаст чужого — это для клиента, для скорости, для денег. Раньше копипастили со скриптопомоек, сейчас делают то же самое, только место другое, скрипт больше, документирован лучше и вообще. ;) Я понимаю причины и вижу выгоды, меня удивляет, что многие программисты не только не стесняются этого или молчат (виноват, не смог сам, не петрю, некогда, время-деньги и проч.), а приветствуют такой подход, пропагандируют его, распространяют. Это уже клан.
На самом деле правильнее загрузить framework.
Во-первых, он обычно грузится один раз в шаблоне сайта;
Во-вторых, такой код читабельнее и реюзабельнее.
теперь просто используем нужный класс сколько угодно раз…
Во-первых, он обычно грузится один раз в шаблоне сайта;
Во-вторых, такой код читабельнее и реюзабельнее.
$('.white-something').click(function(e)
{
e.preventDefault();
$('#something').css('color', 'white');
});
теперь просто используем нужный класс сколько угодно раз…
Код нечитаемый — ничего не говорит тому программисту, который знает js, но не знает либу, код безграмотный — даже объяснять не буду почему ввиду очевидности, код неудобный в отладке — это до кучи. Что касается реюза, то это вообще нонсенс, т.к. в примере нарисован вызов процедуры, само «реюзаемое» мясо за кадром, точно такое же мясо, только точечное, оптимальное может быть построено без использования фреймворка, автор предыдущего примера об этом уже говорил: «Что Вам мешает написать это другим (более подходящим Вам способом) без использования фреймворка?»
Ну как-бы это сказать, клиент платит не только за то чтобы разработано было быстро, а еще и за эффективность разработки, за ее надежность, эффективность, как уже писали выше, у стороннего решения, заточенного под широкий круг задач — всегда будет ниже, чем у узкоспециализированного, надежность — опять-же, как можно ручаться за надежность чужого решения? Тем более случись что — ошибку в чужом коде исправить будет не в пример сложнее, а расчитывать что сообщество ее моментально поправит — тоже наивно, до момента исправления могут пройти месяцы.
Где можно записаться на тест-драйв?
Всегда меня удивляла такая аргументация: «вот, я увидел доморощенный фреймворк, он плохо написан, потому доморощенные фреймворки — зло». Может проблема не в том что он доморощенный, а в том что он плохо написан (документирован, и т.п.)? Тоесть как-бы это выразиться… то что фреймворк «доморощенный» — это-же не суть проблемы :) Тоесть если продолжить логическую цепочку, то плохой фреймворк — зло, а хороший — добро… «По-моему, так!» © Винни Пух :)
Ну а повсеместное использование сторонних разработок — это уже отдельная тема для разговора, безусловно иногда это необходимо, но мне лично претит современная тенденция все что только можно сейчас стараются откуда-нибудь да утянуть, нет, одно дело когда это что-то сложное, комплексное, и требует действительно серьезных затрат на реализацию самому, но скоро уже для вычисления 2+2 «программисты» будут искать фреймворки.
Ну а повсеместное использование сторонних разработок — это уже отдельная тема для разговора, безусловно иногда это необходимо, но мне лично претит современная тенденция все что только можно сейчас стараются откуда-нибудь да утянуть, нет, одно дело когда это что-то сложное, комплексное, и требует действительно серьезных затрат на реализацию самому, но скоро уже для вычисления 2+2 «программисты» будут искать фреймворки.
Ко всему нужно подходить с точки зрения эффективности (стоимости).
Что будет дешевле, потратить месяц сейчас на разработку вещей, которые уже кто-то сделал хорошо, и в дальнейшем тратить огромное количество времени на поддержку, или взять готовое решение, которое поддерживается кем-то другим?
Да, специфичные задачи требует специфичных решений. Но зачем заново решать задачи, которые уже были решены, и решены хорошо?
Что будет дешевле, потратить месяц сейчас на разработку вещей, которые уже кто-то сделал хорошо, и в дальнейшем тратить огромное количество времени на поддержку, или взять готовое решение, которое поддерживается кем-то другим?
Да, специфичные задачи требует специфичных решений. Но зачем заново решать задачи, которые уже были решены, и решены хорошо?
Вы исходите из предпосылок, которые считаете истинными:
— это сделано хорошо;
— это будет всегда;
— «большое коммьюнити» равно «большая отдача».
Если предположить, что ваши предпосылки ложны, то вся теория про «идеальные вечно поддерживаемые велосипеды» мигом испаряется…
— это сделано хорошо;
— это будет всегда;
— «большое коммьюнити» равно «большая отдача».
Если предположить, что ваши предпосылки ложны, то вся теория про «идеальные вечно поддерживаемые велосипеды» мигом испаряется…
См название топика. Говорим не про велосипеды вообще, а про конкретные велосипеды.
1. Миллион фреймворков, которые были сделаны плохо, уже мертвы. Их просто никто не будет использовать.
2. Нет ничего вечного. Время жизни фреймворков и систем, которые на них делаются вполне можно оценить. Я выбираю решения, которые будут жить, пока это мне нужно.
3. Скорее всего, это так. Можете привести пример обратного?
1. Миллион фреймворков, которые были сделаны плохо, уже мертвы. Их просто никто не будет использовать.
2. Нет ничего вечного. Время жизни фреймворков и систем, которые на них делаются вполне можно оценить. Я выбираю решения, которые будут жить, пока это мне нужно.
3. Скорее всего, это так. Можете привести пример обратного?
Не согласен.
Да, когда возникает собственный framework без поддержки — это зло.
Но в некоторых задачах использовать готовые framework'и — не меньшее зло.
Пример — небольшой сайт (или простенькая CMS), к которому надо прикрутить AJAX запросы. И ещё несколько простых операций.
И стоит выбор:
1. написать собственную функцию, которая будет делать всё что надо и занимать 2-3 kb.
2. использовать готовый framework, который «потянет» на все 20-40 kb.
Что ты выберешь в этом случае? Далеко не всегда framework будет оптимальным решением…
Да, когда возникает собственный framework без поддержки — это зло.
Но в некоторых задачах использовать готовые framework'и — не меньшее зло.
Пример — небольшой сайт (или простенькая CMS), к которому надо прикрутить AJAX запросы. И ещё несколько простых операций.
И стоит выбор:
1. написать собственную функцию, которая будет делать всё что надо и занимать 2-3 kb.
2. использовать готовый framework, который «потянет» на все 20-40 kb.
Что ты выберешь в этом случае? Далеко не всегда framework будет оптимальным решением…
Я думаю автор имел в виду ситуацию когда использование frameworkа необходимо.
Когда он ненужен то конечно нет смысла его грузить.
Еще есть ситуация когда большая часть кода с фреймворком используется когда пользователь залогинен(голосования, коментирование и тп ) а когда пользователь просто просматривает страницы — ему все это не доступно.
В таком случае некоторый функционал можно написать своими функциями, а фреймворк уже грузить после логина.
Когда он ненужен то конечно нет смысла его грузить.
Еще есть ситуация когда большая часть кода с фреймворком используется когда пользователь залогинен(голосования, коментирование и тп ) а когда пользователь просто просматривает страницы — ему все это не доступно.
В таком случае некоторый функционал можно написать своими функциями, а фреймворк уже грузить после логина.
Конечно, если скорость загрузки критична, и 20Kb значат много, то лучше написать пару процедур. Их мало, они маленькие, и проблемы, описанной в топике, с ними не возникнет.
Кроме того, современные библиотеки обычно имеют модульную структуру. А значит, есть возможность загрузить только то, что реально используется на данной странице.
Кроме того, современные библиотеки обычно имеют модульную структуру. А значит, есть возможность загрузить только то, что реально используется на данной странице.
Я бы выбрал к примеру jQuery. Во первых, не всегда можно сказать точно сколько нам «простеньких» операций понадобится. Во вторых — очень часто эти простенькие операции нужно как-то красиво сделать, что бы было еще и «приятненько» — а это лишний код, лишнее время (а в jquery многие из этих фишек, которые нужны всегда и везде есть или в самом ядре или же в несчетном количестве плагинов к нему). В третьих — решать несовместимости различных браузеров мне уж никак не интересно.
А сколько места он займет уже не важно. Ибо он во первых — будет грузится только один раз и на длительное время, да и можно под gzip-повать. Да и разница между 2, 20 и 40 кб, при количестве контента, который грузица (а это в большинстве случаев cms — со всякими картинками, текстом, стилями и прочим — если в метр влезим уже отлично будет.) — вообще незначительно
А сколько места он займет уже не важно. Ибо он во первых — будет грузится только один раз и на длительное время, да и можно под gzip-повать. Да и разница между 2, 20 и 40 кб, при количестве контента, который грузица (а это в большинстве случаев cms — со всякими картинками, текстом, стилями и прочим — если в метр влезим уже отлично будет.) — вообще незначительно
ох, метр — это как-то совсем жестоко :)
Хорошо, что есть кэширование в HTTP, и последующие страницы будут быстрее грузиться.
Я сам живу в замкадье, интернет через GPRS. Сайты, полностью сделаные на Flash терпеть не могу, т.к. приходится ждать, пока загрузится все целиком, чтобы посмотреть что там такое.
Хорошо, что есть кэширование в HTTP, и последующие страницы будут быстрее грузиться.
Я сам живу в замкадье, интернет через GPRS. Сайты, полностью сделаные на Flash терпеть не могу, т.к. приходится ждать, пока загрузится все целиком, чтобы посмотреть что там такое.
да-да… дедлайн завтра а мы всё ждём когда же там выйдет эта новая версия с исправленными багами…
а копаться в потрохах того же jquery — занятие не из самых приятных…
а копаться в потрохах того же jquery — занятие не из самых приятных…
ответил выше: intenter.habrahabr.ru/blog/54017/#comment_1439347
проблема не в том, что код чужой, а в том, что у него неудовлетворительное качество. если ты не можешь сделать лучше, чем в популярных фреймворках, то твой велосипед никому не нужен. если можешь, то есть шанс, что вскоре твой фреймворк потеснит мастадонтов. вспомни jquery во времена расцвета прототайпа и сейчас.
ответил выше: intenter.habrahabr.ru/blog/54017/#comment_1439347
Не навязывайте другим людям психологию неудачника.
— Если вам не удается создать доморощенный фреймворк на коленке — не означает, что его не сможет создать на той же коленке кто-либо другой.
— Процесс создания — это в первую очередь процесс познания. Если человек сделает доморощенный фреймворк и разочаруетя, у него будет большой багаж знаний. У такого человека будут хорошие знания языка, а у человека использующего JQuery — хорошие знания фреймворка, но вполне вероятно плохие знания самого языка.
— Если вам не удается создать доморощенный фреймворк на коленке — не означает, что его не сможет создать на той же коленке кто-либо другой.
— Процесс создания — это в первую очередь процесс познания. Если человек сделает доморощенный фреймворк и разочаруетя, у него будет большой багаж знаний. У такого человека будут хорошие знания языка, а у человека использующего JQuery — хорошие знания фреймворка, но вполне вероятно плохие знания самого языка.
Вопрос чисто экономический, и с психологией не связан.
Скажем, я могу разобраться во всех косяках того, или иного браузера, и сваять свой фреймворк. Но заказчик платить за это не будет.
Скажем, я могу разобраться во всех косяках того, или иного браузера, и сваять свой фреймворк. Но заказчик платить за это не будет.
> Доморощенные Javascript-фреймворки
Что за хрень такое ещё?
> — зло
Что за «зло» ещё?
P.S.>: вечная «проблема» прикладных потребителей и идеологических создателей.
Что за хрень такое ещё?
> — зло
Что за «зло» ещё?
P.S.>: вечная «проблема» прикладных потребителей и идеологических создателей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доморощенные Javascript-фреймворки — зло