After spending some time working with Flex 4 on a real project, I can’t say I’m happy with this product. My list of complains is based on moderate sized project, 5 months, 4 developers, WebService-only back-end.
1. Flash Builder 4 has lots of issues – more than Flex Builder 3. AS of today it has lots of bugs:
-it doesn’t release resources;
-debugger does not allow to run several instances and consumes a lot of resources;
-debugger intercepts all network calls and the debugging proxy is terribly slow and inefficient;
-code navigation between several projects is absolutely impossible;
-compiler is unpredictable and slow;
-it periodically tries to do incremental compilation, even if you explicitly tell it not to do so — and you have to disable incremental compilation, because it’s slower than full rebuild of all related projects with Maven.
-Help system is not well designed — Adobe moved help to a separate AIRr application, in-place contextual help is non-existent; search always shows one link — “yes, there are probably some topics for your query — open separate application to search again”
2. Flex compiler is broken
It’s slow. It’s slower than any previous version I’ve used. And it’s buggy. Periodically it shows some cryptic messages like “there is no x or y or width or height properties on UIComponent”. It never points to exact source of problem — and I doubt it exists. Because sometimes fix is to set “-keep-generated-actionscript” flag on. And sometimes off. And if it doesn’t help then the fix is to reorder attributes in MXML tags. Just insane. And I can’t find the exact root of these messages, the only thing I can say for sure that they are caused by new MXML skins — no skins, no errors.
3. The new Spark library is over-engineered.
I worked on some Java Swing projects some time ago. It seems that Adobe takes the Swing route, however Flex becomes popular just because of the opposite — it was way far simpler than Swing. Flex ideology was “keep simple things simple, make complex things possible”. Now it turns to be the Swing ideology: framework usage is irrelevant, the only relevant thing is framework per se, and it should be perfect.
I can’t do a lot of things with Spark I was able to do with MX. Icons in buttons? Develop descendant component of Button, define new parts and develop separate skin. ComboBox where items in drop-down are large than input field? Develop own skin — just copy-paste and tweak a bit. Paddings? What paddings? It’s not a css attribute any longer, extend and develop own skin. Left/right/top/bottom? You can’t customize this via css, or develop your skin if you truly need this option.
But architecturally Spark is beautiful, no doubt. Astronauticaly beautifull architecture, if Joel Spolsky permits me to use this term.
4. New Spark library is incomplete.
Yes, this statement doesn’t contradict with [3]. Being overdesigned it’s missing a lot of functionality from MX: no Calendar, no DateInput, no ColorPicker, no PopUpButton etc. No clone for MX SWFLoader/Image. There is no complex containers at all (like Accordion and TabNavigator) Needless to say, there is no advanced controls like DataGrid and the supplied “proxies” for ItemRenderers confirm that there are will be none any time soon.
5. New states engine encourages unmaintainable code
Previously we have states with explicit overrides. All data related to override was co-located, so it was easy to see what and when changes. There were inheritance of states, and it was sufficient. There were no groups, but when you need state groups — then 99.9% of times you in fact have to extract part of component as sub-component, and coordinate isolated state changes there. But now the great property.inStateFoo=”xyz” notation comes.
Now you have to scan over tens or hundreds of lines of code and check all and every includeIn / excludeFrom attribute and decompose them back to the very same old “overrides”. In short, when you are debugging states you have to do job of compiler but without the help of compiler. And the existence of state groups multiples the complexity by the factor of ten. It’s a Ruby-way productivity — it’s easy to develop a sketch / prototype, it’s a nightmare to polish this sketch to be a real product and it’s absolutely impossible to support it. But sure, you can start quickly, who cares about the rest…
6. Vectors (Flash-10 related, not just Flex 4)
Vector is a canonical example of a half-pregnant woman. Hey, developers! Use new features - Vectors and Generics (or this is templates??? we are not sure on our own). Yep, it’s cool, Vector is a parametrized type. Though, there is no type covariance/contr-variance and no type bounds in syntax. So you have to cast data Vector whenever it’s declared as parameter or as a return value. But who cares?
7. Text engine (Flash-10 related, not Flex 4 only)
It’s great that “Gordon works on text”, and new engine is indeed superior. But may we have both Spark and MX on same engine by default without the dual way to embed fonts and dual size of embedded fonts?
Am I missing something?
Valery Silaev
Anatole Tartakovsky said,
June 22, 2010 @ 2:43 pm
Valera,
I would argue that 5 – new state engine – is positive change – simplicity and declarative approach versus code is better IMHO regardless on possible usage patterns. Also, you are working in high productivity mode/data bound application so you would stay primarily in MX. I consider Spark only on media/mobile apps, and there you have to be really creative with containers as guestures/UI navigation are different in iPhone/Android/RIM/Nokia.
Regards,
Anatole
Nathan Hinish said,
June 22, 2010 @ 3:00 pm
Hey Valery,
For (7), if you’re working in Flash Builder, you can right-click a project, then click Properties. In the Property window, click Flex Compiler on the left, then under “Compiler options” sections, check “Use Flash Text Engine in MX components.
Nate
Nathan Hinish said,
June 22, 2010 @ 3:07 pm
Ah, also regarding the network proxy note in (1), if you’re in Flash Builder you can disable the Network Profiler (if that’s what you’re talking about) from within the “Network Monitor” view. I think by default in the Flash perspective, it’s grouped with Console, Problems, etc. There’s a little icon in the top right of the panel with a slashed circle over a monitor. Alternatively, I think you can open .actionscriptProperties in your project and look for includeNetmonSwc=”true” and set it to false.
Hope that helps.
Mykola Golubyev said,
June 22, 2010 @ 3:28 pm
I think that the main idea of Spark’s skins and states design is to support Flash Catalyst and not to create them by your own. It is really easy to create skin for button mixing Adobe Illustrator and Adobe Flash Catalyst.
Ross R said,
June 22, 2010 @ 3:29 pm
I would say you are missing everything….. considering I was an active participant in the beta process and had almost none of the issues you raise…
“I can’t do a lot of things with Spark I was able to do with MX. Icons in buttons?” — ?? The entire point of the new Spark library is to allow you to do things like this easier than you could with MX. The mechanics of it are different, but, once you build it once, the end result is faster than MX and IMHO better than MX. I have build several applications using Lists and icons inside of each Item of a List. The first POC spark project I built to learn the Spark architecture integrated graphics and text in a complex layout inside of a button – and had the layout change on rollover.
I have seen the random cryptic error messages with the compiler, and the specific issues I discussed with the engineers were fixed for Beta3.
I do agree that the Spark component library is incomplete. It desperately needs, among other things, a Tree. Though, if you actually understand how the components are architected, they give you everything you need to do 99% of the things you may want to do. (IE – with a little fussing a Tree can be built using custom itemRenderers on a List, embedding Lists inside each item. You do run into problems when you go more than 2 levels deep, but it works great for lighter Tree implementations)
As for #5 – I have to agree with the fact that it “encourages” difficult-to-maintain code. Personally, I have yet to run into a problem with this, and the time saved in development because of this has more than made up for debugging time. Though – I use very format-intensive strategies to make updating things easier.
Marco Pracucci said,
June 22, 2010 @ 4:14 pm
I work at spreaker.com and we have benefit the Spark architecture. Yes. It’s an stronauticaly architecture, but it’s the most powerfull way I have ever seen to skin components. We currently don’t use Flash Catalyst: we have a graphical designer that work on Illustrator and then we import .ai directly into Flex. It usually require to write no AS code, but it still require (a lot of) hand-written MXML. I think it’s acceptable.
Marcos Neves said,
June 22, 2010 @ 4:32 pm
Totally agree,
In times where great ideas like ruby, python, jQuery and MongoDB are getting space, flex is going in the opposite direction.
Valery Silaev said,
June 22, 2010 @ 4:44 pm
@Nathan,
Thank you for your valuable reply, but…
1. MFTEText is not enabled by default when project type is Spark+MX. It wonders me why. In reality, no one will use Spark alone for more or less serious application — it lacks too many components out of the box, and third-party offers (either open source or commercial) are note available yet (or at least the amount of libraries are not comparable to Flex 3 counterparts).
After I’ve read your reply, I googled about this issue (it easy to search when you know what you are looking for) and found another option:
-theme+=${flexlib}/projects/spark/MXFTEText.css
However, the only option I know from documentation is that I need different embedAsCff css attribute for Spark/MX, but not the fact that I may enable new engine for both libraries. As Yakov says, if it is not documented, it doesn’t exist.
By the way, what command line options we have for this feature? Is it available in existent Maven plugins?
2. It good that I can disable network monitor, but, well… isn’t it was too preliminary to ship it and have enabled by default?
@Mykola,
I believe I understand this move and the necessary changes required in designer/developers workflow. However, I do not expect that design job will be necessary up to _that_ extent. But my point is a bit different: beside just creating skins you have to create extensions to Spark components to accommodate new UI features. Guess how it’s simple to correctly implement padding (attribute that affects size) to component that doesn’t handle such feature. In many cases it’s not just about putting [Style] metadata tag a top of sublsass declaration. It requires serious involvement of developer(s) to support design/skinning. Sure, it is in fact simpler than previously (if we forget about Degrafa for a while, that is far more superior to FXG). But, this development job has to be done anyway even in simplest cases, that was/is covered by MX part of framework.
@Anatole
Well, previous version of states was, in my opinion, “declarative enough” but better structured. I pointed out that in new model it’s far easier to start tweaking states, however it’s harder to maintain code, even in the simplest case — when you need to introduce new state. Altering existing state in complex component is a detective task — state-dependent changes are scattered all over the code.
Valery
Jonathan Keener said,
June 22, 2010 @ 5:23 pm
I’ve been in the process of converting a number of mid to large FB3 projects over to FB4 and I’ve ran into similar issues.
1. Definitely agree, the stability of the Flash Builder 4 environment has been worse the Flex Builder 3. I’m using the plug-in, with Eclipse 3.5, and I’ve had it crash or lockup a number of times during compilation of the projects. It seems that the JRE used with Eclipse has made some difference, I’ve settled on JRE v5.22 at the moment. Seems to run slightly smoother, but still not as dependable as FB3. So far, I can’t say compile time has been that great. For me, I’d say comparable to FB3 at times, sometimes slower. Mine will sit at 100% for like 30 seconds before it goes away, which is strange. I have found myself turning off “Build Automatically” which I never really did in FB3. Another area regarding stability has been going from Source to Design mode. I’ve had a number of times where the interface didn’t come up right and eclipse needed to be restarted.
2. There have definitely been some strange error messages during conversion. So far, I’ve worked through them.
3/4. I do like the Spark library to a point. I see where they are going, and I wish they were there. The fact that many components are not in Spark yet is frustrating, I feel like I’m using a beta version or something. I like the idea of skinning, but the lack of certain css attributes has made the FB3 to FB4 conversion pretty painful. I’ll convert something to Spark, and then for one or two css tags that are not longer supported, I have to create a skin. I have not tried Flash Catalyst yet. I understand Adobe’s take on “The Designer” and “The Developer”, and providing separate tools for each, and using Catalyst to connect them. However, I’m filling both roles, and am more the Developer, and I need a tool that is quick and easy for me. I think they’ve left a gap there from an efficiency perspective. Maybe a license to Flash Catalyst should have been included with Flash Builder 4 Premium, I don’t know. It’s hard to justify buying their “Master Collection” to do appropriate skinning.
5. So far, State conversion was pretty straightforward for me from FB3 to FB4. I do agree that it can definitely still get confusing with complex states, but I think FB3 was prone to the same issue.
6. Haven’t played with Vectors yet, but I’m actually looking forward to using them. I never liked having to use ArrayCollections in FB3 for classes that had 0-many children of a specific class type. Now with Vectors, I can enforce that all child objects are of the correct type.
7. Haven’t focused on the new text engine yet.
A couple of other items I’ve noticed. There doesn’t seem to be a lot out there on theme development. I was considering creating a common theme that could be used for all of my projects, but it doesn’t seem to be the best way to do it at the moment. From what I could tell, recompiling the them did not reapply it to the projects automatically (I had to go into each project and deselect and then reselect the theme to refresh) So I’m stuck with copies of CSS, images and skins in each project. (I’ve got to compile everything into one swf that can’t reference any other swfs at runtime)
I do like the code formatting and import cleanup tools. I’m also using SourceMate, and I’ve been very happy with their tool.
Tom Gruszowski said,
June 22, 2010 @ 5:32 pm
Maybe we can all agree that Flex 4.x is just a really nice start for a great future product. The line had to be drawn somewhere and that’s it. I don’t think it’s possible for things to be more complicated with the hybrid (Spark+MX) modes that we have now. Here’s to wishing that one day with a component complete Flex 5 it will all come together.
Igor Costa said,
June 22, 2010 @ 6:09 pm
Hi there Guys
Some of your points are really interesting and others a true. But keep in mind that Flex 4 is still in transition, when they release the new SDK I said “OMG is not possible”, due to pressure of investors or Adobe I don’t know.
The true we can avoid is, the design in mind is a very positive way on new ux and cute UI for end users. But is still in transition. Most of features released on 4.0 Builder and SDK were not finished yet. And might believe they will update soon in the spring.
But for sure you should start trying to change the way of doing Flex 3.x to Flex4.x 50% of your behavior in previous version are now changed and you have to adapt.
Some points on Spark is true, but they are still working on new implementations, Example of that, Spark VideoDisplay does not have attachCamera method, and among other things. Refined version I think is just going to be on 4.2 version above.
Regards
Igor Costa
Valery Silaev said,
June 22, 2010 @ 7:49 pm
@Ross
Probably I indeed miss everything, for me simplicity counts a lot
And having just host+skin is not very convenient for me, I’m more comfortable with host+skin+rich_set_of_customization_attributes.
Actually, host/skin divide was introduced in Flex 3. Look at mx.controls.Button — control itself is a host, it’s passed to skin as styleName and maintain the state of the skin to match state of the host. Sounds similar? Yes, this is indeed how Spark works, just mentally replace styleName with [HostComponent]. There where no FXG, but there was (and is) Degrafa, and it has far richer options to declaratively create graphics (Degrafa repeaters are the most notable feature missing for me in FXG). It’s a no-brainier to create List of Icons or List of any other complex renderers in Flex 3.
You are telling me that it’s easy to copy button skin in Spark and create own one that displays icon. I know this. But try create a reusable Button with icon implemented as component part and customizable via css; just several “easy” css style properties: source as well as placement (4 positions around label) and gap. Try to create truly reusable host+skin that accommodates these requirements. I had this in MX, I want to have same component in Spark available. Am I asking too much?
For you and for readers who thinks that I just don’t get Spark, here is the list of features I truly liked in Flex 4:
1. Two way data binding. Just one character difference compared to what was available previously but how it’s convenient!
2. “Externalized” layout algorithms. Just excellent, and I don’t understand why it was not done in Flex 2
3. destructionPolicy. Finally, we have a fully controllable life-cycle of a component.
4. Probably new effects and filters should be in this list — but we didn’t use them yet.
Valery
Valery Silaev said,
June 22, 2010 @ 7:57 pm
@Marco Pracucci
“but it’s the most powerfull way I have ever seen to skin components”
yes this is exactly what I’ve said. Java Swing is one of the most powerful UI library, but its complexity drives it to grave. JavaFX tries to change the situation with no much luck so far. Time will show whether or not Spark will manage a balance between framework completeness / simplicity and developer productivity / performance.
Bjorn Schultheiss said,
June 22, 2010 @ 8:51 pm
I have recently had to manually (no catalyst) re-skin a Flex 4 app.
The disadvantages (compared to flex 3) were, that it was not was I used to.
Skins vs styles thinking has changed a lot,
there was a lot of copy and pasting,
no inheritance,
it just didn’t feel natural.
The benefits were that it was easier to make detailed changes.
It seemed verbose for for simple changes but it was the difficult changes that makes this method worthwhile.
In all I feel the new spark architecture is still a step forward from where it was.
Bjorn
tcs said,
June 22, 2010 @ 11:10 pm
No, this dude is right. Flex is a pain in the ass. Every time you turn around they are touting the revolutionary new framework, this time, it really will be easier to skin components, connect to data blah blah blah. Wherever they have made a major improvement to the architecture, something else goes the opposite way.
And why, why why, cant we just get an Adobe engineered and supported actual SOFTWARE PROGRAM for writing Flex apps. Why eclipse….no I know why they say eclipse is so good…but bullshit. I can open dreamweaver and save an HTML page and close it before eclipse…Flex building Flash builder ever opens. Its just mostly just moving text around and passing that on to the compiler.
Adobe, the whole damn thing should just be Flex.
And by the way, the whole general public doesnt need to get involved in keeping up with the dot point releases of the Flash Player. Only devs need to ever ever hear…”get Flash Player 10.1.1.0.1 release candidate b debug version to enjoy the latest Flash experience!” It is already getting confusing to end users.
Nathan Hinish said,
June 23, 2010 @ 12:25 am
Wow… 8 hours later, and this thread has erupted. Valery, it looks like you’ve hit a nerve with some people. Glad the post was helpful.
After perusing the later posts, I notice that pretty much everyone here is in at least partial agreement: Adobe is profiting from a “best game in town” scenario. While they are satisfied with the new Flex product COMPARED TO ALTERNATIVES, it seems the developers are yearning for a bit more power. Here’s the conundrum: Adobe’s Flex SDK is “open source.” While in essence it may be titled as open source, what’s the point if there is no direct say in the future of the framework. Of course, of course, I forgot. There’s the feature request or “wish form” (https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform). I used to make wishes to Santa Claus too. I have created a bug before and seen it lay dormant for an extended time. Then someone from HP added comments and suddenly it was looked into. (I couldn’t actually find the bug anymore but it had to do with wmode and CTRL-+) Yes is anecdotal, and yes it dealt with wmode. My point here is that for a product to have the spirit of open source software, it should be open to the community to advance/evolve in the way the community sees fit. Part of open source is an open forum of discussion concerning how the system should work. Adobe’s approach is the same as Apple’s: give the tools but don’t give a voice. Paraphrasing Yakov in his post: Adobe’s approach is to take it nice and slow and milk Flash for everything it’s worth. But now Apple has swooped in and dazzled with its new “magical” interfaces and put up a sign saying “No girls allowed.” Unfortunately, I don’t think the situation bodes well for the Flash platform as the less technical people, our end users, keep hearing “HTML5 is here. No Flash necessary.” For the time being, Adobe will continue profiting from Flash but eventually that will give way to HTML5/CSS3/new JS APIs. So it’s up to Adobe to embrace the new paradigm and help shape it (AKA profit from it) or to try to cling to the Flash platform. I think they are starting to move in the right direction having Flash IDE export to Canvas, but as Yakov also states: “They can deliver given the right support from top management and proper investment, which is definitely not there.” (is twice in one post too much? sorry)
Faisal said,
June 23, 2010 @ 2:06 am
Apparently, Some Pros complain and complain only when things don’t go according to their plan or scheme. Flex is a great tool and one of the best when one knows how to utilize it. I use flash builder 4 and i wont trade it for anything. You can not just jump on the flex ship without becoming familiar with its internals. Many of the issues raised in here miss the point, and depict the lack of deeper understanding of the flex architecture.
I
William said,
June 23, 2010 @ 4:15 am
I’m happy to see people at Farata share my opinion on states and spark
From some years now, I’m pretty sure Adobe doesn’t think its tool for large application.
Only for small one ‘evangelists’ can explain and share on AdobeMAX and others events.
But he! We doesn’t use Flex to make some widgets! We’re making large applications, using several Flex lib projets and sometimes for AIR & Flex at the same time!
Ross R said,
June 23, 2010 @ 7:48 am
The true difference is that the Spark architecture and way of doing things is so completely different from MX that people used to MX are having problems shifting their focus. IMO this is similar to the UI shift between CS2 and CS3 – and subsequently between CS3 and CS4. Many people complained up a storm about how much different the UI was. But, at the end of the day, once they shifted gears and started using the new interface, people started to realize that it was BETTER than before. They were working faster, and more efficiently than before. For me the same goes with Spark.
To be fair, I only dabbled in Flex before the Spark architecture, only building a half dozen or so different applications. So it wasn’t that far of a jump for me to convert over to Spark when FB4 came out in beta. I quickly picked it up, and even more quickly converted over to it. As I see it, Spark is hundreds of times better than MX. It is more intuitive, faster, and easier to code.
For the record, every application I build is powered by external XML, and is typically styled with an XML as well.
JabbyPanda said,
June 23, 2010 @ 9:40 am
Regarding (7) and using -theme+=${flexlib}/projects/spark/MXFTEText.css – actually this option is well documented with all current limitations if this approach will be taken at “Using Flex 4″ documentation:
http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8f-26a13bbf123c441239d-8000.html
As for the compilation of our app, we are using Ant and *local* configuration file
http://livedocs.adobe.com/flex/3/html/help.html?content=compilers_10.html
The structure of this local configuration file reminds “flex-config.xml” file.
Inside this XML file we specify absolute (can be relative too) path to include MXFTEText.css file into compilation routine:
…..
c:\Flex4SDK\frameworks\projects\spark\MXFTEText.css
…..
JabbyPanda said,
June 23, 2010 @ 9:43 am
s:Image http://forums.adobe.com/message/2845456?tstart=0#2845456 and s:Form http://forums.adobe.com/message/2827512?tstart=0#2827512 components are now part of Flex 4.5 SDK, and I would expect from SDK team that Spark DataGrid and Spark Tree components are currently being baked.
Ari Walker said,
June 23, 2010 @ 10:07 am
Change is sometimes difficult for some to swallow, but clinging to an old way of doing things can make you feel dissappointed. It takes you out of your comfort zone. But you don’t grow muscles from being comfortable, and you don’t improve yourself and your projects without going through growing pains. I have been using Flex for years and the new Flex 4 is an awesome system. From Groups, to layouts, to skinning, to the new css, to the new FilledElement primitives, to the FXG support it is amazing full of usefull features to enhance productivity. So you are dissappointed by some temporary bugs, and yet, fail to see the lasting great new features? Please reflect on your perceptions and make sure they are correct. Measure the temporary bugs that will go away against the lasting new features with the appropriate weights. You do so and you will see your dissappointment fade.
Carsten Schlipf said,
June 23, 2010 @ 4:53 pm
WRT points 1-2 I’d say that everyone, who still uses Flash Builder is at his own fault. Our whole team has switched to IntelliJ IDEA: Much fast with multiple modules, when compiling and way more intelligent. The refactoring and auto-completion capabilities of FlashBuilder are just a bad joke. I was very dissappointed, when I had to use FlashBuilder for the first time after I had used Flex Builder first and then Idea.
WRT point 7: Absolutely agree. Why is Vector the only class, where I can use this generic/template style? Should have been incorporated everywhere else.
Valery Silaev said,
June 23, 2010 @ 7:57 pm
Ari,
If you bother to fully read my post and my replies, than you surprisingly find that “an old way of doing things” I accustomed to is very similar to Spark skinning. And that having layout algorithms separated from containers is noted by me as one of the greatest features.
Have you completed any real-world project with Flex 4? I understand your excitement based on examples of neat-and-cool Solar custom layouts built by enthusiasts and published on the web. But try to complete end-to-end product with Spark and you will notice how much time is spent to develop not the business functionality, but missing components and tweaking monolithic skins per every tiny change necessary. Is it the source of productivity boost you mentioned? Or probably sluggish IDE? Or compiler that I can’t longer trust because it fails from time to time with cryptic messages (even if the only change is removed MXML comment)?
I agree that Spark has some great design decisions. But till they will be polished and exposed in usable and customizable form they’ll remain just a cool technology preview rather than a product (as it’s being sold).
After reading comments from those who tried to use Spark in real projects I have yet another thought. Some time ago there was a company called Sun Microsystems, and it’s introduced J2EE to the world. Among many questionable decisions of initial J2EE architecture there was a notion of roles: Developer, Assembler, Deployer etc. In real life all these roles were played by the same person — developer. And if all roles are played by the same person then there is no workflow. But the complexity to support this non-existing workflow was already introduced, and we all remember how J2EE was received (probably, not everyone today remembers “why”, but, definitely, everyone remembers “how”). I’m trying to foresee the fate of Adobe’s Designer-Developer workflow, that is one of the driving forces behinds certain important design decisions in Spark. Are companies ready to invest into new tools, training or hiring new personnel, changing product development process etc etc to support this model? Or in reality we will end up with the same “roles aggregation” short-circuit with all associated drawbacks?
Darren said,
June 23, 2010 @ 10:39 pm
@Valery, I fully support Adobe pushing the Designer-Developer workflow. There are already too many horribly-designed apps in the world. In most cases, developers designing apps is as bad as designers developing apps. Other developers don’t usually mind an app designed by a developer but for the average user it’s an unusable piece of crap even if all the functionality is working 100%.
By the way, there was a very good discussion on the pros and cons of the new Flex skinning model here:
http://www.flexjunk.com/2009/08/03/flex-4-skinning-ignores-developer-needs/
Nick Kwiatkowski said,
June 24, 2010 @ 4:53 pm
I was kinda disappointed by this post.
– In my testing, the compiler is faster, if you are using the Flex 4 technologies. I’ve found if you are running in the legacy mode (Flex 3 compatibility mode), it seems to take longer than before. Is that what your project is in?
– I run FB4 in standalone mode, with great success. I use it every day, and I can only think of maybe one time where it crashed. Are you using one of the recommended JREs / Eclipse versions that was recommended?
– The Spark / States engines are great! They did take me a while to get used to them, but I feel like I’m doing a lot less hacking to get things to work right. The states engine is more verbose, but I can tell you that is much easier to program from scratch (not using the IDE), and a heck of a lot easier to deal with if you are debugging.
– I do agree with you that it’s a disappointment that not all the components are Spark based yet. But I know that there are some great engineers working on moving these extremely complex items over to spark. I wouldn’t want to be re-creating the DataGrid component — that thing is a beast!
Have you tried anything from the Flex 4.5 beta? It would be worth your try!
Valery Silaev said,
June 25, 2010 @ 6:08 pm
Nick,
– We were using FB4 as a full bundle (not as stand alone plugin). After Nathan’s replies to this post I disabled several features (most notably network proxy) and indeed it is more robust now (not that resource hungry, memory release is performed regularly). Actually, all the team besides me is on IntelliJ IDEA now, and I’m the only with FB while we have to profile application. Leaks happen, you know
– Project setup is not very complex: one application, 3 modules, 2 swc libraries, and number of fonts-only modules — we compile font modules separately as far as fonts transcoding takes plenty of time with either Flex 3 or Flex 4 (this is understandable, no complains). I don’t know why, but it takes significant time to compiles even such relatively simple 1 + 3 + 2 setup. I had a far more complex setup for applications developed with Flex 3 — and compilation runs way faster. The most frustrating thing is that Flex compiler has bugs with MXML/skins processing — otherwise how I can explain that turning on/off compiler option -keep-generated-actionscript affects “correctness” of program? Or that removing XML comment from MXML changes the compiler SUCESS/FAIL status. Btw, we get same error in all environments (FB/IDEA/Maven)
– To understand my complains about new states paradigm, please do the following experiment in your mind. Imagine that your application must handle a business object Project that has several states (Proposed, Estimating, Executing, Archived). Now imagine that you need to introduce new state Approving right between Estimating and Executing. If you designed your business objects model thoroughly, and you have GoF State pattern (http://en.wikipedia.org/wiki/State_pattern) applied then it’s very easy and fully incremental change — just introduce new _encapsulated_ state, add it in one place and you are done. Same as with old Flex states model. However, if you din’t use the State pattern and didn’t account for such changes at all, you would have to scan your code to adjust each and every if/case statement to add handling for new Approving state. Bad OOP (or actually no OOP at all). With the new state engine it looks like this.
Let me repeat this again: it’s easier to write in new state model, but it’s harder to read. And hence it’s harder to extend / maintain. Take a look at default FXG skins of Spark — how long does it take to explain how object will look in every specific state? What rects are drawn, with what stroke, what filters are applied etc? You mentally have to do the same job as compiler when it combines all individual changes back to IOverride (that you were creating in Flex 3 by hand).
Valery
Andrei Kuzmenkov said,
February 3, 2011 @ 11:20 am
I wonder if anybody tested changes in performance which brings with it migration to Flex SDK 4.
Simple tests show that instantiation of visual components, adding them to the stage got 3-4 times slower than in SDK 3!!!
For simple apps the difference may be not noticeable, but for apps with complex custom components, or simply apps overusing containers, migration from SDK 3.5 to SDK 4 means a big issue. Be aware such apps may need to be redesigned to better reuse objects.
See more details and simple samples for SDK 3.5, SDK 4.1 with MX, and SDK 4.1 with Spark:
http://forums.adobe.com/thread/786472?tstart=30
Yordan Yanakiev said,
June 25, 2011 @ 9:45 am
Seems like the author is not yet ( or at least he were not at this time ) fully Flex 4 developer, else he would be really happy with Flex 4+;
Flex 4.5.1 is something which all Enterprise developers dream of.
Go go Flex , you are amazing product !
Bertrand L said,
July 5, 2011 @ 6:24 pm
I agree with the author. We’ve started migrating a 100 000 lines Flex 3.5 application and it’s hell…
Flex 4.5 is great… the migration is not. In fact I don’t even know why we are talking of a migration process as we need to rewrite 50% of the MXML. It’s a re-development of the whole UI.
We have stopped our migration process half-way. We can not justify the costs… and what if Adobe changes everything again in Flex 5 ? Now considering alternatives such as rewriting the application in HTML 5/JQuery.