Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why not Flex?
37 points by mrshoe on Sept 3, 2009 | hide | past | favorite | 74 comments
I'll never get back those weeks of my life that I've spent trying to fix cross browser HTML/CSS/JavaScript issues.

I feel like I have to jump through several hoops just to achieve good-looking rounded corners, especially if the element has a border.

Many relatively standard GUI widgets just don't exist in the web stack (e.g. tabs have to be expressed as an unordered list with an extra element in each to do the "sliding doors" effect).

The set of available fonts is still, in 2009, incredibly limited.

My current project (http://shoptalkapp.com) has typified all of the above pain, and more. It's heavily AJAXy, which only exacerbates the problem.

So I ask the HNers, "Why not Flex?"

It's user-hostile.

Flex code runs inside a sandbox element, much like Java applets. It doesn't feel native to the browser - the Flex app can change things only within its own little canvas. (Okay, there's ExternalInterface as well, but then you're back to writing JavaScript and DOM manipulations.) It's not aware of browser resizing - you're locked into a fixed width layout. It can easily result in horizontal scrolling if you have a full-width Flex app in a small browser window. It generally doesn't show up on mobile devices. It takes forever to load. It disables UI conventions - like being able to right-click on the page - that users are used to. Hitting Ctrl-T when a Flash app has focus does not open a new tab. It's not easily indexable by search engines.

I look at it as Flex:Javascript::Swing:native GUIs. It makes development easier, but at the cost of never quite meshing right with the rest of the platform. You may like it, but your users probably won't.

I'm sorry but most of that is FUD.

It doesn't feel native to the browser

Most advanced javascript apps don't feel particular native to the browser either because HTML still lacks basic widgets like a combobox or -button. How many native browser buttons do you see in your Gmail or Google reader interface?

It's not aware of browser resizing - you're locked into a fixed width layout

Wrong. Flex handles browser resizing out of the box, see for example http://www.grooveshark.com

Moreover the Flex layout manager is heads and shoulders above the box model madness of HTML/CSS.

It generally doesn't show up on mobile devices.

That's one valid point. But then again, how many AJAX apps can you name that are really useful on (which?) mobile devices without a special mobile version?

It takes forever to load.

Nonsense. http://omgpop.com feels quite zippy, no?

It disables UI conventions - like being able to right-click on the page - that users are used to.

Point taken. It replaces the browser context menu with a customizable flash menu. That sucks but it's hard to imagine how it could be done otherwise.

Hitting Ctrl-T when a Flash app has focus does not open a new tab.

Works fine here (OSX/Firefox).

It's not easily indexable by search engines.

Neither is AJAX content.

You may like it, but your users probably won't.

That depends very much on the application. Right tool for the job.

"You may like it, but your users probably won't."

At my job we hold focus groups for all of our projects. Never once has a layman not liked one of our projects because it uses flash.

Most flash hate comes from developers who favor other platforms. Mac vs Windows all over again...

Just a personal gripe, flash plugin runs subpar in Linux, which I developed flex in for a few months.

>>>>It's not easily indexable by search engines. >>Neither is AJAX content.

You typically wouldn't load your entire layout via Ajax.

You typically wouldn't load your entire layout via Ajax.

Depends on the application. Flex doesn't compete with your average listing-based HTML webapp. It's competing with GWT and Ext in the field of complex, desktop-like GUIs ("RIA").

Clicked on omgpop.com just to see and it took 25 seconds before I was able to click something. So uh, flex does take forever to load. Twenty five seconds is your idea of "zippy"?

This is like the DIV vs TABLES argument. It really doesn't matter. Use what's best for your target audience and application. If you're writing a game, use flash. If you're making a traditional website, use html+javascript. For everything else in between, some key decision points off the top of my head:

(1) do you care about mobile browsers? if not, flex works on 99% of desktop browsers, and looks almost exactly the same on all platforms with no additional code.

(2) do you need real, bidirectional, binary-friendly sockets or is long-polling with json/xml parsing sufficient?

(3) do you need to make extensive use of tables, images with flowing text, and other complex forms text layout that are trivial to do in html but difficult to do in flex?

(4) do you plan on creating a lot of sound / video / vector animations that need to perform reliably and consistently across browsers and platforms?

(5) does your application need to do a lot of client-side processing?

(6) can you combine the two approaches? example: gmail uses flash just to play the "ding" sound in chat or to show the file upload progress bar; video sites mostly use flash only for the video element and do the rest of the layout in html/js; etc.

Here's an interesting one: compare the rendering speed of maps.yahoo.com (flex) versus maps.google.com (javascript). And the fact that on the smartest mobile devices -- iphone, G1, blackberry -- they all have native versions of the maps app, because the javascript on maps.google.com is so intensive that it's an incredibly poor experience in any mobile browser.

Full disclosure: I work on voxli.com, where the UI of the chat room is 100% flash, but the rest of the website (registration, login, intro, etc) are in html/javascript.

I really don't buy the user-hostile argument. You write your code and you get a SWF. Youtube has SWFs. Newgrounds has SWFs. DeviantArt has SWFs.

Normally the thought of whether something is running in a sandbox is not a concern if I'm using any of these sites. The only times I would get annoyed by load speed issues had nothing to do with the SWF format, it would usually be of the magnitude of the whole site being overloaded.

I could say Meebo doesn't feel native to the browser either, but I think we're way too much into the opinion territory to be saying that, generically speaking, x or y technology is hostile to all users (especially without knowing what the app is to begin with).

Flex is aware of browser resizing.

You can also handle right click/context menus.

In trying to answer my own question I had come up with some of the same ideas, but you put together a great list. Gracias.

1. There are a million small disadvantages to using proprietary plugins, it is not "the internet", google can read flash, but not well, you dont have firebug, your site cannot be scraped, these may not all affect you, but there are lots lots more.

2. The flash plugin sucks on most browsers, its a slow unreactive user experience, compare a few full flash sites to their equivalent in javascript.

3. Flex's layout constructs are similiar to pretty much every widget manager around, are in no way close to the power of xhtml/css, I for one didnt find it enjoyable at all to develop for.

how long have you been doing html/css? its a pain that goes away quite quickly, if it hasnt, I would ask some more experienced developers to look over your stuff and see if anythings being done wrong.

and you might want to look at graceful degredation, if ie isnt a particularly large chunk of visitors, your exact problems are very easily solved in a way that very gracefully degrades (-moz-border-radius:, font-face:)

1 - This is a completely valid point. There are tradeoffs in build a site in Flash. You have to put extra work into being crawler friendly - something you get out of the box with HTML/CSS.

2 - Depends on what you're doing. Animations definitely run smoother and with less resources in Flash than they do in HTML/CSS.

3 - A lot of Flex's layout capabilites "just work" out of the box. You don't have to figure out the complexities of the box model and you don't have to know the intricacies of floats. You just say "I want a container that positions things horizontally and I want them to be aligned on the top of the box" and it does it.

Flex's components I have found are incredibly hard to precisely skin. Then again, so is HTML if you don't have experience in it.

re 2 - I disagree. On a powerful computer flash is OK, but on let's say a Core 2 duo 32 bit and an intel i950 graphics chip, almost any flash will take one of the cores to 100%...

And the Javascript equivalent wont?

thats a tiny tiny part of firebug, the lack of the ability to introspect the code makes it virtually useless (dom inspection, profiling and tracing, this is also the same problem relating to seo and such)

hu? There is profiling and tracing (actually is native if you have Flex Builder on debug mode). And DOM inspection doesn't make sense in Flex.

And you can have SEO in Flex easily. Check it out: http://www.google.com/search?q=listen+to+free+music+online

2 of your 3 points are purely opinion, so agreement will vary from person to person, but I disagree with number 2.

Flash player is not so popular because it doesn't perform well. It perform great. One of the best sources to deliver video and complex interactivity such as games available.

People always attribute the low barrier to entry of flash (7you can crank out a bad website or animation quickly) to the speed and quality of the flashplayer or actionscript/mxml. Honestly, there are many more bad html/css and java sites than flash.

To make a long rant short, quality flash/flex can provide just as good (and oftentimes better) UX than anything else.

No Firebug, no life...

Flash has its place, for sure but it has many short comings when developing an entire web-based app.

As far as I know, the answer to these questions is no for Flash based sites:

1) Can it be indexed by most search engines?

