Wrapping Up the Warfield/Lucchini/Flex/Javascript Smackdown
Posted by Bob Warfield on September 11, 2010
Come on, admit it, we all love a good smackdown! 
In response to my article about Flash coming back to the iPhone, Bill Lucchini wrote a well-reasoned rebuttal: 5 Reasons Adobe Flex is Doomed. Here they are, paraphrased for brevity:
– Flex creates an unnatural and dilutive web user experience.
– Flex performs poorly relative to Javascript.
– Steve Jobs argument that you can’t trust a 3rd party platform to reliably keep up with the features of the underlying device. This results in sub-standard apps in Steve’s mind.
– Bill doesn’t buy the “apps are where it’s at” argument. In his words, “Some things like games seem much more appropriate as apps, but for many apps, mobile web seems more appropriate.”
– AJAX toolkits are so much better these days as insulating developers from platform and browser issues that the relative advantage of Flex as eroded.
Point-by-point, let’s have at it!
Flex creates an unnatural and dilutive web user experience
Sorry Bill, I’ve got to call total BS on this. Flex and Flash have been used to create some totally crazy web sites that are very annoying to use. But that just reflects the poor UX taste of those authors. Flex is perfectly capable of creating very mainstream UX as well. As you would expect for a platform created with tons of designer (e.g Flash/Flex) as opposed to hacker (e.g. Javascript) input it’s set up to be able to push the envelope of User Experience, and some designers love to do that (been to a Museum of Modern Art lately?).
BTW, you can create crazy UI to your heart’s content in an AJAX app too, it’s just a lot easier to do so with Flex. I can’t hold that against the platform.
Flex performs poorly relative to Javascript
Bill saw this in the form of complaints from his last gig with the Intuit Partner Platform. I think it is important to look at his money quote for the insight:
Despite our research that showed that Flex had really great performance characteristics, we saw development team after development team struggle to get their apps to perform as fast as they needed to…
The italics are mine because I wanted to call out that obviously Intuit’s own development staff anticipated this and concluded there wasn’t a problem with Flex. In fact, there isn’t. I write 3D graphics code in it for CAD/CAM applications that just simply wouldn’t even be feasible otherwise. Flex looks to me like it can support more of the cpu capacity of your machine because of how the Flash engine works, and the JIT compiler is excellent. I spent time reviewing tons of benchmarks via Google, and didn’t find any counters. I will tell you that some of the Flex components can bog down. It’s hard to use the TextArea with files of many megabytes, for example. OTOH, there are straightforward ways to work around that.
In the end, I really don’t buy the argument that Flex is slow. But, I will tell you what argument I would buy:
It takes a better grade of developer to get the best performance from Flex than it does from Javascript. If you have a developer who is up to speed, Flex is faster. If you don’t (well if you don’t, you may be doomed anyway), it’s easier to get Javascript to perform decently, in part because the lesser developer won’t even be tempted to do a lot of things they are tempted by in Flex (image manipulation, fancy video, and the like are all performance intensive).
Sorry, I know “them’s fightin’ words” to someone out there (probably annoys both camps, actually), but Flex has a couple idiosyncracies that can be both strengths and weaknesses. I also know I can’t leave that grenade on the table sans pin without elaborating a bit.
There are two areas that seem likely to trip up less capable developers in Flex: the validation model and the elastic racetrack. If you properly harness both of them, you can get pretty amazing performance from your application–much better than Javascript in my experience. If you don’t, and you try to ask the application for too much, things can get so bad you will think the app has crashed. I want to emphasize that for most garden-variety work, you’ll never have to worry about it, and, validation and the elastic racetrack are not secrets or arcane. But, if you’re making the app struggle with either large data volumes or a lot of manipulation pushed down onto the client, you have to deal with them properly. I don’t want to spend a lot of time here, in what is really more of a business blog, debating the technical details behind this further. I have been toying with the idea of starting yet another blog for the really Geeky stuff, but I don’t know that I have time for a third blog!
Bill doesn’t buy the “apps are where it’s at” argument
I broke this out into a whole other blog post, because it is a fascinating and deep topic. Suffice it to say that Bill and I seem to agree both models are needed. Where we may differ is in how often the app model has to come up, and perhaps on the relative monetizability of the two, which I also think is very important. To paraphrase, the point from the other post is that the app model comes up a lot. You can’t just shoehorn any old thing into a browsing experience and expect a good experience. There are sound cognitive reasons why sometimes an app is better. I argue that if what you’re about is creating something, the manipulative orientation of an app is far more intuitive than the navigational orientation of browsing.
Apps are not just about games, Bill, though they are another excellent example. All that stuff you’re browsing around in with your web experience had to get created somewhere, and that somewhere is best expressed as an app. Sure, that app need not be installed on your machine AIR-style (though many will benefit from that and AIR is one more thing Flex has over Javascript that is very important), but once you pass through the login gateway (ala your favorite SaaS app), it had better start looking less and less like web browsing. As it does so, it will get easier and easier to deliver a great User Experience via Flex versus Javascript.
The other thing about apps is people are predisposed towards monetization of them versus the browse. It’s very easy for a paid for browsing experience to cross the line to looking like a pay wall, and that’s not a happy thing. It’s been tried and found wanting.
I do notice that Bill isn’t arguing Javascript is a better tool for building apps, so there again, we have a point of agreement.
AJAX toolkits are so much better these days as insulating developers from platform and browser issues
Bill, I just haven’t seen much evidence of this, either in my recent Helpstream experience where it was a pain, or in the conversations I have daily all over the Valley when this topic comes up, let alone in the further research I did before writing this post. AJAX is a pain in the keyster for cross-platform and cross-browser. Ain’t no two ways about it. There are some limited cures like GDT that help, but GDT is more Java than Javascript as far as that cure goes, so I’m not buying GDT as portability saviour. Moreover, none of the AJAX toolkits are nearly as complete as Adobe’s toolset and Flex framework. Not even close. So even in the best of circumstances and giving the full benefit of a doubt, you’re going to pick an AJAX framework, and then all the code you still have to write that isn’t handled by the framework is still going to be very platform and browser dependent.
I was recently chatting with VC Bruce Cleveland at Interwest about this very topic and he was lamenting that no sooner had we reached a point of write once run everywhere for the server and on PC clients than the mobile world was plunged back into the old “port for every platform with long-term maintenance pain” headache we’d just gotten away from. His portfolio was not very happy about that.
You can’t trust a 3rd party platform to reliably keep up with the features of the underlying device
I had to save this one for last because it is so richly ironic it is silly. Here is Steve Jobs lamenting that 3rd parties might make arbitrary decisions that affect the User Experience on his platform. That would be the same Steve Jobs whose arbitrary decisions (among many many other deleterious effects over the years) kicked Flash right off his platform and then suddenly brought it back again. Or the Steve Jobs that won’t really give Adobe the same access to the underlying hardware to make Flash Player better as they can get on other platforms. I have to admit, if I was Steve Jobs, I would be terrified at the prospect of doing business with myself!
But everyone isn’t Steve Jobs. In fact, most are not, and most think about products and going to market very differently. Some actually understand that platforms have to be Switzerland. More importantly, as my first post that started this smackdown made abundantly clear, it is competition that benefits the consumer, not arbitrary decisions by Steve Jobs, Adobe, or any other entity, however enlightened and brilliant they may be. If the platform or toolset owner ignores the wishes of its audience, and there is competition, that platform owner will lose.
In this case, I think our little smackdown shows that there is wonderful healthy competition between Flex and AJAX/Javascript/HTML 5. Flex is not the incumbent or default choice by any stretch. It is not the lowest common denominator “easy choice.” It takes a little more skill to really make it sing. But I don’t think it is anywhere close to being “doomed.” Markets like choices. It’s why we have chocolate (Flex) and vanilla (Javascript) or BMW (Flex) and Lexus (Javascript).
One last point I want to raise is that we may be having the wrong smackdown. If I have to create an app (or a particularly rich browsing experience), I want to use Flex to do that. It really is a “LAMP stack for UI”. But let’s go back to the Apple mobile platforms. If I couldn’t use Flex there, I think the Objective-C environment, from all I have heard from developers, makes a much better solution than Javascript. Perhaps from that standpoint, setting Flex and Javascript at each other’s throats is picking the wrong battle. There’s a whole ‘nother post here somewhere to talk about these new webby apps and something I call “Fat SaaS”.
Thanks to Bill Lucchini for the excellent debate. He raised a lot of interesting points and sharpened my thinking. In many ways, I think we are in peculiar agreement!
polygeek said
I’m not an artist but I just don’t see artists sitting around coffee shops debating which medium is better: “Water colors and paper are superior to oil and canvas.” “Only amateurs use water colors. Oil and canvas are superior because . . .” I wish developers could be more like that. When I see someone develop something amazing in Javascript I don’t think anything less of the team who made it because they chose JS.
Anyone who says Flex is doomed is just displaying their own insecurities. Flex and Flash will be around for many, many years to come. There are too many things that are done on the Flash Platform that are impossible with HTML/JS. Namely content protection for video. That means the big studios are going to be relying on it for the indefinite future, like 10+ years. That means the vast majority of users will have the Flash plugin.
It’s a pointless argument but there’s a good case to be made that Flash will outlast even browsers. I can see browsers going away someday – not likely but possible. But not Flash.
mrinalwadhwa said
Hi Bob,
That’s an excellent rebuttal to Bill’s post, great read as always.
Some thoughts based on my experience of doing both Flex and Javascript development for 5 years or so ..
First, I have to point out that Flex vs. Javascript isn’t the best comparison, the two stacks kinda look like this …
# Flash Player (with ActionScript Virtual Machine) –> Actionscript API to interact with Player –> several layers of abstraction —–> Flex (or similar frameworks)
# Browser (with Javascript Virtual Machine) –> Javascript API to interact with Browser –> several layers of abstraction –> Dojo, Mootools, JQuery etc.
So its better to compare Flex with Dojo than to compare Flex with raw Javascript without any framework’s layers of abstraction.
Layers of abstraction bring with them ease of use but very often there is cost for this ease of use .. sometimes its performance, other times its loss of flexibility/control.
Also, abstraction by definition means obscurity from what’s happening underneath.
Now while most Javascript developers start learning from the bottom up by first learning to use the Javascript API to the browser and then learning a framework like Dojo or JQuery …. most Flex developers tend to start top down by directly jumping into FlexBuilder, now FlexBuilder is very good at giving a quick illusion that a developer already knows how to build flex apps .. but really there is a lot going on underneath that a developer must understand to build good apps, the component architecture as you pointed out with the invalidation/validation model and the elastic racetrack are good places to start.
And to add to all this most enterprise teams tend to add another layer of abstraction with an application architecture framework like Caringorm, Robotlegs etc. All these layers are great since they provide ease of use, lots of functionality and greatly boost productivity but make sure that all developers on the team understand what’s underneath otherwise the project is setting itself up for failure.
Most Javascript frameworks right now don’t provide as much functionality as Flex, they have fewer layers of abstraction. The ones that do provide a lot of functionality are just as complex and not understanding what’s going on under the hood will land the project in trouble weather you’re using Dojo or Flex or JQuery.
Another common mistake that teams make is that they don’t look beyond Flex .. Flex is just a reusable bunch of actionscript classes, that make life easy… the super set of functionality resides in the Flash Player … they should explore other Actionscript frameworks that may provide less functionality … but maybe that is all they need … less layers of abstraction mean no unnecessary bulk, better performance and more control … but just like in case of Javascript more control means more responsibility.
About some of the points Bill raised …
>> Flex creates an unnatural and dilutive web user experience
As you rightly said, this is complete BS, both Flash Player APIs and Javascript Browser APIs let you control the color of every pixel on your screen .. they also both let you completely control every movement that happens on your screen. Most Javascript and Actionscript frameworks including Flex/Dojo/JQuery etc. expose complete control to visual appearance … so either platforms can be used to create equally bad or equally good UX.
>> Flex performs poorly relative to Javascript
This isn’t true in my experience, but there are multiple things to consider here and the needs of an application may vary …
* Raw Actionscript vs. Javascript in virtual machine performance – some of the recent VMs have gotten pretty good and comparable http://jacksondunstan.com/articles/618 .. but remember there is a very large number of old browsers out there.
* Rendering – I can’t find a benchmark but I’m pretty sure Flash player is better for now, plus there are so many features that are available in Flash player that are just not possible in browsers (at least not consistently) yet .. like really fast bitmap rendering with PixelBender, 3D manipulation etc … some of the newer browsers like IE9 are getting much better at this .. but you know consistency with browsers is a whole other issue.
* the performance of the components in your framework … this is where Flex comes in … some components perform great, some not so much … also depends on your use case … Flex has generic components trying to accommodate for all possible use cases .. this generic behavior might not be what an application needs … if a developer understands the flex framework well enough then writing custom components is not very hard … the TextArea example you gave is perfect .. Flex’s TextArea wasn’t written for MBs of text .. so you can write your own … Buzzword is a great example of an app that uses its own text controls for dealing with large files
>> AJAX toolkits are so much better these days as insulating developers from platform and browser issues
As you rightly said, this isn’t true … I have horror stories … lets take @font-face for example, one of the very few HTML5 features that can work consistently in pretty much all browsers http://html5readiness.com/ … but setting up your server and client side code to serve the right font for each browser is so complex that we have services like typekit that do it for you .. it took me two days to get the right font files, the right css, the right compression, the right content-type etc setup .. to make it consistently work in all browsers. That’s just one example …. maintaining cross browser compatibility remains hard.
To conclude, as you rightly pointed out flex is more complex than most Javascript frameworks and requires deeper understanding and maybe even more skill .. but once you invest in developing this understanding it can help create great applications with features that are not yet possible with browser technologies. Both the Flash Player stack and the Browser stack have their strengths and weaknesses and while architecting an application developers should spend considerable attention on choosing the right platform for their application.
Flash Player is a powerful and certainly not nearing doom … Adobe is innovating (their rate is debatable) .. but have you seen the new feature were we can make a P2P connection between Flash Player in my browser and Flash Player in your browser … how cool is that !! Skype like video calls with no server involved is only the start of what’s possible with that. Features like this may never come to browsers, and when they do, standardization will take its time .. so Flash Player has a lot of potential in teh next few years.
Thank you,
Mrinal
http://www.mrinalwadhwa.com
Bill Lucchini said
First off, it’s hard to disagree with Bob – very well reasoned always. Although “smackdown” may be more fun, I think we agree on most things except the title of my post. Let me do three things: specify what info I’m working from; respond to a few of your comments; and do my own “wrap up”.
As I mentioned in my original post, my experience comes from the Intuit Partner Platform which is focused on business apps. Further, my opinions come from listening to loads of developers and watching the products they came out with. As with any similar endeavor, there was a great variety of results. Some products were really slick and some struggled to get out of the gate. So, my opinions come from listening to development teams (some beginner, some really sophisticated) and evaluating output.
Regarding performance and look and feel:
I have no doubt that you can get great performance out of Flex and although I have some doubt, I am willing to accept that a very skilled developer can make Flex UI feel web-natural. However, as I watched things unfold in the business apps domain, I saw very talented development teams who had a history of success, struggle to deliver on both fronts. You’re probably right that it takes real Flex expertise to get the most out of the tool… but that’s a problem, isn’t it?
Regarding mobile:
I think we’re on the same page. We need mobile apps and we need mobile web. To me, the real innovation that Apple drove is the creation of the marketplace where app buyers could find great apps for reasonable prices and developers could build a business.
My wrap up:
I hope Flex succeeds. I believe in choosing the right tool for the job. In cases where video or graphics are important Flex is probably a strong choice (not common in my experience with biz apps). I also believe that what Adobe has put together is impressive.
So, is Flex doomed? Some great debate here and a lot of fans… but, I remain concerned about any given development team’s ability to create great apps with it. I’d be less concerned if I felt like Adobe could deliver on the improvements to keep knocking down arguments like mine at a fast pace… but I don’t. I’d be curious to know what Adobe’s aspirations are for Flex. If it is intended to be a specialist tool for video applications or something like that, then it probably can succeed. However, if it’s intended to be a general purpose app development platform then I still think it has little chance of gaining significant developer mindshare/use over the next few years. History will tell. Agree that you need mobile web and app. My point is that the excellent findability of apps and monetization that Apple has spawned is the key… doesn’t matter how the apps are built as long as they do the job they market well.
smoothspan said
Bill, thanks for the debate around Flex. Nice wrapup post. I think
it is perfect as the last word on the subject, so I won’t respond
further.
saleswave said
I’m not a developer. Just a layperson who’s experienced vicariously the challenge of developing a fairly complex business website with Flex. I cannot express the depth of my frustrations from hiring so-called expert Flex developers who ultimately caused more harm than good, yet had no qualms about charging for their dismal results. So here’s my take on the smackdown question concerning Flex. If you can actually find someone who know how to develop with it, you better hang onto them with dear life. That dynamic creates a very small “club” of developers and you’ll pay a high price compared to non-Flex websites. It also means you probably won’t have a large experienced team of developers so the production pace will crawl. The trade-off is that the website will be beautiful and desktop-like IF you can ever get it completed. So would I do it all over again? Absolutely not. Adobe’s promise of a framework that speeds development, hides the complexities, etc. is a joke. One ironic upside is when you get the website developed, there’s probably few other sites like it. So your site will stand alone as mine now does. But the financial and emotional toll wasn’t worth the results and this will be my last Flex website. For those who would like to see more about our site, you can go to http://www.saleswave.com. That’s the marketing website explaining the Flex application.
Bob Warfield said
Chuck, welcome to the world of managing developers. If you get bad ones, you’re going to have a terrible time, no matter what language or platform they use. Once you have bad developers, you’re doomed:
http://smoothspan.wordpress.com/2010/08/12/once-you-have-bad-programmers-youre-doomed/
Here is the other conundrum: there are surprisingly few good developers:
http://devluchadore.wordpress.com/2010/09/12/there-are-very-few-programmers-period/
Judging from the look of your site, you needed some pretty good developers to pull it off. Now you need someone to manage the developers who is technical and understands how to match the needs of the business to their needs.
A surprising amount of harm comes from outsourcing your development, failing to hire good developers, and failing to have someone on hand who knows how to manage good developers. There is a reason they’re called “Software Companies”, not Sales companies, marketing companies, or some other kind of company.
Cheers,
BW
saleswave said
Hi Bob, thank you for the welcome and reply. I couldn’t agree more with the points you added. I was fortunate to finally locate a strong developer and yes, our application was pretty intense. We developed an HTML WYSIWYG editor from the TLF framework that supports tables plus absolute and relational positioning. There’s also a ton of PHP and 3rd-party software it interacts with. So it has been a big technical challenge. My frustration though is partly with Adobe and partly with the Flex development community. I believe the smackdown issue involves why Flex is doomed. Although I feel it will have a relatively small niche for many years, I do agree that it’s universal acceptance is “doomed” as a future possibility. Adobe’s byzantine product decisions must baffle even God. We spent over 12 months developing a fairly robust HTML editor as mentioned above because Adobe doesn’t appear to “like HTML”. They prefer their own version of XML or whatever proprietary version appeals to them this month. They could easily convert Buzzword into a robust HTML editor and help the Flex and Flash community immensely, but they’d rather release dribs and drabs of minor features in TLF when the community is crying for tables and HTML support (can you say deaf?). I spent thousands of dollars getting the editor developed so had Adobe offered a paid-version of Buzzword for $5,000 or even $10,000, I would have snapped it up.
As for the developer community, I know it’s hard to find good people in almost any industry. I’m a retired commercial architect and I used to hire and fire on a regular basis. But much of my decisions were based on work ethics. That’s because I was required by State laws to meet a certain minimum standard of education and experience. I was also required to take on-going training (CE) to maintain my license. A person may not agree with a design style for a high-rise office building, but they knew it wouldn’t fall down because I was licensed by the State with annual renewals. But in the software developer world, it appears there’s no oversight and a trusting fool like myself won’t know what a mess they purchased until it’s usually late and the money’s spent.
Although I’m a former architect, I worked as a programmer (ALC, Cobol, Fortran, RPG) in the early 70’s. I was one of the first architects to use CAD in Texas (1980) and did much of my own programming (RSXM11+). So I’ve had some exposure to software over the past 38 years. And all I can say is a really knowledgable AND PROFESSIONAL Flex developer is hard to come by. I hired and fired multiple American, Canadian, Indian and Russian Flex developers. The one person I found that knew what he was doing has been a gem and I thank God I found him. But I hate being in a position where one person holds my future in their hands. So that’s why I feel Flex’s future as a universally accepted framework is indeed doomed although I fully support it’s potential.
Bob Warfield said
I hear what you’re saying, Chuck, but you’ve approached it wrong and with some bad assumptions about software based on experience with architecture and construction that doesn’t really carry over.
For example, you’re assuming that the world is teeming with developers who you can hire or fire as commodities, and that these developers should be much like hiring and firing contractors to build a building. It just doesn’t work that way. There aren’t that many good developers to be had relative to construction workers. What ones are available are very expensive. It’s very hard to tell in advance, especially if you aren’t technical, whether you’re getting a good one or not. Also, you’re not done just because the “building is built.” You have follow on releases and maintenance. If you bring on entirely new developers to do the follow-on work, you’re going to be very sorry as they tell you the old code has to be completely rewritten, or you get to pay for them to reverse engineer how it worked until they’re productive on it. It doesn’t matter how good the last guy’s code might be, the new developers will tell you it’s crap. Because of that, any time a software company outsources its distinctive competency, which is building software, they are in for a rough ride at some point unless the software is so pedestrian that it would be easy for any developer to recreate it.
The second issue is that full featured HTML editors (not to mention the rest of what you’re trying to do) are NOT in that category! There aren’t many HTML editors around for any platform. Just imagine what it took to build Buzzword. You’d like Adobe to give that away as part of Flex. No easy thing, that. It’d be like assuming that as you’re building a skyscraper, you can just write a check for a module comprising floors 10-20, helicopter it on top of your building, and off you go.
Heck, forget full-featured HTML editing. Let’s just focus on the subset used by WordPress.com for writing blog posts. Flex does come with that much built in. We used AJAX at my last startup and spent countless hours with very competent developers fighting browser incompatibilities. Those who think HTML 5 will be a panacea for all this have forgotten or never knew how much time goes into fighting those browser incompatibilities.
The real crime of Flex, if there is one, is that people who really have no business doing more than a little HTML because they aren’t really developers will be tempted to build complex apps. No language or platform can fix that problem, and thinking you can outsource it only makes it worse. You’d have had the same problems no matter what tools you chose, is what I am saying.
You are right about one thing, though. Flex will never be “a universally accepted framework”. Neither will HTML5. There is no such thing. There are only tools with various strengths and weaknesses that have to be weighed against the problems at hand. In addition, you have to consider that not only do developers not like to learn each other’s code, they hate learning new tools as well. You can see more about this peculiar psychology in this post:
http://smoothspan.wordpress.com/2011/02/12/scoble-discovers-developers-are-schizo-about-new-platforms/
My best advice is you need a very technical co-founder to help manage these issues.
Best,
BW