With the heavily discussed announcement from Adobe about their commitment to Flex they crossed the line were it seems very likely that the Flash platform will not survive in the long term.

What Steve Jobs started, seems to be completed by Adobe themself.

This is somehow weird and bizarre because they own a technology which was incredible successful the last 12 years and is still the best solution for many kinds of Rich Internet Applications.

To just name a few reasons why I see Flash as such a strong platform:

• Nearly multi-platform technology. Ubiquitous penetration of the browser plugin + AIR (well I know: Steve Jobs left his marks….)
• Good development environment (language, tools, community, Flex framework…)
• Good performance and security model
• Easy and cheap to deliver good looking multimedia enabled user experience

Flash has set new standards and drove the internet forward (ok, I know ads are done with Flash as well…). Animation, multimedia, rich user interaction and the possibility to build desktop-like applications running in the browser are with Flash not a big deal. The rise of what Adobe coined Rich Internet Applications (RIA), were mainly driven by Flash/Flex.

I am not saying Flash is the best platform, and there are many things on my wish list and stuff to complain about. I also would prefer an open source technology following standards.

From a technology point of view there are many better solutions, like Director or the Java plugin were in the past much better then Flash but did not survive because of the low plugin penetration and the odd installation process. Flash was somehow the star for a long time and left the others behind, probably mainly because of the ease to install the plugin which leads to the high penetration rate of >98%. With Flex Adobe managed it to deliver a pretty good GUI framework and also attracted developers from more traditional languages like Java or C#.

The competitors like Silverlight, JavaFX or now HTML5 are seeming somehow (in the best case) like a copy and did not shine with much innovation.

Of course Flash is used in many places where it does not make sense, like for video or more complex web page navigation combined with HTML pages. So it is good that the modern browsers are able now to do this stuff directly without the indirection of a plugin. And of course it would be much better to have a browser being capable doing all kind of stuff directly which is done currently in Flash or with other plugins.

But why has this not happened in the last 15 years since browsers are prominent actors in the IT world?

Probably the biggest advantage of Flash was, that it bypassed the nasty problems with the incompatibility of the browsers and the slowness of innovation with the trick of using the plugin architecture to deliver a standard runtime for any browser and OS.

Like Java Flash can proudly proclaim: Write once, run everywhere!

And it looked great, was fast, was multimedia aware and made fun to play around. Concentrate the work on the application or game and not on dealing with browser compatibility problems.

With Actionscript (2,3) they set the foundation for a robust development environment. When you read about features of Googles Dart or some of Scala it somehow seems similar to that hybrid and well cooked mixture of Java and dynamic language features.

On this foundation it was possible to build large scale applications which were previously build as Java or C# desktop apps.

Why did companies move from the mature software development standards to something new and risky like Flash/Flex?

Because the apps looked good just out of the box, it was easy to develop and customize, multimedia was just a natural ingredient and it was more suitable for agile development models (rapid prototyping). At the end the costs were much lower as with a traditional software development process.

I think that was the main driver why RIAs became a success story. I think often the real reasons are pretty trivial.

Of course it is a benefit to have a browser based application available anywhere and the management of updates is much easier to handle. But the nature of RIAs is different to web pages. With an application you have a closer relation and there is no real barrier to install the app if it shows some real benefit to you. The success of mobile apps is proving that users have no problem to install an app they are using on a regular basis. If the way how to install it is easy, secure and free, the user does not mind the installation and even prefer the app model over the browser model (If you use twitter on your mobile, you use the app not the browser, right?).

What I want to say with this:

I do not believe the rise and success of RIAs came from the fact that the application is available on any computer via a browser, but more from other factors.

• The browser is recognized as trusted environment (no problems with security issues)
• The development costs are lower
• The maintenance costs are lower
• The User experience is often better (looks better)

With the decline of Flash/Flex I do not see yet any alternative technology which has the strength and market power of Flash.

The main problem with HTML5 I see in the politically motivated fragmentation of the browsers.

That seems even worse then 10 years ago. Back there was Microsoft against the rest. Now we have Google against Apple against Microsoft ignoring the rest.

They are all following totally different business targets with their browser concepts and I do not see any reasons why they should work better together in the future.

For me the problem with HTML5 is that you have to write code handling the differences of the most important browsers, so the main features works on all of them. Then you need to support some other browsers with a reduced feature set. And you need to test all versions in a very fast changing environment. That all comes with a poor language (Javascript is like Actionscript 1 12 years ago), a poor development environment and poor performance. I do not see any technological progress with this HTML5 hype. Flash 5 in 2000 was already more advanced (is the matching version number a coincidence?).

So in my opinion the only solution will be a technology which strongly supports multi-platform compilation.

Unity3D does this, haXe is doing this and openLaszlo did this partly already since 2004, as well as some other interesting moves in this direction (Joa Ebert). Adobe seemed to missed this trend.

The developer should not care about the output platform and concentrate to build applications without hacking to make it run in different environments.

Isn’t that the evolution of computer languages?

Machine code -> assembly -> C -> VM languages -> ?

Liberate the developer from the low level technical implementation and let him concentrate to the domain he is modeling in software. Writing hacks to make an application run on different browsers is against this evolution.

Of course writing multi-platform apps comes with some inherent problems. There are different capabilities, sizes, contexts and limitations to deal with, but they come naturally with the platforms and are not politically motivated hurdles created artificially by browser vendors.

I think the right candidate must be able to deliver an application for all major target platform without dealing with significant adoption problems and provide a modern, state of the art development environment (language, tools,…):

• Desktop (Win, Mac, Linux)
• Mobile/Tablet (Android, iOs)
• Web (Flash, HTML5)
• And maybe also Consoles or even Set-top boxes

This will define a new situation for the RIAs:

Assume you can develop an application for any platform, getting results which are close to native apps for this platform.

What are the benefits of RIAs when the Desktop app is much faster and has more capabilities?

Of course sometimes it makes sense to have the app, maybe as light or demo version, in the web for giving a lower entry barrier or to get a higher visibility. But in general the choice for the main platform will be much more derived from the nature and usage of the app then from external factors.

The stuff I use regularly I want to have as desktop or tablet app to get the best performance, security and feature set. If I need it to be mobile I install it as mobile app. Only the casual stuff will be a target candidate for the browser.

I do not think the browser will have the same importance in future like now (I know I am in opposition to Google with this). With a multi-platform compiler you can choose which platform matches best to your needs, and the browser will be reduced to that what it can do best. Displaying web pages and not imitating desktop applications.

I think sometimes ones success is more driven by the weakness of the others. Again pretty trial and no hot slogan for driving a hype.

Flash was successful because the browser vendors did (and still do) such a bad job in making a common standard and to being innovative.

The browser has been so successful because the OS vendors did a real bad job to not providing an easy and secure installation environment (the reason for Apples app store success). As well as not providing a native platform for cheap and easy software development (it is much easier to start with Flash or HTML then to write C code) and ignoring the importance and integration of the internet.

I guess in future there will be a multi-platform paradigm with focus on a main platform which makes most sense for the specific domain. The Desktop applications are looking somehow old as they have missed many important trends and can learn a lot from some successful RIAs. The RIAs which are imitating desktop apps will loose ground as with a multi-platform compiler there is no much motivation anymore not to deliver the better target platform.

Maybe I am all wrong with this. I know that I am against the current trends with these opinions, but i simply cannot see any real progress with this HTML5 hype and feel that there is a real need for something new.

After working 10 years with Flash and 3 years with Flex I am still not convinced that the Flex Life Cycle is necessary.

I discussed this topic already with many developers but nobody could really give me a satisfying answer.
So I spread out my thoughts now to the public in the hope to get some valuable feedback.

Of course I am familiar with the concept of the Flex Life Cycle and the “elastic racetrack” behavior of the Flash Player.

The reason why I am not a friend of this concept is because it introduces an asynchronous code execution where a synchronous code execution would be much easier and faster.

In all my ActionScript based projects it was never necessary to use this pattern and defer code execution to another frame (or Render Event).
At bwin we have built a similar application as the current Flex-based Live Betting application previously in AS2, with a lot of complex components and auto layout containers, without running into any serious problems.
And to be honest the performance of the AS2 project felt somehow the same as the Flex version. But AS3 is about 10 times faster (of course that´s a bit too simple said and we did not measure the difference, but I am not the only one complaining about poor Flex Performance).

So isn´t it valid to question the concepts Flex is based on?

