The latest buzz in the dev community online is all about Silverlight. From my perspective, there are a number of things to tease apart:
- Silverlight as a Flash alternative
- Silverlight as a WPF-lite, with CLR
- Silverlight as a dynamic language runtime, and the DLR itself (standalone) - one can preview this framework in IronPython
I know I'm not a typical web user, but my main experiences with Flash have been:
- Amazingly annoying advertisements
This is the main reason I disable Flash by default, with FlashBlock in Firefox. If I wasn't able to use Flashblock, I would uninstall Flash instead - I'd rather lose video than suffer distraction.
- A video solution
One of Flash's nice advantages is that it keeps the Linux folks onside, as even though it's not open-source, they can still consume.
- Extremely crummy rich applications
I have never encountered a Flash application that (a) had good keyboard support and wasn't terminally mouse-dependent or (b) didn't prioritise flashy (ha!) animation over and above actually making use of the richer platform than poor/pure HTML or (c) whose rich vector animations didn't regularly peg a CPU at 100%.
WPF-lite with CLR
There's another thing I find striking about the Silverlight story: how similar it is to Java applets. Things that make Java applets suck are (a) the cold start cost (chuggalug of disk, bloat of memory) and (b) ugly Swing UI controls, and (c) the plain fact of JVM dependency.
Cold starts are always important, and I feel the CLR has a better handle on controlling those costs than most JVMs, and certainly expected browser memory usage is a lot higher these days, regularly climbing above 200MB on my machine for one.
It ought not to be hard for WPF to improve on Java's controls, and there are folks out there already looking to market for this platform.
The dependency is the most troubling issue. Flash has gotten to where it is chiefly (I believe) because of video; MS needs some similar mass-market hook to get adoption, and I'm not sure its video implementation is a differentiator, much less an advantage - mainly because I haven't seen it yet. But really: how much better could it be, that would make a difference?
DLR: Dynamic Language Runtime
The DLR is also an interesting platform play, creating an interoperability platform suited to dynamically typed languages with late-bound types, methods and fields. Most dynamic languages permit things like expando methods, jamming on fields and closures to existing objects and extending them, very rich reflection and metaprogramming, runtime 'eval' support, etc. - but all in quite similar ways. In some respects, DLR is a little like late-bound COM for the .NET generation.
It's interesting that the Java platform never developed this, even though it's the other main target for dynamic languages looking for performance improvements. The open-source movements for e.g. Jython, JRuby etc. never really get together and try to find the commonalities, and implement them in a shared library, and eliminate duplicated effort. It's one of the structural deficiencies of open source - once the code's been implemented in specific layer, it tends not to migrate to a lower layer. It's also an obvious move that it's taken someone like MS to make - I wonder if Sun regrets not doing something like this. Finally, it's notable that Java doesn't have anything like Reflection.Emit, one of the most interesting features of .NET for me ever since it came out, and one that DLR leverages heavily for its performance benefits. Java users have to work a lot harder to get the same effect, dynamically generating .class files.
On the other hand, the DLR, as a thing in itself, is great stuff. I can see opportunities to add DLR awareness to more traditional statically typed languages and get benefits from both worlds.