Как стать автором
Обновить

Комментарии 43

А почему не мигрируете на Extjs 6.*?
Я бы с удовольствием. Но это больше вопрос бизнеса.
Если у меня получиться привести аргументы в духе «это принесет компании столько-то денег» или «нам искать разработчиков будет в 2 раза легче» то конечно мигрируем. Но пока я не могу привести такие аргументы.
Аргументы для бизнеса с ходу:
1. Sencha touch будет интегрирована в extjs, а это поддержка всех мобильных жестов из коробки — то есть готовая мобильная версия, а там, останется собрать каким-нибудь phonegap и мобильное приложение готово — соответственно экономия на разработчиках и расширение рынка.
2. Ну и разумеется, чем раньше переходить — тем меньше будет потом боли и времени, что тоже == деньгам.
Вроде речь про админки своего приложения, там, зачастую, даже кроссбраузерность не требуется.
Спасибо за статью. Мы у себя используем ExtJS совместно с Delphi в составе Унигуя. Очень удобно. Вместо того, что бы заниматься велосипедостроением занимаемся своими бизнес-задачами. Сейчас Унигуй активно переписывают на 6-ку. Фаршад писал недавно, что следующий релиз будет уже на 6-ке. Писали, что скорость работы существенно повысится.
Пожалуйста, прекратите спонсировать плохие продукты :(
Давать совет, если у вас тормозит наш сайт в браузере — обновите железо, это уже вообще за гранью!
Замечу, что гриды в вебе везде такие. Особой скоростью гриды везде не блещут. Упирается всё в сам JS.
Делал в своей жизни несколько гридов, полно информации как грузить в грид десятки тысяч записей. Не вижу тут проблем в реализацией, тут скорее проблемы с постановкой — а реально ли пользователю нужно столько записей в видимом окне браузера?
Вы наверное не правильно поняли, и приняли этот «совет» (хотя я просто делал выводы) на сегодняшний день.
На тот момент (2013), у юзеров нашей админпанели были Chrome и ноутбк с 2gb RAM. Учитывая количество таких пользователей для бизнеса дешевле им было купить железо получше. Сейчас учитывая новые мощности и на новых версиях ExtJS этой проблемы нет. Так как убрали поддержку старых браузеров.
Я хотел только донести, что в каждой технической реализации есть плюсы и минусы. И собственно производительность — это как раз тот минус. Но мы понимаем, что взамен мы получаем кросбраузерность аж до IE6 (которая есть в ExtJS 4.*) и конечно же это должно повлиять на другие характеристики системы.

Я ничего не спонсирую и не делал выводы хороший или плохой. Делайте выводы сами. Если я вам помог понять что это плохой продукт, это отлично. Я просто поделился своим опытом работы с этим фреймворком. Цели «продать» что-то у меня нет.

Пусть нас окружают только хорошие продукты!
Спасибо за развернутый комментарий, для меня посыл статьи был немного другим.
Спонсорство, оно не только в деньгах меряется :) Использование продукта это тоже своего рода «спонсорство».
Мой опыт работы с ExtJS сугубо негативный. Объяснение потянет на отдельную статью, но для меня ключевым было 2 вещи:
1) Безумная иерархия «объектов». Даже на Вашем скриншоте иерархия до грида ужасает! А ведь каждый слой абстракции приносит код, стили и верстку. Вложенность DOM дерева будет огромной (оттуда в общем то и все тормоза растут).
2) Все хорошо работает ровно до момента, когда нужно сделать что-то нестандартное — сделать дерево-грид (tree-grid) со своей стилизацией и способом загрузки данных, добавить к кнопкам нестандартные штуки, объединить реализацию двух компонентов, чтобы они друг друга взаимодополняли… Уйдет куча времени чтобы осознать как это сделать, потом сделать и отлаживать.
добавить к кнопкам нестандартные штуки

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

Поэтому ExtJS — отличный выбор для всяких опердней и админок, где можно пожертвовать собственным неповторимым фир-стилем, и модным молодежным UX-ом. А если хочется понтов красоты, скорости, и индивидуальности, то надо сильно больше денег — на реактах в проект можно смело закладывать человеко-месяцы на велосипедостроение своих гридов и кнопочек.
Есть KendoUI под ангуляр. Стоит 1к$ и предоставляет кучу компонентов.
Самый главный плюс ExtJS — это, как и сказал автор статьи, возможность не заморачиваться ни с чем, кроме, собственно, бизнес-логики.
По большей части бизнесу совершенно второстепенно как система будет выглядеть, главное — чтобы она выполняла возложенные на неё задачи. А свистелки и перделки прикрутить можно потом, когда функционал будет готов.

