Update: OK, so everyone's caught up on the EPIC FAIL title (hey, it got your attention!) so I've changed it — I retract my original statement: it's not an EPIC FAIL, heck, it's probably not even a FAIL. However, it's definitely a FOL, so let's move on to address the real issue here which is that it's in all of our interests to make Flex 3 to Flex 4 migration as easy as possible. As such, please read my follow-up post, The Flex 4 One-Step Migration Challenge and let's try and make a list of the Flex 4 migration challenges for Flex 3 apps and try to address them.
The The change from Fx prefix to namespaces is an EPIC FAIL for Flex opportunity to concentrate on making Flex 3 to Flex 4 migration seamless article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Please also note what I mean by "migration" (from the comments):
I don’t consider simply compiling a Flex 3 app to constitute Flex 4 migration … If you’re migrating to Flex 4, you are most likely doing it in order to take advantage of Flex 4 features and thus you will want to layer in and/or transition to Spark components at some point and that’s when you will require more extensive namespace changes to your entire codebase. (And you real apps have dozens, if not hundreds of source files, libraries, skins, etc., all of which have to be reviewed and possibly updated.) That’s the use case that I feel we must make as painless as possible.
Having an easy migration path from Flex 3 to 4 will benefit all concerned and I cannot see how trying to make that process simpler (via an effort such as the 1-step migration challenge, etc.) is a bad thing.
Original post follows…
I just upgraded a simple app I wrote yesterday from an earlier version of Flex 4 (Gumbo) to the latest SDK and I got hit with the Fx prefix to namespace changes. Needless to say, I'm not impressed at all.
With the Fx prefix, I could easily layer Gumbo functionality into my existing apps and easily mix Spark and Halo without changing existing code or libraries. This ability is now gone.
I had to go through both my code and third-party libraries to add namespaces and I even had to alter the CSS. Previously, I had no such headaches and everything Just Worked (tm). Mixing Flex 3 and 4 was a joy. Not any longer.
This is a huge step backwards for anyone wanting to migrate existing Flex 3 apps to Flex 4 or reuse components. It makes the transition to Flex 4 and the creation of hybrid Flex 3/4 apps a real pain. It’s the triumph of formalism over pragmatism and the platform will suffer as a result.
And this namespace soup is going to make it all the more confusing for people new to the Flex platform to make sense of things.
Flex and similar technologies are commodities and compete in a supply market. The simpler things are, the more people will use them, and the higher the chances of the platform surviving and flourishing. Simplicity, user experience (yeah, even for a framework/platform) are key.
This namespace change adds lots of complexity for very little gain. It may satisfy the formalists who are probably as we speak trying to find a way to incorporate XSLT into the Flex workflow somehow and whose wet dreams would be a shift from ActionScript to Java for the platform but I hope that everyone involved understands the ramifications this move will have on developers who are new to the platform (so is that mx: again? No? fx: ... oh but that tag is s: and oh, that’s the language namespace but that’s a library... what again? huh? Just a sec, I think SilverLight was easier...) as well as for people migrating and transitioning existing Flex 3 applications.
Flex gods, please reconsider.
Update: As some of you have pointed out, my experience was exacerbated because I was porting from a previous version of Flex 4 to the latest Flex 4 SDK. You're right that this made my porting experience more difficult than a straight Flex 3 to Flex 4 port would have been since I had removed namespaces on all mx and Spark (previously Fx) components. However, I stand by my core point which is that the introduction of these language and library namespaces, along with namespaces in CSS makes it more difficult than necessary to port apps and will be more confusing for developers who are new to the platform.
A number of you have pointed out that the Fx prefix was not a long-term solution and that we would be faced with a similar choice for Flex 5. I don't feel that that's accurate. Flex 5 could keep using the Fx prefix for new components as I don't see such a radical overhaul of the component system occurring in the next version.
And while it's true that we already have namespaces, we've now introduced two framework-level namespaces and separated library namespaces and also introduced namespaces into CSS. Basically, we've introduced a lot of complexity for what I would argue is very little gain.
I'm sure tooling will take care of some of this complexity (and that should work in Adobe's favor and translate to more Flex Builder licenses sold even though they were not the ones to instigate this change). However, when you have to rely on tooling perhaps the problem is that the underlying technology is too complex. There is something sublimely beautiful about not needing any tooling whatsoever in Python, for example, that speaks volumes about the elegance of the language. Let's just say that I don't believe Flex would be in this namespace soup if Guido were calling the shots.
That said, Flex is still the most elegant rich-client technology I know. Yes, I love the tools in Cocoa and Objective-C is quite a marvelous achievement when you consider the limitations of C that they had to work with but there are also up-and-coming contenders ranging from Nokia's Qt to Unity 3D that are vying for the limited attentions of developers in a supply market. Simplicity is a key factor in differentiating your platform and wooing developers.
Simplicity is not something to be ashamed of. It does not make your Code Fu any less if you have simple tools and languages to work with. It just makes you all the more productive and lets you concentrate on crafting that most important part of your application: the user experience.
Flex is simple. We should try our utmost to at least preserve this simplicity, if not to take it a step further in each release.
Flex Fail Whale from Twitter Fail Whale by Yiying Lu
The The change from Fx prefix to namespaces is an 
I was/am doing the same yesterday and today and you’re completely right.
At first sight I thought it was not so bad and that I just couldn’t see the tree trough the forest, but with this namespace soup (jummie) it’s like not seeing a forest trough another forest in a swamp (or something like that, you get what I’m saying right?)
Surely someone can (and will) write a tool or a plugin to automate this.
Unfortunatly, this is the pain that we will suffer when we use beta, or in this case, alpha level software in our projects. The Flex4 SDK is not complete yet, and won’t be for quite some time. The SDK you used earler was even doubly so. To move from alpha to alpha is not really a supported workflow they are targeting (people will be moving from Flex 3 -> Flex 4 once it’s complete).
The beauty about the way they are doing things right now is that you can take your Flex 3 code, and with a handful of tweaks, compile it right in Flex 4. This is because the mx namespace from 2006 /WILL NOT BE CHANGING/ as it would have if they introduced the Fx prefix. I don’t expect it to be much more of a pain to port a 3.0 to a 4.0 app than a 2.0 to a 3.0.
Just give it a few more months to bake out. They had a target to have everything switched from the FxButton to Fx:Button model by beta one, and I feel that they will be close. The builds in between are rough.
I think this has nothing to do about the state of a application Nick. Its a basic thing that by adding this “feature” Aral as tester felt it was a big step backwards to the former releases.
As I worked with namespaces in the past I thought: Why do we need them in first place? Packages are namespaces already: why to indulge two ways of them? The code ain’t getting more useful or better to read.
Its been used for overloading where actually real overloading would be a lot more appropriate feature. Its been used for unit testing where annotation would have been a lot nicer.
Well lets see, maybe they found some nice reason but it looks like its just some typing exercise.
So I’m confused.
Is it purely Flex 4.olderalpha to Flex 4.neweralpha porting that is causing these problems. Or is it Flex 3 to Flex 4 porting that is causing these problems?
I haven’t looked into Flex 4 extensively, could someone give a small example?
I think this was done under great pressure of community.
Surely this is going to be better in the long run though?
And doesn’t Flex Builder autocomplete your code, so you won’t have to worry about the namespaces? I guess it would suck to change all your existing code, but won’t it be a better model for the future?
[...] prefix in Gumbo revisited May 26th, 2009 Goto comments Leave a comment Aral Balkan blogged about what he called an epic FAIL of removing the Fx prefix from [...]
humm the FX prefix change to a fx: namespace
have been discussed few months ago here
http://forums.adobe.com/thread/298585
the change was driven by the community of Flex developers
see the votes (100+) on JIRA
https://bugs.adobe.com/jira/browse/SDK-17854
if you’re not happy with the change, you’ll have to convince not only Adobe but also the whole community who voted for this particular change
Blogged my thoughts on the Fx prefix issue here: http://www.peterelst.com/blog/2009/05/26/fx-prefix-in-gumbo-revisited/
As zwetan also wrote, it got reported on the public Flex bugbase October 30th last year, 117 votes to drop the Fx prefix in favor of namespaces and has been extensive debate about it in the community. I think there’s little chance of turning that decision back now.
bugger. all the code formating is lost so that post isn’t going to make much sense ;(
I haven’t played with Flex 4 at all yet, but I am making production Flex 3 apps and still consider myself just a tinkerer in it. However, from the very beginning of learning Flex I was introduced into namespaces beyond mx — custom components for instance.
I want a Flex 4 component? I’ll use fx namespace. Flex 3 component: mx namespace. I don’t really see the confusion though my view is admittedly from the sidelines.
I’m pointing out my own real-world experience in porting a Flex 3 app to Flex 4 (and, as pointed out, from a previous version of the Flex 4 SDK to the latest). The “handful of tweaks” pointed out earlier _were not_ necessary when going from Flex 3 to the earlier Flex 4 SDK (before the namespaces “feature”).
Unfortunately, we’ve seen all this before with the additional complexities introduced into AS3 at the behest of a couple of extremely niche players whose needs are not mirrored in the majority (e.g., Google, etc.) The JavaScript community abandoned AS3/ECMAScript 4 for a reason. (I love a lot about AS3 but it could have been simpler).
Looks like we’re introducing some similarly unnecessary complexity into Flex now with this move to language/library namespaces.
@thebouv: No offense, but part of the problem is that there’s a lot of commentary and “me too” comments from the sidelines on this issue. I’d like to hear from people who are _actually porting stuff to Flex 4 from Flex 3_ and also the thoughts of developers taking up Flex 4 for the first time.
i.e., less theory, more empirical evidence please. My own _experience_ has been less than stellar. The _experience_ I had porting a different (larger) Flex 3 app to Gumbo with the previous Fx prefix was much simpler.
Looking forward to hearing about your _experiences_ with this.
Hey Peter, just replied to your post on your blog; here’s a proof-read version:
This will mean that _existing code_ cannot be reused without making changes. So if you’re using five different libraries and maybe a couple of skins you’ll have to go in there and add namespaces to everything, including the CSS.
With the Fx prefix, you could just drop your existing code into your project. Wanna add a Gumbo afterwards, go right ahead, just add it, no need to change anything. Wanna use a skin created for Flex 3, no problemo.
^^^ All that’s lost with namespaces.
These are real, _practical_ reasons for why this change is a step backwards. I’m not talking about aesthetics or formal beauty here but pragmatism.
It also adds additional complexity that will confuse newer developers and make it harder to learn the framework. That’s great news if you’re writing books (because they’ll have to buy more books to read about this confusing stuff) or if you’re a consultant/advanced developers (you can charge more and get more work and dazzle people by knowing all this complex stuff) but not great news if you’re just getting into Flex, evaluating it against similar technologies or if you’re concerned about the competitiveness of the platform and future adoption rates among developers.
@nouba: I wouldn’t call 100 votes “great pressure”, especially since quite a number of those were probably “me too” votes without a firm grasp of the ramifications. The real impact of this will become apparent months, if not years after the release of Flex 4 when people actually start migrating their applications to it.
@Marc Hughes: The issues will hit people migrating from Flex 3 to Flex 4. The previous workflow required absolutely no changes to existing code. This update requires that you update your existing code, even third party libraries and CSS. That’s a big step backwards and will affect adoption of and migration to Flex 4.
@zwetan: The original conversation only briefly registered on my radar as I was working on other stuff (still am, but gave a short break this week to churn out a couple of little AIR apps). So yeah, I’m late to the game but that doesn’t make the core issue any less relevant. :)
Going back to iPhone dev in the afternoon so, unfortunately, this is all the “convincing” I’m going to be doing on the subject. I do hope that those in the community supporting this change have actually tried porting Flex 3 stuff and mixing Flex 3/4 and working with Flex 3 skins, etc. If not, please do.
That’s all, Aral is over-and-out on this subject. Good hunting!
Thanks Aral, I don’t quite see how namespaces is making things so much more complex — but I’ll give it a shot myself tonight and see how I get along.
I’m happy to stand corrected if it turns out to be a real pain to port ;)
Flex 4 is a complicated release. It is complicated because you need to use parts of Flex 3 long with parts of Flex 4. That has nothing to do with namespaces. We have never had a version of Flex before where we needed to use pieces from Flex 1.5 and Flex 2 all at once. Flex was always a full major version revision before now.
Namespaces were a decision on how to deal with *that* complexity in a way that was sustainable into future releases. Yes, fxButton sounds like a nice simple solution, but it is not sustainable as future releases occur and we have new and interesting buttons. This is not a new solution though. Namespaces were already used for all custom components and custom libraries. So, a namespace is a logical extension of this concept.
Yes, it will require more work to move code from version 3 to version 4. Yes, new users will need to understand a bit more to write code that effectively uses components across (n) versions of Flex.
Again though, I don’t believe this is actually a namespace issue, the issue is just that 4 is more complex because it is composed of multiple component frameworks.
Michael: The Fx prefix doesn’t just “sound like a nice simple solution” it *was*. I ported my Flex 3 app to the previous Flex 4 SDK with absolutely no headache whatsoever. Heck, initially, I didn’t even change anything because I didn’t need to.
Then, as I needed to add Gumbo functionality, I simply layered it in and — to my surprise at the time — it just worked. I was even telling some Adobe folks recently how cool that was. It was an awesome experience.
If Flex 4 is a “complicated release”, it has failed. An iPod is a complicated piece of machinery and yet you don’t get to see any of that complication. Google is a very complicated system and yet you don’t even get a whiff of that complexity. Complexity of the system and complexity of the interface are two hugely different things. Make the system as complicated or complex as you like (that’s your problem as the developer of the system) but make the interface as simple as possible for yours users. In this case, the interface is the grammar and semantics of the framework. And this change reflects the complexity there. It places the complexity on the shoulders of the user (the Flex developer).
It basically boils down to this:
We had a system that was trivial to implement and required no changes to existing code.
We now have a system that requires extensive changes to existing code and is non-trivial to learn.
That’s a loss.
Aral, I think your issue is more with the old SDK vs. the new SDK. After this post, for “fun” I ported one of my medium sized apps from Flex 3 to the 4.0.0.6992 SDK. Minus some fun messing with the States updating and some CSS updates, I was able to take an app that had about 35 screens/windows and have it workable for the most part. Now, mind you there are still some bugs in the SDK, and I am OK with that (this is STILL ALPHA).
Also, please remember, very early on with the Flex 4 SDK, it was based on the Flex 3 SDK, which means that of course you could just compile it in the new one — you didn’t get any of the forward movement or benifits! Namespace aside, you got some new gumbonents and that was it, none of the new state management or other great things that are happening with Flex 4.
And also, please remember, this is still in ALPHA. things are not all fleshed out, and not complete. The directions are there, but it’s not all done. Things will get faster/easier/better as it progresses through the software lifecycle.
I don’t understand why you had to modify existing code, other than stuff you had written in an earlier version of Flex 4. A Halo button is still a Halo button and still uses the mx prefix. Like others have pointed out, if you have ever written or used a custom component you are used to multiple namespaces. If you have used Flex for more than 60 minutes or so, chances are you’ve done that.
Can you elaborate on what code you had to change?
Great post as always Aral, but on behalf of sound logic, I’d argue that to prove that A out-weights B it’s not sufficient to argue that A is very very heavy. It turns out that be B has to be proven not to be heavier than A.
Ok, call us Formalists. ;-)
I haven’t played at all with Flex4 yet, so I may be missing something here, but how would using the Fx prefix scale in subsequent releases? Would we be forced to deal with Fx2Button, Fx3Button, etc?
It beleive using namespaces is the correct way to go here. Perhaps the prefix is feels to some as more user-friendly or pragmatic, but it seems to me to be a short-sighted solution.
Sounds like nobody learned from the palaver with XML namespaces. During a large project a couple of years back, we wrote “It’s a namespace problem” at the top of the whiteboard. It was accurate about 90% of the time.
I’ve had a look in Flex 4 SDK already and wrote ten blog posts about it.
I can’t say that I find the new namespace solution difficult. I like it more than the previous way. Why should there be two different way to create a Button (“mx:Button” and “FxButton”)? “mx:Button” and “s:Button” sounds better to me.
Please, would (once) shup up ! … and maybe don’t try to market your name on all hot topics ?!
[...] got pinged several times this morning in response to Aral Balkin’s post on the use of namespaces in Flex 4. I can’t get his site to load so I can not comment on his post there. But I feel strongly [...]
@flo, I’d hate to point out the obvious but regardless of which solution you pick, there will always be two ways to create a button as long as there are two different buttons to create. i.e., (1) mx:Button and (2) s:Button.
@aral,
Great discussion. It’s about 2 months too late, but still cool of you to chime in. I’m a fan of following the namespace convention. Seems like the fx prefix was trying to solve a problem that the language already had a solution to. As the framework grows adding random prefixes seems awkward and unmanageable.
I liked Flo’s comment about scalability–Fx2Button, etc. Also, really, this ship sailed so long ago and is already docked in Bermuda. But beyond that, I too would like to understand a bit more about the difficulty you’re having. Were you relying on default namespaces rather than explicit ones? Because I use distinct namespaces all the time (in fact I’m unsure how you’d get by in MXML without them), including for my own component libraries.
I had a few ideas I wanted to contribute to the discussion, but your blog decided my post looked “spammy” (because of some ‘xmlns’ code?) and rejected it without any option to make edits. Seems a little harsh…
Aral –
I’m not going to weigh in on the pros and cons of prefixes vs. namespaces here. I just wanted to point out one clarifying point, to make sure it’s clear to anyone reading this discussion. Modulo the kind of (minor) incompatibilities that creep into any rev of software, Flex 3 MXML will simply work in Flex 4. You can continue to use the 2006 namespace as you wish. You can create new 2009 MXML files and use them in the same project as 2006. You still have to update your CSS, and it doesn’t address the learnability problem you, among others, see in using segmented namespaces in general, of course. But I wanted to make sure the point was clear.
Ely Greenfield
Adobe, Flex SDK
Aral, you’re kidding, right? First, that ship sailed like, three months ago.
Second, the alpha of Flex 4 broke with best practises in establishing the prefixing convention, which admittedly was in the good old spirit of hackiness for which Flash component frameworks used to be famous for, but would have created a precendent in the future direction of the Flex framework making it difficult if not impossible to correct or get away from later on, in say Flex 5 onwards (Fx2Button, GXButton, anyone?). The community rebelled, Adobe saw the light, and that nasty nasty hack in the framework was put to rest.
And in having that discussion Adobe realized that if it was to live up to Flex being open source, that it would have to take input from the community and not arbitrarily decide things which may break with future compatibility. So that’s a good thing. Dis the votes on JIRA if you want Aral, but the noise that generated made a difference. (Now if only they could listen to the votes on FP-444…)
If you’re having migration issues, my suggestion would be to write an ant task to speed up the process of adding in the extra namespaces.
Namespaces are needed, of course, so that URI definition files can be accessed for a particular framework, or we’d all be adding a gazillion import statements at the start of each file. Messy, messy. By making the rule that all coding libraries must reference a declared namespace for MXML components, the language has become a lot more uniform. And I would argue, easier to understand, because there are no tricky exceptions to the rule to remember, like, “every library uses its own namespace, except the Flex 4 components, because they’re special.” So using namespaces actually makes it easier for beginners to learn (and yes, I have taught Flex to beginners).
This move actually makes it possible for the first time to use different versions of the framework simultaneously. Now tell me, which is easier: namespaces instead of prefixing, or The Marshal Plan?
re: ipod
Aral, an IPod and Flex are not the same thing. Yes, an IPod is a complicated piece of machinery, which, through a fantastic interface allows you to do 20-40 unique functions very well. It does not try to do everything.
Flex is a langage/sdk that is intended to be infinitely flexible and tries to allow anyone to create anything they might want to create. Those two things warrant a very different level of of complexity.
If you want to compare the IPod source versus the source to a music-playing application in Flex, that would be a fair comparison.
I still disagree with one of your statements “However, I stand by my core point which is that the introduction of these language and library namespaces, along with namespaces in CSS makes it more difficult than necessary to port apps and will be more confusing for developers who are new to the platform.”
The point i can’t get past is that this isn’t a new concept. If you create a custom component or you use a custom library in Flex today (version 3 and before) you create a new namespace to reference those classes. That is today’s metaphor, not a new one. So, yes, there are more namespaces you have to deal with by default, and, that sucks.
However, to my original point, I don’t think the issue has to do as much with namespaces as it does with missing pieces in the SDK. When moving from 2 to 3, there was complete parity, so, even if you did have to change a namespace, it would have been minor. I think the issue here comes from the fact that you need to mix pieces from 3 and 4 on virtually e
As far as the rest, I still believe the real issue exists because there isn’t 100% parity between 4 and 3. If we could simply change a namespace and everything still existed, this would be less of an issue.
Cheers,
Mike
[...] I documented the trouble I had in porting my Flex 3 app to Flex 4 and I blamed the move from the Fx prefix to namespaces for my woes. As some of you have pointed [...]
Thank you all again for your comments and insight.
Let’s see if we can’t do something to make this better: The Flex 4 One-Step Migration Challenge – http://aralbalkan.com/2209
[...] I documented the trouble I had in porting my Flex 3 app to Flex 4 and I blamed the move from the Fx prefix to namespaces for my woes. As some of you have pointed [...]
While I do find:
Better than
I do have an issue that in trying to experiment with Flex 4 “Gumbo”, I have not been able to find a current example that works.
Finally I stumbled on the following, which at least doesn’t generate an error:
Adobe needs to update it’s examples. Everything seems like it’s stuck in 2008.
My bad…let’s see if this shows up:
EXAMPLE:
<s:Application xmlns:s=”library://ns.adobe.com/flex/spark”
xmlns:fx=”http://ns.adobe.com/mxml/2009″
xmlns:mx=”library://ns.adobe.com/flex/halo”
creationComplete=”">
</s:Application>
[...] the impact of this change recently hit Aral Balkan, a prominent Flash community member, and suddenly the controversy was reborn. In Aral’s [...]
In the update to your post you state that folks pointed out that the real crux of your problems were all due to the *removal* of namespaces in your Flex 4 Alpha codebase, issues that wouldn’t arise in the far more common scenario of a Flex 3 to 4 migration. Yet, you argue that your point still stands. How so? You made your argument based on headaches you attributed to the namespace changes, when in fact those headaches were due to issues far more particular to your specific scenario.
Given everything outlined, and in particular given the migration post Ben Stucki just made (Flex 3 to 4), what are your specific issues? What example can your provide of migration being difficult?
I think the issue here is the definition of migration. Ben made the point that a trivial five-line app will run with the addition of a single CSS namespace definition. While true for the simplistic, contrived example, I don’t consider simply compiling a Flex 3 app to constitute Flex 4 migration.
If you’re migrating to Flex 4, you are most likely doing it in order to take advantage of Flex 4 features and thus you will want to layer in and/or transition to Spark components at some point and that’s when you will require more extensive namespace changes to your entire codebase. (And you real apps have dozens, if not hundreds of source files, libraries, skins, etc., all of which have to be reviewed and possibly updated.) That’s the use case that I feel we must make as painless as possible.
Having an easy migration path from Flex 3 to 4 will benefit all concerned and I cannot see how trying to make that process simpler (via an effort such as the 1-step migration challenge, etc.) is a bad thing.
I agree with the apparent misnomer of the term “migration” in this regard. Similarly, my brain has been struggling over whether or not the use of namespaces in Flex 4 is technically “correct”, or if it is instead a clever “work-around” to a much larger architectural problem. Naturally, this sort of conceptual brain-busting would easily be debated for days on end if you locked a group of architects in a room and left for the weekend.
In regard to my recent comment, it seems my thinking is on track with Dominic’s (see comment #22).
I also just remembered hearing Matt Chotin acknowledge the overall problem in the architecture and why namespaces had to be used as a solution, even if it is not technically correct; it is the most painless for now. As I understand, a separate team was recently compiled, separate from the Flex SDK/Flash Builder release time line, with the goal of re-architecting the Flex framework from the ground up. The project is largely experimental at this point though I believe.
Aral, instead of blazing your frustration to the community like this, can you give us some concrete examples to your problem? What do you file under “extensive namespace changes”? Really, I think you’re making this way bigger than it is :).
Note: article updated, “EPIC FAIL” retracted; let’s move on and address the core issue here which is that making Flex 3 to Flex 4 migration seamless is in all our interests. As such, please read the note at the top of the post and also my follow-up post. Thanks!
Seems to me that one of your big points is that this is going to be difficult for people to figure out and “all the more confusing for people new to the Flex platform”. But people have shown that it’s trivial to compile a Flex 3 app in Flex 4, and not too hard to migrate a relatively simple Flex 3 app to Flex 4. Isn’t this most likely the kind of thing “people new to the Flex platform” are going to be doing? Or, if they are really new, they are just going to be starting straight from Flex 4.
Yes, I guess a hugely complex app will be more difficult to port over, but give people some credit. They had the smarts to create a hugely complex app. I’m sure they will be able to grasp the concept of multiple name spaces.
Aral, your points are all completely legitimate in both the original and updated posts. I agree that its time to move on as well, and focus on whats really going on… Moreover, I agree that there is a core underlying issue architecturally, and it has been made clear to me personally that the product managers are aware of this “Epic Fail” – and by the way, exaggeration or not, I like the extreme nature of that verbiage. For petes sake, that little 2-word phrase attracted more attention than any blog titles I’ve seen in a hell of a long time! (lol).
More importantly, the attention is warranted. Based on my studies, it is questionable as to whether or not the use of namespaces in this context is consistent with the original intent of namespaces in the first place, and I have yet to hear any disagreement from anyone on that. Generally, a namespace is an architectural tool to be used during application development in order to avoid conflict with the naming conventions of the framework. They’re not meant to separate code libraries within the framework itself. Like I said though, I’m pretty sure everyone involved with the Flex SDK team is aware of this, and I would not be surprised if Flex 5 is a complete overhaul of the framework.
@Keith: Please read my note regarding the definition of migration. Simply compiling a Flex 3 app with the Flex 4 SDK is not migration. Refactoring your Flex 3 application so that you can enhance it with Spark components is not trivial and that’s the definition of migration that we need to adopt as that’s the real-world use case for migration (it doesn’t matter whether or not you can compile your Flex 3 app with the Flex 4 SDK if the first Flex 4 feature you’re going to use is going to require a far more extensive refactoring of your codebase to migrate it to a Flex 4 project utilizing both libraries.)
> Simplicity is not something to be ashamed of. It does not make your Code Fu any less
> if you have simple tools and languages to work with.
Simplicity is what everyone wants and aims for, but speak for yourself Aral. I don’t know what you are working and you certainly don’t know what we’re working on. In terms of natural language, speaking like a caveman may be simple, but it doesn’t make it easy to communicate. A language like English is highly complex, but if you know it communicating becomes easy. Simplicity doesn’t necessarily = easy and complexity doesn’t necessarily = difficult.
Many computer language features evolved to solve real-world problems. Faced with simple tools, people can and will do the most incredible things, in spite of their tools. But because I can hand-wash my clothes and would do just as good a job as the machine, would I want to? If someone else doesn’t understand how to use the machine, my heart bleeds for them, but I’ve got better things to do with my time and the complex tools I have evolved in order to free me to get on with something meaningful.
Complexity is nothing to be ashamed of either. With complexity I can build my own simplicity. That’s what object oriented programming gave us. Or I can buy someone else’s complexity to simplify my life. As the complexity of Actionscript has grown, our productivity has shot through the roof.
> It [simplicity] just makes you all the more productive and lets you concentrate on crafting that
> most important part of your application: the user experience.
Kind of like building the space shuttle using stone age hammers and clubs would let them concentrate on the visual design?
Sorry Aral. I respect you but this is all populist nonsense.
[...] use all the cool new features and components, but I didn’t go into a lot of details. However Aral’s blog does have information on what I might expect when I start to use spark components. Simply compiling [...]
I need to disagree with the main point of your argument Aral. I think that refactoring a Flex 3 application to Flex 4 (with the use of Spark components) *is* trivial.
I’m very comfortable with the use of namespaces, after all that’s what I’m used to as a Flex developer. Heck I can even migrate one class a day and my app will still compile and run just fine. How much simpler can it get?
The decision was right to to use namespaces
The decision was wrong to decide to release an unfinished product with missing components.
I’d rather wait a bit longer for a complete release. But adobe needs to make money too…
but it is nice that we can migrate one screen at the time as Stefan points out. I wonder how much migration
i’ll be doing anyway, There must be a really good reasons for it that canot be solved in flex3, otherwise flex3 will do.
ah well, at least your blog post became EPIC, he he
[...] about Fx prefix versus namespaces in Flex [...]