Привет. У меня вопрос к фронтенд-разработчикам.

Расскажите, кто что знает про Yahoo UI 3. Я сейчас работаю над архитектурой достаточно большого проекта и как один из вариантов рассматривается YUI, потому что считается что она хороша как раз для больших проектов, со сложной модульной структурой. Хочется узнать ваше мнение по этому поводу. Все плюсы/минусы/подводные камни этой библиотеки, с которыми вы сталкивались.

Спасибо.

Tagged with →  

19 Responses to Привет.

  1. Aurko:

    jUI используй и не суйся туда

  2. U4Zero:

    отнюдь. На больших проектах часто бывает комфортнее использовать фреймворки типа YUI или GC

  3. 0omodin:

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

  4. Veaer:

    Насколько я знаю, они в одной из последних версий реализовали поддержку Application Framework по аналогии с Backbone.JS, это большой плюс.

    Основной бонус от таких библиотек — виджеты, но обычно они применимы, если вы делаете Back-end UI или Desktop-like App. Если же вы делаете нетривиальный Front-end или Mobile — лучше взять что-то более легковесное типа Backbone.JS + jQuery(с некоторыми виджетами из UI при необходимости).

    Можете ещё посмотреть на Google Closure Library, Google WebToolkit, SproutCore, Ember.JS, Cappuccino, ExtJS. Но на самом деле с каждой из них есть определённые проблемы, так что я бы смотрел на Backbone/YUI.

  5. 0omodin:

    Спасибо за ответ. А какие проблемы есть у Google Closure?

  6. 0omodin:

    идиот, не туда.

  7. 0omodin:

    Спасибо. А какие проблемы есть у Google Closure?

  8. U4Zero:

    настройка окружения, jsdoc’и в обязаловку, нельзя обращаться к пришедшим данным data.field, только data[‘field’], надо собирать зависмости. Еще есть навязанный синтаксис с неймспейсами и прототипами. После сжатия возникнет проблема с нахождением ошибок, которая частично решается с помощью map. Модульная система довольно хитрая, к ней надо приспособиться. Также нужно следить за объектами, диспоузить их, когда они удаляются со страницы (хотя это опционально и ребята разработчики постралаись сделать это максимально удобно).

    Основная проблема — это стиль кода и всё, что связано с компиляцией.

  9. 0omodin:

    К стилю кода можно привыкнуть, главное, чтобы был результат. А какие проблемы с компиляцией, кроме отлавливания ошибок после сжатия?

  10. U4Zero:

    Только codestyle. Для правильной компиляции нужно писать понятно для closure compiler’a, добавлять везде jsDoc’и. Следовательно, типизация там есть и проверяется на уровне компиляции. Также возможны side-эффекты, ничего сложного, надо просто примерно понимать как closure compiler жмет код.

    Нельзя будет использовать:
    MyObject.prototype = { foo: function(){}, bar: function(){}},
    только:
    MyObject.prototype.foo = function() {};
    MyObject.prototype.bar = function() {};
    иначе он не сможет заинлайнить методы, где это возможно.

    Придется познакомиться с @enum, чтобы не писать одинаковые строчки текста повсюду.

    Если ваши js-шаблоны будут тектовыми, а оттуда надо будет дерагть переменные из общего окружения, все накроется медным тазом, так как compiler переименовывает переменные небезопасно (т.е. не только внутри скоупа, даже неймспейсы типа «myApp.pages.searchPage.Button» он переименует в «a»). Тут можно юзать soy, но у них есть своя прекомпиляция и свои тонкости.

    При разработке надо будет собирать deps при добавлении новых файлов. Тут есть минус, когда js-ок уже много, браузер может прилично думать, пока загрузит их все. Есть специальная штука для автоматизации оного — plovr, но мне она по душе не пришлась.

    У меня сложалось впечатление, что создатели — адепты Java и С, поэтому код выглядит немного избыточно. Но зато после сжатия код сильно уменьшается + есть проверка типов на этапе компиляции, это удобно.

    Если приложение построено на фреймах, там есть свои тонкости, придется юзать domHelper’ы и учитывать, что closure будет грузиться только в основной window.

  11. U4Zero:

    А вообще возови в гости, Игорь, я все расскажу на словах 🙂

  12. 0omodin:

    Заходи, конечно на неделе 🙂 Я напишу когда.

  13. U4Zero:

    Только за пару дней скажи.

  14. 0omodin:

    Конечно.

  15. Veaer:

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

  16. U4Zero:

    Мне кажется, что Closure не умрет. Да и не факт, что сам Dart выживет, хоть мне он и понравился.

  17. 0omodin:

    Я тоже не уверен, что Closure прямо-таки будет забыт и заброшен. Google ничего не делает просто так и точно не будет выбрасывать такую мощную библиотеку. Что-нибудь они с ней придумают. К тому же Дарт еще не скоро выйдет.

  18. Veaer:

    Closure будет переписан на Dart скорее всего, вроде бы они планировали полуавтоматический перевод текущих продуктов на новый язык. Google уже сейчас вкладывает достаточно ресурсов, перетягивая людей из других проектов: в частности, за API Design сейчас отвечает Joshua Bloch, ещё многие люди из команд GWT & WindowBuilder теперь тоже работают на Dart. Что касается сроков, я не удивлюсь, если в конце года мы будем иметь стабильный Dart и портированную на него Closure Library.

  19. U4Zero:

    Значит, что перейдем на дарт. Я в общем не против, он довольно приятный и в принципе совместимый с js. Я так понял, что они часть библиотек возьмут из ноды и даже научились их портировать.

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