Silverlight Website
29 Jul 2010Yesterday I mentioned that I'm writing a new web application with Silverlight. I also expressed a few misgivings about the current level of support for Silverlight in VisualStudio and other tools. Today, I'm going to talk a little bit about the design of this new website and some of the decisions that we made to arrive at this design.
Our current web application is written in ASP.NET/C# and uses a series of third-party plugin controls to add improved aesthetics, performance, and capabilities. This strategy works reasonably well, though I've personally found it to not be maintainable as-is. I've found that complexity is growing much more quickly than capability does, and that our limited development resources quickly get strained. This is especially true when we start running into impossible-to-debug errors in hundreds of lines of generated javascript. Our entire team has ground to a halt on more than one occasion while one intrepid developer suffered through long sessions of phone tech-support to resolve these kinds of issues.
If we were using a combination of PHP and JavaScript, with a comprehensive client-side framework like jQuery things might be a little different. But, we're not. That ship has long-since sailed and there is no going back now.
The fact is that my office is a C# house. All our developers know C#, all our projects are written in C#. Trying to switch our main web application to use PHP instead would require major retooling time and effort, retraining for several developers, lots of lost time and productivity, etc. C# is as good a language as any, and if we can get moving with the right tools and the right technologies it should work just as well as anything else.
The problem I have with ASP is that it doesn't run directly, it generates HTML, CSS, and JavaScript. The result is that the source of the actual page which the client receives bears only the vaguest resemblance to the code which the developer wrote. Find a bug somewhere in the CSS? Unhandled JavaScript exception? Unless it is painfully obvious where the problem is coming from, it might be impossible for anybody to trace that problem directly back to the offending ASP code. Producing a robust and portable solution may be even harder.
This is not to mention that there are major differences in JavaScript, HTML, and CSS implementations between browsers and there's no guarantee that anything you see on your development machine will look the same when the client gets it. I can guarantee that Microsoft tries hardest to make things look spiffy in Internet Explorer, but even then I have found some severe problems with ASP websites not rendering properly in various versions of IE. For modern browsers this usually isn't a huge problem anyway, but we deal with several clients who use IE6 by corporate mandate and refuse to update for "security concerns". Go figure.
[Side Note: If your IT personnel claim that upgrading from IE6 to something newer is a security concern, fire them. This is the first sign, and not a trivial one, that the person in charge of your IT department is incompetent.]
JavaScript differences between such a huge range of browsers is really a pretty serious concern. There's a reason why I like working with VMs, which provide a standard interface across multiple platforms. Parrot is my favorite, of course, but .NET/Mono earns a strong honorable mention too. The more we can write in a managed language like C#, and the less it gets converted to something less reliable, the better. Generated code is the enemy here, and HTML/CSS/JavaScript is really a terrible choice for target "language".
These are the reasons why, in a nutshell, that I picked Silverlight for the new website. Toolchain support is sophomoric at best, but it does give us what we need otherwise: We can write everything in C#, we don't have to worry about differences in rendering, performance, or capability between different browsers. Even the poor IE6 folks have a Silverlight plugin installed. We can leverage the strengths of our existing team too, which is deadline-friendly. We have a good opportunity here to mature with our tools, and I've already filed a few bug reports and sent in some feedback to Microsoft about some of the issues I've found. All we need now is to wait for service pack 1 without killing ourselves or each other.
The website requirements are a pretty nebulous beast, as I'm sure they are for any sufficiently-usable web application. Different customers all want to see different things and have different tools at their disposal. What we needed was a framework that would allow us to create a pluggable interface and support/enforce encapsulation and abstraction like any modern MVP application wants. To do all these things, we decided to use Prism. Prism is part framework and part "guidance" which provides tools, lessons, and examples to follow for building modular MVP or MVVM applications. Basically, it's a nice booster to make sure your team is following some modern best-practices when it comes to scalable and maintainable application design.
Like any methodology, adhering too strictly to MVP or MVVM design can put you in an uncomfortable place, but if you take the lessons to heart and use the tools that you need, I've found that it works out pretty well. One particular nit that I do have about it is that aggressive decoupling of your classes leads to referring to modules by name with strings, or System.Type objects, and you miss out on entire classes of analysis and error-detection tools that your compiler's type system would provide otherwise. "Be really careful" is a strategy that doesn't really work well in life and doesn't really work well in programming either. There's nothing worse than trying to track down an error which raises no compiler warnings and fails silently at runtime too without throwing an exception. Combine this with my inability to debug Silverlight from VisualStudio and I've run into a few situations where I almost pulled some hair out. Once I get my debugging issues sorted out this won't nearly be so much of a problem, but right now it makes for long days.
This entry was originally posted on Blogger and was automatically converted. There may be some broken links and other errors due to the conversion. Please let me know about any serious problems.
Comments
Brian
8/3/2010 11:39:05 AM
Whiteknight
8/3/2010 12:27:12 PM
Sounds like a pretty tough situation to be in, and it's rather familiar to me: "this would probably be easier in X, but that would require everybody in this Java/.NET shop learn X. They'd hate me and probably not learn X well, so the product would end up being worse than where they are now. Alas."
I wanted to comment on your side note. First off, I agree that IE6 is long past its use-by date. No self-respecting shop should still be using it. I've seen some very large organizations that do stick with IE6, especially large medical orgs. So I've been mulling over it and trying to understand why. The best I can come up with is that IE6 may be evil, but it's a *known* evil. These huge IT infrastructures are brittle. If an upgrade exposes some other vulnerability in the org, it's not just an annoyance or a hassle. It could end up being a scandal that gets scattered all over the news. Nobody wants "IT at BigHealthCare Inc. until an upgrade rollout brought down half the country's hospitals" on their resume. Rather than risk their career, they lock down systems and forbid any changes. It's a false sense of security, but it feels real enough to them.
That's my guess, anyways. But what do I know? I'm the guy that finds a way around IT policy in the first 45 minutes of my first day. Their only consolation is that I hardly ever call them for help.
In reality, any general-purpose programming language can be made to work, and it' my experience that C# isn't a bad choice for this kind of task. I would prefer PHP if it were me by myself making a website in my basement, but considering the organizational support I get if I do it in C# instead, I don't mind too much.
With IE6, I definitely understand what you're saying but it really just proves my point more. If the IT people prefer IE6 because it's a known vulnerability over a newer browser with fewer known problems, the IT people are bad at their jobs; period. If they stick with IE because they mistakenly think it's more secure than a newer offering, they aren't just bad at the job, they are utterly incompetent.
Now, if people stick with IE because they're hamstrung by third-party software that requires it, that's a different story. In that case, it's the developers at IT people at the third party that should be fired.