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 418016
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Very solid
by google_ninja on Fri 9th Apr 2010 12:41 UTC in reply to "Very solid"
google_ninja
Member since:
2006-02-05

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.

The down sides to SL is that moonlight lags at least a major revision behind and the mac version blows, so realistically it is only single platform, the performance of it (and all WPF) is absolutely terrible, the design of XAML and its APIs still leaves a great deal to be desired, 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.

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. If you are doing client facing controls, there is no reason not to use flash.

Reply Parent Score: 2

RE[2]: Very solid
by Nelson on Fri 9th Apr 2010 15:12 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[2]: Very solid
by arbour42 on Fri 9th Apr 2010 17:36 in reply to "RE: Very solid"
arbour42 Member since:
2005-07-06

I have to disagree with much of what you said. I've been a very hard critic of MS over the years, but what they're doing now is quite good. And the guys doing Mix weren't hesitant to point out flaws. It wasn't some rah-rah session.

I've used most of the Javascript frameworks, and it has mostly been disappointing. The dynamic typing of JS is a huge problem, especially as code bases get large. That's why Google wrote GWT in Java, and 280 Slides is written in Cappuccino, in strongly-typed Objective-J. Creating Linq queries which are strongly-typed is a HUGE plus.

As for performance, on my 4 year old Vaio with 1gb ram, VS 2010 runs fine, and that's a WPF app itself. Large SL apps with a lot of animations sometimes lag a little, but less-graphic ones do just fine, as does video.

XAML and the API are not a weakness. The new Flex component system looks eerily similar to WPF/SL - I wonder why Adobe ditched the old component model, and now mimics WPF?

At this point, to build large web programs, I only see SL, GWT (but with add-ons like Ext-GWT), and Cappuccino.

Reply Parent Score: 1

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

If you think dynamic typing is a weakness for large codebases, I would encourage you to go deep with a good dynamic language (like python or ruby). There is a tradeoff in static typing between performance and being able to catching a certain class of bug, with flexibility and succinctness. I find often in a direct comparison, i can write the same thing in a third to a fifth of the code that it takes me to do the same thing in C#, and the code is simpler and more readable in ruby. Not only that, most of what makes a big codebase big is introducing flexbility through polymorphism and loose coupling. In dynamic languages, often that is built right into the language itself, which eliminates entire layers of architecture.

The problem with XAML is that there is far too much going on in the markup. In well designed web interfaces, there is a seperation between structure, behavior, and style. That seperation reduces the complexity of all three bits, because over the years we have found that rolling all of them together produces a big ball of mud. XAML rolls them all together. Not only that, but the markup is more on the verbose side, making it extremely difficult to read or maintain a .xaml file of sufficient complexity.

Now, you can pull style out into global resources (although still using xml, which is rather ugh), and behavior out into C#. The problem here is that the C# equivilents to the things designed to be done in XAML are not all that great (which is understandable). This was a design concession, because they wanted the designer to have full access to everything from blend. While that is cool, it leads to poor code (as always happens when you are using design surfaces), and there isn't any realistic options to not go that way.

My problem isn't with using xml to define structure, (which MS didn't invent btw, in linux, gnome apps have worked that way for years, and it is the only way to build mac applications) my problem is some serious issues for people like me who are NOT interested in banging out crappy apps quickly. Thats not to say there isn't a lot I like about WPF, but that isn't what we are talking about ;-)

WRT studio performance, like I said before, a single project with a few code files in it is fine. Im talking about half a million+ loc spread accross a dozen or so projects in a solution, where you actually need an IDE to manage everything. But either way, you can't compare studio to the requirements of a good editor and thats it.

Anyways, I would recommend checking out some Herding Code episodes from a few months back when they were talking about SL and WPF a lot, they brought these things up with people from the mothership, and they were acknowledged as legitimate concerns. I would also recommend reading this http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html. The first time I read it, I didn't think he was right. Over the next two years, working with big, hefty codebases of various levels of quality, and learning some dynamic languages, I have gone from not agreeing with him, to completely agreeing with him. Even if you don't, it is still worth getting to hear that point of view from an extremely experienced and talented developer who has worked with a lot of languages in a lot of environments.

Reply Parent Score: 2

RE[2]: Very solid
by nt_jerkface on Sun 11th Apr 2010 17:27 in reply to "RE: Very solid"
nt_jerkface Member since:
2009-08-26

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


Heh? If you're doing controls for an intranet app you don't have the install base problem and if your team is familiar with .net using Flash would be a total waste of time.

Reply Parent Score: 2

RE[3]: Very solid
by darknexus on Mon 12th Apr 2010 00:51 in reply to "RE[2]: Very solid"
darknexus Member since:
2008-07-15

If you're doing controls for an intranet app you don't have the install base problem


Not necessarily, especially if you're in a company with a mixed environment such as some Windows machines and some Macs. True there's an sl for Mac but at the moment it's lagging behind the Windows version. If you do have a mixed environment, Silverlight is probably not what you want to use unless you know that only your Windows machines will need to access the intranet app in question.

Reply Parent Score: 2