2) Is the text always selectable, & copy and paste-able?

3) Does the structure of the Flash movie imply anything about the information it presents? (e.g. <table> elements imply tabular data.)

4) Is Flash & Flex an open platform which can be developed on for free?

Your argument against HTML doesn't point out any weakness in HTML itself. It does point out the lack of a standard and accepted HTML UI library, as well as a simplified, cross-browser compatible development environment for that UI library (the notable exception here may be cappuccino.org and some other, larger dev environments like WebObjects, neither of which I've used extensively).

Let's drop the absolutes, shall we?

1) Google can index it. I wasn't aware of other search engines that are relevant. I'm willing to concede that you -should- do extra work to make sure you are search engine friendly, but that doesn't rule Flash out completely.

2) Yes, text is copy/pastable. No, the experience isn't nearly as good. Yes, it's a really big deal that copy/paste sucks for Flash.

3) No, Flash markup isn't semantic because Flash markup isn't public. Then again, how much information does <DIV> imply?

4) Yes. Flex is open source and can be developed for free (http://www.adobe.com/products/flex/). I do all my Flex development with simply mxmlc and fdb, I don't use Flex Builder at all.

teej, I appreciate your response and dispelling any absolutes that I may have inadvertently spoken in. However, I don't think I spoke in strict absolutes by saying things like "As far as I know" and "Is the text always selectable & copy and paste-able?". I concede you're right, about #4 and your correction reminded me that as recent as about two years ago I used ActionScript 3 (or was it 2?) with a free compiler, as well as Flex (and I sure as hell didn't pay for any Flex compiler). Anyways, I'm not attacking Flex or Flash, I think both tools solve certain problems well. I was just trying to point out some broad issues with it that you, yourself concede exist. Apologies for that coming across as absolutes. You clearly have far more experience than I in the Flash and Flex world so thanks for your feedback.

the last time i looked at this issue, writing flash applets with mxmlc meant that you can't use flash GUI controls. is that still true?

This is true, you don't have direct access to flash GUI controls from vanilla Flex. That being said, I have found it rare that I find a Flash control that hasn't been ported to Flex.

We're using Flex + ZendAMF(PHP) and development is enjoyable. Serializing PHP data types that are also native to Actionscript remove the need to parse JSON and XML. On the wire the data is binary, thus small(no XML tag tax) and fast.

Flex's default widgets and classes are all easy to extend and customize. You never need patches of js to customize some component on the bottom of the page.

Adding features like drag and drop, navigation trees and tabs are almost too easy. Dividing your app up into loadable(and cacheable) modules can keep your application fairly lightweight, althrough still much bigger than a standard AJAX app.

We(developers) will always be able to feel it when we're using a Flash app(before we even right click), but the CSS/Style/Skin support is good enough to make the app look inviting.

We're using the upcoming Flex 4 for a new project and I'd compare Flex to GWT but not something like jQuery. It definitely has its trade-offs and benefits. The state management and skinning system is first class and there are some great micro-application architectures being created in the Flex world.

We have started to see the same sort of thing in HTML/JS land (Sproutcore/Cappuccino) but honestly, they come with almost all the same tradeoffs as Flash does.

I would say the File upload/download, animations, skinnable components, layout management, and more in an single well thought out package outweighs anything in the HTML/JS land currently. Sure if you want to patch together components you can get all of the same things, but that's like arguing insert flavor of linux is as fun to use as Mac OS X because it has all the same features.

I choose Flex for the same reasons I choose Rails. It's not a chore to develop in.

Ajax is easy to use, and the dom is easy to manipulate using jquery. When yo create a site with plain html, it fits in perfectly with how the user expects the web to work.

When you do this is flash, it is an application running in your browser. It is far from seemless, and is the equivalent of a java app. It is something that takes time to load, and when it finally does, it takes time for the user to get used to the new experience.

The simple question is, when you come to a page that uses flex do you notice that flash is running. If so then why? Why isn't it completely transparent to the user? Why does it seem like an isolated little object on the page that has little interaction with what is going on around it.

Perhaps I just don't like a company owning any type of represention on the web.

Perhaps you knew all these answers though, and this whole post is a light form of flame bait. In which case I fell right into it by explaining the obvious down sides of flex.

So the positives: *Things move around and look pretty.

I have a client using Flex right now. They're having a desperately hard time finding anyone adequately qualified to perform the work, so availability of hackers is an important consideration.

Also, everything else people have said. It uses a plugin, which slows things down and appears non-native. It's proprietary; if one day Adobe says "Flash Player is universal, let's start charging for it, and jack the IDE cost up 50%. We don't care if everyone moves off of it because we'll make a lot more money off of the relatively short-lived mass influx of license money", or "Let's just not release the new version or ensure compatibility on (Windows 7/OS X 10.6/Linux/Solaris/any other platform important to your userbase) [yet]", or "Let's break compatibility in Flash Player 11 and make a really difficult downgrade path", you and your users are kind of screwed, and so on.

It is pretty sound to be sceptical of any open-source offering from a company like Adobe. I'd much rather spend time learning some skills in an open source project where the full stack is open-sourced future proof.

I'm sort of wary learning to code iPhone programs as well -- it seems cool, and there's lots of interesting ideas there -- but do I really want my hard-earned development skills to be dependent on the whims of Steve Jobs?

Hearing this, I thought I'd jump in. The stack is open-sourced. The Flex SDK and BlazeDS (if I remember correctly) are both open-sourced, as well as the AMF specifications. There is absolutely no reason why you could not write AS3 code and MXML against the Flex libraries and build your own Flex application without Flex Builder (the IDE, which costs a paltry $199-$299 last time I checked).

I've done it, and it does work. Is it a pain? Of course it is. Do you get the Adobe built data components you get with the advanced and charting editions? Nope. Can you build them yourself? Of course, and there's a bunch of open source controls & components you can download too.

You really have to be careful whilst criticizing a company who essentially gave away their protocol and build tools. They could just as easily have marked that IDE and tookit up to $1,000 and we'd still buy it.

The stack is not open source -- the player is a blob.

One of my co-founders like flex and have programmed some admins in flex, in xml. Myself I don't care much for flash. I've dome some actionscript programming and presentation development but I only do it if I really have to. I much prefer to work with HTML/Javascript. My co-founder would like us to work with flex instead of rails which he dislikes. I have no love for programming in XML, so the middle ground is that we have coded up some small web frameworks in java with seaside-style html generation. It works fairly well.

I'll agree, Flash Player is not OSS (though projects to emulate this do exist), and it can be a royal pain but...

You can definitely use Rails with Flex. Flex is not a server side language or framework. It can interface with all of them really well through web services. Heck, I'm pretty sure Flex can even inject and call JavaScript functions on your pages. Rails can render things to XML amazingly well, and you can still build an HTML response as well while maintaining the functionality of the Flex application.

Your co-founder is comparing apples to oranges, but whatever works for you all is great. Just don't let the tools limit you.

I like flash/flex when it's used as part of a site, to display video, a game, or some presentation. There are too many benefits from using standard HTML as to not use it for the main plumbing of a site.

In such a hypothetical scenario, Adobe would also be screwed.

Flash reconciles various needs, from indy creatives to high-budget publishers to ordinary consumers to videographers to anyone seeking a means to communicate their beyond-text ideas to an audience.

Reconciliation of all these interests is a difficult task. If Adobe were to mess over any of these constituencies, Adobe would pay the price.

Who paid the price for HTML4's confusion over OBJECT and EMBED tags? The responsibility was not as direct.

What put me off was that mxlmc was really slow (10-seconds-to-compile-a-hello-world kind of slow). Also, I find that debugging HTML/CSS/JS stack is really easy with Firebug et al, whereas debugging swf's isn't quite a walk in the park.

With that being said, every development environment will have its warts. If you're sick of HTML/CSS/JS, nothing is stopping you from using whatever you want. Look at the QuakeLive guys, for example.

Don't invoke mxmlc every time -- that has to start up Java, and that's what's slow. There's a compile "shell" named fcsh that comes with the Flex toolkit that starts up a JVM once and lets you recompile without having to relload all the libraries.

Fcsh is indeed a lot faster than mxmlc. I've written a small shell script that stands in for fcsh and provides an interface like the standard mxml compiler (mxmlc) so that you can just call it (like you would call mxmlc) and have it return an exit status instead of dropping you into an interactive shell like fcsh does. It's called fcshctl:


Thanks for sharing this - you just sped up my Flex development workflow by a huge factor.

The "cross-browser" compatibility is greatly exaggerated by adobe and "widget" programmers who don't have to do heavy application programming. I have been working with a large team for two years on a website with heavy flex integration and we have had far more browser incompatibility problems with the Flex than the HTML/Javascript portions. Rendering is very consistent across browsers but the network stack is largely handed off to the browser which introduces all kinds of problems. Also, things like transparency and background mode can massively degrade in the wrong browser/OS pair which means testing all of your supported platforms for performance and turning off features accordingly. The network stack is very hard to get right on all browsers. Big surprises like Internet Explorer can't parse an XML file over HTTPS if caching is disabled for the resource. Thats right. Now considering that virtually all XML API calls out there disable caching, this is really annoying. So basically we had to detect when a Flex client was calling our services and remove the no-caching headers. And of course, since you don't want to cache you have to add in a nonce on the url or it will never be called again. Also, Flex can't by default handle anything other than HTTP 200 so better recode all of you server processes to basically be Flex specific, returning Flex friendly HTTP codes and headers. The Flex network stack is simply pathetic. Our QA team tests the Flex application on all supported browsers. They do not even bother anymore with the HTML portion because errors have become so comparatively rare.

Do you use jQuery for your ajax? That should resolve many of the cross-browser issues.

There's nothing unique about jQuery in that regard. GWT would solve the same issue.

jQuery is unique in that he wouldn't have to change backends to use it. Similar to Prototype/scriptaculous or Mootools. GWT requires a Java backend - it's a non-trivial effort to move to.

Check out http://groups.google.com/group/Google-Web-Toolkit/browse_thr... for people using client-side GWT with PHP, Python, .NET. There no absolute need for Java on the backend with GWT.

It is a very common misconception that GWT requires a java back-end, but it does not:


Why not HTML/CSS/JS?

You can use it for web, widgets, iPhone/Android Apps. It's free, has a low barrier to entry, is easy to update, and has extensive documentation, both free and commercial.

I'm not saying that Flex doesn't have it merits, but as a long time web/flash developer, I'm finding myself using Flash/Flex type stuff less and less (Thank You, JQuery!)

It's the texture. HTML/JS/CSS feels like paper. Flex/flash feel like plastic.

Shoptalk looks great btw. You'll probably want to allow multi-selecting users - dragging them one by one can get tedious.

BTW: V. classy operation at SmallTalkApp... wish I could have entered a suggestion via your "Feedback" button... without going through Bloomplex's "question handling". Makes it feel way less like I'm actually connected with developers of STA... taken away to "getsatisfaction.com ...

As for the original topic, I feel your pain over losing a chunk of life "to fix cross browser HTML/CSS/JavaScript issues". But I appreciate your raising the flex issue; the ensuing discussion has convinced this noob that he neeeds to study up on and experiment with it.

First off, flex is not flash. Do not confuse the two. Flex is the fast, just works, flash is the pretty.

Secondly, the reason webby people don't like it is that they can't scrape it, tie it in seamlessly, etc. The reason it may be a good idea for your business is that it is 1000x easier to whip out a consistent, good flex website then the equivalent in cross browser complaint javascript/jquery/whatever

Flex is absolutely Flash. It is simply a library/toolkit for Flash development.

ORLY? Then tell that to my current flash only performing client how you easily add the flex libraries to his project.

Oh wait, you can't.

Seriously, they're not the same thing. Flex is a toolkit that compiles to swf but its not flash.

Definition troubles. Flex generates content for the Flash Player. The Flash authoring tool generates content for the Flash Player. So do you define "Flash" as "output runs on the Flash Player" or as "created using the Flash authoring tool?"

output that runs on the flash player. that's all the users care about.

That's not flash. That's swf files.

Flash, as something you hire developers for, is an authoring environment. As of CS3, it is not very compatable with Flex.

CS4 actually as adobe tying them together a lot better, but I've yet to put enough time in on CS4 projects to know one way or the other how well they have.

While you may think of flash as "that which runs on a flash player", a vast majority of people developing software in this arena think of it as "that which is written with the component of Adobe Creative Suite 3/4 called Flash Builder"

Tell that to users that have to download the flash player to access your client's project

Well first, you're writing a chat app.

In this case Flex might be the right solution for you. Heavy back and forth, it dosn't really need to be indexed by browsers.

You likely want some sort of combo with Flex and HTML.

The border issue is kind of a non-starter and not really relevant for a broader discussion (BTW I just use the new CSS rules and let new browsers have rounded edges and the rest get squared - easy enough)

Are there any screen readers that support Flex content?

(that's not rhetorical; if anyone knows of one, I'd like to know)

Yes, Flash Player has sent text to the big two (JAWS and WindowEyez) since 2002 or so, and is also supporting an opensource screenreader effort: http://blogs.adobe.com/accessibility/2009/08/adobe_supports_...

(I think Apple may have finally added an API which browser plugins can access for their text-to-speech, but I'm not sure how many people have moved over there yet.)

this comment is loading....... loading.......

I think you've answered your own question. Flex sounds like a good fit for your project.

The number one request in our user feedback forums is to get rid of Flex/Flash.

Is anybody using Flex for embedded systems? Any thoughts on that?

While not a traditional embedded system, I built a HTML/CSS/JS/Flex app that lives on a touch screen kiosk inside a museum.

Did you encounter any problems while using Flex? Was it stable? Did it need to be restarted often, etc.?

Yes. There have been past projects (if memory serves, Jaguar and BMWs, a yacht, Chumby, etc), but most of the action is now occurring in the next-generation cross-device Player, at openscreenproject.org.

I know it's not practical at the moment due to lack of deployment, but how does flex compare and contrast with silverlight/moonlight?

wow this community is friendly. i'll keep my opinions to myself from now on. peace.

Constructive comments and criticism, please. You are welcome to have and share opinions, but please back them up with reasoning.

So the rationale is, if an opinion isn't thoroughly explained, it's better that nobody hear it, regardless of whether or not the opinion is valid or makes sense?

Yes, that's how HN works. As a reader, there's no way for me to evaluate a bare opinion. Should I believe it or not? Without any argument backing your opinion, it's just noise.

See http://www.paulgraham.com/disagree.html

Abrasive words require support to back them up. Otherwise you're just calling names.

"polishing a turd" is an expression. http://www.urbandictionary.com/define.php?term=turd+polishin...

also, why is there no reply link under your comment?

Step one: Be provocatively insulting. Use gay slurs if possible.

Step two: Complain of victimization.

Step three: Profit?

in my humble opinion, flex is like polishing a turd. premature optimization.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact