Currently i am working on developing one Warehouse solution from scratch, i am planning to build it in silverlight (as this solution will take around 8-10 months) and the programming will start from Feb 2010.
I need to develop this application for one organization. Certain parts needs to be accessed by public which we are planning to build in ASP .Net 3.5
Now i just wanted to start a thread here for pros and cons of using silverlight, some of them i have already analyzed
Pros :
Rich UI
Excellent user experience
Reduction of scalability concerns
New set of features like data binding, control template etc..
Speed of development (After initial learning curve..my experience says it is faster to develop it in silverlight)
Other rich set of features coming up with SL 4.0 (SL 4.0)
Cons :
Cross platform issues (moonlight is there but it may take some time)
Cross browser issues (Chrome or other browsers)
Learning curve
Any other unknown risk (As there are not many enterprise level application developed in silverlight...or may be i am not aware)
I have also got one link for Pros and cons of silverlight(here) some of the cons might not be relevant with SL 4.0
Also i am having one good link for comparison between ASP .Net Ajax with Silverlight (here)
EDIT :
I have also found Technical Article series in code project (Just Type # google "Adventures while building a Silverlight Enterprise application" and you will get it, i am trying to analyze this series as well)
Please add some pros and cons if you find as i am trying to analyze it from all the angles. It will be of great help if you find any whitepaper on it.
The Pros and Cons have to be weighed against your own requirements.
Rich UI
Compared to what? Its not really a Pro, other tools can deliver Rich UI, where does one draw the line that allows a UI to call itself Rich? A Pro can't be a Pro if can't be measured.
Excellent User Experience
That isn't a Pro either. I wish I could buy product that delvers such a thing out of the box. The reality is it's up to you to deliver the UX. E.g. Stackoverflow delivers an excellent user experience, it doesn't use a tool like SL and it's entirely down to good design not the tool (ASP.NET-MVC+various other tools).
Reduction of Scalability Concerns
Compared to what? Early ASP.NET Forms with extensive use of callbacks then yes. However plain old HTML with Javascript frameworks can deliver this same "Pro".
Speed of Development
Well that depends on how you measure speed and how you weigh the importance of the UX. Currently SL developement isn't any better at ticking off business function points than other tech like poor old ASP.NET Forms and is probably worse. However delivering those same function points with a slick, imaginative UI may tip the balance more in WPF/SL's way. In reality SL allows you deliver more UX with some (but importantly not prohibative) extra effort.
Other Rich Features in SL4
Only a Pro if they would actually add value to your requirement.
Cross Platform
Do you really have a Cross Platform requirement? Within a warehouse business how many Linux and Mac desktops are there? That should answer your cross platform question.
Cross Browser
Is this a Con? Does the company in question allow the use of a variety of browsers? If so which? You can compare that to the browsers SL4 supports and out pops your answer but its your answer not everyones answer. Isn't cross-browser a bigger concern for the Extranet-esq part of the app?
Learning Curve
In all of these factors what are you already versed in is by far and away the most important. I'm guessing its MS tools and in particular .NET, right?
If you're not familiar with WPF already there is some learning curve but its not very steep. However you should definitely make sure you take the time to perform some training projects before you even start designing your real product. That process should help you measure how long it will really take and whether it is really feasable.
Other Known Risks
SL is still very young and it won't sit still. Frustrating "issues" will eat time.
Other questions to ponder
What UX ideas do you have that can't be delivered by a browser?
Why deliver the app via a browser hosted app at all? A WPF application not an option?
Silverlight 4
Considering your timescales if you do choose Silverlight you should target SL4.
Since you are developing solution for the warehouse, you may need consider building a web service with wcf pollDuplex (basically push data from server to the client periodically), just a note on it: it is not (yet) a very scalable and reliable (prior to SL4). Default concurrent connection is 10 (if I remember well), and you have the option to overwrite this default number, however, I haven't find a way to dynamically change this number which turns out to be a scalability issue.
One cool feature I like about SL 4 is the added support of printing, now you have the built-in ability to print the content.
Anyone bulding an Enterprise LOB with a Silverlight client should take a look at John Papa's PDC video.
However, IMHO the initial release of RIA Services was too limited. Now that the next version is buit on top of WCF Services, and the endpoints can be switched out to make them more accessible by more UI clients RIA Service is probably a very sensible investment too.
Related
everyone, maybe on many occasions you have come across someone who has many winforms applications developed in visual studio. Well, in my case, I have a fairly complete system made in a winforms environment and I need to transfer it to the web since a client changed his entire team to use mac. Someone has a recommendation because I would not like to have to start from scratch to reprogram everything. I also did not bother the customer by asking him to install virtual machines.
In advance, thanks for any suggestions
Converting Winforms to ASPX aka Webforms? Probably not a good idea: Webforms is discontinued. I would prefer Blazor, that is built on ASP.net Core. With outstanding interface performances.
You don't have much of a choice.
this really comes down to two systems having VAST different architectures.
Even on the desktop? You can no more convert a complex FoxPro application to vb.net. Or convert a ms-access system to FoxPro. They all would have been built from the ground up with 100's, if not 1000's of little design choices based on the given tool set.
This is kind of like the difference between a car, and say a airplane. They are both machines for transportation. But even things like the seats. One (the car) might have big comfortable seats - power assisted tilt etc. The goal is comfort, and total over all space and weight of that seat is not all that huge of a design goal.
Now, take the design for a seat in the airplane. It has to be lighter, thinner, probably use more fireproof materials. So 100's if not 1000's of SMALL design choices along the way will result in a seat for that car, or the plane.
It just a seat, right? So, since the architecture between the desktop and the web is much like the difference between a car and a helicopter? then little of the 100's if not 1000's of design criteria you used to create that desktop application simply will not apply, and thus the work can't be salvaged.
However, if you had used WPF in place of win forms for the desktop application? Then you can salvage a LOT more, since both the web application and the desktop application will have "mark-up" used to create the form/display in question.
In fact, this is one reason developers will choose WPF over winforms. (it allows easier migration to the web). And for those coming from web development? They will find WPF forms and layout VERY similar to how they do web development.
And the other reason of course is now with css, HTML5 and a whole bunch of other new things for the web? Well, then web developers actually have MORE UI choices then the desktop now!. So, WFP is an attempt to leverage many/much of the web based new technologies into desktop development. So while winforms don't support a graphics in a button? WPF does support this - so does the web.
But, ask any WPF developer? The cost + time for WPF desktop applications is a LOT more work. And so is creating web based. Some claim they can develop just as fast with WPF applications for the desktop - that's not what I seen - and NOT even close!! You find for the web, as much as 2 times, and often 3-5 times the cost compared to desktop.
Now to take a huge application and re-write because of a few Mac's? Well, that is crazy. You would setup terminal services, and have those Mac use remote desktop to run that application. Thus, the Mac's don't need VM's or anything.
But, there is no automated conversion system, and like parts, sets and doors from a car? They don't work nor fit on a helicopter. Too much difference of a architecture is at play here.
I guess this would depend on the size, scope and estimated cost of the existing application. But to allow workers at home (remote), people on the road, and that of allowing Macs to use that software? I don't see why terminal services is not a solution - and that can be setup in less then 1 day as opposed to a whole re-write of the given application (to run on a few Macs? - doubt that can justify a re-write).
If you're asking how to take the code you wrote over the years to create Winform-based, rich user experiences and adapt it for the web, then you will be disappointed.
The best you can hope for is to have such a clean separation of concerns in your existing app that it would allow you to salvage all code that's not UI dependent and use it in the backend of a whole new application. Everything else will have to be rewritten from scratch.
If your client still wants to use your Winform-based app in a Mac environment, he'll have to use a VM.
Broad, sweeping question here...
Assume you have built an enterprise level framework with some rich client in the .Net (Microsoft) sphere, with a WCF back end. Now, imagine that that enterprise framework's UI technology is being deprecated in favour of UWP.
The choices for a front end replacement basically are: UWP, Web (HTML), or some other rich client technology.
How would you go about the decision making process?
I personally lean toward a rich client where the user base is a captive user base. I mean, where the users' IT department is happy to install the necessary runtime environment on the machines, etc. This is usually not a problem with Microsoft technologies, and this won't be a problem in about 10 years when organizations roll out Windows 10.
But, people are telling me these days that web has come a long way. People are telling me that JavaScript frameworks are becoming very sophisticated, and that low level JavaScript for basic data binding and the like is mostly unnecessary.
I have really been turned off by web solutions like ASP in the past, but I do understand that technology has moved forward, and I do understand that Microsoft have been working on ASP.Net v Next which might actually be good?
The question is not so much what would you opt for? But, what factors would you take in to account to decide which platform to go for?
Opnion based answer here...
In a decision to adopt a particular tech for any project lies in many factors. I can cite two majors for your particular scenario.
1 - Client adoption. It's easy for the customers to use/install it? They need to pay some sort of license? Can it run in all platforms/devices the customer already own?
2 - Market adoption. It's easy for you co-workers to adopt it? It's hard to find/hire experienced/hardened developers? We need to pay some kind of license? Can I trust it ill be a long lived technology?
The answer to your question can be HTML.
Not only it is already got a lot of momentum in market, it ill take years to change it even if today someone (big like MS or Google) put some new (better) stuff on the table.
Also if someone on MS marketing dep say next week Universal Windows Platform or WinRT must die it ill die (like Silverlight). So Im not adopting some new technology just because some big player told me to do it.
Yes web has come a long way indeed. You can do a lot of amazing things just with JS+HTML+CSS those days. Also the right usage/architecture of it ill allow you to put your app running in PCs, Tablets and Mobiles (at a minimum cost to port between devices) and capable in running in anything can access internet.
I suggest you to catch up and learn a lot about webservices, Json, JS libraries like JQuery, Sammy and some nice stuff like Knockout, SPA, Angular, Node, etc.
Edit, answer to comments
To not start a chatty comment I'll respond here. Yes your questions and comments brings interesting questions. To let it readable for posterity both of us can edit answer and question to organize it.
Silverlight. How not love it? In special after strugling with flash. It's a shame MS pulled the plug (die in hell MS CEOs). When MS let it to die I was planning a big web app SL was my first choice. Why I changed my mind? Well 2 years to develop that app and at the end how much browser ill get along supporting it? The SL community is great, the tool is great but browsers can just say, Hey tomorrow there's no guarantee it keep working.
.Net and MS platforms. I'm a .Net developer. I adopted it since beta, first to work with winforms (in a previous life I was a proud Delphi developer). After a while started to work with web. I also worked in classical ASP (bad times) and loved .Net ASP from start.
You can run .Net apps in almost any PC in the planet today. Not exactly true for all mobiles/gadgets. For browsers pure HTML+JS+CSS ill to better because it's lightweight (done right). Also we can move a lot of thing to client side and just let it hit the server only when necessary. .Net apps can do that, sure, but ill never be light as a tailored HTML+JS+CSS.
In fact I believe you can do anything with .Net and you can do amazing things if you got a few good developers in your team. But depending on the project it ill do better (and cheaper) in HTML or PHP or Ruby or Java, etc.
In fact at a previous shop, with both PHP and .Net teams we found (after 1 year study, metrics, lots of projects) small projects are better done in PHP, larger ones in .Net (if I remember a medium project can be 4k to 6k men/hours).
The point here is. You really must read a lot about HTML, CSS, JS, SPA, Angular, etc. Bringing to live a big and shinning web app is challenging today not because what we can do (we can do anything) but how we can do. DDD, MVC, MVVM. Testing framework, etc. Man Node is the future (the concept at least).
Web developing really changed in the last years and with it the clients and users expectations. Today no one ill wait for more than 2 secs for a page to load. Everybody wants usability to be at the top of the table from project scratch. You app must be responsive, etc. (not using Dilbertian management buzz words here for the sake of it. Just stating usability is that important today).
And don't forget everyone wants it to be beatifull (from a graphical designer point of view) even if it's a dull B2B supposed to be used only by cave mens.
Even if you stick to a classical .Net app learn about the (many) options, that can bring a new wider perspective.
I have decided to answer this question here because we've had a lot more time to investigate and look at different options. The original question turned out to be a bit of a furphy. Pure UWP and Web are not the only options. There is also a Xamarin Forms as an option which includes UWP, Android, and iOS. As a personal preference, I am leaning toward using Xamarin Forms as a client instead of any other development platform because it supports three OSs out of the box: Windows 10, iOS, and Android.
I believe the answer to the question is: you should only develop a web app if you need to. Does your user base consist of people who will mostly prefer a browser over apps? Are your potential users likely to want to avoid downloading an app? Is your app very simple, and you want people to be able to dive in very quickly? Are you able to get away without access to things like the camera, location and push notifications? If you can answer yes to these things, then I think you should go for HTML 5/JavaScript. If however, your user base is comfortable downloading apps, and you think that your app will require a UI more sophisticated than most browser apps, I'd recommend looking at Xamarin Forms as the preferred option. We've had very good success with Xamarin Forms so far, and the UWP version of our Xamarin Forms app has turned out just as good as our first stab at a UWP app.
Note: I should give Web Assembly (http://webassembly.org/) an honorable mention here. This technology is being considered in all the big tech organisations like Microsoft, Apple, and Google. One day, it may make deployment of native apps in a browser great again.
I work in a company which is primarily concerned with desktop apps not served over the internet.
Part of my value is I have a web based background and proficiencies in ASP.NET, JavaScript, JQuery etc.
The issue I'm having is that compared to a traditional desktop application building a rich web based app is more time consuming. This is understandable in terms of the hoops that need to be jumped through for web development. This is a cause of frustration for those not familiar with the ways of the web.
However because people are used to the non web world where I work I need to utilise every possible tool and technique to be productive as possible while building web based applications.
As such I'm looking for what other people do to be as productive as possible while making web based applications. I'm primarily thinking of ASP.NET (not using MVC) but apart from that everything is open.
The best tools for web development, in my opinion, are:
.Net Reflector
Firebug
IE Developer Toolbar
IE Tester and MyDebugBar
Fiddler
You should also look into NHibernate as an option.
The best choice of tools tends to vary quite a bit from one developer to another. It's also very dependent on the details of the type of application you're building.
For me, Visual Studio Team Suite is indispensable. It has a rich set of visual designers and other features that have a big impact on my productivity. Deep integration with bug reporting and source control is another huge time saver (I use Team Foundation Server).
With web forms, you can of course often use drag-and-drop components, which improves productivity for some people (although not me). I can't say I'm a fan of most third-party components. They can be quirky, take a long time to learn well, and then still not do exactly what I want them to. It's also a skill that often isn't portable from one job to the next.
You can leverage jQuery to help simplify scripting -- although even with jQuery I find scripting to be one of the most time-consuming and error prone aspects of web development.
If it's suitable for your environment, you might explore Silverlight. That way, you can often have the best of both worlds, building desktop-like apps using desktop-like tools, but with web-based deployment (Expression Blend is an awesome tool). You can also use Silverlight as a replacement for JavaScript in many cases, with code that's compiled and type-safe.
Good tools on the data side are critical, such as SQL Server Profiler. Visual Studio Team Data (part of Team Suite) is invaluable for it's data generation, unit testing and deployment and management aspects.
Something very underrated by many web developers is building up an appropriate infrastructure: things like logging and performance counters, that can help you track down problems quickly when they occur. A solid configuration system is also important.
In case it helps, I put together a longer list of tools. I also write about something I call the "ultra-fast approach" in my book, which is about more than just building web sites that run fast; it's also about how to build them quickly and reliably: Ultra-Fast ASP.NET.
You should use third party tools.
Telerik RAD Controls and the AJAXToolkit are two such tools available to you. They make much of the 'fancy' stuff built in.
Then, and probably preferably, use JQuery.
With those three options, you can make a fancy web application in the quickest way possible.
Finally be sure your UI and business logic is properly segregated so you can reuse your business logic easier.
There are several ways to increase productivity while building web applications, and they're not too different from desktop programming.
Code re-use. As a shop that is primarily desktop-based, this may not be an immediate option. But as you build your code-base, you'll find that you can use some of the code over for new applications, and even begin building your own customized frameworks.
Development tool knowledge. If a lot of the tools are similar, then you may see immediate benefit from this. If not, it may take more time as the team gets used to new IDEs, etc.
Third-party tools. UI toolkits, backend frameworks. These exist in both worlds, and could be utilized to help jump start development, until items 1 and 2 can be worked in.
A few must-have tools on the client side (i.e. the browser)
FireBug - let's you debug your javascript, DOM, headers, etc
WebDeveloper - provides all sorts of information about the rendering of the page
Selenium - Web UI functional testing framework + tool
(all are firefox add-ons)
Here's some of the tools I use for IE and FireFox, http://www.learn-ajax.com/blog/2008/04/debugging-tools-for-web-applications_03.aspx . Chrome, Opera and Safari also have their own built in client-side web development tools as well.
Most important tools for ANY productive development
Dual large screen monitors
keyboard and mouse that works for YOU.
Comfortable high-backed chair that will save you taking 2 weeks off for physiotherapy down the road.
This is not a pure technical question, but I believe answers will help the RIA community.
We are a software development company working on development of a stock trading product. We chose to use Adobe Flex (in mid of 2008) due to its browser penetration and its maturity relative to Silverlight. We already developed the system, and we are quite happy with it.
Now we are planning to launch the second version of our product, and it will feature a much more advanced user interface -- basically a framework of dockable windows and panes as in Visual Studio 2005 and onward, etc. We searched on the internet and found that the market of 3rd party components for Adobe Flex is still very small, but for Microsoft's Silverlight there are many advanced 3rd party components available e.g. data grids, docking frameworks, etc.
When can we expect the same type of components in Adobe Flex? What do experts think if we develop to the new version of Silverlight (Expertise in Adobe Flex vs. Silverlight is not an issue at the moment, assuming we have to develop everything from scratch).
The launch of next version is expected to be in mid 2010. Any feedback regarding this is highly appreciated.
I can tell you from direct experience that Flex is a more productive platform. I work for a large RIA consultancy that builds a large number of apps with both Flex and Silverlight and we see that equivalent functionality in SL takes about 10-20% longer to develop than in Flex. Data binding support in Flex is significantly easier to use than in SL. I can also tell you that a suitably-experienced Flex developer could easily build a MDI toolkit in Flex with a couple of weeks of development time. So I would advise you to consider hiring experienced Flex developers rather than shelling out money for SL components.
SL does have a big advantage in that C# can be used on both the client and server and business logic can be reused in both tiers. This is significant and should not be discounted. ActionScript doesn't have a server-side counterpart and lacks this ability, although Flex does play nicely with a number of different backend technologies, especially Java using BlazeDS. Silverlight services integration has a variety of options on the .NET side (see Bart's comment below) while Flex can use very performant AMF in both RPC and data push (messaging). BlazeDS is free and open source.
I also think basing your decision for a development platform solely off the availability of 3rd party components is not a great idea. Putting that aside, MS platforms have always had a huge number of component development shops and a wide variety of components to choose from. It's likely even with a smaller market share that SL will have a bigger selection of 3rd party components than Flex moving forward.
Finally, I don't think MS is going to be giving up on Silverlight anytime soon. They are aggressively developing new features for SL4 and the Blend tool offers some innovations for designer/developer interactions that even Adobe is struggling to match with their new Catalyst tool.
If you have to make the decision today, I'd say go with Flex, especially for a public-facing application where you don't want to lose users because they can't or won't install the SL plugin. In 12-18 months I'm confident that SL will give Flex a much bigger run for its money but I don't think it's there, yet.
Although I cannot give you the desired answer, I hope I can give you a couple of good questions and ideas that maybe help you in the process:
City Coder: Flex 3 versus Silverlight 3 in Enterprise development
Microsoft Silverlight vs. Adobe AIR/Flex Debate
I personally think, that Adobe Flash is going to lose a noticeable user base in the near future duo to new features in the upcoming html 5.0 standard. Furthermore I prefer the tools (Visual Studio), addons and languages (C#) over the Adobe equivalents and I would consider these superior. However I have to emphasis that this is only from my perspective.. :)
A few people in this thread assume that you can't develop Flex or Flash-based projects with Visual Studio. From 30th August, 2010 that is no longer true. You may want to look at Amethyst which is a VS visual (drag+drop) Flash Platform IDE with a multi-process debugger, IntelliSense and refactoring: http://www.sapphiresteel.com
best wishes
Huw
actually i am also thorn between the 2. in fact, i still considered Flash, but sort of struck that off because thats more for animations rather than RIAs. with Flex, theres AIR to enable deployment in both desktop and web, tho i havent tried it and dunno how easy isit to use. and i also am not sure if Silverlight can be used as a desktop app anyone?
comparing Flex and Silverlight, i dont think we shld just base our judgment on what is more widely used now. Silverlight maybe something good!
just starting exploring the 2 and find Silverlight's XAML markup more intuitive than Flex mxml. further more Silverlight will integrate with C# which is getting better with LINQ and all. so data binding, an important part of any RIA is better. for Flex, one can probably link up with something like PHP with AMF but seems abit harder from what i saw. that said i am not really familiar with both.
UPDATE: and Flex is open source now while Silverlight closed right? so Flex can be said to be cheaper to use.
One thing to consider is Microsoft's dedication to Silverlight. Silverlight is not taking off. How long are they going to stick with it? If the next version of Silverlight doesn't get significant market penetration, is Microsoft going to continue supporting it?
Even if they do stick with it, and even if it does take off, are they going to do like they did with Internet Explorer: develop it into the most awesome browser available at the time with IE6, and then coast for 5+ years and become a major thorn in developers' hides?
Silverlight doesn't have a lot to do with Windows. People using Silverlight does not make Microsoft much money. There's not an especially compelling business case for MS to push Silverlight.
Silverlight doesn't offer anything to the users that Flash doesn't. It's the users that are going to drive Silverlight adoption, and until there's a compelling case for me to install it on my computer (which it's not, incidentally), it's staying off.
Flex is a natural companion to Flash, which is one of Adobe's flagship products. Adobe's not going to drop Flex. Even if they did, it's entirely open-source, and Flex development could quite definitely proceed even if Adobe fell into the ocean tomorrow. (Flash runtime is not open source, unfortunately, but it's a quite good multiplatform implementation of a mostly open SWF standard, with open source implementations progressing)
I work in a .NET/Flash shop. We use Flex to talk to a .NET back-end. It can be a pain in the ass to get them to interoperate (although not impossible). I like .NET. It would be great to be able to develop our front-end in C#. I would love it. But we're not willing to bet the farm on Silverlight, given MS's technology parade.
One of the most important thing in our decision on our future RIA technology is RTL support (specifically Arabic). I am very disappointed to hear that Arabic(RTL) is still not supported in Silverlight 3.0, on the other hand it is now supported on Adobe Flex 4. and I don't want to apply all non-standard tricks again that we used in our existing version of application (which is based on Flex 3). so Now One problem is solved in Flex but still remains in Silverlight... and still no docking framework in Flex, so it is going to be stalemate I guess.. :).
I will keep you updated regarding any new findings of our research...
One word (or two) --> "Open-source"
The world is going open source. Think android vs apple
How will you run applications for clients on Linux platform with any amount of confidence.
Right now I am not a netflix customer because no "Moonlight" support.
I have three computers at home all running Linux (Cannot shellout money to buy Windoze license) !
Think target market (and where it will be in the next few yrs)
Flex is more compatible with browsers, as it runs on top of Flash. Silverlight, however, needs to be downloaded, which might be a problem for users behind a proxy or network (in a workplace, for example, you can't install things). Flex also has a better framework than Silverlight, so you can customize a component in a few clicks and keystrokes.
I agree with you that VS and C# are more mature than their Flex counterparts (FB3 and ActionScript, respectively), but you'll get used to it quickly.
Then again, I am a Flex developer, and not a Silverlight developer, so my opinion can be somewhat biased. However, I did choose Flex over Silverlight because I thought that it was more compatible (nearly everyone has Flash Player) and has better support than Silverlight, and I don't regret my decision thus far.
If it is a stock trading product, does it stream the stock price in real-time? If it does, the cost of streaming the data will make some difference.
Both of them support some kind of data push (RTMP vs. Socket) and smart polling (RTMPT/RTMPS vs. HttpDuplexPollingChannel).
Infrastructural cost: Flex uses LCDS/BlazeDS while Silverlight uses IIS.
Development cost: RTMP/RTMPT/RTMPS is already defined (and cannot be changed) while you need to define your own protocol for socket (you need to handle security and compression yourself)
From programming perspective, Silverlight should be better since XAML is drawing the interface and C# updates the state of XAML components. There are plenty of C# developers and Expression Studio to create the XAML components.
MXML is relative simple and you need Flash to draw the fancy UI. You can wait for Flex 4 (in beta) with FXG support, however. Then, it might get better support for third-party components.
If you have expertise on both products is hard to say, from my side having an IDE like Visual Studio is a plus (I'm a .net developer), and using the same language on server (services) and client side it's something that makes me feel quite comfortable.
I would say... go for a Proof of Concept, take a week, make two teams (same level approx.), and check in a week (without any formal testing, or formal designing) to progress in Flex and SL (for the third parties they can take advante of all the trial versions). After that week check how far the have gone and their findings.
A waste of time one week? Try to focus as a live wireframe for your final app.
Good luck
Braulio
I don't think I could speculate on when or if Flex will have a similar number of 3rd party components. Many of the Silverlight components developed by companies like Telerik and DevExpress are ports or updates of existing .NET components. You might want to do a survey of companies that develop components for other Adobe products and ask on their forums if they plan to release a Flex product. Aside from that all I have to go on is what's available today and it sounds like you've already done the research on existing technologies. Good luck!
I have worked a bit with Flex but being more .Net oriented I can't say Flex can get any close to Silverlight in terms of developing business apps. Specially with RIA Services V2 and all the suit of .Net framework and visual studio everything is so integrated and professional.
The only reason I would consider not using Silverlight is if the product has public audience and you are going to loose customers due to low penetration of silverlight.
Ther is flex dock : http://code.google.com/p/flexdock/
And there is dock able flex : http://code.google.com/p/dockableflex/
I'm working on a project that currently has zero users but we would like to scale up to potentially hundreds. Currently we are running on a MySQL database with AMFPHP interacting with Flex. We used Flex because of its robust graphic features (important to this project) and because the initial developer (not me) already knew ActionScript. We are currently using AIR but might switch to web-based Flash at some point.
My questions are:
Is Flex a good tool for a project like this?
What are the main limitations of Flex that we might encounter?
What are other development platforms we might want to consider?
Thanks.
- Dave
Short answer, Yes. There are already many prime-time Apps using Flex as their UI development platform. If you go to the Adobe site they showcase quite a few.
Speaking personally, I chose Flex for two reasons, first was that, although you probably can do much of what Flex does in HTML or with an appropriate toolkit, Flex is designed for attractive and compelling user experience and has available all of Flash. Plus the development environment and available widgets make it easy and fun to program. I don't want to spark a religious war about HTML vs. Flex, so I'll leave that there - it works for me and my application and customers.
Second, and more important, was that it balances the processing load more towards the client which means my server architecture can be optimised just for serving the content and persisting the data. Most of my business logic has migrated across to the client. Having spent many years in classical architectures I think this is a huge step forward, but I can already her a chorus of disagreement about that too.
My word of caution about Flex comes from needing to adopt the right architecture for your client code. It is pretty easy to create a huge and badly performing app with Flex if you get that wrong. Make everything event driven and apparently asynchronous and you should be OK ('apparently' because the Flash player is single threaded). And that is downside 1, the single threaded Flash player sometimes causes issues.
Downside 2 is perhaps more serious and that is locked down desktops in corporate environments. Quite often your target audience won't have administrative rights to their computer and will have either the wrong flash player or none at all. This is particularly true in public sector organisations and the military, so if you are heading there I would test carefully the presence of Flash amongst your users.
Other than that I heartily recommend Flex. It's also a great thing to have on your CV!
HTH
Flex has no inherent scalability problems, however if you have a graphic intensive application, proper serving of these resources might be a problem, but that has little to do with Flex.
The only note-worthy and likely platform you won't be able to run on is the iPhone (no flash) and some older non-flash mobile devices (although most support Flash-lite nowadays)
As for alternatives, if you are Graphics heavy, and don't mind the iPhone, then Flex is good if not best cross platform solution besides using pure HTML technologies, the trick here is HTML alone can do 99% of what Flex can do, but if your App requires the missing 1% then you're out of Luck, also Flex will reduce crossplatform and most browser compatibility issues. So it might make your work more productive.
Silverlight 2 is an alternative to consider. WPF if you're looking for something with offline support.
Yes, the scale and type of project
fits.
Immaturity of frameworks and libraries you might depend on. Immaturity of IDE's.
Silverlight, JavaFX.
Flex + AIR is probably as good a tool as Visual Basic was; it may be a better tool for having a much more flexible programming language and having free development tools, but keep the limitations in mind....
The main limitation I've seen from working with it is documentation. There seems to be not enough documentation, not good enough documentation, and not enough high-visibility work on it in the community. (This is coming from years in .NET; I've been constantly upset with how little MSDN says about methods but generally able to deal with it by finding the most useful blog posts.)
Other possible development platforms would depend very heavily on the specifics of the project. Web-based platforms bog down in deep, stateful interactions with data sets (even with nice AJAX libraries), whereas maintaining client-side installations of any thick client program (say, Flex + AIR) might be overkill if it's just a few CRUD forms.