Орел wrote:
Еще в ассемблер запросите, кочубеи.
Нет, если в языке нет изящности то я писать на нем не хочу. Постоянно будут ашипки, и ловить их будет трудно. Поэтому нах. А какие еще проблемы есть у Флекса? Окромя хреново написанного интерфейса.
Скопи-пастю выжимку из своеи рабочей записки по этому поводу (англ), без перевода - много букафф и спец. терминов:
Problem: lack of _quality_ support in the community. This
one came as a surprise. For such a popular technology, community
support is underwhelming. Chances to find answers to non-trivial
questions are slim. It seems that the community is mainly driven by
folks who mock up simple applications, and anything beyond that is gravy.
Solution: growing home expertise is essential; a point (or points) of contact
inside Adobe would be nice as well.
Problem: Lack of support for numbers greater than 54
bits. This was a real pain for us, as our objects must be consistent with
server-side, and String presentation/manipulation is expensive. It came as a
(rather telling) surprise that Flex didn't have something like BigInt for
arbitrarily sized numbers. Solution: I converted Javascript implementation of
BigInt to Actionscript.
Problem: IDE makes it easy to implement back-end calls,
but there is penalty: it has a tendency to hardcode things and generate code
that relies on libraries that change from release to release. Backwards
compatibility is there, but adding a new call may be problematic once a version
change has occurred. Solution: we rely on our own framework of backend calls
converted from Java. Since our inter-tier methods must be generated from IM
definitions it's a better solution anyway.
Problem: Performance. Most benchmark tests show that
Actionscript (and hence Flex) falls way behind Java in performance (I'm not
sure about Javascript/AJAX). Solution: this must be addressed at the design
level. Pure language performance is rarely a reason for a slow UI;
there are enough ways to suffocate it without even getting to the language
limitations. If we do our part right performance will be more than adequate.
Problem: Lack of support for collections. Yet another rather telling omission.
Solution: Luckily this is covered by community support: I found at least one quite
decent freeware lib that offers reasonable mapping to java collections.
Problem (?): no explicit thread support. There is
implicit thread support (in the form of callbacks to events and timers). While
this may be limiting, I don't know yet if this is a real problem.
Problem: Even though IDE is eclipse-based it actually
offers less than eclipse/Java in terms of code navigation features and build
flexibility and intelligence. I'm talking about little things here: it's quite
normal to fix "almost" all highlighted errors just to see yet another
batch of them getting highlighted as you've corrected the last one.
Я не писал об очевидном, например о том, что будучи "loosely typed" языком, AS тяжелее тестировать - компиляционные ошибки становятся run-time ошибками.
Обрати внимание на разделы об отсутствии поддержки цифр более чем на 54 бита и о коммюнити - для меня эти два момента были самыми странными.
Silverlight ты конечно глянь, но с UI-технологиями к сожалению на сегодняшний день ситуация - "выбери себе сам свой яд". Все затаили дыхание и ждут HTML 5. Не удивляйся, если обнаружишь, что Флех при всех его недостатках - лучшее из того что есть.
Login
Register
FAQ
Search
