JavaScript « Какой JavaScript-фреймворк выбрать или как их выбирать?
Очень хочется услышать Ваше экспертное мнение по поводу использования отдельных, ведь даже у лучших есть подводные камни.
Ведь использование определенных фреймворков требует ресурсов или же познаний. Одни лучше других в размере и скорости. На дворе почти 2010 год, а мы до сих пор выбираем.
Почему и как?
Приветствуется глубокое погружение в суть вопроса и какая-нибудь аналитика.
1 ответов
Очень интересный вопрос, жизненный) Могу только поблагодарить RayZ за такой вопрос)
В той или или иной степени, мне пришлось работать с достаточно большим количеством фреймворков, каждый из которых я изучал на основе исходного кода, а затем уже на документации. В результате этого могу не согласится с моими коллегами о сути вопроса) Самолет и вертолет? Какая разница - наша цель летать, средства конечно различаются, но в целом среда одна - земля, воздух, аппарат на котором мы летим. Кроме того, совершенно естественно, что большинство фреймворков в целом имеют идентичный функционал, который сравнивать в принципе не имеет смысла - сравнивать можно уже только реализацию. Ко всему этому можно добавить еще и то, что конкуренция также оказала влияние на фреймворки - если появиться что-то новенькое в одном фреймворке (или для одного фреймворка), то через короткое время подобное реализуется уже и в других.
В связи с этим бессмысленно сравнивать вилку десертную и вилку для рыбы, в том и другом случае функциональность одна. Но! Каждый из фреймворков имеет свои уникальные особенности, которые отражаются уже на качестве его применения в зависимости от масштабности и объема задачи, сроков и технических требований.
Выбирать нужно, действительно, исходя из задачи. Например, если у меня простенький сайт визитка (пусть даже с кучей красивеньких элементов, прокаченным юзабилити на основе js) логичнее использовать либо совсем простые фреймворки, либо собственные сборки, в которых будет только то, что нужно, но может быть и случай когда гораздо логичнее писать на чистом js (уникальный функционал, или незначительный функционал). Собственные сборки, вообще отдельный разговор, один из самых удачных сборщиков у dojo, с его помощью можно принципе любой фреймворк пересобирать как будет удобно.
В случае если у меня сложный проект, то логичнее выбрать фреймворк, предоставляющий различные паттерны проектирования на основе различных программных методологий.
И так, теперь конкретика о наиболее интересном:
1. jQuery - очень простой, весьма не плохо написанный фреймворк (по сравнению с большинством), вся мощь которого скорее в огромном количестве плагинов и надстроек. Очень выгоден для малых и средних проектов, но при разработке крупных проектов неуместен, так как приводит к дефициту проектирования, хотя весьма производителен благодаря простому содержанию и коду. Однако, при совершенно классическом для js исходном коде в нем есть весьма узкие места, которые приходилось либо переделывать, либо переписывать.
2. Prototype - фреймворк, которые до определенного момента был эталоном, правда код у него несколько специфический с явным влиянием не js. С точки зрения проектирования фреймворк очень удобен для средних проектов, так как предоставляет элементарный способ эмулирования классического ООП в добавок к простому функционалу. Производительность у него несколько нестабильна, то быстро работает, то не очень... При достаточно большом опыте работы с этим prorotype не приходилось переписывать код, однако были некоторые функциональные добавления.
3. Dojo - весьма правильный фреймворк), в последнее время стал весьма привлекательным с точки зрения проектирования и содержания, исходный код становится также все лучше и лучше) Распределенная модульность фреймворка позволяет существенно оптимизировать разработку. С точки зрения производительности еще год назад у меня были серьезные нарекания, но в последнее время все становится все лучше и лучше. Кроме того в добавок к исходным кодам существует очень удобная система сборки.
4. ExtJS - весьма и весьма грамотно спроектированный фреймворк, которые предоставляет весьма интересные возможности проектирования. В свое время спас меня от серьезного дефицита проектирования в крупном проекте. Производительность у него средняя, но правильность проектирования, которую он позволяет организовать в полной мере компенсирует это.
В целом, как мне кажется, нельзя говорить о выборе постоянного фреймворка для всех проектов - это весьма затратный и не оптимизированный подход... Задача определяет интсрумент. Если у нас жареная рыба, то берем вилку для рыбы, а если у нас десерт, то десертную вилку)
Знаете, есть такая байка, мол, в юности один студент не смог разобраться в математике и тогда просто взял и придумал свою, другую математику (кажется, приписывают Лобачевскому, точно не помню).
Мое мнение: jQuery и Prototype — пионеры и долгожители js-фреймворкинга, дофигамного раз переписанные и переработанные, проверенные временем и огромным количеством сайтов. Все остальные, перечисленные в списке, родились по принципу, рассказанному выше. Это не значит, что они хуже, просто они другие.
Есть еще такая байка. В комнату, в центре которой горит костер, переходящий в пожар, впускают инженера, физика и математика.
— Инженер входит, видит огонь, засыпает песком и уходит.
— Физик входит, видит огонь, садится и начинает наблюдать.
— Математик входит, видит, что решение есть и уходит.
Не совсем в тему, да? Ну эт чтобы читать не скучно было.
Так вот, вопрос, заданный топикстартером, глубоко философский. Сродни вопросу, почему вы занимаетесь веб-программированием и не прикладным или системным. Каждый человек уникален, у каждого свои предпочтения, свои интересы, привычки.
Каждый фреймворк по-своему хорош для одного человека и просто ужасен и неюзабелен для другого. Нужно брать и пробовать. Может оказаться так, что, попробовав jQuery, вы не захотите больше ничего другого и никогда не попробуете Dojo, хотя на самом деле Dojo понравился бы вам в разы больше и кодили бы вы с его помощью в разы быстрее.
Вы уверены, что та женщина (обращаюсь к мужчинам), которая рядом с вами, — та самая единственная и неповторимая? Хрен там. Вы бы нашли в миллионы раз более подходящую вам по всем параметрам и были бы с ней в миллиарды раз счастливее, но на это вам пришлось бы потратить не одну жизнь.
Надеюсь, я не донес свою мысль, но вы поняли.
Мое мнение не из первых рук, я смотрел на фреймворки скорее со стороны руководителя проекта.
Есть фреймворки для манипуляции с DOM, есть для создания визуального интерфейса. Для манипуляции с DOM мы выбрали jQuery. Достаточно легкий, быстрый, широко распространенный, возможность давать его закачивать с серверов Гугла. Хорошая документация и много сторонних примеров в сети. Много плагинов. Это и плюс и минус. Плагины нужно выбирать тщательно, ибо пишут их другие люди и контроль качества у них может быть не на высоте.
Для создания UI мы смотрели ExtJs и YUI (Yahoo UI).
ExtJs производит впечатление очень продуманного фреймворка и визуально тоже получается все красиво. Мог бы работать побыстрее, но это не очень критично. К сожалению мы не смогли им воспользоваться из-за проблемы с лицензией. Наш продукт (PHPRunner) генерит PHP/Js код и попадает под то, что у них описано как конкуренция с самим ExtJs. Для большинства проектов это не будет проблемой.
В итоге для визуальной части мы используем некоторые классы YUI. Весьма обширный фреймворк, за ним стоит мощная поддержка Yahoo. Несколько тяжеловат по размеру, но есть возможность выбирать нужные модули и большая вероятность того, что на машине у пользователя он уже есть. Заслуживает всяческого внимания.
Для новичка в любом случае будет полезно начинать с JQuery, он и прост и документации по этому фреймворку очень много. Он используется на абсолютно разных сайтах и успешно справляется с возлагаемыми на него задачами, думаю, что после изучения JQuery с другим фреймворком работать не понадобится.
Наличие широкого выбора качественных инструментов - необходимое условие создания качественных вещей, удобного окружения, разнообразия форм. Не существует "идеального комбайна": у каждой попытки создать такой будет не менее одного минуса: например, скорость работы или тяжеловесность.
Для каждой задачи есть интструменты, в той или иной степени удобные для её решения: одни низкоуровневые, другие - наоборот, но заточенные под конкретное применение. Нужно уметь оперировать если не всеми доступными средствами, то как минимум - знать их и уметь выбрать подходящие.
Это как вопрос, что купить: джип, смарт, или обычную легковушку? смотря для каких целей.
У меня всё :)
- Скажите, Вам бутерброд с колбасой, ветчиной, корейкой или грудинкой?
- А какой из них лучше?
Или
- Скажите, что лучше, самолет или вертолет?
Ваш вопрос примерно того же порядка. Каждый фреймфорк - это инструмент. Инструмент надо подбирать под задачу. Для забивания гвоздей использовать молоток, для закручивания шурупов - отвертку. Сделать описание в стиле "для задачи А подходит фреймворк Ф1 и Ф2" не представляется возможным - большей частью фреймворки объемные и представляют богатый функционал. Получится слишком общо. Единственное, что мне представляется возможным, так это описание того, что НЕ стоит делать на том или ином фреймворке. При этом, всегда найдутся люди, которые именно это "не" делали и будут доказывать, что именно так хорошо и правильно. :)
Но, все-таки, хочу внести немного конструктива. Так как вопрос очень общий, то позволю себе дать тоже несколько общих рекомендаций, про которые, по опыту, многие забывают:
1. Не стоит решать локальные задачи глобальными фреймворками. На фреймворке должно проектироваться все приложение изначально и использовать более 60% его функционала. Тянуть фреймворк ради использования одной-двух функций неоправданная роскошь.
2. Чем меньше распространен фреймворк, тем дороже стоимость разработки приложения с его использованием. Программист (верстальщик) обладающий уникальными знаниями мало того, что будет хотеть больше, чем "обычный", так еще при смене (дополнительном наборе) персонала компания будет терять время (сиречь, деньги) на подбор и обучение.
3. Наличие поддержки у фреймворка, постоянной команды, которая его разрабатывает - необходимое условие для крупного проекта. Идеальная схема, когда фреймворк бесплатен, а поддержка работает за деньги. В поддержке важны не только решение текущих проблем и багов, но и возможность узнать планы. В идеале - если можно на эти планы влиять. Например, нужна функция, которая не поддерживается (не полностью поддерживается) во фреймворке. Идеальный вариант - возможность узнать у поддержки, будет ли такая функция разрабатываться в ближайшее время, а если не будет, то можно ли добавить в план. Исходя из этого принимаем решение - ждать или писать самим. Это важно, ибо переход от самописной функции к функции фреймворка - это время, деньги и потенциальные ошибки. А значит, следует максимально избегать этого.
Надеюсь, информация будет полезной.
Не сочтите за пиар, тут описан выбор между jQuery, Dojo Toolkit и ExtJS
http://ignar.name/2009/09/22/ria-приложения-сравнение-javascript-фреймворков/
Я пользовался несколькими фреймворками ( jQuery, Spry, ExtJs). У каждого есть свои преимущетва и минусы.
Критику Sultry я полностью поддерживаю. Для каждой задачи нужно подбирать
Хочу привести статью (сравнение скорости js-движков), которая в свое время поставила все точки над и для меня:
http://source.nnov.ru/content/zend-framework-dojo-jquery
Возможно, кому то она будет полезна.
Начинал с Prototype, использую jQuery, перехожу на MooTools...в Prototype не хватало готовых пряморуких визуальных эффектов (плагинов). в jQuery мне сильно не хватает OOP, а писать все на прототипах...гемор не сусветный...по этому перехочу на MooTools...в нем и эффекты нормальные (для юзабилити и красоты), в нем и все на OOP и работает достаточно шустро...