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 418090
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Very solid
by arbour42 on Fri 9th Apr 2010 17:36 UTC in reply to "RE: Very solid"
Member since:

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:

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 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[4]: Very solid
by smex on Mon 12th Apr 2010 15:34 in reply to "RE[3]: Very solid"
smex Member since:

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

IronRuby does negate some of what you say regarding this point. SL has a long life ahead of it and who knows how it will improve in the future.

Reply Parent Score: 1