Linked by Thom Holwerda on Thu 8th Apr 2010 22:35 UTC, submitted by poundsmack
Microsoft "While Adobe has been getting most of the press recently for their Flash 10.1 RC, Microsoft has quietly announced their plans to release the final version of Silverlight 4.0 as early as next week. This major update will provide more fundamental changes than prior iterations, including Google Chrome support, better performance (up to 200% over Silverlight 3), improved security with digital signing and sandboxing, and greater control for developers."
Thread beginning with comment 418056
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Very solid
by Nelson on Fri 9th Apr 2010 15:12 UTC in reply to "RE: Very solid"
Nelson
Member since:
2005-11-29

So the thing to remember about MS conferences nowadays is they are mostly commercials for ms products. As long as you keep that in mind, you can still find great sessions, but you have to keep that in mind. I find MIX especially has deteriorated the last few years. The comment about javascript being too hard to work with is very typical of the microsoft community, and explains why there are very few public facing sites using the microsoft stack.


But I mean it's true, Javascript is an abomination of a language. With C# you get VS2010 which has world class debugging and profiling support (even concurrency profiling).


The down sides to SL is that moonlight lags at least a major revision behind and the mac version blows


Moonlight is compatible with most of SL2 (SL3 is just sprinkles ontop of SL2) and even supports some SL4 stuff.

The only real reason is that Silverlight had a lot of catching up to do to reach parity with WPF in any meaningful manner.

Things should settle down soon.

I've been (real recently) doing full trust OOB development on Windows and OSX and have run into no such performance problems. However I just started testing OSX during SL4's development phase.


the performance of it (and all WPF) is absolutely terrible


I strongly disagree here. WPF and SL are one of those things that if proper care is taken, run much faster than the competition. Especially WPF.


the design of XAML and its APIs still leaves a great deal to be desired


Like what?


and finally, its got a single platform development environment that requires really beefy tools (you need a pretty powerful machine to run VS properly), combined with its newness which makes it difficult to find people with experience in it.


VS2010 was shown running just fine on a netbook. Incidentally, a great portion of VS2010 is written in WPF and managed code.

Additionally, VS2010 is only half of the equation. Any good WPF/SL developer will either know how to use the Expression Suite, or have a designer who knows how to use it.

Sure, I can pump out XAML by hand or use VS2010's designer (which is very good), but Blend just blows my mind with how productive you can be.

Watch some of the MIX Panels using Blend 4 and you'll see what I'm talking about.


It is good for rich controls in existing ASP.net intranet apps written by good teams of .net developers who aren't scared of learning something new, but thats about it. If you are doing a full app in silverlight, there is no reason not to just do it in WPF with XBAP.


Whoa no. Red flag. XBAPs are terrible and need to die off. My experience with XBAPs have been terrible, deployment really blows on anything other than IE, and it requires the machine to have the full blown .NET Framework installed (Which is now ~35MB but at the time was over 300MB). SL by comparison is 5-7MB.

They also cannot be run full trust like Silverlight can, well at least not easily. Which ties into the whole deployment mess.

Silverlight has largely eliminated the need for XBAPs and thank god for that.

If you are doing client facing controls, there is no reason not to use flash.


Flash really holds no water to Silverlight. There is no area where Flash excels and Silverlight does not.

Reply Parent Score: 3

RE[3]: Very solid
by google_ninja on Fri 9th Apr 2010 16:04 in reply to "RE[2]: Very solid"
google_ninja Member since:
2006-02-05

But I mean it's true, Javascript is an abomination of a language. With C# you get VS2010 which has world class debugging and profiling support (even concurrency profiling).


Ok, so it has some real nasty warts (automatic type coercion if you use == instead of === for example), but if you play to its strengths, it is a phenomenal language. For example, its functions and inheritance model blow the equivalents in c# out of the water.

I strongly disagree here. WPF and SL are one of those things that if proper care is taken, run much faster than the competition. Especially WPF.


So I work in a .net shop, and we recently re-wrote an internal winforms app in wpf. Startup time is at least 3x as long, ram usage isn't comparable, and there are frequent lags in the UI during things like databinding. The back end functionality is mostly the same, and we were building things the way the guidance says to (so we aren't blocking the UI thread or anything like that). There is also some bug or something that makes it perform rediculesly bad in terminal services.

VS2010 was shown running just fine on a netbook. Incidentally, a great portion of VS2010 is written in WPF and managed code.


