Комментарии 21
Сразу говорю — не для холивара, а чтоб собрать мнения
Dojo vs ExtJS / Sencha Touch — преимущества и недостатки в сравнении.
Вопрос платности ExtJs рассматривать не хотелось бы, ибо тривиально
С Dojo я знаком слабо, но приведу парочку аргументов за и против для затравки:
— AMD вместо своего механизма загрузки в Sencha — как следствие — проще интегрировать сторонние библиотеки
— у Sencha очень вкусная инфраструктура сборки проекта (Sencha CMD) которая умеет и кофе варить :)
Dojo vs ExtJS / Sencha Touch — преимущества и недостатки в сравнении.
Вопрос платности ExtJs рассматривать не хотелось бы, ибо тривиально
С Dojo я знаком слабо, но приведу парочку аргументов за и против для затравки:
— AMD вместо своего механизма загрузки в Sencha — как следствие — проще интегрировать сторонние библиотеки
— у Sencha очень вкусная инфраструктура сборки проекта (Sencha CMD) которая умеет и кофе варить :)
Из Ext.js хорошо делать приложения для интранета, уж больно дикие слоны получаются. Хотелось бы услышать как обстоят дела с животноводством в Dojo.
Я видел изнутри большой проект на dojo. Что-то вроде 100 метров JS, это без самого dojo.
Так вот — у dojo вроде относительно неплохо с модулями, по крайней мере они одни из первых вроде начали заморачиваться дальше чем просто весь JS на проекте склеить и сжать. Какая-никакая там система UI компонент есть. Какое-никакое разделение на шаблоны и код компонент, с удобной привязкой по свойствам. Есть декларативная привязка этих компонент к DOM. Есть библиотека с кнопками и слайдерами (dijit), есть куча библиотек под названием dojox, где есть крутые контролы типа гридов и календарей. Правда 90% того что есть в dojox — сырое как понос, т.е. по факту ни гридов, ни календарей в dojo нет.
Правда жизни в том, что это всё уже сгнило лет 5 как. Там sitepen этот на саппорте по-инерции бабло рубит, но ни про какое развитие технологии речи не идет уже давно.
Короче dojo представляет лишь археологический интерес.
Так вот — у dojo вроде относительно неплохо с модулями, по крайней мере они одни из первых вроде начали заморачиваться дальше чем просто весь JS на проекте склеить и сжать. Какая-никакая там система UI компонент есть. Какое-никакое разделение на шаблоны и код компонент, с удобной привязкой по свойствам. Есть декларативная привязка этих компонент к DOM. Есть библиотека с кнопками и слайдерами (dijit), есть куча библиотек под названием dojox, где есть крутые контролы типа гридов и календарей. Правда 90% того что есть в dojox — сырое как понос, т.е. по факту ни гридов, ни календарей в dojo нет.
Правда жизни в том, что это всё уже сгнило лет 5 как. Там sitepen этот на саппорте по-инерции бабло рубит, но ни про какое развитие технологии речи не идет уже давно.
Короче dojo представляет лишь археологический интерес.
А вот ExtJS бурно развивается, постоянно добавляются новые фичи, фиксятся старые баги, регулярно в целях оптимизации с нуля переделываются компоненты…
В итоге ветка 4.х зарелизилась с опозданием на несколько месяцев, и потом где-то год после релиза содержала кучу багов, и собственно релизом можно было назвать только с версий 4.1.х.
Некоторые баги разработчики отказываются фиксить в community-версии предлагая покупать лицензию. Приходится писать свои патчи, которые отваливаются с выходном новой версии — чего только стоил баг со скроллингом в гриде, когда до семи первых и последних строк в таблице были не видны и недоступны для скроллинга, это даже в примерах видно. Вот снова передалали Grid в 4.2.
Некоторые вещи в dojo есть, что называется из коробки (по заявлениям нашего программиста, который имеет большой опыт работы с dojo), а в extjs приходится их программировать вручную. Местами непродуманный API — иногда приходится лезть в приватные методы, чтобы добиться нужной функциональности.
События в некоторых местах срабатывают по таймеру, а значит вдруг могут появиться трудно объяснимые баги на слабых машинах. Приходится делать свои обработчики опять же по таймеру — напрягает. Пример: изменённое значение в cell-editor-е записывалось в store не в момент потери фокуса, а через какой-то небольшой промежуток времени, и в итоге ручное сохранение датастора на сервер по клику на кнопку пришлось делать тоже с небольшой задержкой. Может быть в последних версиях уже исправили.
В общем, ExtJS фрэймворк хороший, но не без проблем.
В итоге ветка 4.х зарелизилась с опозданием на несколько месяцев, и потом где-то год после релиза содержала кучу багов, и собственно релизом можно было назвать только с версий 4.1.х.
Некоторые баги разработчики отказываются фиксить в community-версии предлагая покупать лицензию. Приходится писать свои патчи, которые отваливаются с выходном новой версии — чего только стоил баг со скроллингом в гриде, когда до семи первых и последних строк в таблице были не видны и недоступны для скроллинга, это даже в примерах видно. Вот снова передалали Grid в 4.2.
Некоторые вещи в dojo есть, что называется из коробки (по заявлениям нашего программиста, который имеет большой опыт работы с dojo), а в extjs приходится их программировать вручную. Местами непродуманный API — иногда приходится лезть в приватные методы, чтобы добиться нужной функциональности.
События в некоторых местах срабатывают по таймеру, а значит вдруг могут появиться трудно объяснимые баги на слабых машинах. Приходится делать свои обработчики опять же по таймеру — напрягает. Пример: изменённое значение в cell-editor-е записывалось в store не в момент потери фокуса, а через какой-то небольшой промежуток времени, и в итоге ручное сохранение датастора на сервер по клику на кнопку пришлось делать тоже с небольшой задержкой. Может быть в последних версиях уже исправили.
В общем, ExtJS фрэймворк хороший, но не без проблем.
С ExtJS вплотную работал только с третьей версией, про четвертую сейчас бегло посмотрел, мог что-то упустить. Буду рад уточнениям в чем не прав.
— кастомизация
AMD это не только легкость интеграции сторонних библиотек. Это еще и широкие возможности для кастомизации с помощью наследования, в том числе множественного. Насколько понимаю, ExtJS такого не позволяет. Поэтому Dojo это скорее фундамент для создания своего фреймворка, а ExtJS — конечный инструмент. Многие виденные мною сайты, что сделаны на ExtJS, даже стандартную CSS тему не сильно меняют или вообще не меняют. В Dojo можно создавать свои виджеты на базе основных добавляя им новый функционал и\или меняя разметку.
— ленивая подгрузка
AMD модули можно подгружать по одному и только те, что нужны на странице, можно делать слои содержащие ограниченный набор модулей, который нужен конкретному сайту. Первого в ExtJS нет, второе, вероятно, есть в инструментах сборки проекта.
— deferred
правда очень удобная вещь в асинхронном мире JavaScript. Об их существовании в ExtJS не слышал.
— тесты
Java-робот, конечно, уступает силениуму, но в остальном как минимум не хуже QUnit-ов. В комбинации с phantom.js получается отличный инструмент для авто-тестов. У ExtJS есть какие-то инструменты для тестирования?
— touch и мобильные версии
не работал с ними ни в Sencha, ни в ExtJS, но судя по описанию и отзывам Sencha тут вне конкуренции.
— дизайн
у Sencha все модно и красиво. Dojo, такое ощущение, каким был 5 лет назад, таким в дефолтной теме и остался. Но это сделано специально, т.к. Dojo это в первую очередь фундамент.
Таким образом если нужно быстро сделать интерфейс, то ExtJS подходит лучше. Если же есть большое количество собственных виджетов и планы на будущее развитие, то лучше подходит Dojo.
Про животноводство: минифицированный, обфусцированный и склееный в один файл полный Dojo весит примерно 500кб, но как уже писал можно разбивать это все на слои или грузить каждый модуль отдельно. Или вопрос был про объем кода, который нужно написать для создания своего интерфейса?
— кастомизация
AMD это не только легкость интеграции сторонних библиотек. Это еще и широкие возможности для кастомизации с помощью наследования, в том числе множественного. Насколько понимаю, ExtJS такого не позволяет. Поэтому Dojo это скорее фундамент для создания своего фреймворка, а ExtJS — конечный инструмент. Многие виденные мною сайты, что сделаны на ExtJS, даже стандартную CSS тему не сильно меняют или вообще не меняют. В Dojo можно создавать свои виджеты на базе основных добавляя им новый функционал и\или меняя разметку.
— ленивая подгрузка
AMD модули можно подгружать по одному и только те, что нужны на странице, можно делать слои содержащие ограниченный набор модулей, который нужен конкретному сайту. Первого в ExtJS нет, второе, вероятно, есть в инструментах сборки проекта.
— deferred
правда очень удобная вещь в асинхронном мире JavaScript. Об их существовании в ExtJS не слышал.
— тесты
Java-робот, конечно, уступает силениуму, но в остальном как минимум не хуже QUnit-ов. В комбинации с phantom.js получается отличный инструмент для авто-тестов. У ExtJS есть какие-то инструменты для тестирования?
— touch и мобильные версии
не работал с ними ни в Sencha, ни в ExtJS, но судя по описанию и отзывам Sencha тут вне конкуренции.
— дизайн
у Sencha все модно и красиво. Dojo, такое ощущение, каким был 5 лет назад, таким в дефолтной теме и остался. Но это сделано специально, т.к. Dojo это в первую очередь фундамент.
Таким образом если нужно быстро сделать интерфейс, то ExtJS подходит лучше. Если же есть большое количество собственных виджетов и планы на будущее развитие, то лучше подходит Dojo.
Про животноводство: минифицированный, обфусцированный и склееный в один файл полный Dojo весит примерно 500кб, но как уже писал можно разбивать это все на слои или грузить каждый модуль отдельно. Или вопрос был про объем кода, который нужно написать для создания своего интерфейса?
Разработкой на ExtJS уже около 6 лет занимаюсь, хочу по пунктам вам ответить.
— Кастомизация. В принципе возможно все, но да, в этом фреймворке это будет непросто…
— Ленивая подгрузка. Есть. В последних версиях подключаем ext-dev.js и грузим только необходимое. Соответственно и само боевое приложение грузится также. Компилятор SenchaCMD умеет собирать проект используя только те файлы, которые необходимы приложению. Лишние модули фреймворка можно убирать
— deferred. Тут во первых в эксте все на событиях, посему итак все асинхронно вроде как. Для асинхронных задач есть Ext.util.TaskRunner
— Тесты. С этим в sencha есть Selenium, CasperJS, Siesta. Можно почитать тут. Плюс я тестирую отдельно код, без визуалки посредством js-test-driver + Jasmine
— touch реально хорош. это нужно смотреть.
— дизайн в эксте очень кастомизируется просто. Но, начинать смотреть стоит с версии 4.2.1 и последней версии SenchaCMD. Появились пакеты (package) с темой/кодом. Все на SASS+Compass
Обфусцированный, минимизированный ExtJS может занимать от 700-800Кб, по крайней мере это то, что делал я. Текущий большой intranet проект полностью скомпилированный с фреймворком одним файлом весит 1.2 мб
— Кастомизация. В принципе возможно все, но да, в этом фреймворке это будет непросто…
— Ленивая подгрузка. Есть. В последних версиях подключаем ext-dev.js и грузим только необходимое. Соответственно и само боевое приложение грузится также. Компилятор SenchaCMD умеет собирать проект используя только те файлы, которые необходимы приложению. Лишние модули фреймворка можно убирать
— deferred. Тут во первых в эксте все на событиях, посему итак все асинхронно вроде как. Для асинхронных задач есть Ext.util.TaskRunner
— Тесты. С этим в sencha есть Selenium, CasperJS, Siesta. Можно почитать тут. Плюс я тестирую отдельно код, без визуалки посредством js-test-driver + Jasmine
— touch реально хорош. это нужно смотреть.
— дизайн в эксте очень кастомизируется просто. Но, начинать смотреть стоит с версии 4.2.1 и последней версии SenchaCMD. Появились пакеты (package) с темой/кодом. Все на SASS+Compass
Обфусцированный, минимизированный ExtJS может занимать от 700-800Кб, по крайней мере это то, что делал я. Текущий большой intranet проект полностью скомпилированный с фреймворком одним файлом весит 1.2 мб
Как к специалисту вопрос: для всяких внутренних бизнес-ориентированных приложений (1С-стайл — гриды, да формы) — extJS покатит? Насколько трудоемко, когда уже рука набита, делать новые формы/странички с гридами? Насколько тяжело оно поддерживатся?
Короче — насколько дороже/дешевле делать веб-морду таким 1С-стайл приложениям на ExtJS, относительно любого другого известного тебе подходящего для этого фреймворка?
Короче — насколько дороже/дешевле делать веб-морду таким 1С-стайл приложениям на ExtJS, относительно любого другого известного тебе подходящего для этого фреймворка?
Для ExtJS накидывать стандартные формочки и гриды очень просто и достаточно быстро. Если есть опыт, то простейшая форма с гридом/полями займет не больше часу сделать, вместе с примитивной логикой проверки вводимых значений. Плюс, если писал опытный человек, поддерживать будет достаточно просто. Особенно, если код будет комментироваться и будет постоянно компилироваться документация (JsDuck ориентирован на экст).
Я думаю дорого/дешево зависит от того, есть ли специалист. Порог входа в экст все таки как мне кажется выше. Многие фронтендеры подходят к таким приложениям как к обычному вебу и верстке. Такой код превращается в ад. Если спеца нет, наверное все таки лучше посмотреть на dojo или может yui. хотя тут выбор велик и нужно отталкиваться от того, какой дизайн приложения и насколько сложна структура форм.
Я думаю дорого/дешево зависит от того, есть ли специалист. Порог входа в экст все таки как мне кажется выше. Многие фронтендеры подходят к таким приложениям как к обычному вебу и верстке. Такой код превращается в ад. Если спеца нет, наверное все таки лучше посмотреть на dojo или может yui. хотя тут выбор велик и нужно отталкиваться от того, какой дизайн приложения и насколько сложна структура форм.
Ничего мой проект не должен. С чего вы взяли?
Чем оно лучше YUI3?
сортировку поправьте — прошлый пост был год назад: habrahabr.ru/search/?target_type=posts&q=[dojo%20toolkit]%20&order_by=date
Использую на работе dojo. Библиотека приятна, но есть один большой недостаток: не всегда актуальная и очень поверхностная документация, мало примеров для начинающих. Некоторые вещи приходится в исходниках выискивать.
У dojo нет готового каркаса для одностраничных приложений «для чайников», может, dojox.app и подходит для таких целей, но недружелюбен и непонятен. Нет нормального сообщества, где могут ответить на не самые примитивные вопросы.
Думаю, из-за проблем с документацией dojo и непопулярен.
Наследование, deferred и promise очень понравились, после того, как удалось разобраться в этих компонентах.
P.S. Подскажите пошаговый мануал по сборке dojo в один файл.
У dojo нет готового каркаса для одностраничных приложений «для чайников», может, dojox.app и подходит для таких целей, но недружелюбен и непонятен. Нет нормального сообщества, где могут ответить на не самые примитивные вопросы.
Думаю, из-за проблем с документацией dojo и непопулярен.
Наследование, deferred и promise очень понравились, после того, как удалось разобраться в этих компонентах.
P.S. Подскажите пошаговый мануал по сборке dojo в один файл.
У Dojo были большие проблемы с документацией на начальных этапах. Авторы сами это признают (в частности в интервью, которое проскакивало на хабре: habrahabr.ru/post/149594/) и в районе версии 1.8 проделали большую работу по написанию и актуализации документации. Теперь она состоит из tutorials, reference guide с живыми демо и интерактивного API, которое автоматически генерируется из комментариев в коде. Но в силу большого объема (В Dojo 1.8 — 175 суб-пакетов и более 1 400 модулей) все возможности фреймворка описать сложно. Вопросы можно задать на офсайте в разделе коммьюнити, также на stackoverflow много знающих Dojo.
В русскоязычной среде с Dojo совсем капут, несмотря на то, что в создании ранних версий участвовало несколько русских разработчиков, в том числе Илья Кантор. Есть гугл-группа — там могут помочь, но особой активности не заметил. Сам по мере сил пытаюсь отвечать на вопросы по Dojo на форуме javascript,ru. Если знающие Dojo хабражители присоединятся ко мне там, то может быть мы сможем организовать место, где смогут ответить на не самые примитивные вопросы.
Мне, правда, очень понравился Dojo и очень жаль, что в России он почти не используется. Я планирую продолжать освещать его на хабре. Пишите про какие его возможности хотите прочитать в первую очередь. Если есть интерес могу попробовать написать туториал одностраничного приложения «для чайников».
По сборке dojo есть статья в reference guide: dojotoolkit.org/reference-guide/1.9/build/buildSystem.html. Есть статья на хабре, но она уже устарела.
В русскоязычной среде с Dojo совсем капут, несмотря на то, что в создании ранних версий участвовало несколько русских разработчиков, в том числе Илья Кантор. Есть гугл-группа — там могут помочь, но особой активности не заметил. Сам по мере сил пытаюсь отвечать на вопросы по Dojo на форуме javascript,ru. Если знающие Dojo хабражители присоединятся ко мне там, то может быть мы сможем организовать место, где смогут ответить на не самые примитивные вопросы.
Мне, правда, очень понравился Dojo и очень жаль, что в России он почти не используется. Я планирую продолжать освещать его на хабре. Пишите про какие его возможности хотите прочитать в первую очередь. Если есть интерес могу попробовать написать туториал одностраничного приложения «для чайников».
По сборке dojo есть статья в reference guide: dojotoolkit.org/reference-guide/1.9/build/buildSystem.html. Есть статья на хабре, но она уже устарела.
Довольно подробная статья. С фреймворком не знаком, поэтому почитать было очень интересно. Приведу несколько заметок, если вы не против:
1) Я считаю, что аспекты — это прекрасно, пока они контекстно зависимы. В общем же случае это уродство крайней степени, которое просто уничтожает целостность приложения.
2) Вам пример с SVG я бы дополнил иерархией.
В общем, в чем я больше и больше убеждаюсь, общая беда всех подобных канонично спроектированных фреймворках, где всё по уму, заключается в том, что они по сути не являются готовыми решениями для разработки. Это отличные расширяемые инструменты, которые в руках мастера могут творить чудеса, но перед человеком, только начавшим изучение такого фреймворка, стоит задача не только изучить всю документацию, но и сообразить как это всё грамотно использовать в конкретном проекте. И если первая часть решается наличием времени, то со второй возможно придется повозиться основательно. И что самое смешное, что пресловутое вторичное использование кода при разработке нового проекта часто не работает для таких фреймворков. Потому что смена разработчика неизбежно приводит к переосмыслению структуры кода. Да и скилл одного разработчика может расти, что тоже скажется на подходе. Всё это следствие высокой гибкости, которую все так невероятно любят.
Последнее, что я освоил был AngularJS. Его подход ничего кроме негодования не вызывает. Однако, сложно спорить с эффективностью такого подхода в большинстве сценариев. Это то самое готовое решение, которое можно взять использовать, потому что оно уже знает, что тебе нужно и знает как тебе это нужно сделать (опять таки в большинстве сценариев). И мне кажется такой подход притягивает новых разработчиков, несмотря на весь абсурд и «негибкость» оставшиеся на втором плане.
извиняюсь если слегка сумбурно.
и да, это просто имхо, не принимайте близко к сердцу.
1) Я считаю, что аспекты — это прекрасно, пока они контекстно зависимы. В общем же случае это уродство крайней степени, которое просто уничтожает целостность приложения.
2) Вам пример с SVG я бы дополнил иерархией.
В общем, в чем я больше и больше убеждаюсь, общая беда всех подобных канонично спроектированных фреймворках, где всё по уму, заключается в том, что они по сути не являются готовыми решениями для разработки. Это отличные расширяемые инструменты, которые в руках мастера могут творить чудеса, но перед человеком, только начавшим изучение такого фреймворка, стоит задача не только изучить всю документацию, но и сообразить как это всё грамотно использовать в конкретном проекте. И если первая часть решается наличием времени, то со второй возможно придется повозиться основательно. И что самое смешное, что пресловутое вторичное использование кода при разработке нового проекта часто не работает для таких фреймворков. Потому что смена разработчика неизбежно приводит к переосмыслению структуры кода. Да и скилл одного разработчика может расти, что тоже скажется на подходе. Всё это следствие высокой гибкости, которую все так невероятно любят.
Последнее, что я освоил был AngularJS. Его подход ничего кроме негодования не вызывает. Однако, сложно спорить с эффективностью такого подхода в большинстве сценариев. Это то самое готовое решение, которое можно взять использовать, потому что оно уже знает, что тебе нужно и знает как тебе это нужно сделать (опять таки в большинстве сценариев). И мне кажется такой подход притягивает новых разработчиков, несмотря на весь абсурд и «негибкость» оставшиеся на втором плане.
извиняюсь если слегка сумбурно.
и да, это просто имхо, не принимайте близко к сердцу.
НЛО прилетело и опубликовало эту надпись здесь
Грустно что это перевод статьи возрастом в год, хотя учитывая русское сообщество кому-то да полезно будет.
Сам пользую его. Из явных плюсов по сравнению с многими другими — не навязывает какой-то архитектуры, предлагая огромный вагон разнокалиберных кирпичей для построения всего.
Что касается тестирования… лучше использовать что-нибудь более общепринятое типа Mocha, Jasmine, Sinonjs
Сам пользую его. Из явных плюсов по сравнению с многими другими — не навязывает какой-то архитектуры, предлагая огромный вагон разнокалиберных кирпичей для построения всего.
Что касается тестирования… лучше использовать что-нибудь более общепринятое типа Mocha, Jasmine, Sinonjs
Полезная статья. Спасибо! Для построения приложений с web-интерфейсом использую qooxdoo. А выбор js-библиотеки для обычных сайтов был проблемой. Захотелось попробовать что-то альтернативное jQuery и qooxdoo (к сожалению, у qooxdoo совершенно разные подходы к созданию web-приложений и сайтов). Решил поискать чего-нибудь про dojo. Попалась Ваша статья. В результате, после нескольких экспериментов и краткого изучения документации выбор был сделан.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 причин почему ваш проект должен использовать Dojo Toolkit