Да, в ExtJS есть проблемы и со скоростью рисования сложных интерфейсов, и баги внутри самого фреймворка встречаются. Но это, пожалуй, единственный фронт-фреймворк, который охватывает вообще всё, от описания бизнес-моделей, до их отображения в UI.

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

Свистелки и перделки обычно не нужны, это верно.


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


С универсальными UI библиотеками, типа Extjs бывает сложно сделать юзабельный интерфейс. Все компоненты фиксированные, нельзя так просто взять и сделать большую зеленую кнопку "Выполнить операцию", чтобы пользователям было удобнее (быстрее) в нее кликать.

С универсальными UI библиотеками, типа Extjs бывает сложно сделать юзабельный интерфейс.

А с неуниверсальными? «Юзабельный интерфейс» — это вообще субъективное понятие.

Все компоненты фиксированные, нельзя так просто взять и сделать большую зеленую кнопку «Выполнить операцию»

Даже во времена второй версии это спокойно реализовывалось подключением css с переопределением/добавлением необходимых стилей. С четвёртой или пятой версии имеются sass (или less) шаблоны для подстройки темы оформления под свои нужны.

Неуниверсальными? Имеется в виду что на Angular/React у вас есть прямой доступ к html/css, можно задизайнить все что угодно. Нужна большая кнопка в пол-экрана — будет сделано.


В Ext есть поддержка тем, я об этом даже писал статью, поэтому я в курсе, что с их помощью сделать можно, а что нельзя. Я сейчас перепроверил, возможности изменить размер индивидуальной кнопки нет, а SASS-переменные меняют размерности для всех.

У меня ни разу проблем с доступом к html/css не возникало. Во-первых, можно конкретной кнопке задать свой стиль, который определить вообще отдельно от темы. А во-вторых, если совсем всё плохо, можно сделать разметку в отдельном файле и загрузить её.

В общем, полагаю, у нас слишком разный опыт с ExtJs, т.ч. спорить бессмысленно.
В общем, полагаю, у нас слишком разный опыт с ExtJs

Это верно. Если бы мне не довелось писать кастомную тему для ExtJS чтобы перекрасить его в фирменные цвета компании, а затем еще написать 3 кастомных компонента, то, может быть, я бы и топил за него.


В то же время я слабо представляю себе проект, которому не понадобятся все эти кастомизации. 4к$ — сумма немаленькая, а значит и проект серьезный, на несколько лет, а может и навсегда. По-любому понадобятся кастомные доработки. Вот примеры того, что понадобилось мне с коллегами писать самим поверх ExtJS:


  • Кнопка увеличенных размеров (см. коммент ниже, там раскрою этот пункт)
  • Навигационное меню (гибрид вертикальных табов и аккордеона, чтобы у навигации появилась иерархия)
  • Компонент для рендеринга Яндекс-карт

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


Не исключаю того, что в мире Angular/React/и-другие тоже не все гладко с качеством кода. Но вы всегда можете написать свой компонент отдельно от остальных, вам не придется нырять в эти длинные цепочки наследования и сильно привязывать свой код к остальным компонентам.

проект ещё не требует кастомных компонентов, значит он просто недостаточно большой

Проект у меня, действительно, небольшой, но все кастомные компоненты были написаны без каких-либо проблем, т.к. в основном требовали нестандартного поведения, а не вида.

По поводу дикой цепочки наследования и порой странного кода внутри самого фреймворка согласен. Иногда приходилось проводить неоправданно много времени под дебаггером, чтобы понять, почему метод работает не совсем так, как описано в документации или подсказывает здравый смысл.

Теперь про кастомизацию кнопок:


можно конкретной кнопке задать свой стиль, который определить вообще отдельно от темы

Именно так мы и поступили, но проблема в том, что Ext.Button генерирует много html


<div class="x-component x-button x-has-text x-icon-align-left x-arrow-align-right x-layout-auto-item" data-xid="4">
  <div class="x-inner-el">
    <div class="x-body-el">
      <div class="x-icon-el x-font-icon"></div>
      <div class="x-text-el">Button</div>
    </div>
    <div class="x-arrow-el x-font-icon"></div>
  </div>
  <div class="x-badge-el"></div>
  <button class="x-button-el" type="button"></button>
</div>

* Немного почищено от id и onfocus/onblur атрибутов для улучшения читаемости


Как это переопределять? Более того, в версии 6.2.1 производится совсем другой html, так что все ваши переопределения будут еще и ломаться в процессе апгрейда.


6 лет назад, когда я разрабатывал ExtJS 4.x, ситуация была такой же (мы ловили баги из-за сломавшегося CSS при апгрейде), и я сейчас посмотрел на 6.x, лучше не стало.


Сравним с html для кнопки, который дает Bootstrap:


<button class="btn btn-primary" type="submit">Button</button>

