This content has been marked as final. Show 2 replies
We are well down the path of building a real app (Java backend for ours, but that does not matter). We have about 20 screens or so and our app is largely reporting only some data entry. Our production version swf will end up around 450 to 500K which is fine. There are about 30K worth of embedded fonts and stuff for printing in there and a couple of smaller embedded icons and stuff like that.
All this follows is largely opinion. Happy to hear different ones ;-)
It's early days, but overall it hangs together quite well. Reminds me a bit of early Java development really. Main issues
we found are:
2) A fundamental limitation is that it's all single threaded (so if you have something computationally heavy you need to work very hard and manually "time slice" it to keep the UI responsive)
3) Flex runtime has some garbage collection issues, i.e. the libraries lure you into hanging on the references that you shouldn't (I think they are all solvable, you just have to be careful)
4) Some Flex APIs aren't very well designed / thought out - the learning curve is quite steep and even when you understand you often run against private methods, etc that make extending / fixing the standard classes difficult
- You need a very beefy machine to run FlexBuilder with larger projects, it is very slow compiling (in comparison to Java) and you always sit there waiting for it to sort itself out
5) It's fundamentally a disconnected model, so you'll need to design your app pretty carefully around that to make it work (apps where you can do a lot on the client and only ship large chunks of data back and forth will work well, small transactional things are bad news)
1,2,5 are fundamental, 3 and 4 should get sorted out over time - it's at a Java 1.1 and JBuilder 2.0 stage if you know what I am saying.
Not that good yet, but probably the least painful rich client platform out there, as far as I can tell.
Hope this helps.
I agree with everything said above, except I don't understand #1:
Given that, I'm curious if you could clarify what you were trying to get at in #1.
As to the original question (and again, what follows is strictly opinion): I'm on my second enterprise Flex application, and there are a bunch more out there--more than you know, because enterprise ISVs tend not to market their products' underlying technology. And I love Flex, but you have to evaluate its strengths and weakness against your other technology options, and ultimately base your decision on what can best satisfy your customers' needs.
As to the "one great big SWF file"--by default, yes, though the size isn't that bad, especially if your target market is business users who typically have high-speed connections. Note too that the SWF will get cached like any other web resources (images, .js files, etc), so your user's won't need to download it every time.
If you're worried about size, you should check out the mx.modules package; it provides support for loading pre-compiled code modules on demand from your main application SWF. It's a great tool, but using it is a somewhat advanced topic--basically, don't start modularizing your Flex application until you know you need to--actually that rule really goes for any kind of performance tuning or optimization.
Last thing--if you're considering using Flex Data Services to connect to your .NET services, make sure you understand the licensing. I'm just sayin'.