I am sure the architects at Adobe have had good reasons why they decided to introduce this pattern.
In the Docs and Blogosphere one can find several papers about it, but none of these explanations satisfied me, and some are not telling the full truth (that code execution is deferred to another frame).

So I try to discuss some assumptions for possible reasons:

• Avoid Performance bottlenecks
• Keep the Frame-rendering fluidly
• Avoid Performance penalty from unintended repeated method (setter) calls
• Pattern for separating different concerns
• Problems with reading out the measurements of DisplayObjects before they are rendered on screen
• Problems with complex execution flow from auto-layout containers code

So let me add my thought to these points:
Avoid Performance bottlenecks

That was my first assumption when I started with Flex, that this pattern is used to avoid performance bottlenecks. First I thought there is a hidden mechanism for detecting code execution which is running too long and delay this execution to the next frame. After checking out the SDK code I found out that it is simply delaying the 3 phases to 3 “half-frames” (Render Events and Enter Frame Events). So if you have really heavy code your player is still freezing up for a certain time and the Life Cycle does not give you any support for solving this problem.

That leads to the next argument:
Keep the Frame-rendering fluidly

Delaying the render code to the next frame helps the Flash Player running more smoothly and fluidly. That is basically true, but in my opinion 90% of the time the Life Cycle is wasting performance. For me it is a bad trade to get maybe at startup time some more fluidly running pre-loader animation but startup time takes much longer.

Why the Life Cycle is wasting Performance?
Because code which normally would be executed in one frame is now executed over 2 frames (or more).

There is another related issue with performance:
Avoid Performance penalty from unintended repeated method (setter) calls

Assume that in a large project it could be hard to control the execution flow so that it could happen that setting a text or layout property to a component is not only applied once but unintended multiple times.
For this scenario the Life Cycle helps because the call to the setter of the property is relatively cheap, so if the setter is called 10 times instead of once it will not hurt much. Then at commitProperties the property is only applied once to the component.
Again some weird scenarios with multiple invocations of commitProperties will not hurt much because the applying of the property to the component should be protected by a “changed” flag (see best practice with the Flex Life Cycle).
Also if you need for layout code some measurements the pattern helps to avoid unnecessary and repeated code executions.
BUT – is poorly written code really the reason why this pattern was introduced? It is true that it gives you some kind of fault tolerance, performance-wise. I guess this argument should not count in professional software development, and in fact it is dangerous because it could hide some deeper problems. If your setters are called more then once, why not look for the reason and clean it up?
I know in complex situations this could be sometimes hard, and under real life circumstances and time pressure you have to deal with something like this. But it should not count as a criteria for such a basic framework design decision.

I made also some measurements to check out the performance penalties for repeatedly called setters:

With 100 000 iterations applying a changing text to a TextField (in a AS3 project) I got these results:

1. Case:
Setting the text property to a variable in a loop and then applying the already stored text to the TextField again in a loop:

[code lang="actionscript3"]setText(): 119ms
applyStoredText(): 481ms
[/code]

In contrast to applying the property directly to the TextField:

[code lang="actionscript3"]
setAndApplyText(): 2879ms
[/code]

So you can see it is much slower in the 2. Case, so the Life Cycle really helps here, because it only applies the last stored property and not the changing values in between. But again – setting multiple times unnecessary property values is another problem.

The same test with setting the x position does not deliver such a big difference, in fact it is nearly the same time consumed (40+52 vs. 114)

[code lang="actionscript3"]setXPos(): 40ms
applyStoredXPos(): 52ms
setAndApplyXPos(): 114ms
[/code]

Let´s continue with the next point:
Pattern for separating different concerns

To have a kind of pattern which separates different concerns is basically a cool thing. So you have your code block for setting properties, another method where the properties are applied to the component, a method where the measurement is defined and another one for the layout code.

I have no really argument against this pattern, but I don´t know why it is necessary to defer some code of these phases to the next Frame. The execution of the Life Cycle methods could have been triggered also at the Render Event, then there would not have been any delay to another frame, even it still would add this nasty asynchrony.

So this pattern could make development easier but introduce asynchronous behavior where we lived in a beautiful synchronous Flash world before. In my opinion: Not a good trade.

What else?
Problems with reading out the measurements of DisplayObjects before they are rendered on screen

