Linked by Thom Holwerda on Wed 3rd Mar 2010 20:21 UTC, submitted by poundsmack
Internet Explorer "With the latest releases of Opera, Google Chrome and Firefox continuing to push the boundaries of the web, the once-dominant Internet Explorer is looking less and less relevant every day. But we should expect Microsoft to go on the offensive at its upcoming MIX 2010 developer conference in Las Vegas, where, it has been speculated, the company will demonstrate the first beta builds of Internet Explorer 9 and possibly offer a preview release of the browser to developers. Several clues point to the possibility that the next version of IE will include broad support for HTML5 elements, vector graphics and emerging CSS standards. If Microsoft plays its cards right in Vegas, IE 9 could be the release that helps IE get its groove back in the web browser game."
Thread beginning with comment 412294
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Comment by Kroc
by Nelson on Fri 5th Mar 2010 01:43 UTC in reply to "RE[5]: Comment by Kroc"
Nelson
Member since:
2005-11-29

COM Automation in Silverlight is limited to Out of Browser applications, which require Full Trust, and are extremely rare in their use. Your run of the mill Silverlight website won't use it.

The most common use case for COM Automation in SL4 would be in-house clients designed for consumption internally.

The WebBrowser complaint is also something which again, requires a full trust OOB application to use. To be honest, you'd be hard pressed to find a scenario where you'd even want to embed a webbrowser inside a Silverlight canvas ontop of another webbrowser.

Anything else? No? Ok.

Find me any combination of open standards which do anything even remotely close to what Silverlight does, and I'll be glad to pick the technologies apart.

I've been following Silverlight since it was a glimmer in the eye of Avalon at PDC03, and I've seen (through various Avalon Alphas and WinFX CTPs) the extreme lengths they went through to try to mesh a bunch of sub-par webstandards together. The result was lacking in so much cohesion that they just scrapped it all.

XAML does what it does better than XUL and HTML
ControlTemplates/Styles do what they do better than CSS
XAML's SVG support is on-par with SVG to the point where the differences are really small.
and of course, the JIT Compiler of the .NET Framework slaps the shit out of the fastest Javascript engine out there.

Reply Parent Score: 3

RE[7]: Comment by Kroc
by lemur2 on Fri 5th Mar 2010 04:52 in reply to "RE[6]: Comment by Kroc"
lemur2 Member since:
2007-02-17

COM Automation in Silverlight is limited to Out of Browser applications, which require Full Trust, and are extremely rare in their use. Your run of the mill Silverlight website won't use it. The most common use case for COM Automation in SL4 would be in-house clients designed for consumption internally. The WebBrowser complaint is also something which again, requires a full trust OOB application to use. To be honest, you'd be hard pressed to find a scenario where you'd even want to embed a webbrowser inside a Silverlight canvas ontop of another webbrowser. Anything else? No?


Actually, yes. Two OSes (Windows and OSX) does NOT qualify as "cross-platform". Sorry. How about the plethora of other platforms which can access the web, hmmmmm?

Ok. Find me any combination of open standards which do anything even remotely close to what Silverlight does, and I'll be glad to pick the technologies apart.


The entire set. Silverlight is just a re-write (in order to obscure) SVG, DOM2/DOM3 and ECMAScript.

I've been following Silverlight since it was a glimmer in the eye of Avalon at PDC03, and I've seen (through various Avalon Alphas and WinFX CTPs) the extreme lengths they went through to try to mesh a bunch of sub-par webstandards together. The result was lacking in so much cohesion that they just scrapped it all. XAML does what it does better than XUL and HTML ControlTemplates/Styles do what they do better than CSS XAML's SVG support is on-par with SVG to the point where the differences are really small. and of course, the JIT Compiler of the .NET Framework slaps the shit out of the fastest Javascript engine out there.


Blah, blah, blah.

Why re-implement SVG? Just do the real thing, then it would be acceptable. Also implement DOM3, CSS3, HTML5, ECMAscript (correctly) with a decent JIT compiler, SMIL, etc. Why scrunge it all up and regurgitate it as Silverlight? What is the point?

If Microsoft want Silverlight/.NET to be a standard, then make it so. It is simple really ... make it so that anyone may implement, no roylaties, no patented proprietary bits (such as multimedia codecs, Winforms, ASP.NET or ADO.NET), no caveats about "non-commercial development" etc, etc. No threats. No talk of any need for "indemnity".

If Microsoft did that, then Silverlight/.NET can become a public-access web standard.

Not otherwise. No way.

People just aren't going to swallow that kind of malarky from Microsoft any more.

Reply Parent Score: 2

RE[8]: Comment by Kroc
by Nelson on Fri 5th Mar 2010 23:23 in reply to "RE[7]: Comment by Kroc"
Nelson Member since:
2005-11-29


Actually, yes. Two OSes (Windows and OSX) does NOT qualify as "cross-platform". Sorry. How about the plethora of other platforms which can access the web, hmmmmm?


That's almost coverage of 100% of the desktop market.


The entire set. Silverlight is just a re-write (in order to obscure) SVG, DOM2/DOM3 and ECMAScript.


Everything done in Silverlight is done better than these collection of standards. They lack cohesion.


Blah, blah, blah.


Oh, I see. You're so blinded by ideology that you put your hand over your ears and try to drown out reason. I must give you credit, you're certainly consistent in your nonsensical rants.


Why re-implement SVG? Just do the real thing, then it would be acceptable. Also implement DOM3, CSS3, HTML5, ECMAscript (correctly) with a decent JIT compiler, SMIL, etc. Why scrunge it all up and regurgitate it as Silverlight? What is the point?


I find it interesting you use the word regurgitate. Silverlight is the sum of it's parts, and it does so wonderfully. With open standards, you're often left with a scenario where you're trying to fit a round plug into a square hole.

I believe Microsoft will implement these standards as they make sense. However, these standards and Silverlight can coexist. People can choose what they like.

Companies, like the one I work for, can evaluate their options.

Hmm, should I have my programmers spend time using Javascript, which by probably every possible measure is firmly below any .NET language, or should I let them be productive with tools they've already been trained for?

How about using a world class IDE and Designer? Writing scalable applications? Yeah, o. Sorry, next to impossible.

Debugger support which doesn't blow? A declarative UI markup language (HTML5, XHTML, and even XUL make shitty declarative markup languages for UI. I've tried to use them all, and specifically XUL, falls flat on it's face).

I can be more productive with Silverlight than with any other web framework on the planet.

It's actually quite comical that people suggest retarding the progress of web programming for the sake of singing cumbaya with RMS.

XAML has a 1:1 mapping with .NET objects, that kind of cohesion is something you will never get with the mish mash of open standards you're advocating.



If Microsoft want Silverlight/.NET to be a standard, then make it so. It is simple really ... make it so that anyone may implement, no roylaties, no patented proprietary bits (such as multimedia codecs, Winforms, ASP.NET or ADO.NET)


Silverlight is a small subset of the .NET Framework. ASP.NET, ADO.NET, and Winforms are not a part of it.

The Media codec you choose to use with Silverlight is entirely up to you.

Reply Parent Score: 2