I've been developing an administrative application the last couple of weeks. I actually developed it twice: the first version was done using Adobe Flex, the second version was done using Microsoft Silverlight.
Because Silverlight was new to me (I know, use and love .NET however for server side development) I couldn't compare development time. Therefore I decided to compare the size of a number of application files.
Some value object class
Adobe Flex: 19 lines
Microsoft Silverlight: 164 lines
Main reason for the difference: Adobe Flex has a [Bindable] attribute
Some data entry screen (without datagrid)
Adobe Flex: 61 lines of MXML + 25 lines of Actionscript
Microsoft Silverlight: 108 lines of XAML + 53 lines of C#
Main reasons for the difference: Form layouting and field validation is better in Adobe Flex
Some data entry screen (with datagrid)
Adobe Flex: 170 lines of MXML + 198 lines of Actionscript
Microsoft Silverlight: 261 lines of XAML + 315 lines of C#
Main reasons for the difference: Form layouting and binding is better in Adobe Flex
My conclusion: it takes 1.5 to 2 times more lines (and in reality therefore hours) to develop an application using Microsoft Silverlight compared to developing the same application using Adobe Flex.
skip to main |
skip to sidebar
Sorry - I'm addicted. But I shouldn't be ashamed: I'm addicted to Adobe Flex - the solution that we should have had 10 years ago. If that would have been the case the internet would look completely different today. But don't worry: in 10 years from now it WILL look completely different :)
20 comments:
So, what about the 'other' size... as in executable? I haven't ever seen any comparisons of compiled size
Good question. I think they're roughly the same in size but I'll check them out tomorrow and post a follow up.
"My conclusion: it takes 1.5 to 2 times more lines (and in reality therefore hours) to develop an application using Microsoft Silverlight compared to developing the same application using Adobe Flex."
And you can say that after wiriting roughly 300 lines of XAML/C# code?
I took a couple of files (at random) from the complete project. I also have 20 years of development experience. Statistics don't prove anything but are often a very good indication.
Interesting, Tom. I would love to see a similar study on a larger scale.
I agree but the overall project isn't that big so I'm afraid I can't help you with that (and I wonder who will be given the fact that nobody is eager to develop an application twice...).
Looking at the code it's however clear that even with bigger ADMINISTRATIVE applications the difference would be similar (due to the inherit differences between the 2 technologies).
Dusty a new post is online with information on the size of the 'executable': http://riaflex.blogspot.com/2009/01/adobe-flex-silverlight-compiled-size.html
I'd like to see the Silverlight code so that we could see if there are things you could have done differently to reduce the amount of code you wrote. Since you freely admit you're not that familiar with Silverlight it's possible you missed some ways to reduce the code.
I agree and I wish I could but the code has been developed for a customer and therefore I can't share it...
Not even the size of the executable matters that much.
What it the size of the bandwidth of each. What kind of network load is present?
Good question but I'm pretty sure Flex wins hands down because of the fact that you can use AMF, a very compact binary protocol.
What about performance of both?
Sergey, which performance? UI, data serialization/deserialization, ...?
Definately the wrong approach to answering this question (but you probably all knew I was going to say this).
Here's why:
- You're comparing an output of code and not detailing the heavy lifting the tools can provide. Visual Studio vs Eclipse is and has always been stacked in our favour when it comes to developer based user experience.
- You're not comparing the server-to-client time to market. Meaning how tightly intgerated can Silverlight to ASP.NET become should you keep it all on Microsoft stack etc.
- You've not highlighted the power of LINQ. Given LINQ can reduce foreach loops to one line of code, this has to be factored in as signficant reduction cost in both line by line management as well as DataProvider / Binding techniques.
- Compile Times. Silverlight compiles much faster than Adobe Flex and as applications grow in size, our compile time doesn't get as impacted as Eclipse approach.
- Sample project is extremly small to base any calculation off of. I think you've not only done Silverlight a diservice but also Flex.
- Tools. How many tools does it require to produce an Application in Flex instead of Silverlight for a Developer/Designer workflow. As of CS4 it's anywhere between 3-5.
- Runtime performance. All experiments that i've seen and produced have weighed in Silverlights favour when it comes to handling large calculations.
- etc..
I could list them a mile long and someone whom works for the ex-Flex Product Designer and one whom has used Flex since its birth prior to joining Microsoft I can honestly say that the above metric is just simply bogus.
I've my own opinions on each strength and weakness, and they varey depending on the context of both developer and solution intended to be built.
One doesn't rule out the other that cleanly i'm afraid.
-
Scott Barnes
Rich Platforms Product Manager
Microsoft.
Scott thanks for the lenghty comment! I'm not going to start an endless discussion. I've been doing .NET development since the first beta so I'm definitely NOT anti Microsoft! I actually love LINQ (to LINQ to SQL situation is a bit debatable however...) but with my posting I wanted to share my experience with Silverlight compared to Flex. I did this with a typical administrative application doing a lot of CRUD stuff (and hardly anything else). And my conclusion is clear: Silverlight isn't there yet (but I'm sure that the next version could already make a big difference!). But the status today: binding is way too limited, binary data communications are not an option yet (or did I miss something?) and bugs in essential components (combobox and popup) are just some examples. Oops - I'm forgetting the fact that this fantastic Visual Studio (which it is when doing non-Silverlight development!!!) often forgets to stop at unhandled exceptions making debugging pretty tiresome...
Your comparison is very specific. Try to parse a XML file into value objects with E4X (Flex) and LINQ To XML(Silverlight). Compare the number of lines coded this time and Silverligh will be the winner. Given that almost every RESTFULL webservice returns XML, this is an important win for Silverlight. I haven't even mentioned validating XML with schema's in Flex....
Alex I agree BUT I was actually referring to the development of an administrative software application. I'm sure you agree that I wouldn't start using XML if I can use AMF and typed objects for my administrative application. What I want to say is that there are always situations where one is better than the other but IN THIS CASE (and probably in most cases where someone wants to develop an administrative application end-to-end) Flex is the clear winner if we're talking FRONT-END development.
Parse XML to Object in Flex only take three lines:
var xmlDocument:XMLDocument = new XMLDocument(event.target.data.toString());
var xmlDecoder:SimpleXMLDecoder = new SimpleXMLDecoder();
var myObj:Object = xmlDecoder.decodeXML(xmlDocument);
that's all! And if you want you can code it in just one line:
var myObj:Object = (new SimpleXMLDecoder).decodeXML(new XMLDocument(event.target.data.toString()));
I there:
I found 3 serious lack on silverlight (as a developer viewpoint).
1) it is not compatible with linux (moonlight is still on beta), only windows and osx.
b) The silverlight code can be easily hackable, in fact to decompiler the code is so trivial, while is possible to do it flash/flex but in silverlight include even the comments.
3) is big in size.
There is an interresting implementation of a LINQ-like API in actionscript 3 for flex, check it out here: LINQ to Objects for Flex in AS3
Post a Comment