Skip to main content
Microsoft Silverlight
Home Forums Silverlight Programming Programming with .NET - General Silverlight/WPF Mismatch
26 replies. Latest Post by jzabroski on August 28, 2008.
(1)
andyboyne
Member
105 points
56 Posts
03-20-2008 12:27 PM |
I’m a big fan of Silverlight and coming from a .Net and WPF background, I was really looking forward to what Silverlight 2.0 had to offer. Sadly, I have ended up highly disappointed as I was hoping to port several high-profile financial industry applications to a more portable framework, but at the moment there are just too many obstacles :o(. It really seems the elegance and separation of concerns of WPF has been replaced by a framework that encourages ‘hard coding’, bad design and minimal reuse. It is somewhat reminiscent of old VB apps with business logic behind buttons! Don’t get me wrong, Silverlight as a Web technology does have enormous potential, but to tout it as being similar to ‘WPF’ is simply not true. I understand the need to streamline WPF, but Silverlight has done more than that, it has removed some of the fundamental principles that made WPF such a good technology. All of the demo applications published by Microsoft showing how easy it is to port between Silverlight /WPF are simply convenient ‘hello world’ type scenarios, and I believe all the marketing and hype around Silverlight and WPF similarities is sending out the wrong message. A WPF app done the WPF way cannot be easily ported to Silverlight, even down to the form definitions. The same is true of the reverse.
Below are some observations I made whilst in my first few hours of Silverlight whilst trying to accomplish several ‘basic’ tasks I would easily accomplish in WPF. I have separated the issues into two categories based on how they have affected my projects. I am hoping at least some of the issues below are resolved in Beta 2 or RTM, or failing that, make it into future Silverlight versions. Let’s keep our fingers crossed :o)
If any Microsoft guys could please give us a clue as to what to expect and when in the Silverlight roadmap then that would be great.
Absolute Show Stoppers
1. Where has MarkupExtension gone? How do we write our own? Are Silverlight bindings from markup “{Binding Forename, ...}” just ‘magic’?
2. How to handle databinding currency, especially with lists as there are no ICollectionView types? E.g. List<People> bound to a textbox, how do we know which person the textbox is displaying?
3. Binding is inconsistent between WPF and Silverlight:
No ElementName source No RelativeSource Self BindingExpressions not compatible between Silverlight/WPF. Therefore form layout reuse is not possible.
4. No way to get Binding from a control. In WPF we were able to use techniques involving Bindings to know what control was bound to an object and vice versa.
5. No ErrorProvider. In WinForms and ASP.Net there is an out-of-the-box error provider. In WPF it is fairly easy to create an ErrorProvider by tracking the bindings and using AttachedProperties and style triggers with adorners. In Silverlight it seems an awkwardly difficult task! :o(
6. No Adorners. As mentioned above, ErrorProviders in WPF can be implemented with adorners and attached properties. Of course there are a multitude of other reasons as for why Adorners are useful.
7. No ControlTemplate Triggers, DataTemplate triggers, Style Triggers, DataTriggers.
Annoyances
1. No commands/input bindings/gestures – there goes the nicely layered architecture...
2. No ReadOnly DependencyProperties – not a major problem but it is a loss of encapsulation.
3. No tunnelled (preview) events.
4. No RoutedEvent class.
5. No UpdateSourceTrigger=PropertyChanged.
6. Visual / FrameworkContent element missing. Not a major problem, but certainly leads to interesting API changes.
7. No ability to specify a keyless style and have it applied to all matching TargetType..
8. Cannot specify FrameworkMetaData when creating dependency properties. So how to define inheritance behaviour, and default values etc?...
9. No style inheritance -> I.e it is not possible to do ‘BasedOn’...
10. No ValidationRule/ValidationResult.
11. No Xml DataBinding Support.
12. No DynamicResource.
13. No MultiTriggers.
Cass
Contributor
3157 points
654 Posts
03-20-2008 4:00 PM |
Welcome to Silverlight 2.0 Beta
I actually find comming to Silverlight 2.0 from WPF background very frustrating, but if you are new to Silverlight 2 (without WPF knowledge) you really don't know what you are missing so, there are quite a few issues more than than you mentioned.
Most of the issues you have mentioned are mostly the same I have to sum up your list, I would simply say
If Silverlight have all that I would be one happy bunny. And I have been screaming for MSFT to fix these four major issues, maybe someone heard me.
Alan Cobb
467 points
201 Posts
03-21-2008 11:44 PM |
Hi Andy,
Nice list. Thanks for posting the detailed thoughts.
I think your post really may be in the wrong forum though. It's not really a bug report, but rather a general evaluation of SL vs WPF. Maybe "Getting Started" or "Programming with .NET" would be better?
You said you were working with "high-profile financial industry applications". Are you really getting that much pressure to port to non-Windows platforms? Aren't most of your users running Windows and Office already and probably on beefy machines with broadband connections? So what's the problem with using WPF (maybe as an XBAP if you need some sandboxing)?
Alan Cobbwww.alancobb.com/blog (Silverlight blog)
03-22-2008 8:12 AM |
Thanks for you post and suggestions, but we do already have WPF (and WPF XBAP) version of the application. The problem lies in the requirement of .Net 3.0 - as an example, would you be happy with your internet banking if it only worked on Windows and you had to install the .Net framework first? The beauty of Silverlight is the streamlined CLR and cross-platform support.
Cheers,
Andy.
03-22-2008 1:48 PM |
I can see your point if it's a consumer-facing app.
The fact you already have a WPF version seemed to imply more of a internal line-of-business type of application, where requiring Windows and .NET 3.0 is not as big a barrier. Are you saying you did a prototype of a consumer-facing app in WPF hoping that it would be easy to port to Silverlight X when it finally arrived?
I'm just trying to understand the context.
03-25-2008 7:34 AM |
Not exactly, the WPF version serves its purpose in-house, and will continue to exist - as we do require, in certain circumstances, for the application to run in partially connected environments. To reach a wider market it would be preferable to run an 'online only' version as Silverlight.
03-27-2008 3:47 PM |
Here is a great blog post on this same topic:http://devlicio.us/blogs/rob_eisenberg/archive/2008/03/13/there-s-some-darkness-in-your-silver-light.aspx
Title: There's some darkness in your silver light. First sentence: First, let me begin by saying that I'm a huge fan of Silverlight...Alan Cobbwww.alancobb.com/blog (Silverlight blog)
suedama1756
6 points
5 Posts
03-28-2008 5:17 AM |
Ok, now we have established that more than one person is encountering similar issues, and that this may or may not be the correct forum for this post, etc. how about someone actually providing some usefull information?
If this is the wrong forum, then which is the correct one?
Can we get some confirmation as to whether any of these issues/features will be addressed/added in beta 2.0?
Key issues for me are:
1. Binding inconsistencies, i.e. {Binding FirstName} in silverlight does not work in WPF as you require {Binding Path=FirstName}. As silverlight is a subset of WPF you can accept element and relative binding not being supported, however, supported CLR binding should be transferable.
2. No general way to navigate logical control hierarchy (With this feature many of the issues, adorners etc. could be worked around).
3. ErrorProvider functionality, how do we get error icons next to controls "in error", this is supported in ASPX, WinForms and WPF, how do I achieve this in silverlight without hard coding?
03-28-2008 12:52 PM |
Hi,
Re. which forum is best for this:IMO, this "Report a Silverlight Bug" forum is the right place if you are using a feature documented in the Silverlight docs that does not seem to work as described.
But most of the issues brought up in this thread are:- Requests for new or changed features. (Like "DCRs" = "design change requests")- Requests for clarifications of current feature details.
The "Programming with .NET - General" forum has >10x the traffic of this "Bugs" forum. That is the one I usually browse first. Putting these kind of questions / requests there makes sense to me, since it will get more readers and they are not really "bugs".
jzabroski
70 points
53 Posts
07-19-2008 6:45 PM |
I'm bumping this thread. A few days ago I found Andy Boyne's complaint on Microsoft Connect and I replied to it. Today I found out he posted it on the forums, too.
So far, it seems no one from Microsoft has addressed these complaints.
In particular, as Beta 2 has come out, I'm seeing more and more developers ask "Where is MarkupExtension?" See for instance: Creating a DependencyProperty of type "Type", and Custom markup extension support in Silverlight XAML parser implementation...
I have to wonder what Don Box and Chris Anderson think of "XAML without the X". Chris was so adamant and defensive about the importance of MarkupExtension when he first introduced it. Silverlight uses AML as far as I'm concerned, and it extremely limits the expressiveness of what I want to achieve in many areas.
As a developer for a Micro-ISV, we see Silverlight perhaps differently from how the big chiefs at DevDiv see Silverlight. We see Silverlight as a potentially dominate platform for corporate intranets, a true killer application domain. However, Silverlight has been given arbitrary and bizarre goals that it has already failed to meet. Scott Guthrie was so adamant about "4 MB", and Beta 2 blew clear past that relatively worthless, arbitrary 4 MB limit. Beta1 was past it, too, weighing in at 4.3 MB. It's time to admit this 4 MB arbitrary limit is silly and to give us as much of the WPF toolset as possible.
It also seems that the Silverlight team does not have a spokesperson explaining to us Micro-ISVs how we should actually manage WPF/Silverlight compatibility. Glenn Block's WPF CAG is sort of worthless in the Silverlight context when our customers are demanding more and more stuff be on the web, but still want the desktop for certain things like Outlook-style Master Replication. We need the equivalent of what Eric Lippert has given the C# Language Design Team. A voice of reason who will ensure that the quality of the API is being watched over carefully. So far, the Silverlight team blogs I've read have given very little in this respect. Tim Heuer did a nice job explaining why he thinks Silverlight.js is not the right approach for all situations. However, very little about the API compatibilities with WPF and Silverlight has been thoroughly discussed. If it has been discussed, then it hasn't been mentioned in any of Scott Guthrie's link listing series and it hasn't come across dotnetkicks.
I have to credit Yi-Lun Luo, though. Luo has done a good job recently explaining Silverlight/WPF event bus differences and what the roadmap is for unifying the two. However, some stuff just seems like a bad idea and left me wondering if the removal of some base classes from Silverlight was done just to reach that 4 MB goal. Sams' Teach Yourself WPF in 24 Hours author Rob Eisenberg mentioned on Jesse Liberty's blog that he felt Microsoft was making a mistake by not having Silverlight and WPF infrastructure be 100% compatible. Rob further criticized Silverlight 2 on his blog in March, but some of his criticism no longer applies since it is now clear what the direction for ControlTemplate is with the introduction of VisualStateManager. However, some of it still applies and hasn't been addressed by Beta 2.
An example of a never discussed API incompatibility is the removal of the Visual class. The best answer I've found is from Ashish Shetty, a Program Manager on WPF. However, all he says is that "[removing the Visual class will] keep the object hierarchy shorter, have one less type to deal with, small size reductions and still be a subset of WPF both conceptually and behaviorally." The troubling thing is that, in the comments, Ashish asks a Silverlight developer, "if Silverlight and WPF results are 100% similar on render, then do you care if their internal algorithms are different? If so, why?" The problem is that it is not the same. Anything interactive is not simply rendering but also infrastructural event-bus logic. Internal algorithms are also not the same thing as API concepts. The "internal algorithms" I can work around are the fact that Silverlight apps share the same process and therefore you can't do synchronous calls. Fine. I can work around that, because it doesn't effect WPF infrastructure.
Trust me, give us the right features in Silverlight and we'll have our customers install it on 30,000 Windows clients over night. We're not the Olympics, but we run a ton of corporate intranets.
07-27-2008 12:30 AM |
Rob Eisenberg recently updated is blog with new comments concerning his opinions on Silverlight/WPF.
07-27-2008 10:20 AM |
It would be very interesting to hear the back story about this from the devs at MS. My speculation is that it may be partly like this:
They already had WPF written. So how hard can writing SL be? Turns out harder than expected (or time budgeted for). Why? Try shoe-horning 50+MB of stuff into 4MB, then try making it run cross platform. In order to make it cross platform you have to do a lot of stuff down in unmanaged code in parallel classes. A nasty and bizarre refactoring job. In some ways it requires a complete redesign (over several "beta" versions :), rewrite and retesting of the whole thing. Pray for them (and us too).
Realize the magnitude of what is going on here. SL has the potential of being as fundamental, widespread and important to MS and its ecosystem as Windows was to the younger MS. Any parts of the (re)design that get screwed up now we will have to deal with for the next 20 years.
An excellent place to spend some of the $44 billion they saved from not buying Yahoo :).
07-27-2008 12:28 PM |
Well, Scott Guthrie replied to Rob's post, which is great.
I have a lot to say about what the next 20 years should be like, but this isn't the place for the Microsoft's shareholders meeting. :)
Some of the 50 MB has to do with hardware acceleration and calls to DirectX. Scott Guthrie has kindly told us that he doesn't see that sort of hardware acceleration support coming to Silverlight, because making it cross-platform would be a significant challenge. Also, baml is not part of Silverlight, neither is a 2 MB spell checking dictionary.
What's more, is that it doesn't seem Scott's answer really matches how the dev team is deciding what to put into the run-time. Todd Anglin's blog, What's cooking for Silverlight 3.0?, mentions that client developers are being asked what features they want. Noticeably absent from that list is WPF Compatibility. Yet on the list is features that should not ship with the core run-time, like dictionary support.
ScottGu says WPF is 20 MB, but it ignores the fact that some of that is strictly unnecessary, especially in Silverlight. It also portrays a misconception that WPF is bloated, when it is not. WPF actually is surprisingly lean, thanks to XAML. For instance, in the WPF beta days, there were Factory classes like FrameworkElementFactory that you didn't really need because you could just use XamlReader.Load() instead. He also tells Rob that "older machines" need to run Silverlight, but doesn't qualify what that means. So far, it seems Windows 2000 will certainly not be running Silverlight. I am guessing he means "users who bought that $299 eMachines Windows XP computer with zero RAM at Walmart". It is these sorts of vendor issues Apple doesn't have that Microsoft has to deal with.
Sorry for the roll-up-my-sleeves blunt approach I take, but the last thing I want is Silverlight to be is the <blink> tag writ large. I want the community to know what they should be asking for, and why, to help MS develop a great product.
07-27-2008 1:50 PM |
Also, Scott's reply to Rob still doesn't answer a question those of us have been wondering: How much MB did you save by removing the Visual and Freezable classes? How do you justify those saved MBs in terms of compatibility with WPF and ease of portability?
For those of you reading this and are curious what the heck Visual is, you can read the WPF MSDN documentation on Windows Presentation Foundation Graphics Rendering Overview.
For Silverlight, there was a lot of talk of "simplifying" the programming model in Silverlight. Nobody at Microsoft has actually explained what this means (that I've seen), but here is a rough explanation of what I take it to mean:
Looking at WPF XAML, you can immediately see the Logical Tree of elements. I hate using silly acronyms, but probably the one that works here is WYSIWYM (What You Say Is What You Mean). The Logical Tree gives you a specification of what you can program against in your code-behind files. However, looking at WPF XAML, you cannot immediately see the Visual Tree of elements. This is because you can arbitrarily gut-and-replace the Visual Tree of any given element.
To a degree, Silverlight is helping fix some problems WPF developers have had working with the Visual Tree by introducing the VisualStateManager. The key role the VisualStateManager plays is introducing a well-studied computer science technique called Statecharts. Statecharts have very desirable mathematical properties (they prevent combinatorial explosion of state -- very bad!, b/c managing excess state causes a ton of bugs and undefined state transitions) and are also very intuitive. The big deal is that they formally specify what state a state machine is allowed to be in. VisualStateManager takes the concept of a Statechart and applies it to the SL2 rendering engine and programming model. This gives you the added benefit of clearly defining a one-to-one correspondance between a control's logical state and its visual state. The "Manager" suffix on the class gives the programmer the impression that it is in control of state-process, but it is not! VisualStateManager is a slave state machine for the logical state of the control, as dictated by the control vendor. The TemplateParts annotation give you a contract that you can program against. This way you can actually sort of see in XAML the Visual Tree. You can also therefore program easily (compared to WPF =<3.5) against it at run-time, although you probably shouldn't! (In WPF, you program against the tree using LogicalTreeHelper and VisualTreeHelper.)
07-27-2008 2:19 PM |
>I have a lot to say about what the next 20 years should be like,>but this isn't the place for the Microsoft's shareholders meeting. :)
I'd be interested to hear what you have to say. Maybe you should start a blog or something?
>Noticeably absent from that list is WPF Compatibility.
I really think WPF compatibility has been over sold / over "spun". Yes it's a great goal, but there are those 4MB and cross-platform barriers. It's like getting used to driving a Ferrari (WPF + full .NET) and then hoping to get the same power and features in a Hyundai (SL) at 10% of the price (memory and platform footprint and living inside the straitjacket of the browser + security sandbox). The reality is that SL is different enough (and probably will be for years) that a major part of being productive at it is learning how to work around its current short-comings / differences. It's like an exercise at engineering school, where they give you a bag of springs, wires and bits of metal and challenge you to build an X out of the pile.
07-27-2008 11:28 PM |
Alan Cobb:I'd be interested to hear what you have to say. Maybe you should start a blog or something?
I do not blog, but I am starting an open source project aimed at simplifying coding XAML by hand. I'm in the analysis stage of the project, and I am underwhelmed by the open source libraries on the .NET platform coming over from C, C++ and Java. For instance, I need to roll-my-own deep data structure pattern matching library or ask Charlie Poole if he'll let me refactor out the NUnit's new Constraint-Based Model for assertions. However, from what I've seen, his implementation of constraints isn't what I am looking for. Honestly, who has time to blog when trying to make other programmers lives less painful?
Prior to having the job I have now, I was writing medical imaging statistical analysis software that helped do things like image neurological systems at the cellular level. A technical blog is a bad idea for me, because there is no guarantee I will find coding Enterprise applications interesting long term. Currently, it is a fun change putting the "wow" factor into business applications.
I also find it requires a lot of pain killers to read some of these blog articles, because people read Martin Fowler's Supervising Controller pattern and then start to think, "Hmm. How would I do that in WPF?" They talk on their blog how hard the pattern is to implement, rather than pointing out that maybe Martin was incorrect to even bother with these silly patterns. So they blog rather than reading more about WPF and thinking about how to best build WPF applications sans any patterns madness.
Alan Cobb:I really think WPF compatibility has been over sold / over "spun"
Building real extremely complicated applications that target multiple platforms will change your mind on this. Right now, ISVs are not doing a lot with Silverlight yet because it is still beta. What I am mentioning right now will be things people will complain to Scott Gu about after it is officially released and the decisions cannot be reversed.
I am not tied down to Silverlight, and could easily move to Flex if the deployment model does not require two code bases.
Alan Cobb:It's like an exercise at engineering school, where they give you a bag of springs, wires and bits of metal and challenge you to build an X out of the pile.
No. Don't manage labor, eliminate it.
Sorry, I am 24 years old, and sick of mastering any level of complexity just because I know I can, without actually solving any real problems at all. I don't need an exercise to sharpen my mind. Far less smarter people have less patience, or will bankrupt their Micro-ISV trying. I've learned that people don't care that I have all this knowledge about Swing, SWT, AWT, X/Motif, QT, wxWidgets, GTK+, etc. People want software that doesn't cost a lot of money to write and doesn't require them to juggle two different, somewhat overlapping sets of APIs to write. This is the fundamental fact for Micro-ISVs. Without it, the Micro-ISV industry would've never gotten past writing mailing label software and into true enterprise application development. Programs like dBase II, Foxpro 2.6, Pagemaker, etc. enabled your average developer to do a "template design" and that really lowered barriers. Microsoft saw this and built Visual Basic, and they ended up with 99% of the the market, crushing Apple.
Having Silverlight and WPF be compatible, including the abstract notion of rendering instructions being serialized to a Visual Tree of objects, would lower barriers further. Trying to mimic what Flex is doing is the wrong approach, because there is a lot wrong with the Flex model, and even they realize this and are trying to fix it.
Mark Rid...
2521 points
287 Posts
07-28-2008 8:56 PM |
I'll be happy to respond! Note that while I don't have the answers for each and every comment, I would say this: With regard to compatibility, we are building Silverlight with the approach that a Silverlight 2 designed application can be ported to WPF. There are cases where we identify improvements or a simpler API that we will get ported to WPF in the future. What we didn't try to do is say "lets port code features from WPF". What we did start with (in Silverlight 1.0) is "lets port XAML element syntax and rendering compatibility from WPF". It should be noted that Silverlight 1.0 doesn't have managed code and that everything we write is mostly a complete re-write from WPF (sure we can take advantage of concepts and make code better). With Silverlight 2, managed code is how you write against Silverlight more than how Silverlight is built (Silverlight is not built on managed code with the exception of some controls and databinding).
As with all coding projects/products and frameworks you need to define a gate for when you are "done". We gated ourselves in terms of time and in terms of scenarios. What XAML features are necessary to complete a scenario? We also tried to not provide three ways to skin a cat -- just ensured you could do it. This is how we develop something under 20mb. XamlExtensions are hard to do actually since our XAML parser is quite different (unmanaged) than WPFs. We don't have the infrastructure to be calling out to managed code to create user objects. In addition we had to figure out how security plays into things such as calling user code. That isn't to say that we won't try to re-write our XAML parser to do this, just priorities and time.
I think the important thing to note is that Silverlight is a rich framework for developing RIAs and for displaying quality media experiences. We have to choose the most direct way to enable those experiences and still be a subset of WPF.
-markSilverlight Program ManagerMicrosoftThis post is provided "as-is"
07-29-2008 10:31 AM |
jzabroski: > >Alan Cobb:> >I really think WPF compatibility has been over sold / over "spun"> > Building real extremely complicated applications that target> multiple platforms will change your mind on this. ... What I > am mentioning right now will be things people will complain > to Scott Gu about after it is officially released and the > decisions cannot be reversed.>
Just to be clear, I naturally agree that the more compatible SL is with WPF the better.
What I meant by saying "WPF compatibility was 'over spun'" was not that it wasn't desirable. What I think has been 'over spun' is how achievable that is given the constraints. ScottGu and the SL/WPF team have as much of a desire to make them compatible as anyone, but the "inconvenient truth" is that there are major incompatibilities now and will continue to be. That does not make a particularly attractive marketing pitch, as your reaction demonstrates. Still, most of us would rather get the straight story up front.
Mark Rideout:
Hi Mark,
Thanks for the details.
I'm guessing that the decision to do most of the implementation in unmanaged code says something about the size and speed advantage (probably significant but not vast) of unmanaged code? Or is that not the main reason?
Thanks,Alan Cobbwww.alancobb.com/blog (Silverlight blog)
alexmont...
74 points
41 Posts
07-29-2008 11:50 AM |
I don't really understand why Microsoft self-imposed a 4MB limit on themselves for Silverlight. The percentage of people using broadband internet on the planet is growing every year and pretty soon pretty much everyone will have some sort of high speed connection. 4MB vs 20MB download is pretty much meaningless imho for a one time installation.
07-29-2008 2:14 PM |
@Mark Rideout
Thank you for your reply. I can tell by the fact Silverlight team members have stopped blogging that the project is officially in crunch mode for the Olympics, and am amazed you found time to reply. Thank you very much. When Silverlight is released, I will enjoy watching the Olympics on Silverlight 2 through the Beijing Smog. :) Here are some thoughts that Microsoft will have to consider post-mortem RTM.
"Skinning a cat" is about the worst metaphor possible for designing a public API for client developers. I am sure that is what the executives at Sun said when they ordered AWT to be built in one month. I hope someone enjoys adopting abandoned kittens. :)
A formula I found that works well when developing a public API for clients is to Listen, Understand, Respond, Repeat (LURR).
Most of us really, really want event tunneling.
The MarkupExtension is merely a curiosity for Silverlight 2, but will be a necessity for the next iteration, because it enables generic programming and that is a lot to give up. According to John Gossman, the Silverlight XAML Parser and the WPF XAML Parser are tested for compatibility, but Rob Eisenberg, myself and others have identified a number of regressions. There is also the long outstanding bugs in WPF XAML, such as not being able to nest a MarkupExtension inside a custom MarkupExtension using Attribute Syntax. It might be worth exploring formally specifying the XAML parser as a Ragel State Machine file and therefore take a model-driven approach to Silverlight XAML/WPF XAML compatiblity. Ragel is a State Machine Compiler able to generate C, C++, Objective-C, D, Java or Ruby code. Unfortunately, no C# backend exists.
Inheritance Context and MarkupExtension are the two things that differentiate XAML from MXML. Smart programmers like Daniel Cazzulino appear to have come to the same realization that I have: See: Why XAML Makes System.Configration and Enterprise Library.Configration Obsolete.
I have more to say, but I'll stop for now. I'm not expecting updates on these issues until after RTM, because there is zero hope of anything getting changed or accomplished merely by establishing a committee to explain why things are in chaos.
@alexmontreal
I don't understand why ScottGu said during Beta 1 that the goal for Silverlight 2 was to be 4 MB, when Beta 1 was already 4.3 MB. Beta 2 grew to 4.6 MB and I still heard talk about this mythical 4 MB runtime.
Adobe AIR 1.1 installer is 12 MB. Flash is 1.2 MB.
07-29-2008 4:37 PM |
re: jzabroski and tunneling events
I agree with you 100%. In fact, we were so close to adding it but identified the very large test cost associated with something, even though internally the core input system knows about tunneling/bubbling. In addition, like what I've described previously, we have to take into account calling out to managed code during each input action _before_ (read: while on the stack) native event handlers. This opens up security concerns for us. We did (this is for RTM) open up protected virtual On*** methods for most input related events, but that only goes so far and doesn't really enable what seems like a simple scenario (drag around controls) without creating your own custom controls.
re: Alan Cobb and question about implementation in unmanaged vs/managed
I think the first reason is "because that is how we developed Silverlight 1.0" - we didn't have a managed runtime in 1.0. Second - we wanted to ensure that "core" level features could be used regardless of you using Javascript or C# to develop your application. This requires coding the feature in native code. Silverlight 2 hosts this "mini" CLR runtime and AppDomain, the more features we can put into the core native Silverlight engine, the less p /invokes, and reverse-p/invokes are required -- equating to faster execution. Size of code also comes into play -- managed classes and code take up more space (disk) due to the metadata vs native code.
samcov
Participant
985 points
392 Posts
07-29-2008 5:05 PM |
@Mark
Mark, this is a tad off topic, but I think, still important. Is MS going to seed the world with SL2B2 via the Olympics, or are we going to see a release candidate prior to the Olympics.
This has a lot of business implications for MS, us, and our customers. A lot of the issues revolve around the following areas.1. The ability to specify realistic roll out dates for customer product.2. If we target intranet only, or can target internet applications3. If shipping beta 2, how will the upgrade and breaking changes affect our customers.
There are probably more issues, but we're really in the dark here. Any direction would be very helpful.
Sam...
07-29-2008 5:52 PM |
Great question. I know that the current RTM code branch has breaking changes from Beta 2. I'm not sure how much the Olympics team have been working on new code vs. shoring up the existing experience. My personal guess is that they will want to avoid breaking changes and stick with a pre-rtm release.
jemiller
445 points
237 Posts
08-28-2008 12:20 AM |
What I want to know is why they seem to be writing all these classes from scratch. Awhile back Microsoft was saying that 95%+ of Vista's UI was going to be implemented in .NET. Theoretically, .NET is platform independent. I don't know why they don't just do the same thing as Java and get the core working cross platform. WPF/Silverlight should just run on the core and you shouldn't have to do a complete rewrite as they seem to be doing. Didn't they design this stuff in layers? I don't agree with the 4 MB limit on the download size either. I would rather have a system that works as it should without tons of limitations. They don't even have ValidationRule in it? They don't have a ComboBox? Why on earth should they have to write a completely different implementation of ComboBox for Silverlight? They should just be able to use the one from WPF. Maybe I need to have a look at JavaFX Script.
08-28-2008 1:52 AM |
You are asking the million dollar question every product manager all the way up to Scott Guthrie does not want to answer.
What confuses me is the fact they took out the Freezable and Visual classes. Freezable is essential to WPF resource injection. The Visual class is the interface to milcore (Media Integration Layer). In SL, there is a concept of a VisualTree, but barely. I've asked repeatedly to know how much MB they saved in this particular case. I want to know how they justify a pretty massive API incompatibility (How can you remove a base class from a foundation library?). I've heard the argument that shortening the class hierarchy "simplifies programming", too, but ad-hoc explanations like that without hard reasoning are usually lies or wrong.
Stuff like Visual and Freezable missing in Silverlight was a huge paralysis in my understanding of how Silverlight even worked. I don't understand how VisualTreeHelper works without Visual. I can understand why I can't print, though!
When I explained to my boss why I can't print, I used an analogy... I told him about a story from my freshman year in college when I met a girl who later became a good friend. The subject of food allergies came up, and I said, "It must be terrible being allergic to gluten." Then she told me she was allergic to corn. I said, "So what, just don't eat corn!"
She narrowed her eyes in contempt and yelled, "CORN SYRUP!"
It hit me: "Oh my god! That's in EVERYTHING!"
I then told my boss that it looks to me like the Silverlight team decided we are all allergic to corn, by taking away WPF's Visual class. In WPF, the Visual is the raw material used to make all kinds of graphics. The moral of the story was, "Whether or not you are allergic to corn, without corn syrup, you can't print web pages." Now it looks like the Silverlight team is bending over backward making corn-free syrup, so that concepts like VisualTreeHelper actually work. I have no idea how any method or class in Silverlight with the word "Visual" works without a Visual class to orchestrate visual details, though.
jemiller:Maybe I need to have a look at JavaFX Script.
WPF Best Practices are already emerging, and that shouldn't be taken lightly. Still, I'd prefer one and only one API. Speaking for a Micro-ISV, having one UI feature team would make WPF/Silverlight a no-brainer. It's also not clear what Silverlight's goals are beyond streaming media, because they've been silent on Silverlight/WPF compatibility. Right now, it's not clear how DevDiv intends to differentiate Silverlight from the ability to pop a disc into the CD ROM drive and watch it spin. All we're getting is re-hashed marketing from Joe Beda's WPF release presentation: Rich vs. Reach (WPF vs. WinForms). As a developer, I don't like being treated like I'm the CEO that tells the lead developer he heard Oracle is more unified than Java. Simple slogans like Rich vs. Reach worked in 1993, when every developer on the planet believed Bill Gates had a crystal ball into where the software industry was going. Thanks to relative unknowns like Tim Berners-Lee and Marc Andreesen, we've learned not to be so naive, and we should demand better answers.
Although I've ruled out JavaFX Script for my purposes, I wish Microsoft Product Managers were more like Sun's Joshua Marinacci [1] [2] [3] [4] and Dean Iverson [1] [2], in terms of honesty and general helpfulness to developers.
08-28-2008 1:36 PM |
The thing that I find a bit dumb about the 4 MB requirement is: How many MBs or GBs of Windows Updates have you installed over the years? If the purpose is making it so that it is workable over a dial-up connection, dial-up users are screwed anyway because there is no way they're going to download all the Windows Updates. You basically have to re-download the entire OS after awhile. The Java 6 JRE is 15 MB which is easy enough to install and includes the full power of Java. Personally, I think it is more of a business decision than a technical one. Microsoft is probably afraid of erroding their OS dominance. If you could write apps using .NET that run just as good on Mac OS X, you wouldn't need to buy Windows. Another thing that I don't understand about Silverlight is why is JavaScript so important? Who wants to write code in JavaScript when you can do it in C#? I think maybe they should have tried emulating the JRE a little more and emulated Flex a little less.
08-28-2008 5:56 PM |
jemiller:Personally, I think it is more of a business decision than a technical one. Microsoft is probably afraid of erroding their OS dominance. If you could write apps using .NET that run just as good on Mac OS X, you wouldn't need to buy Windows.
I don't support your theory. If people desire cross-platform that badly, then it will inevitably become a reality. See Jim van Dam's Eclipse project StUIML for one vision of the future. See Matt Holloway's PilferPage for another example. Yet, cross-platform is nowhere near as important as component interoperability.
jemiller:Another thing that I don't understand about Silverlight is why is JavaScript so important? Who wants to write code in JavaScript when you can do it in C#?
JavaScript is necessary merely for talking directly to the browser. I wouldn't say it's "so important". All my SL code is C#.
Silverlight/WPF Mismatch