Комментарии 43
Если у меня получиться привести аргументы в духе «это принесет компании столько-то денег» или «нам искать разработчиков будет в 2 раза легче» то конечно мигрируем. Но пока я не могу привести такие аргументы.
1. Sencha touch будет интегрирована в extjs, а это поддержка всех мобильных жестов из коробки — то есть готовая мобильная версия, а там, останется собрать каким-нибудь phonegap и мобильное приложение готово — соответственно экономия на разработчиках и расширение рынка.
2. Ну и разумеется, чем раньше переходить — тем меньше будет потом боли и времени, что тоже == деньгам.
Давать совет, если у вас тормозит наш сайт в браузере — обновите железо, это уже вообще за гранью!
На тот момент (2013), у юзеров нашей админпанели были Chrome и ноутбк с 2gb RAM. Учитывая количество таких пользователей для бизнеса дешевле им было купить железо получше. Сейчас учитывая новые мощности и на новых версиях ExtJS этой проблемы нет. Так как убрали поддержку старых браузеров.
Я хотел только донести, что в каждой технической реализации есть плюсы и минусы. И собственно производительность — это как раз тот минус. Но мы понимаем, что взамен мы получаем кросбраузерность аж до IE6 (которая есть в ExtJS 4.*) и конечно же это должно повлиять на другие характеристики системы.
Я ничего не спонсирую и не делал выводы хороший или плохой. Делайте выводы сами. Если я вам помог понять что это плохой продукт, это отлично. Я просто поделился своим опытом работы с этим фреймворком. Цели «продать» что-то у меня нет.
Пусть нас окружают только хорошие продукты!
Спонсорство, оно не только в деньгах меряется :) Использование продукта это тоже своего рода «спонсорство».
Мой опыт работы с ExtJS сугубо негативный. Объяснение потянет на отдельную статью, но для меня ключевым было 2 вещи:
1) Безумная иерархия «объектов». Даже на Вашем скриншоте иерархия до грида ужасает! А ведь каждый слой абстракции приносит код, стили и верстку. Вложенность DOM дерева будет огромной (оттуда в общем то и все тормоза растут).
2) Все хорошо работает ровно до момента, когда нужно сделать что-то нестандартное — сделать дерево-грид (tree-grid) со своей стилизацией и способом загрузки данных, добавить к кнопкам нестандартные штуки, объединить реализацию двух компонентов, чтобы они друг друга взаимодополняли… Уйдет куча времени чтобы осознать как это сделать, потом сделать и отлаживать.
Поэтому ExtJS — отличный выбор для всяких опердней и админок, где можно пожертвовать собственным неповторимым фир-стилем, и модным молодежным UX-ом. А если хочется
По большей части бизнесу совершенно второстепенно как система будет выглядеть, главное — чтобы она выполняла возложенные на неё задачи. А свистелки и перделки прикрутить можно потом, когда функционал будет готов.
Да, в ExtJS есть проблемы и со скоростью рисования сложных интерфейсов, и баги внутри самого фреймворка встречаются. Но это, пожалуй, единственный фронт-фреймворк, который охватывает вообще всё, от описания бизнес-моделей, до их отображения в UI.
И, честно говоря, стильно/модно/молодёжные реакты с ангулярами уступают extjs именно в том, что каждый раз приходится придумывать как данные будут читаться/храниться на клиенте и отправляться на сервер, как сделать простое текстовое поле с валидацией введённого значения, как поля будут связываться с моделями данных.
По большей части бизнесу совершенно второстепенно как система будет выглядеть
Свистелки и перделки обычно не нужны, это верно.
Но вот юзабилити у системы должно быть на уровне, например не должно быть лишних кликов для выполнения типичных операций. Лишние клики -> больше трудозатрат -> ниже эффективность -> меньше денег.
С универсальными UI библиотеками, типа Extjs бывает сложно сделать юзабельный интерфейс. Все компоненты фиксированные, нельзя так просто взять и сделать большую зеленую кнопку "Выполнить операцию", чтобы пользователям было удобнее (быстрее) в нее кликать.
С универсальными UI библиотеками, типа Extjs бывает сложно сделать юзабельный интерфейс.
А с неуниверсальными? «Юзабельный интерфейс» — это вообще субъективное понятие.
Все компоненты фиксированные, нельзя так просто взять и сделать большую зеленую кнопку «Выполнить операцию»
Даже во времена второй версии это спокойно реализовывалось подключением css с переопределением/добавлением необходимых стилей. С четвёртой или пятой версии имеются sass (или less) шаблоны для подстройки темы оформления под свои нужны.
Неуниверсальными? Имеется в виду что на Angular/React у вас есть прямой доступ к html/css, можно задизайнить все что угодно. Нужна большая кнопка в пол-экрана — будет сделано.
В Ext есть поддержка тем, я об этом даже писал статью, поэтому я в курсе, что с их помощью сделать можно, а что нельзя. Я сейчас перепроверил, возможности изменить размер индивидуальной кнопки нет, а SASS-переменные меняют размерности для всех.
В общем, полагаю, у нас слишком разный опыт с 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. Ну и лицензия запрещающая делать тулзы с его использованием.
отсутствие поддержки современных фича JS
Если проект собирается путем sencha app build, то «из коробки» есть поддержка всех фич es6 в том числе async/await, которые транспайлятся в es5 для совместимости со старыми браузерами
Хотя есть некоторый минус, этот фреймворк не очень популярен в РФ, понял это когда искал разработчиков под него. Самих кандидатов с опытом использования ExtJS не так много, и от многих был ответ: «Да, опыт с ExtJS есть, но на нем писать не интересно.». В итоге приходится искать кандидатов без опыта и обучать их ExtJS.
В 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.
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. Одной кнопкой разворачивается инфраструктура + архитектура рекомендуемая фреймворком.
Выбор плагинов и их написание это и есть работа разработчика.
… разработчик написав пару строчек — я решу бизнес задачу
Очередные утопические мечты… Я на своей памяти уже столько таких «мечателей» повстречал, что уже тошно становится видеть еще одного. НИКОГДА не будет продукта, в котором двумя кликами мышками / двумя строчками кода / и т.д. можно будет решить любую бизнес задачу. Гарантировано.
6-я версия заметно удачнее прошлых, но всё равно полно костылей, о которые спотыкаешься.
Опыта работы с этим добром в сумме год, но ещё нигде я не испытывал столько боли, как в случае с ExtJS, ковыряя исходники отладчиком в поисках причин некорректного или недокументированного поведения.
В общем, мой итог — фреймворк очень хороший, пока не выходишь за пределы функционала демок. Кастомизация приводит к боли. Хотя можно один раз пройти через это и потом рефлекторно обходить все больные места, написав к тому времени кучу своих заготовок, затычек и костылей. Их таблицы, если один раз победить и потом копипастить, пока вне конкуренции (имхо). Не видел пока ничего похожего по функционалу.
Их таблицы, если один раз победить и потом копипастить, пока вне конкуренции (имхо)Делайте сразу генератор на сервере, чтобы динамически выдавал готовый конфиг грида, и свой класс, от которого сгенерированные грибы будут наследоваться — удобно, если много однотипных таблиц.
Хотя можно один раз пройти через это и потом рефлекторно обходить все больные места, написав к тому времени кучу своих заготовок, затычек и костылей.Половину заготовок, затычек и костылей придётся переделывать после каждого апгрейда :)
Документации не так много, примеров вообще мало.
Для меня лично extjs = гемор.
Находили много багов которые очень мешали работе и заставлял тратить много времени чтобы все переписывать с велосипедами.
А обновлять фрейм не так просто и гладко.
Если вы уже завязли в Ext JS то… горе вам.
Куча багов, фиксить которые приходится костылями, которые отвалятся при переходе на следующую минурную версию, которая принесёт много новых багов.
Периодически меняют что-то внутри, отчего ломается старая логика.
Сейчас перевожу один большой старый проект с 4-й версии на 6-ю, надеюсь, разработчики фрэймворка просыпаются ночами от икоты :)
Но лучше для разработки интранетных вебприложений ничего пока нет, да.
13 выводов которые я сделал, после 4 лет использования Ext JS