Удивительно просто, не правда ли? Да еще и поддержка разных размеров уже встроена в библиотеку.

У ExtJS есть пара фатальных недостатков. Минимальная стоимость лицензии 4к$, тормознутость из за тонны оберток и контейнеров и отсутствие поддержки современных фича JS. Ну и лицензия запрещающая делать тулзы с его использованием.

Ребята из Sencha вроде же пытаются с каждым обновлением поддерживать новые фичи JS… пускай не сразу, но процесс идет…
Все так, кроме
отсутствие поддержки современных фича JS

Если проект собирается путем sencha app build, то «из коробки» есть поддержка всех фич es6 в том числе async/await, которые транспайлятся в es5 для совместимости со старыми браузерами
Но до сих пор нет поддержки source map.
Спасибо за статью! Мое мнение, в отношении ExtJS, полностью совпадает с Вашим. Это отличный инструмент для корпоративных приложений. Максимум внимания бизнес логике. Сам использую, очень доволен!
Хотя есть некоторый минус, этот фреймворк не очень популярен в РФ, понял это когда искал разработчиков под него. Самих кандидатов с опытом использования ExtJS не так много, и от многих был ответ: «Да, опыт с ExtJS есть, но на нем писать не интересно.». В итоге приходится искать кандидатов без опыта и обучать их ExtJS.
EXT JS — гуманитарен очень, по сути делаешь конфиги на таблицы и другие элементы. Если какой-нить конфигины не хватает все падает и не показывается, и ты можешь целый день искать. чтоб поставить какую нить фигню: типа autoasync:false. Последний extjs весит полгига, представляете сколько там конфигин? Чуть влево-вправо от стандартных туториалов и все тихо рушится не выдавая ошибок.
Есть же Sencha cmd с отладочным режимом (test)… там можно посмотреть ошибки, если все тихо рушится.
Времена Ext JS прошли. Современный тренд в веб-разработке — уход от грязных, ручных DOM-манипуляций и переход на декларативный способ построения интерфейса. Ext JS позволяет только поверхностно декларировать поведение своих компонентов, но когда нужно сделать сложный и оптимизированный компонент, начинается беготня по DOM, по дереву компонентов Ext JS и большим колстекам при генерации событий.

В React, Vue разработчик может полностью сосредоточится на работе со стейтом приложения, делегировав всю грязную работу с DOM самой библиотеке. Похоже в Sencha это и сами осознают и сделали версию под React — ExtReact.

По поводу велосипедов, opensource развивается очень активно, полно решений и для работы с формами и для построения гридов и для грамотной организации стора. Все вопросы гуглятся очень быстро, обучающих материалов хватает с избытком.
Спасибо за комментарий.

Учитывая что вы написали, расскажите если не сложно как реализовать задачу описанную в статье (CRM с Kanban доской) на основе приведенных вам фреймворков (которые только View) React и Vue. Какие шаги разработчика? Сколько времени на это понадобиться?

Попробую я ответить на этот вопрос.
Мне что бы эту задачу сделать понадобиться очень много времени. Надо собрать архитектуру, подключить все зависимости, написать документацию, найти UI плагины (DnD, Popup, Grid+(filter+paginator)), написать middleware.

Ведь React или Vue это только View. Я не против хоть каждый день собирать свой «фреймворк» — мне как разработчику это очень нравиться, но бизнес ценности я не принесу такой работой.

Почему нельзя написать такой фреймворк на подобии Ext JS, где будут все современные тренды разработки, с хорошей документацией и как разработчик написав пару строчек — я решу бизнес задачу? (не забывайте мы говорим про админ-панель).

Кстате фронтенд приложение написано у нас React, а мобайл на React Native.
Выбор фреймворка и основные шаги зависят от типа проекта: небольшой(до 3 месяцев) или крупный на несколько лет, от состава команды: есть верстальщик и дизайнер или нет. Основное на что стоит обратить внимание при разработке на react:
1. Самому создавать инфраструктуру для сборки, разработки проекта будет большой ошибкой. Поэтому выбирается наиболее популярный шаблон подходящий под требования из этого списка www.andrewhfarmer.com/starter-project. Если часто приходится делать небольшие проекты, то имеет смысл изучить один раз самый популярный и простой шаблон — create-react-app и везде его использовать.
2. Выбираем способ работы со стором — Redux или Mobx(mobx-state-tree). Redux имеет смысл использовать в сложных проектах и при наличии достаточного кол-ва времени, если хотим иметь четкое понимание работы приложения и возможность на 100% покрыть код тестами. В redux придется либо писать много бойлерплейта, либо изучить много мелких библиотек позволяющих строить более удобную архитектуру. Поэтому я бы сейчас в проект взял Mobx(mobx-state-tree), где уже из коробки есть функционал для нормализации данных в сторе и оптимизации вычисляемых зависимостей.
3. Дальше либо поверх css-фреймворков делаем свои продвинутые компоненты, работающие со стором, либо берем готовые из тех же ExtReact, DevExpress и пр. Обычно в приложении нужна малая часть того функционала, что реализована в таких монстрах как Ext JS, и бывает проще написать свой компонент с базовым функционалом и постепенно его допиливать, чем пытаться на Ext JS сделать что-то нестандартное.