Remembering back to some of my Flash projects I have had sometimes strange problems with TextFields and measurement when setting text and using autosize. But I could not reproduce these problems in a test case anymore. So I am not sure if that was caused by some other stuff or maybe by differences in some older Flash Player versions? But at least in my situations these problems could always be solved without deferring code to another Frame. But at this point I am not sure if there are certain use cases where you cannot read out the size of a DisplayObject (TextField) before it is actually rendered to the screen. If there are such cases this would be a valid argument, but then I am wondering why this could not be solved on the Flash Player level instead of solving this problem at a Framework level.

And my last point:
Problems with complex execution flow from auto-layout containers code

I can imagine that complex situations with nested auto layout containers could be sometimes really tricky to handle. To avoid recursions or unnecessary calls for any possible situation in a generic framework is a tough challenge.

But also in complex situations it is a deterministic behavior, so it should be possible to solve this without the Life Cycle pattern as well. From my experience there was no problems with auto layout containers, but of course in normal project development you have limited use cases and we were not forced to deal with all the possible use cases, like Flex has to do as a generic framework.

So finally I don´t have any idea for the real reason why Adobe has introduced the Life Cycle.
Maybe it seemed that it could help solving a lot of tricky problems (auto layout containers, mixing MXML with AS code,…) and was considered as a good pattern to make development easier. Maybe the fact that Flash has a strong support for Event driven programming and the Flash developers are already used to handle this asynchrony, led to this decision?
Maybe is was a strategic decision to make Flex easier for new developers without Flash background, who were not familiar with the Flash Players frame-based execution model?

I don´t know. I really would appreciate if someone from the Flex Team could illuminate this topic.

I just have made the experience that many things where much more transparent, cleaner and faster in pure ActionScript then in Flex, and i think the Life Cycle is one of the reasons for that.
I really like the API of Flex but I am wondering why Adobe don´t give more attention to performance, specially for large scale applications.

Any comments or insights are highly appreciated!

P.S.: Just found an interesting post related to this. I 100% agree what Paul Taylor says about UIComponent, but that is another story. Ever heard about Reflex? Sounds pretty promising!

If you ever had some strange problems with styles in Flex, you might want to know how styles are internally handled and implemented.
Ok this post will not cover too much of all the stuff going on there, but a bit of the basics how styles are finding their way from the css file to your component.

Lets assume that we have a css file with type selectors and class selectors, a module based application and some custom components which are designed the way that you can use them out of the box and that they can be individually skinned and styled by other developers reusing them. That´s what custom components are for, right?

So the first question is:
How are the styles compiled into your swf file?
Assume that they are defined in an external css file. You know you can compile css files to swf files and load them at runtime or simply compile them into your application at compile time with a simple assignment like this:

[code lang="actionscript3"]
 
[/code]

Here is the content of our simple css:

[code lang="actionscript3"]
Button
{
	color: #990000;
}
.myCustomStyle1
{
	color: #009900;
}
 /*
     some additional styles here...
     like Button.myCustomStyle2
*/
[/code]

That´s what we will use for our example here.

In this case the MXML compiler creates a bunch of classes and inserts the css definitions right into a method called from the constructor in the generated Applications class.

[code lang="actionscript3"]
public function StyleExample() {
	mx_internal::_StyleExample_StylesInit();
}
mx_internal function _StyleExample_StylesInit():void {
	var style:CSSStyleDeclaration;
	// Button
	style = StyleManager.getStyleDeclaration("Button");
	if (!style) {
		style = new CSSStyleDeclaration();
		StyleManager.setStyleDeclaration("Button", style, false);
	}
	if (style.factory == null) {
		style.factory = function():void {
			this.color = 0x990000;
		};
	}
	// myCustomStyle1
	style = StyleManager.getStyleDeclaration(".myCustomStyle1");
	if (!style)
	{
		style = new CSSStyleDeclaration();
		StyleManager.setStyleDeclaration(".myCustomStyle1",
                                           style, false);
	}
	if (style.factory == null)
	{
		style.factory = function():void
		{
			this.color = 0x009900;
		};
	}
	// similar code follows here....
}
[/code]

I only pasted the relevant code, so this is not complete but should give the basic idea.
So what happens here?
(Read more…)