VS runs great when you are running a project with 5 code files and a few hundred loc. You need a beefy machine when you are talking about a solution with a dozen projects and half a million loc though.

Sure, I can pump out XAML by hand or use VS2010's designer (which is very good), but Blend just blows my mind with how productive you can be.


I'm not exactly a program by drag and drop kind of guy. All my wpf work has been done writing XAML.

Whoa no. Red flag. XBAPs are terrible and need to die off. My experience with XBAPs have been terrible, deployment really blows on anything other than IE, and it requires the machine to have the full blown .NET Framework installed (Which is now ~35MB but at the time was over 300MB). SL by comparison is 5-7MB.


So I've never actually used XBAP, just knew it was there ;-) That makes a good use case for SL then, when you dont want to use click once.

Flash really holds no water to Silverlight. There is no area where Flash excels and Silverlight does not.


I work at a company where the devs write asp.net controls that the designers use to build our sites. We have been trying for years to get them to switch to the microsoft stack, and each time a new version comes out, its the same response, it just doesn't come close to comparing what adobe offers.

Thats what I am basing that opinion on, so if our designers are the exception to the rule, I'll admit to being wrong. I doubt it though.

Reply Parent Score: 2

RE[4]: Very solid
by Nelson on Fri 9th Apr 2010 17:34 in reply to "RE[3]: Very solid"
Nelson Member since:
2005-11-29


but if you play to its strengths, it is a phenomenal language. For example, its functions and inheritance model blow the equivalents in c# out of the water.


I don't really think so, especially in .NET4 with dynamic and ExpandoObject, a lot of the strengths of Javascript's dynamicism is offset.


So I work in a .net shop, and we recently re-wrote an internal winforms app in wpf. Startup time is at least 3x as long


For this you need to profile. Get things out of the startup path, use Lazy<T> to lazy-load heavy objects. Use NGen to improve cold start. There's really a ton you can do, but you'll never know until you profile.


ram usage isn't comparable


Profiling helps here too. In WPF you can freeze resources to lower memory consumptions, simplify control templates to reduce visual complexity, implement data and ui virtualization, etc.


and there are frequent lags in the UI during things like databinding. The back end functionality is mostly the same, and we were building things the way the guidance says to (so we aren't blocking the UI thread or anything like that).


This can be debugged in the IDE, and check to make sure you're not binding to CLR properties, but to dependency properties. For your backend adapter, ensure you're implementing INotifyPropertyChanged / INotifyCollectionChanged (via ObservableCollection).

Another thing to note is that crossing thread boundaries often has the same effect as blocking your UI thread. For high frequency updates (since things like ObservableCollection need to be updated on the UI thread), I batch updates by a few milliseconds, greatly improving UI responsiveness.


There is also some bug or something that makes it perform rediculesly bad in terminal services.


This is limited by the speed at which bytes can be sent over a network.

For WPF you need to minimize this as much as possible.
First, you can cap the framerate of animations, or eliminate them all together.

Use SolidColorBrush instead of the various GradientBrushes, and eliminate various BitmapEffects (or just Effects in general) and don't do 3D.

There are new APIs in .NET like VisualScrollAreaClip to help increase perf in Terminal Server scenarios.

But really you just need to profile. WpfPerf can show dirty region updates, laser in on these and try to reduce their frequency or complexity.


VS runs great when you are running a project with 5 code files and a few hundred loc. You need a beefy machine when you are talking about a solution with a dozen projects and half a million loc though.


Well it's actually quite modest regardless. However, I'll concede that point. However I think it's a very specialized scenario.


I'm not exactly a program by drag and drop kind of guy. All my wpf work has been done writing XAML.


Heh, same here. At work the designers hand us the Blend generated XAML (which is quite reasonable) and I manually make whatever tweaks I need. It's become pretty good at generating smart XAML. Unlike other WYSIWYG tools.

They make it pretty, I make it pretty and fast.


I work at a company where the devs write asp.net controls that the designers use to build our sites. We have been trying for years to get them to switch to the microsoft stack, and each time a new version comes out, its the same response, it just doesn't come close to comparing what adobe offers.

Thats what I am basing that opinion on, so if our designers are the exception to the rule, I'll admit to being wrong. I doubt it though.


Maybe there is something I'm missing. Maybe I'm also terribly biased, but I've just become infatuated with the Expression Suite.

Reply Parent Score: 3