Сделать канбан доску можно в течении 1 дня при наличии опыта в технологиях.
Извините, но сразу видно, что вы разработчик без опыта.
Мне что бы эту задачу сделать понадобиться очень много времени. Надо собрать архитектуру, подключить все зависимости, написать документацию, найти UI плагины (DnD, Popup, Grid+(filter+paginator)), написать middleware.

Для всего этого уже давно используются boilerplates. Одной кнопкой разворачивается инфраструктура + архитектура рекомендуемая фреймворком.
Выбор плагинов и их написание это и есть работа разработчика.
… разработчик написав пару строчек — я решу бизнес задачу

Очередные утопические мечты… Я на своей памяти уже столько таких «мечателей» повстречал, что уже тошно становится видеть еще одного. НИКОГДА не будет продукта, в котором двумя кликами мышками / двумя строчками кода / и т.д. можно будет решить любую бизнес задачу. Гарантировано.
Правильней писать «Ext JS», а не как у вас «ExtJs».
Спасибо! Везде поправил и обновил.
ExtJS крайне плохо переваривает какие либо кастомизации, и даже свои собственные компоненты не всегда нормально дружат друг с другом. Например, есть несколько разновидностей Store (вроде), устроенные внутри совершенно по-разному и работать с ними однотипно невозможно. Фреймворк пропагандирует declarative way программирования, но я постоянно сталкивался с тем, что как только пытаешься сделать что-то, чего нет в демках, то в каждом втором случае declarative way уже не работал и приходилось писать свои костыли. На форуме поддержки продукта так и писали — делайте обработчики. И это я просто пытался связать воедино таблицы, хранилища и модели данных, которые динамически грузятся с сервера с поддержкой многостраничности. Ещё меня постоянно доставало, что к одному и тому же объекту надо везде по-разному обращаться. Поиск по иерархии компонентов — одно имя, получение из фабрики сторов — другое имя, декларативное связывание — третье имя.

6-я версия заметно удачнее прошлых, но всё равно полно костылей, о которые спотыкаешься.

Опыта работы с этим добром в сумме год, но ещё нигде я не испытывал столько боли, как в случае с ExtJS, ковыряя исходники отладчиком в поисках причин некорректного или недокументированного поведения.

В общем, мой итог — фреймворк очень хороший, пока не выходишь за пределы функционала демок. Кастомизация приводит к боли. Хотя можно один раз пройти через это и потом рефлекторно обходить все больные места, написав к тому времени кучу своих заготовок, затычек и костылей. Их таблицы, если один раз победить и потом копипастить, пока вне конкуренции (имхо). Не видел пока ничего похожего по функционалу.
Их таблицы, если один раз победить и потом копипастить, пока вне конкуренции (имхо)
Делайте сразу генератор на сервере, чтобы динамически выдавал готовый конфиг грида, и свой класс, от которого сгенерированные грибы будут наследоваться — удобно, если много однотипных таблиц.

Хотя можно один раз пройти через это и потом рефлекторно обходить все больные места, написав к тому времени кучу своих заготовок, затычек и костылей.
Половину заготовок, затычек и костылей придётся переделывать после каждого апгрейда :)
сгенерированные грибы

Прям по Фрейду и в тему :)
Без sencha architect даже не стоит входить в этот фрейм.
Документации не так много, примеров вообще мало.

Для меня лично extjs = гемор.
Находили много багов которые очень мешали работе и заставлял тратить много времени чтобы все переписывать с велосипедами.

А обновлять фрейм не так просто и гладко.
Если вы ещё не встряли в Ext JS то… бежите от него подальше.
Если вы уже завязли в Ext JS то… горе вам.
Да норм, зато без работы не останешься :)

Без работы не останешься, а вот оставшихся не-седых волос лишиться можно.

Пользуюсь ExtJS 4 с «релиза» в 2011-м, который на поверку оказался ранней бетой.
Куча багов, фиксить которые приходится костылями, которые отвалятся при переходе на следующую минурную версию, которая принесёт много новых багов.
Периодически меняют что-то внутри, отчего ломается старая логика.
Сейчас перевожу один большой старый проект с 4-й версии на 6-ю, надеюсь, разработчики фрэймворка просыпаются ночами от икоты :)
Но лучше для разработки интранетных вебприложений ничего пока нет, да.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий