I've been programming for over 15 years and started with .NET 5 years ago. We built our framework for windows data-oriented apps and it is a quite stable.
At this point, we are considering to make a new platform. But, I am a little bit confused with all these new technologies. We considered CAB and SmartClient technologies but there are also WPF, WinForms and Silverlight options in there.
It sounds like you just need a quick overview of the technologies you have outlined there.
WPF: Windows Presentation Foundation - a new graphical rendering system for building interfaces based on the XAML markup language.
WinForms: Windows Forms Applications - Visual Studio's classical drag-drop GUI.
Silverlight: a Web Application framework - usually used with WPF, very similar features
ASP.NET & MVC: ASP.NET is the web application framework used in conjunction with C# and VB.NET used and MVC stands for Model-View-Controller - a design pattern that has actually been around for ~30 years
Without knowing the true intricacies of your framework, what you need it to do, what limitations you have - I can't say X would be better than Y - especially seeing as WinForms and WPF is used for desktop applications, and Silverlight, ASP is used for web applications - unless you're thinking of linking these in with each other? You haven't given enough information in your question.
However, the best for investing in the following 5 years? The most recent and still in development technologies are WPF, Silverlight and the ASP.NET MVC - but nobody has a crystal ball to say whether these will still be alive, kicking, and technologically advanced in 5 years time.
We built our framework for windows data-oriented apps and it is a quite stable. At this point, we are considering to make a new platform.
For your specs, all choices might be very good :)
I know that, but what you think is the best for investing in the following, let's say, 5+ years?
If you have a choice ( meaning if you are just displaying data without all the fanciful animation, movie and game like stuff), use ASP.NET MVC.
I always advocate web applications over desktop ones, because web apps are hosted in a single place, and so they won't produce upgrade nightmare.
In terms of which one has the brightest future, well, none of us have crystal ball and we don't know what Microsoft will throw at us in a few years time. But you should orient your apps around your business, not around fashion. If you really ask me out of the so many, which one will still remain standing 5 years later, I would say ASP.NET MVC, because ASP.NET is a mature technology, and MVC is a tried-and-true design pattern that has been used by open source and non-MIcrosoft companies. The fact that it is widely accepted makes it less likely to fade out of fashion.
If you want to continue with creating desktop applications, then your two major choices are WinForms or WPF. WPF is the "hot" technology right now, but there are a few things to consider before choosing it.
WPF requires .Net 3.5 (maybe it's 3.0, but whatever). This is significant because many corporate customers are still using .Net 2.0, and may not authorize upgrading to 3.5 for some time (my former company still has some clients that haven't authorized moving from .Net 1.1 to 2.0 yet). Also, the installer for .Net 2.0 is 23 MB while the installer for .Net 3.5 is close to 200 MB, and the 3.5 installer appears to be buggy, failing occasionally with a helpful "SETUP Error" message.
Developing with WPF requires Visual Studio 2008. If you're currently using an older version, you'll have to upgrade.
This isn't completely true, but for the most part what WPF brings to the table is a much snazzier user interface. In my experience, corporate customers who are paying big bucks for custom software do not care in the slightest how the application looks - they only care that it functions well and that it ultimately saves them money.
Finally, if you already have experience developing desktop applications for Windows, then you will feel right at home going the WinForms route. Also, because of the Mono project, a WinForms app can (theoretically) work on other platforms like Mac, Linux and the iPhone, whereas this is not yet possible for WPF (I might be wrong about this, and I will happily correct myself if someone points it out).
I'm actually sort of torn about this advice, because I think WPF is very cool and powerful, and it may take off and become the only viable way of developing for Windows very soon. It is a risk, however.
Thank you all for answers !
We tested all platforms and we have at least one project finished using MVC, WPF, Silverlight, WinForms...
The main problem with WPF and Silverligth is missing of native ReportVIewer controls since we have a lot of reports (RDL) created.
Personally, I think also that MVC is best structured framework.
I really have positive thinking of MONO. But, I would rather decrease the price of the project so the clients can buy WINDOWS but to handle bugs in Mono-Linux option.
We decided to follow the Microsoft way.
I'm thinking of some kind hibrid framework (Webservice - SQL SERVER- ADO .NET Entity Framework) to be on hosted on server and hibrid CAB-SMARTCLIENT to be usen on clients.
I really miss the times where only one tool and technology was available like Levi's 501 :)
Related
I am trying to evaluate whether Xamarin would be a good option for my project. The project is a large, complex app for Android and iOS with a lot of client-server communication. The user interface is a major focus and has to be really fast and smooth. Also, we plan to make large use of UX graphic effects (comparable to the Spotify app).
For now we are planning to go for two separate native apps using Java/Objective-C. However, the possibility of cross-platform code sharing would be very convenient for us of course.
Most opinions I've heard so far say that Xamarin - although far better than HTML5 apps - cannot match the UX of a native app. Also, I tested the following applications made with Xamarin (on Android):
Rdio
MarketWatch
Busch Gardens Discovery Guide
Sqor
Storyo
From my impression, none of them could quite match the speed and smoothness of a good native app.
If our focus is on a top notch user experience, would Xamarin really be a viable option? Can it really match a native UX? I am particularly looking for opinions from developers who have experience with large and complex cross-platform Xamarin applications. A few critical voices would be very helpful.
Thank you a lot!
I'm on the Rdio mobile development team, so I can make some personal reflections from that standpoint.
Xamarin allows you to write native applications in C#. Any slowness, jankiness, ugliness or bad-appiness usually has nothing to do with the Xamarin layer itself.
You save some time being able to share core business logic between your different clients, but you're still writing the UI from scratch, specific to the platform. You're just writing it in C#.
But while you save that time, you're spending it in other ways. All of those SDKs you want to use probably aren't compatible with Xamarin out of the box. You won't be pod install'ing that iOS framework, and you might be reinventing the wheel for handfuls of things. Xamarin takes advantage of the NuGet repo so you have a library of components that handle many of the things most people need (Analytics, Testing, Facebook SDK, JSON parsing, Database, etc etc) but it doesn't cover everything. And it certainly doesn't cover stuff that's out the day of an Apple or Google product announcement.
Any 3rd party code that you do want to import into your project will be done through writing custom bindings. While not usually difficult, it is time consuming. Xamarin has a team of people that specialize in assisting you in this. This fact speaks to the process being messy at times.
So while the slowness, jankiness, ugliness or bad-appiness probably isn't the fault of Xamarin, it might be the fault of you spending time in places you normally wouldn't, or not being able to take advantage of features you normally would. If that 3rd party partner SDK is giving you problems, your troubleshooting may take twice as long because there's a layer that you don't control.
UI is a wash. You're writing it from scratch anyway.
Business logic is shared. Depending on the app that might be a win if you architect your application to take advantage of it.
Compatibility / bleeding edge ability will be lacking. That might not matter to you at all, or you might be the person wanting to take advantage of that hot new API in the next OS release the day it's announced.
My personal thought, without knowing specifics, is if you want to build an application that you plan on being around years from now, and that will take advantage of the latest and greatest, I'd tell you to write natively for each platform. Unless you can really see huge gains in sharing that business logic the upfront gains are minimal. Or if you really like C#.
Xamarin uses native controls. So you design a fully native UI per platform. The users can't see that your App is made with Xamarin or Java/Objective-C.
There are sometimes performance issues in conjunction with the platform independent UI wrapper Xamarin.Forms. But you're not forced to use it. When you have still performance issues in your Xamarin.Android or Xamarin.iOS app then you produce them in your code.
There are benchmark results for Android apps comparing Xamarin.Android and Java apps: Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?
As you can see Xamarin's internal performance became better and better over the time.
Conclusion: Yes, you can write smooth native Apps using Xamarin.
Thank you in advance for your assistance.
Our team has been spoiled by MS P&P Enterprise Library/Unity as we have made great use of the DI, Exceptions Management, Validation and Logging Capabilities. Traditionally, our front ends have been forms based (Windows Forms, ASP.NET, etc).
As we approach WP7 development, and understanding it is a new platform with much less resources, we are looking to leverage existing frameworks, open source, etc that may exist that deals with these issues on the WP7 client (excepting copy left licensed code).
We are definitely going to implement Prism on WP7, and have started our initial research into the Prism framework capabilities in these areas. It's a great framework, and our initial assessment is that is for legitimate reasons it is more focused on the composite architecture, and we need to use Prism as the architecture to do a little bit more implementation on our own of cross cutting exceptions management, etc capabilities building on the baseline that Prism provides.
Just wanted to confirm, as we have not been able to identify any, that there are no open source or other frameworks out there for WP7 with the Enterprise Library coverage on exceptions management, validation and logging?
Thanks again.
WP7Contrib has lots of support for logging, DI and (much) more.
well you could use Caliburn Micro
Global handling exception in WPF app with Caliburn.Micro
not sure if this goes down with the PRISM well though
22 sept 2011
there is siverlight integration on the enterprise library http://msdn.microsoft.com/en-us/practices
This is a two part question:
I would like to know where does Oracle ADF 11g stand as a framework to develop / deploy Web / Java EE Applications as compared to other frameworks.
How much is Oracle ADF being used as a framework to Develop Web Applications.
I am asking from a perspective that whether or not there are good job opportunities as an Oracle ADF Developer and what the future looks like for those holding Oracle ADF skills.
Also as Oracle plans to use ADF as core technology for Fusion Applications, Is it good time to build Oracle ADF skills as a siebel developer? As the future Oracle CRM Applications like ERP, SCM will be based on ADF should developers start building ADF skills. Around when will customers start implementing those applications based on ADF. Will these be available On Premise or mostly On Demand in SaaS way.
We have chosen Oracle ADF in our company for one of our projects. Sadly, this proved to be a big mistake. I personally have used Oracle products, in particular their DB, but as far as fusion middleware is concerned, I would advise you to stay away from it. ADF was by far the worst framework I have ever used as an architect. Some of its features I noticed are: very complex, Oracle just "invents" or forces some development approaches that have been proven as a bad practice by the Java community years ago. ADF is very slow compared to other frameworks. With being slow I mean ADF pages run slow. The reason for this is extremely complex generated html and javascript. You can check this by opening up Firebug and inspecting the generated html...it looks like something from the 90s...Terrible. Not to be overly pedantic, but ADF pages have huge amounts of validation errors causing problems in making them run on all browsers. The architecture of ADF is, in my view, messy. Struts2 for example is a much cleaner framework which makes it very easy to integrate it with 3rd party libraries such jQuery, etc. Oracle advocates ADF as an MVC framework but frankly I failed to see the actual MVC architecture there.
ADF uses its own javascript libraries, which are huge, practically impossible to modify, unoptimized and slow in comparison to others such as jQuery or Prototype. The emerging trends in J2EE are lightweight pluggable frameworks that are easily integrated with other tools such a Spring for managing dependencies, jQuery for scripting, CC for continuous integration. ADF is a heavy-weight tightly-integrated framework with other ORacle tools, which makes it very difficult to use it any other way than Oracle devised.
Not to mention the development tools that you are forced to used when developing ADF - the JDeveloper which is very buggy and crashes regularly. Developing in Eclipse is problematic, because ADF has numerous "specific" files which JDeveloper generates automatically.
All in all...ADF was a huge disappointment for us. We spent months messing with it, when finally our client decided the application was too slow and difficult for them to support it and the cancelled it altogether.
Based on my experience i can only say stay away from it. Choose one of the more supported and architecturally clean solutions such as Struts2 or Spring.
I have used JDeveloper 10 and 11, both with ADF, on two enterprise ADF projects for a prominent defense contractor. I agree that ADF is complex, but disagree that JDev crashes frequently, or that the pages are slow to render.
Now... why ADF? Read Oracle's synopsis below, stating that JDeveloper and ADF make Java EE development more accessible to "business" programmers. While this does not guarantee elegant programs, it does almost certainly guarantee that, when these developers get into trouble with ADF, they will probably be utterly lost and will have little idea how to open the hood and reach inside. Conversely, they would be lost even sooner trying to integrate the current J2EE open-source cornucopia.
THE SERMON
Source: ADF Developer's guide (paraphrased)
"Since the early Java days in the late 1990's , the Jave enterprise platform has grown massively and today is used by a large community of developers. However, the developer community is not homogenous and includes developers who are not expert Java programmers, but are business developers who have core competencies in their industries. As the Java EE platform and community grows, the average programmer skill level is declining.
It's hard to imagine that there is a single developer who understands all aspects of the Java EE platform in depth. The problem to address in Java EE is to provide a technology that empowers developers to build cutting edge web and SOA app's without limiting their agility.
Existing Java frameworks such as Struts, Spring, JSF, EJB, GWT, etc are blankets pulled over areas of complexity that expose simpler controls to work with. Using frameworks, developers no longer work with the java core API's but instead interact with interfaces and services exposed by the framework.
Blah, blah, blah...
What seems a small problem for experienced java developers is another hurdle for business developers who are new to java and EE development. This type of developer may turn to a a single dev environment promising integration of all aspects of app development in a single technology chouice. Developers from a 4GL desktop dev background might be attracted by PLSQL, .NET, Adobe Flash.
An experienced Java developer might see this a a big mistake, but how would those developers know, unless Java too provides a single solution for them? The solution is an end-to-end framework which pulls another blanket over the technologies, one that combines different framewokrs and technologies into a single product that exposes visual and declarative development gestures as it's predominant programming methodology... ADF."
I have been working with ADF since last 6 months, and i realise that ADF is made particularly large application with strong database integration. I haven't seen any other Framework which can provide you with so fast and easy development of database rich applications.
Yes i agree that it have some bugs, but still it works well if you know how to work with it.
My perception of and experience with ADF is that it is a very solid and robust framework (unfortunately, the development tools are not.) I'm not sure there's much competition to it, at least, not from a single framework. ADF itself is really several different frameworks combined over the years into a mostly cohesive product. Now that Oracle owns Java, i really expect (hope) parts/much of ADF finds its way into Java EE-proper so we can maybe see alternative implementations and better development tools. If that were to happen, it'd pretty well solidify ADF's future (as long as Oracle doesn't screw the Java community in the meantime and push them to alternative VM platforms).
If you are already familiar with or want to work with Oracle(-related) products, ADF is what you want. Given the market penetration of Oracle, it's probably a reasonable bet that they'll remain dominant and your skills will remain marketable for years to come. Oracle is spending lots of money and acquiring lots of companies to try to own and retain the enterprise.
The SaaS question, to me, is a little harder to answer. While it does seem to be moving in that direction, it's not clear to me if it's mostly marketing's attempt to give it that push or if business-need is driving it. And there are lots of questions i don't really track such as business trust of the cloud for critical data and reliability.
Short answer:
You developing Enterpise solution, your product vendor is Oracle - ADF is a best choice
You indie developer, your solution is not for enterprise, you not going to use other products in the Oracle stack - ADF is not for you, look for another framework.
Long answer:
If you going to Enterprise, if your general product's stack vendor is Oracle. Your best choise is to go along with ADF. ADF becomes better with each major release. I've started using ADF since 11.1.1.2, had a look at 10.x and now using 12.1.3, while still supporting large enterprise applications on 11.1.1.6.
I see a huge improvement and its really hard to find another product that provide better integration and support for whole Oracle stack.
However, if you quite familiar with other framework or/and not going to use other Oracle products and/or your customers can't afford to pay quite a lot for ADF/Weblogic/DB/ECM etc.. - your best choise is to avoid ADF. Its good for large enterprise solutions.
Yes, in fact actually you can develop using free and limited version of ADF - Essentials, use other app server as tomcat or glassfish, but you'll be better off with the other framework. ADF Essentials is only kickstart to large enterprise world, not a solution for small lightweight application.
Development in ADF is a pain in the heart. For a newcomer, the learning curve is too steep. I wish it could be more like learning dot NET.
From my perspective, learning and constructing a functionality in dot NET takes a quarter of the time to do the same in ADF. Of course, it imbalance reduces as a person learns along, but that's pretty much the scenario for beginners. It's frustrating.
I have been working with ADF since last 3 months, and i can tell you that ADF is a really suitable for situations which is essential to provide fast development process for large enterprise applications with strong database integration.
Compairing to other JavaEE framworks like Spring,
It is extremely complex when fixing bugs becasue of the architechtur of the ADF and lack of dev community relative to Spring. Spring has large development community
around the framework.
It is hard to impliment MVC architecture with the ADF inter component integrations.
Spring Developers have much more reputation and demand compared to ADF developers.
ADF is very slow, heavy-weight, tightly-coupled compared to Spring and integrated framework with Oracle tools.
Hope this will help you to solve your problem and gain your knowledge. Happy coding!!!
What I want to create is a Silverlight app with a few tabs/modules that will all be separate DLLs.
I see PRISM has the Shell/Module concepts that seem directed towards doing UI and I find a nice demo (showing how to search digg/twitter).
But it sounds like MEF will be included in VS2010 so I would like to go with that option.
Can anyone somehow clearly explain the differences? (I am not a advanced programmer)
MEF and Prism serve two very distinct goals.
Prism is basically guidance for designing composite applications - where you have a shell and "regions" that are dynamically assigned, and integrated. It includes an IoC container (Unity) that it uses for it's injection.
MEF is a dependency injection framework - it's main goal is to "fill in" depedencies at runtime for an application. In this respect, it's filling the same goal as Unity does within Prism (and, in fact, you could pretty easily rework Prism to use MEF instead of Unity).
Prism fills a broader scope, in some respects, but is also really limited to GUI applications. MEF is just doing one thing (Dep. Injection), but geared to be more general purpose, for any type of application.
As for the lifetime of these products -there is no answer here, but this is kind of how they're being developed:
Prism was developed by the Patterns and Practices team. The goal isn't to necessarily make software, but to provide guidance. As such, they update (although somewhat infrequently) the Prism library and sample, but Prism isn't a core part of the framework shipped by Microsoft. It's really a third party library (even though MS funds a lot of it, most of the P&P people aren't MS FTE).
MEF, from the blog posts, sounds like it is planned to be integrated into the framework, and be used directly inside of MS projects. As such, it's getting heavy development, directly from Microsoft, and being used in their products.
I, personally, have read through the Prism documentation (and have the book), and have gone through the samples. It is very helpful to understand how to break apart an application, but it really is guidance more than a complete, usable framework. The samples are very good at doing what they're designed to do - educate an architect in how to design a composite application.
If your goal is to just keep a clean separation of concerns in a silverlight application, I'd focus more on learning MVVM than necessarily just using Prism.
If you want to use MEF, there are other good options. For example, the WPF Application Framework is an entire MVVM framework built on top of using MEF, and fairly nice.
Basically, MEF is a general-purpose extensibility framework:
If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.
whereas Prism is mostly for building GUIs:
The Composite Client Application Guidance is designed to help you more easily build modular Windows Presentation Foundation (WPF) and Silverlight client applications.
So MEF and Unity are basically the same...
Well, not exactly. MEF is more focused on extensions which aren't known at compile time, while IOC containers generally focus on dependencies which are known at compile time. The top answer to this question gives a good explanation of the differences.
Yes. Check these two posts for more:
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
http://blogs.msdn.com/dphill/archive/2009/12/09/prism-and-mef.aspx
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Ajax, Flex and Silverlight are a few ways to make more interactive web applications. What kinds of factors would you consider when deciding which to use for a new web application?
Does any one of them offer better cross-platform compatibility, performance, developer tools or community support?
Here's a quick rundown of each area (with lots of helpful links):
Cross-platform compatibility
Ajax works in any modern browser that can run JavaScript. Flex requires Flash or anything else that can handle SWFs but, once that's installed, it's a total freeride as far as compatibility. Silverlight is tricky and misunderstood so carefully consider your userbase before going with this MS foray into the rich web applications arms race. Also keep in mind that Silverlight is still in Beta, so it may become more widely used and installed in the future as it is developed.
Performance
I'm fearful of making too many statements about performance because it really depends on how much you are willing to optimize and the exact nature of your application. Also, some technology stacks are just never going to be very fast. Some people out there have been making comparisons, but again, it depends on a great many factors (even the version of the browser from which you are testing!). It's probably best to choose based on other factors and optimize once you've started to develop.
Developer tools
There are the "golden standard" dev tools for each of the three:
Ajax has basically unlimited options, depending on the rest of your technology and architecture choices. The big questions you're actually faced with are which libraries to rely upon, and Google has voiced a pretty well adopted answer with things like Web Toolkit. When you get right down to it, it's just XML and JavaScript, right?
Flex is from Adobe and, just like with Flash development, you'd better stick with their homegrown tools because--well--they're making the standards as they go along.
Microsoft has positioned Microsoft Expression Blend versions 2.0 and 2.5 for designing the UI of Silverlight 1.0 and 2 applications respectively. Visual Studio 2008 can be used to develop and debug Silverlight applications (from Wikipedia).
Community support
There is both official and unofficial community, corporate, and open-source support for all three options. Whichever you are already integrated with and which makes you feel most at home are very individual things, but I'll offer this advice: stick with what you know. If you are a MS developer and have MSDN as your homepage, you are probably going to think the Silverlight documentation and forums are really helpful. Flex has a very similar story; the forums are pretty good and if you're a Flash person already, you're going to be right at home with their documentation and user community.
On the other hand, Ajax is basically all over the place because you can implement so many different ways and use so many widely-varied libraries. Each library can have it's own forums to visit and mailing lists to lurk within for answers.
Once again, all three have corporate giants trying to foster their communities and to get the best support possible to the developers that will give them greater market share in the future.
The choice should in my opinion be mostly based on the nature of the application you'll be building (for example, if you need to manipulate vector graphics, Ajax is pretty much out), but here are some general guidelines:
Ubiquity
Ajax -- Supported by all modern browsers across platforms
Flex -- Runtime (Flash Player) has very wide installed base for Windows, Mac OS, Linux. Linux version was a bit buggy the last time I checked, though
Silverlight -- Runtime has quite low installed base (and no Linux support) at the moment
Choice of programming language
(Unordeded because of subjectivity, but note that Silverlight offers the most choice. Also note that the existing language experience of developers in your team should be taken into account.)
Silverlight: Any .NET language (C#, Visual Basic, IronPython(?), IronRuby(?)) (and XAML for UI definition)
Ajax: JavaScript (and XHTML for UI definition)
Flex: ActionScript 3 (and MXML for UI definition)
API Stability and compatibility
Flex -- Runtime is the same across platforms and browsers, more mature and stable at the moment than Silverlight
Silverlight -- Runtime is the same across platforms and browsers, less mature than Flex/Flash, v2.0 is still in beta
Ajax -- Compatibility problems across browsers (may be mitigated via Ajax libraries, though)
Web/Browser Integration
Ajax -- Content is native inside browser, based on standards: searchable by browser and search engine crawlers, subject to any standard UI practices the browser and operating system have established
Flex and Silverlight -- Content not native to browser (i.e. runs in its own little "sandbox/rectangle"): not necessarily subject to established UI practices for the given platform
Developer Tools
Ajax -- Your favorite code editor, browser and debugging toolkit for the browser
Flex -- Flex SDK is available for Windows, Mac OS and Linux for free and can be used with your favorite code editor. A Command-line debugger is included, but the Adobe-provided profiler is only available in the commercial Flex Builder IDE
Silverlight -- AFAIK, The SDK is available for Windows for free and can be used with your favorite .NET development tools
The web runtimes like Flex and Silverlight all offer enticing things, but come with two big costs:
They run only within a rectangle on the page, and don't interact with normal web widgets
They are only available to people who have that plug-in installed
Even the nearly-ubiquitous Flash isn't installed on every web browser, so by choosing to use a plug-in runtime you're excluding part of your audience.
In contrast, JavaScript (or Ajax) is available on pretty much every browser, and interacts better with normal web pages, but is a more primitive and restricting language. Using it for complex animations can be tricky, and you'll need to test your applications in more versions on more platforms to make sure it works.
Cross-platform compatibility isn't the issue it used to be, so the issue is this: Will you gain more in the features of a plug-in library than you'll lose in the audience you exclude?
My own answer has so far always been JavaScript/Ajax, but I'd re-evaluate that in any new project.
What is your audience: public web site or an intranet business app? Adoption rates are not relevant if you have a controlled audience who will install what is needed to run your app. However, if you need the largest possible audience to make your web startup a success then it may be critical.
What is your goal? Building something for the lowest cost? Learning new technology?
Can you leverage your existing skills? If you already know .NET then Silverlight gets a boost. Learning Flex may be interesting and useful, but is it more useful to you than more experience with .NET technologies? Remember to consider the opportunity cost of learning something totally new.
I don't see a clear technology winner at this point, and likely there won't be one for a long time, so the choice will come down to fairly subjective factors.
Other than what's already been mentioned here, another huge thing to consider is what your UI is going to be.
If you're going to be using a lot of advanced UI controls like trees, lists, tab controls, etc then consider the following:
JavaScript/HTML - No native support for anything beyond things basic drop down boxes, buttons, and text fields. If you want something like a tree control or tab control then you'll have to roll your own or find a third party library.
Adobe ActionScript - Native support for a wide array of advanced UI controls
Silverlight - 1.0 had very limited UI controls, but 2.0 will be adding many more and I'm sure we'll continue to see controls added in future releases.