<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Flash Components vs. Flex Components	</title>
	<atom:link href="https://jessewarden.com/2006/09/flash-components-vs-flex-components.html/feed" rel="self" type="application/rss+xml" />
	<link>https://jessewarden.com/2006/09/flash-components-vs-flex-components.html</link>
	<description>Software &#124; Fitness &#124; Gaming</description>
	<lastBuildDate>Thu, 22 Feb 2007 07:31:37 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: dim dim		</title>
		<link>https://jessewarden.com/2006/09/flash-components-vs-flex-components.html/comment-page-1#comment-3776</link>

		<dc:creator><![CDATA[dim dim]]></dc:creator>
		<pubDate>Thu, 22 Feb 2007 07:31:37 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1056#comment-3776</guid>

					<description><![CDATA[&lt;b&gt;hi&lt;/b&gt;


]]></description>
			<content:encoded><![CDATA[<p><b>hi</b></p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Erik		</title>
		<link>https://jessewarden.com/2006/09/flash-components-vs-flex-components.html/comment-page-1#comment-3775</link>

		<dc:creator><![CDATA[Erik]]></dc:creator>
		<pubDate>Tue, 26 Sep 2006 00:38:25 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1056#comment-3775</guid>

					<description><![CDATA[A wonderfull read, nice discussion and valid points. The first thought that popped into my mind though was: &#039;Hmm, I dont really care. We have with the new flash player everything we need to make anything we want&#039;. 

The new flash player makes it possible for us to use the best of both worlds. When I look at the original discussion about the 2nd component set I have to conclude that I think its a perfect step. At first I was a bit sceptical, 2 different sets of components that are compiled to bytecode that runs in the same player sounds a bit strange. But it actually makes sence, with the Flex component framework they made sure that all needs you could have are present: if you need something that you would only use in 1 of every 10 apps you wrote, its in there. This offcourse pulls its weight in terms of file size.

In (what I consider) Flash applications you dont need that. If you want something thats not in the components you either tell your boss that its gonna be expensive for the customer or that other development methods are better suited. In Flash applications (again, as I see them) you need some simple forms and a scrollpane. More important though is that you can make em look kick ass!

It is simply not possible (not in the way that it can not be done, but more in the sence that it would be way too expensive to make) to create a single set of components (flash) that is lightweight and has been extended for &#039;extreme&#039; use (flex). Its alot easier to just create 2 sets. One optimized for performance and magic and the other lightweight, simple and &#039;flashy&#039;. It would make me happy to use one set in a banner and the other set in an application.

Oh, oops, typed way more letters then i was supposed to... Well, thnx for the interesting thoughts, keep it up!


Greetz Erik

ps. Sorry for the bad grammar and stuff, english is not my native language.]]></description>
			<content:encoded><![CDATA[<p>A wonderfull read, nice discussion and valid points. The first thought that popped into my mind though was: &#8216;Hmm, I dont really care. We have with the new flash player everything we need to make anything we want&#8217;. </p>
<p>The new flash player makes it possible for us to use the best of both worlds. When I look at the original discussion about the 2nd component set I have to conclude that I think its a perfect step. At first I was a bit sceptical, 2 different sets of components that are compiled to bytecode that runs in the same player sounds a bit strange. But it actually makes sence, with the Flex component framework they made sure that all needs you could have are present: if you need something that you would only use in 1 of every 10 apps you wrote, its in there. This offcourse pulls its weight in terms of file size.</p>
<p>In (what I consider) Flash applications you dont need that. If you want something thats not in the components you either tell your boss that its gonna be expensive for the customer or that other development methods are better suited. In Flash applications (again, as I see them) you need some simple forms and a scrollpane. More important though is that you can make em look kick ass!</p>
<p>It is simply not possible (not in the way that it can not be done, but more in the sence that it would be way too expensive to make) to create a single set of components (flash) that is lightweight and has been extended for &#8216;extreme&#8217; use (flex). Its alot easier to just create 2 sets. One optimized for performance and magic and the other lightweight, simple and &#8216;flashy&#8217;. It would make me happy to use one set in a banner and the other set in an application.</p>
<p>Oh, oops, typed way more letters then i was supposed to&#8230; Well, thnx for the interesting thoughts, keep it up!</p>
<p>Greetz Erik</p>
<p>ps. Sorry for the bad grammar and stuff, english is not my native language.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Scott Barnes		</title>
		<link>https://jessewarden.com/2006/09/flash-components-vs-flex-components.html/comment-page-1#comment-3774</link>

		<dc:creator><![CDATA[Scott Barnes]]></dc:creator>
		<pubDate>Sat, 23 Sep 2006 08:45:04 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1056#comment-3774</guid>

					<description><![CDATA[I agree with a lot of your comments Jess, yet I sometimes wonder are we talking about the &#039;AS-IS&#039; model or the &#039;TO-BE&#039; model?

Right here, Right now, FLEX and FLASH are different mediums - yet the same output. Why? Not much has been focused in terms of messaging to the Designer market about the existance of FLEX. The Enterprise market aren&#039;t getting as much marketing either. 

Lets put it in realistic terms the FLASH IDE has been around for years, and its THE reason why Macromedia was successful with the rest of the eco-system following suite. 

So from a marketing / contact point it was an easy job to remind people of its existance, there is no &#039;new customer&#039; position its more about stimulating upgrade (with upgrade comes creation, with creation comes new consumer base). I&#039;d argue that the marketing for FLASH would be the web, not Macromedia... FLASH become secondary, a hygiene factor that people would simply associate &#039;oh yeah, that&#039;s just FLASH..you can do it with FLASH IDE.. everyone knows that&#039;. 

If you asked most Designers around the world whats great about FLASH 9? They&#039;d probably not give a lot of information over (except the weblogs.macromedia followers).

In a nutshell I do agree that the FLEX model AS-IS is targeted towards business to business use, rather then business to consumer. Yet, I&#039;d argue that the TO-BE model should not only enable that but also open up to the business-to-consumer model.

In that best of both worlds. For those designers who need to branch out a bit deeper into the user experience design side of things, by all means give them the MXML approach mixed with Timelines (scarey as it sounds, MXML component vs MovieClip? if executed well in language could have a lot of niceties about it).

Anywho, my sore point with all this is &#039;where are the breadcrumbs between FLASH 9 and FLEX 3.0&#039; .. where is the roadmap as we have all said time and time again, we need to encourage &#039;Designers&#039; to get involved in the Development space as the segregation is keeping the business concepts stale?

I&#039;m just after a roadmap to satisify my concerns.. if they were to say &#039;today its FLASH 9, to get them hooked on AS3, wait for the market to digest and then release FLEX 3 which will string the two dimensions into one - bringing balance back to the force -&#039; then... i would eagerly opt in.

Right now? the whole &#039;Its for designers only&#039; approach? i&#039;d rather they package it as a Photoshop Addon then a FLASH &#039;addon&#039; :)]]></description>
			<content:encoded><![CDATA[<p>I agree with a lot of your comments Jess, yet I sometimes wonder are we talking about the &#8216;AS-IS&#8217; model or the &#8216;TO-BE&#8217; model?</p>
<p>Right here, Right now, FLEX and FLASH are different mediums &#8211; yet the same output. Why? Not much has been focused in terms of messaging to the Designer market about the existance of FLEX. The Enterprise market aren&#8217;t getting as much marketing either. </p>
<p>Lets put it in realistic terms the FLASH IDE has been around for years, and its THE reason why Macromedia was successful with the rest of the eco-system following suite. </p>
<p>So from a marketing / contact point it was an easy job to remind people of its existance, there is no &#8216;new customer&#8217; position its more about stimulating upgrade (with upgrade comes creation, with creation comes new consumer base). I&#8217;d argue that the marketing for FLASH would be the web, not Macromedia&#8230; FLASH become secondary, a hygiene factor that people would simply associate &#8216;oh yeah, that&#8217;s just FLASH..you can do it with FLASH IDE.. everyone knows that&#8217;. </p>
<p>If you asked most Designers around the world whats great about FLASH 9? They&#8217;d probably not give a lot of information over (except the weblogs.macromedia followers).</p>
<p>In a nutshell I do agree that the FLEX model AS-IS is targeted towards business to business use, rather then business to consumer. Yet, I&#8217;d argue that the TO-BE model should not only enable that but also open up to the business-to-consumer model.</p>
<p>In that best of both worlds. For those designers who need to branch out a bit deeper into the user experience design side of things, by all means give them the MXML approach mixed with Timelines (scarey as it sounds, MXML component vs MovieClip? if executed well in language could have a lot of niceties about it).</p>
<p>Anywho, my sore point with all this is &#8216;where are the breadcrumbs between FLASH 9 and FLEX 3.0&#8217; .. where is the roadmap as we have all said time and time again, we need to encourage &#8216;Designers&#8217; to get involved in the Development space as the segregation is keeping the business concepts stale?</p>
<p>I&#8217;m just after a roadmap to satisify my concerns.. if they were to say &#8216;today its FLASH 9, to get them hooked on AS3, wait for the market to digest and then release FLEX 3 which will string the two dimensions into one &#8211; bringing balance back to the force -&#8216; then&#8230; i would eagerly opt in.</p>
<p>Right now? the whole &#8216;Its for designers only&#8217; approach? i&#8217;d rather they package it as a Photoshop Addon then a FLASH &#8216;addon&#8217; :)</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: JesterXL		</title>
		<link>https://jessewarden.com/2006/09/flash-components-vs-flex-components.html/comment-page-1#comment-3773</link>

		<dc:creator><![CDATA[JesterXL]]></dc:creator>
		<pubDate>Fri, 22 Sep 2006 19:37:14 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1056#comment-3773</guid>

					<description><![CDATA[There are a lot of significant challenges here that Adobe has to surmount.  Expecting them to do so in a short timeframe is unrealstic.

To be clear, Flash does not work well in Enterprise Applications, and Flex, currently, is not reasonably justifiable for agency work.  That is a fact.  Can you use Flash to make large scale applications pre-Flash Player 9?  Sure.  Is it better to use Flex?  Yes.  Adobe knows this, hence supporting those developers.  Same goes for supporting the Flash 9 workflow of continous integration with design tools and developer/designer workflows.

Those are the MAIN use cases that drive their business.  Anything else is a want, edge use case, and thus a non-mainline contributor to their bottom line.

Do I want Photoshop to export PSD&#039;s straight to MXML?  Yes.  Are there a lot of people like me?  No.  Thus, Adobe won&#039;t make that a priority because it doesn&#039;t sell more software, nor help develop the market.  They need to tailor their products to the main needs of the market in question.  Thus, Flash gets priority of Photoshop interoperability.  Flex gets priority in supporting traditional developer workflows.

This hybrid stuff is cool, but niche and doesn&#039;t contribute a significant amount of continued revenue to Adobe&#039;s bottom line.  People wonder why places hire unqualified C and Java developers to do Flash projects in the past.  I&#039;ll tell you why; because Flash Developers are extremely small in number.  Qualified ones.  Hence our insanely high rates, and long path of horrid code-bases exacerbated by yearly changes to the way we create Flash / Flex applications.

To be focused is to succeed, and succeeding starts with clarifying the market.  Designers do Flash, Developers do Flex.  Those in between are niche use cases, and thus don&#039;t get priority.

Do they matter?  Of course.  We wouldn&#039;t be here if they didn&#039;t.  Flex wouldn&#039;t have happened had we not utilized scripting in SWF&#039;s to create a revolution.

Therefore, you can&#039;t please all the people all the time.  The lessons are as follows.

Flex 1 - does a market for Enterprise Applications exist?  Yes.

Flex 1.5 - people want Flex, but the price tag doesn&#039;t work, not everyone uses servers to deploy their apps, Flash Player 8 doesn&#039;t scale, and the open source world wants in as well.

Flex 2 - designers are better supported than Flex 1.5 with the better live preview, and GUI supported states in Flex builder 2.  The open source world has their free framework and compilers.  Developers have a great IDE, great tools, and a good application framework.  The barrier of entry to RIA&#039;s has been eliminated for programmers.

Flash 9 - better integration with Photoshop.  Components made specifically for the Flash Community since they have different needs than Flex Developers.  Easier way to diff animations like you can in Flex as well as being interoperable via the timeline XML.

The XML is one of the first steps in that process of helping integrate the tools.  There will be more, just not overnight.

I know the above hard facts piss hybrids off, but it&#039;s our own fault for being unique.  If there were thousands of us like there are Java developers, we wouldn&#039;t be having this conversation.  It&#039;s a business, and Adobe needs to focus on those markets, support them, and create new ones.

On the flip-side, we aren&#039;t going away.  We&#039;ve been here for almost half-a-decade now and we all still get paid.  Adobe does recognize the need for interop.  If you look at the history that I&#039;ve outlined in this post, you can see that Adobe has recognized community needs, and acted upon them, like &lt;a href=&quot;http://blogs.adobe.com/mikepotter/2006/09/adobe_and_devel.html&quot; rel=&quot;nofollow&quot;&gt;Mike Potter has elaborated&lt;/a&gt;.

They know the community at large does not follow into strict Flex / Flash camps, and that the need for interop and supported workflows is large, profitable, and desperately needed.

They&#039;re working on it, and it&#039;ll happen.

Regarding fragmentation... dude, this is the multimedia software industry.  It&#039;s very nature is pure f&#039;ing chaos.  Nature of the beast.  Wonder why there is no longer Flash Developer certification?  Because there are 50 billion ways to &#039;correctly&#039; code a Flash app.  Obviously only about 3 are decent, but how do you certifiy 3 different application development paths?

You don&#039;t.

I&#039;m not sure what Adobe can do to clarify the actual PR / marketing perception.  I mean, it&#039;s pretty clear to me:
&lt;ul&gt;
  &lt;li&gt;design, use Flash&lt;/li&gt;
  &lt;li&gt;create apps, use Flex&lt;/li&gt;
  &lt;li&gt;distributed data, Flex Data Services&lt;/li&gt;
  &lt;li&gt;streaming video, audio applications, use Flash Media Server&lt;/li&gt;
  &lt;li&gt;need a middle-tier, use ColdFusion&lt;/li&gt;
  &lt;li&gt;need a server, use JRun&lt;/li&gt;
  &lt;li&gt;do Production Art, use Fireworks&lt;/li&gt;
  &lt;li&gt;design, the Adobe design product line &#038; CS Suite&lt;/li&gt;
&lt;/ul&gt;

The actual workflow between them?  It&#039;s not clear cut &#039;database design&#039; so I think it&#039;s unrealistic to expect Adobe to provide the same for cross product pollination.  You bring a lot of subjectivity into engineering workflows when you throw in design, but... that&#039;s what makes it fun!]]></description>
			<content:encoded><![CDATA[<p>There are a lot of significant challenges here that Adobe has to surmount.  Expecting them to do so in a short timeframe is unrealstic.</p>
<p>To be clear, Flash does not work well in Enterprise Applications, and Flex, currently, is not reasonably justifiable for agency work.  That is a fact.  Can you use Flash to make large scale applications pre-Flash Player 9?  Sure.  Is it better to use Flex?  Yes.  Adobe knows this, hence supporting those developers.  Same goes for supporting the Flash 9 workflow of continous integration with design tools and developer/designer workflows.</p>
<p>Those are the MAIN use cases that drive their business.  Anything else is a want, edge use case, and thus a non-mainline contributor to their bottom line.</p>
<p>Do I want Photoshop to export PSD&#8217;s straight to MXML?  Yes.  Are there a lot of people like me?  No.  Thus, Adobe won&#8217;t make that a priority because it doesn&#8217;t sell more software, nor help develop the market.  They need to tailor their products to the main needs of the market in question.  Thus, Flash gets priority of Photoshop interoperability.  Flex gets priority in supporting traditional developer workflows.</p>
<p>This hybrid stuff is cool, but niche and doesn&#8217;t contribute a significant amount of continued revenue to Adobe&#8217;s bottom line.  People wonder why places hire unqualified C and Java developers to do Flash projects in the past.  I&#8217;ll tell you why; because Flash Developers are extremely small in number.  Qualified ones.  Hence our insanely high rates, and long path of horrid code-bases exacerbated by yearly changes to the way we create Flash / Flex applications.</p>
<p>To be focused is to succeed, and succeeding starts with clarifying the market.  Designers do Flash, Developers do Flex.  Those in between are niche use cases, and thus don&#8217;t get priority.</p>
<p>Do they matter?  Of course.  We wouldn&#8217;t be here if they didn&#8217;t.  Flex wouldn&#8217;t have happened had we not utilized scripting in SWF&#8217;s to create a revolution.</p>
<p>Therefore, you can&#8217;t please all the people all the time.  The lessons are as follows.</p>
<p>Flex 1 &#8211; does a market for Enterprise Applications exist?  Yes.</p>
<p>Flex 1.5 &#8211; people want Flex, but the price tag doesn&#8217;t work, not everyone uses servers to deploy their apps, Flash Player 8 doesn&#8217;t scale, and the open source world wants in as well.</p>
<p>Flex 2 &#8211; designers are better supported than Flex 1.5 with the better live preview, and GUI supported states in Flex builder 2.  The open source world has their free framework and compilers.  Developers have a great IDE, great tools, and a good application framework.  The barrier of entry to RIA&#8217;s has been eliminated for programmers.</p>
<p>Flash 9 &#8211; better integration with Photoshop.  Components made specifically for the Flash Community since they have different needs than Flex Developers.  Easier way to diff animations like you can in Flex as well as being interoperable via the timeline XML.</p>
<p>The XML is one of the first steps in that process of helping integrate the tools.  There will be more, just not overnight.</p>
<p>I know the above hard facts piss hybrids off, but it&#8217;s our own fault for being unique.  If there were thousands of us like there are Java developers, we wouldn&#8217;t be having this conversation.  It&#8217;s a business, and Adobe needs to focus on those markets, support them, and create new ones.</p>
<p>On the flip-side, we aren&#8217;t going away.  We&#8217;ve been here for almost half-a-decade now and we all still get paid.  Adobe does recognize the need for interop.  If you look at the history that I&#8217;ve outlined in this post, you can see that Adobe has recognized community needs, and acted upon them, like <a href="http://blogs.adobe.com/mikepotter/2006/09/adobe_and_devel.html" rel="nofollow">Mike Potter has elaborated</a>.</p>
<p>They know the community at large does not follow into strict Flex / Flash camps, and that the need for interop and supported workflows is large, profitable, and desperately needed.</p>
<p>They&#8217;re working on it, and it&#8217;ll happen.</p>
<p>Regarding fragmentation&#8230; dude, this is the multimedia software industry.  It&#8217;s very nature is pure f&#8217;ing chaos.  Nature of the beast.  Wonder why there is no longer Flash Developer certification?  Because there are 50 billion ways to &#8216;correctly&#8217; code a Flash app.  Obviously only about 3 are decent, but how do you certifiy 3 different application development paths?</p>
<p>You don&#8217;t.</p>
<p>I&#8217;m not sure what Adobe can do to clarify the actual PR / marketing perception.  I mean, it&#8217;s pretty clear to me:</p>
<ul>
<li>design, use Flash</li>
<li>create apps, use Flex</li>
<li>distributed data, Flex Data Services</li>
<li>streaming video, audio applications, use Flash Media Server</li>
<li>need a middle-tier, use ColdFusion</li>
<li>need a server, use JRun</li>
<li>do Production Art, use Fireworks</li>
<li>design, the Adobe design product line &amp; CS Suite</li>
</ul>
<p>The actual workflow between them?  It&#8217;s not clear cut &#8216;database design&#8217; so I think it&#8217;s unrealistic to expect Adobe to provide the same for cross product pollination.  You bring a lot of subjectivity into engineering workflows when you throw in design, but&#8230; that&#8217;s what makes it fun!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: ethan estes		</title>
		<link>https://jessewarden.com/2006/09/flash-components-vs-flex-components.html/comment-page-1#comment-3772</link>

		<dc:creator><![CDATA[ethan estes]]></dc:creator>
		<pubDate>Fri, 22 Sep 2006 17:18:50 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1056#comment-3772</guid>

					<description><![CDATA[I&#039;m with scott. I want to believe it&#039;s a good thing but i was hoping for some kind of shared code base where the blaze components branched to allow for us design-y folks to go town in the skinning area. But i do wonder about this seperation and if it will form artificial barriers between the different dev paths. My work bounces all over the place and i like it to be flexible in reuse. Not all of my jobs are throw away code. A lot are but not all, and clients glaze over when you say &#039;yes i know it&#039;s built in flash and we&#039;re taking it to flex which is flash as well but the old stuff is not compatible so we need to charge you for the rework.&#039; 
Not to mention how this all fits in to Apollo-can both exist and communicate with each other.

It&#039;s early though and Adobe is smart so i&#039;ll sit back and wait but i was hoping for some info on interoperability. I do look forward to easier skinning with less bloat.]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m with scott. I want to believe it&#8217;s a good thing but i was hoping for some kind of shared code base where the blaze components branched to allow for us design-y folks to go town in the skinning area. But i do wonder about this seperation and if it will form artificial barriers between the different dev paths. My work bounces all over the place and i like it to be flexible in reuse. Not all of my jobs are throw away code. A lot are but not all, and clients glaze over when you say &#8216;yes i know it&#8217;s built in flash and we&#8217;re taking it to flex which is flash as well but the old stuff is not compatible so we need to charge you for the rework.&#8217;<br />
Not to mention how this all fits in to Apollo-can both exist and communicate with each other.</p>
<p>It&#8217;s early though and Adobe is smart so i&#8217;ll sit back and wait but i was hoping for some info on interoperability. I do look forward to easier skinning with less bloat.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
