Пришел к следующему выводу:
— если вся херня проходит на клиенте, а сервер только для хранения и валидации, дожо рулит
— если как-нибудь иначе, жквери рулит

Как-то так. Палки, перья, подводные камни?

29 Responses to jQuery vs Dojo

  1. RedSm:

    Ну, есть реализации RIA и с помощью jquery, но специализированные библиотеки типа Dojo подходят лучше, там уже реализованы паттерны типа MVC из коробки.

  2. RedSm:

    А по поводу подводных камней, у библиотек типа Dojo сильно выше порог вхождения чем у jquery и, не имея опыта, следует сильно задуматься использовать ли их в проекте. Я так когда-то с ExtJs сильно облажался, по примерам вроде всё ясно, на практике множество особенностей.

  3. 01pSpb:

    Бля, а что лучше выбрать, css или silverlight для проекта?
    Ты сравниваешь совершенно несравнимые штуки. Dojo — набор всего, что только может быть нужно. Джквери — небольшая библиотека по работе с домом, плюс немного примочек, вроде обёртки над аяксом. Они и по размерам раз в 10 отличаются

  4. Veaer:

    Как-то так вышло, что все переползли на jQuery. Сходите на HH.ru и наберите там jquery, dojo, mootools, prototype. Вместе с тем, на jQuery очень просто писать говнокод, который сложно поддерживать. А так же непросто писать нетривиальные интерфейсы. Горьким опытом пришли к следующему.

    Consumer front end. jQuery. Минимальное использование сторонних плагинов. Виджеты? jQuery UI. Больше сотни строк на странице? Backbone.

    Back end. Для тривиального хватает тех же технологий, что и на front end. Если он реально здоровый, то тут лучше всего подходят компонентые фреймворки: GWT, Sencha ExtJS($), YUI, Dojo, Google Closure. Мы используем GWT, ибо Java Shop. Sencha сейчас делают лучший продукт в индустрии, правда и денег за него просят. YUI — неизвестно, что с ним будет после Yahoo. Google Closure — довольно закрытый процесс разработки, и возможный перевод всего добра на Dart в ближайшем будущем. Dojo — наверное самое большое комьюнити из незваисимых фреймворков.

    Mobile. jQuery Mobile, Sencha Touch(free), Backbone+Zepto — в зависимости от задачи. jQuery Mobile позволяет сделать мобильный сайт под любой браузер. Sencha Touch — native look для iOS/Android. Backbone+Zepto — hand made для нестандартный требований.

    Кроме того — тулзы для тестирования(qunit,jasmine,sinon,seleniu m), модульной организации кода(require/amd), анализа кода(jslint,jshint). Ещё стоит отметить Twitter Bootstrap и HTML5BP, но это не совсем JS правда.

  5. Veaer:

    так же стоит упомянуть, что есть альтернативы Backbone — Ember, Knockout, Angular. Больше тут — http://addyosmani.github.com/todomvc/

  6. Kr0Blank:

    это ты лихо GWT в один ряд с сенчёй, йуём и дожей поставил..

  7. RedSm:

    Говнокод можно писать на любом языке и с помощью любой библиотеки/фреймворка. Утверждать что одна библиотека больше способствует говнокоду — всё равно, что утверждать, что карты более азартны, чем другие виды игр, как будто нельзя играть на деньги в «кто громче пукнет».

  8. Kr0Blank:

    если библиотека предоставляет говноинтерфейс, то всё равно будет говнокод, хотя бы во врапперах над ней.

  9. Veaer:

    единственное гарантированное средство от говнокода — код-ревью.

    jquery — библиотека, backbone — фреймворк. в этом главное отличие — говнокодить в рамках фреймворка сложнее и за этим проще уследить. никто не запрещает забить на модели или декларативные ивенты в рамках одного конкретного вью, я и не говорю, что фреймворки — панацея, они лишь ограничение, которое позволяет раньше замечать проблемы и не давать им вылезти за рамки компонентов.

  10. Yksin:

    Без шуток, однажды проиграл так тысячу рублей.

  11. RedSm:

    Я всё же не понял как фреймворк помешает мне писать говнокод?

  12. RedSm:

    Ставил на то, что говно писать можно всегда, или что не всегда?

  13. RedSm:

    Или не будет.

  14. Kr0Blank:

    значит у нас разные представления о говнокоде.

  15. RedSm:

    Что-то я совсем торможу по ночам. Граф проиграл другой спор, не про код.

  16. Veaer:

    мешает ли фреймворк писать говнокод — это риторический вопрос. по моему опыту — да, на этом во многом основан и мой ответ в этом посте.

    любое средство, ограничивающее программиста или решающее за него ряд задач — снижает количество говнокода. уж сколько вариаций биндинга, валидации, хендлинга ивентов я насмотрелся — как мнинимум за определённые вещи можно быть спокойным, хотя в реализации самой бизнес-логике и выборе паттернов и абстракций он естественно не даёт никаких гарантий.

  17. RelEkb:

    PHP потакает написанию говнокода (хотя на нем можно писать хороший код, не вопрос), а JAVA ставит какие не какие, но рамки, которые дают меньше возможности прострелить себе колено.

  18. RedSm:

    Не мешай, мы тут наугад языки программирования перечисляем. А то, что ты написал неправда, никто не запретит разработчику устроить говно вперемешку со спагетти в любом проекте, будь то java или что угодно. Шовинизм разработчиков заставляет их поливать помоями языки с низким порогом вхождения, тем самым стараясь как-то выделиться, я считаю это ребячеством. При этом, хороший разработчик знает, что шаблоны проектирования не зависят от языка программирования.

  19. SpoSm:

    Пробовал knockout и вроде бы все в нем хорошо если нужно что-то маленькое но с связным ui + это не mvc.
    Angular интересный, но так же как и нокаут выдрачивает дом и имеется куча шелухи внутри. Оба эти брата жутко тормозили при большом количестве элементов, сейчас мб стало лучше, не знаю.
    Ember в его начале я даже толком не завел + до безумия не нравятся его вызовы по 2 точки постоянно.
    В итоге пришел к отличной связке backbone+jquery+require. Если бы у jquery не был так убог ui лучше бы ничего не было с точки зрения небольшого, но «обогащенного» интерфейса. В итоге эта связка отлично дополнятся и работает по принципу — сервер только для хранения и валидации.

    Dojo к слову очень хорошо умеет вгрызаться в Dom дерево и вполне неплохо показывает себя как мощный ui framework со своими Dijit’ами и парсером.

    Поэтому не совсем согласен с твоими выводами, я скорее за то что если нужно что-то больше чем 10 страничек на сайте использовать более зрелые фреймворки, а не зоопарк из библиотек. Если же идти по второму пути нужно быть готовым стрелять себе в ноги каждый божий день.

  20. Xuagreen:

    ох, ты, видимо, не видел говно-кода в яве. Старый Spring, например — классический пример говно-кода в галактических масштабах.

  21. RelEkb:

    Да нет никакого шовинизма, приходилось участвовать в поддержки legacy проектов как на php так и на яве, в пхп обычно сильно хуже все было. А если чисто теоретически, то да, ты прав.

  22. RelEkb:

    видимо да, не видел

  23. RedSm:

    Неверная причинно-следственная связь. Хуже всё было, потому, что писали непрофессионалы. И я даже не пытаюсь защищать php, в нем говна хватает, но когда человек получает завтрашнюю дату через sleep в 24 часа, то в этом виноват не язык.

  24. AmtEkb:

    ассемблер вообще не ставит никаких рамок. Значит ли это, что на нём пишут в основном говнокод?

  25. RelEkb:

    нет не значит, очень высокий порог вхождения

  26. SbVelo:

    Мне кажется, что раз уж ты выбрал фреймворк, понял как он работает и стал ими пользоваться, то писать говнокод будет просто западло. Иначе зачем тогда все усложнять? Ну, это при условии, что ты вменяемый чувак. Бывает, конечно, что непонятно, как сделать определенную вещь по правилам фреймворка и нет времени разбираться, тогда пишешь, чтоб хоть как-то работало. Но все равно остается какой-то зуд, беспокойство, и возвращаешься к этому месту, разбираешься и переписываешь.

  27. ResSm:

    Все правильно, поетому чистый jQuery и не очень то хорошая идея использовать.
    Например jquery + backbone. И опа, уже и не каша.

Добавить комментарий