Flex по сравнению с ExtJS для внутреннего системного фронтэнда, каковы их достоинства и недостатки?

Я начну с резюме:

Если бы мне пришлось выбирать прямо сейчас, я бы выбрал Flex. Привязка данных и взаимодействие с сервером чрезвычайно просты, интуитивно понятны и быстро настраиваются. Вы обнаружите, что если вы много занимаетесь версткой и просмотром фреймворков в стиле MVC, то Flex, вероятно, быстрее вас настроит, и его будет легче читать.

Сравнение разметки

Flex уделяет много внимания MXML, который является языком разметки. Для большинства ваших разработчиков он будет совершенно новым, поэтому если они уже знают HTML/JavaScript/CSS, то это может стать причиной отказа. Сила Flex заключается в том, что он не ограничен, как HTML. Если вам нужно свойство или привязка к базе данных, вы можете сделать это прямо в теге. Возможно, это не всегда лучшая практика для всего, но это возможно.

ExtJS использует подход дополнения стандартной разметки JavaScript, поэтому, хотя ваш HTML, конечно, должен быть сделан хорошо, на самом деле это JavaScript сияет, делая свою работу.

Компоненты/функциональность

Flex лучше работает с данными. Он использует E4X, который является встроенным языком запросов XML, использующим точечный синтаксис. BookCase.Books.Book[@id=43].@title, например.

ExtJS также делает привязку к базе данных, но она более многословна и не так проста, как Flex.

Flex имеет множество действительно хороших встроенных компонентов для моделирования макета, ввода и диаграмм. Они просты в использовании, имеют общий интерфейс стилизации (как правило) и могут иметь пользовательскую стилизацию и подмножество CSS, плюс некоторые собственные расширения. ExtJS использует стандартную разметку CSS, а не только ее подмножество.

ExtJS имеет больше плагинов и компонентов, чем Flex, а элемент управления Menu гораздо более настраиваемый и выглядит лучше. Стилизация по умолчанию также немного красивее в ExtJS.

Механизм компоновки

Flex, на мой взгляд, выигрывает в этом вопросе. Если вам нужен макет колонок, вы можете сделать либо сетку, либо поточный макет, чтобы достичь этого, и это примерно в 4 строках MXML. То же самое в Ext требует передачи объекта Javascript через класс макета. IMO, с ним сложнее работать практически.

Реализация

Обе системы легко развернуть и поддерживать. Копируйте файлы, и обе будут работать, если вы делаете непрерывную интеграцию.

Тестируемость

Вы можете использовать jsUnit для ExtJS, и FlexUnit для Actionscript. То, насколько легко управлять тестируемостью, полностью зависит от вашего контроля над стилем разработки. Оба фреймворка приведут к смешению пользовательского интерфейса и пригодного для тестирования кода, при этом ExtJS по умолчанию требует большего разделения.

Если вы настроите все правильно, то явного преимущества здесь нет.

Производительность

Internet Explorer на Windows имеет лучшую производительность Flash, как это ни печально. Если вы используете Mac, вы можете наблюдать замедление при начальной загрузке плагинов. Flex в продакшене должен работать с продакшен релизом, и вы должны использовать продакшен Flash player, а не отладочную версию. В нашей среде производственный релиз + производственный Flash Player сократили начальную загрузку на 4-6 секунд, поэтому убедитесь, что вы сравниваете яблоки.

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

Ремонтопригодность

У обоих есть серьезный потенциал стать монстрами. Flex станет монстром, если все будут кодировать все на MXML и никогда не писать скрипты или внешние CSS. ExtJS станет монстром, если вы слишком усложните архитектуру обработки данных и менеджеров компоновки.

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

Надеюсь, это поможет.