|
Pete O'Hanlon wrote: Sadly, the reality often falls far short and there's just as much pain in supporting said application, having followed a vastly increased development time as you spend so much time working round web app limitations.
Same thing happens in desktop apps. Count the calls to DoEvents() in a legacy VB app, and you'll get a feel for how much time the author spent fighting, rather than working with the threaded, event-driven model of Windows desktop apps...
|
|
|
|
|
Shog9 wrote: Count the calls to DoEvents() in a legacy VB app
No I won't. 
Seriously though, I agree with Pete, browser development is seriously limited, it is supposed to be. That is not at all comparable to the limitations of the Programmer using the tools.
The invention of the Web and Browsers was never intended to be used as a replacement for client/server desktop applications. The pains we are currently going through is no more than squeezing a balloon where we transfer the problems associated with installing/maintaining local software to a whole new set of problems that are generated using browser development. The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches.
There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit. I am fairly confident that history will view this as a an all to common failure.
|
|
|
|
|
led mike wrote: The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches.
Sure they do. Or rather, they can - don't think of it as HTTP+HTML vs. C++ native app running as root/admin, think of it as a VB app running as a limited user: you've accepted certain limitations in exchange for a framework that lets you do certain things more easily / provides extra security for your users / etc. Folks did some rather complex apps with VB, but still the framework was never designed for multithreading, access to system APIs, etc. In both cases, as soon as you step outside of what was easy, what was envisioned by the designers (data-entry forms / static text pages...), things got weird and difficult.
led mike wrote: There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit.
IMHO, the primary difference with the Web stuff is that we're not in control. After decades of writing apps that - given the right choice of language and library - could pretty much treat the user's system as their own private playground, we're back to writing server software that has only very limited control over the terminals it must use for interacting with users. You really can't publish system requirements for a web page if you want it to have a broad audience; for an internal app, you might be able to mandate a certain browser version and perhaps also screen size and color depth, but ultimately the user still has final say over more factors than you do, and if you don't accept that then both of you will suffer for it.
And... I love it. Because the truth of the matter is, for every desktop app that understood the responsibility that came with the power to control everything, there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways, place arbitrary restrictions on how i could use the app itself, or fail to play nicely with other apps. It's forced developers to learn to write scalable software, after decades of "threads are hard, let's call DoEvents" attitudes. And it's put the users back in control of their own data and their own hardware.
led mike wrote: I am fairly confident that history will view this as a an all to common failure.
History is notoriously cyclical. Plenty of perfectly good mainframe apps ported to the desktop without improving performance, data-entry efficiency, or reliability (although there was plenty of opportunity to achieve all three...) just because desktop apps were Teh New Hotness. Plenty of perfectly good text apps turned into GUIs for the same reason. And now, we're seeing web apps replacing perfectly good desktop apps... including some of the same sorts of applications originally written for now-ancient terminals.
Pointless re-writes and counter-productive redesigns didn't start with The Web, and certainly won't end with it... I'm willing to bet that right now there are teams of programmers re-writing perfectly good web apps in WPF, Silverlight or Air. C'est la vie...
|
|
|
|
|
Shog9 wrote: there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways
Agreed. I guess I am looking at it from a developer perspective of being forced to deal with all the limitations of a browser based scenario because of management decision based on nothing. Then after all that extra work they change the requirements to included writing files to the client machine and want the application to run in offline mode, yes from the browser. Keep in mind that there is almost zero level of real server based activity (like a database) in this application.
It's just a giant Dilbert environment that I work in. No amount of stories can help someone realize the level of stupidity that we deal with on a daily basis. You absolutely have to be here to even begin to grasp it.
|
|
|
|
|
led mike wrote: It's just a giant Dilbert environment that I work in. No amount of stories can help someone realize the level of stupidity that we deal with on a daily basis. You absolutely have to be here to even begin to grasp it.
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
Pete O'Hanlon wrote: you spend so much time working round web app limitations.
What limitations?  Our LOB web app doesn't have any, i.e. we don't need any local file access etc. The only potential limitation is that it requires JavaScript, covered by our requirement of FF with JS enabled.
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
It's the joy of things like Session, round-trips, page navigation issues and the likes.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
We use one page in an IFrame that is loaded for the entire session. JavaScript shows and hides various forms that are all pure JS. Within about a month there will be no more aspx or html pages except for that main one.
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
That's cool, but how quickly would this have been developed as a desktop app?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
That's a tough one. If we had just gone WinForms, maybe half the time, but to keep our Mac clients as well, maybe twice the time. When the decision was made to go web, Mono was till quite lacking, and non of the other so-called cross platform libraries came close.
|
|
|
|
|
Pete O'Hanlon wrote: ollowed a vastly increased development time
I don't agree with it necessarily.
My experience in terms of rapidity of development has been:
VB6 / Winforms > ASP.NET > ASP.NET with jQuery/ExtJS > MFC > WPF > SilverLight.
If I want to develop something really quick and dirty and short lived form/grid based LOB app, I invariably choose winforms.
However, I have found that in a complex - long lived project the choice of technology itself plays very less part in the development time. Because each technology comes with its own set of problems.
|
|
|
|
|
And web applications are truly independent of OS on the clients.
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
It's just a shame that they aren't browser independent.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Ours is getting damn close through extJS.
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
Well, these days there is no excuse of writing browser dependent code. The Javascript libraries are extremely powerful and encapsulate lot of complexities away.
|
|
|
|
|
Christopher Duncan wrote: then it's an unproductive decision that offers no benefits other than being able to say that you're trendy.
Which can then be wrapped as as saying it's "Enterprise" ready, and the decision is practically a given!
|
|
|
|
|
Jim Crafton wrote: Which can then be wrapped as as saying it's "Enterprise" ready, and the decision is practically a given!
So does that mean the software is approved by Star Fleet Command?
|
|
|
|
|
Christopher Duncan wrote: to accomodate the stuff you can do in a web browser (don't get me started)
No, seriously. Why don't you tell us what you think of web applications?
|
|
|
|
|
John - you already know that I like this stuff, so let's get this out of the way straight away, Silverlight is a long way from being able to do the tasks that you'd typically want to do for Enterprise level applications. There's a lot of functionality that you'd want as part of the base framework that you end up having to write yourself.
It sounds like he's picked up a tech magazine and read the byline without having a clue about what's going on. Bottom line - stop reading the toilet roll packets and assuming that it's reality.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
|
John Simmons / outlaw programmer wrote: that Silverlight would be a viable technology to deploy an enterprise-level application.
Answer to this question and any other similar question is that - it depends!
In my experience, deploying application via web browsers is preferred by IT departments of many big companies. So Silverlight scores big points in that area. Silverlight is obviously a subset of WPF but if the subset is enough for your needs, there is no reason why you should not go for it. Also by discipline it is possible to use same code base for WPF and SilverLight which will offer best of both worlds.
Also look at technologies such as Prism and .NET RIA services. They look promising (from a distance at least).
If you can live with certain limitations of SilverLight like running in a sandbox environment and support for only a subset of .NET framework, by all means, go for SilverLight.
One advantage of Silverlight is that it can run on Mac which does not matter for matter for many enterprise applications.
|
|
|
|
|
I would suggest that if your boss wants you to develop in SilverLight then he should send you to a class for programming business applications with Silverlight. Good luck finding one...
I didn't get any requirements for the signature
|
|
|
|
|
Deployment is a big pro for Silverlight:
Silverlight will act like a web application -- it runs right there in the browser, no manual install required. It doesn't require the full, huge .NET framework. (It uses a subset of the .NET framework that takes less than a minute to install on a fresh machine.)
Compare this to to installing the latest WPF runtime on a fresh machine without the .NET framework, which will involve a big download, longer install time, and possibly restarting the computer.
Silverlight apps run in a sandbox; you can't harm the end user's machine.
Silverlight apps and data can be indexed by search engines[^] if you do things right.
Silverlight runs on multiple platforms, including the Mac. With Mono's Moonlight port of Silverlight, you can also run your Silverlight app on Suse, Ubuntu, and Fedora[^].
A con for Silverlight: it doesn't offer everything WPF offers, many WPF features and APIs are missing from Silverlight. Also, because of the sandbox, you can't do things like pop up dialogs willy-nilly, your access to the file system is limited to the isolated storage directories, and you're limited in how much data you can store on the end-user machine.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango
|
|
|
|
|
John Simmons / outlaw programmer wrote: I want a clear and un-biased comparison of the two.
Urgentz ... pleze.
|
|
|
|
|
John,
The development team I'm currently on is facing similar issues, minus the "boss" part.
Here's what I can tell you:
1). There is very little cross-over between WPF XAML and SilverLight
2). SilverLight 3.0 is really closer to be "LOB ready", don't waste time with 2.0
Other issues:
10 SilverLight Gotchas, with SilverLight 2.0[^]
But again, from what the "guys" on my team have mentioned, I would skip 2.0 and concentrate effort on 3.0.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
