Most websites glossed over this, but we didn’t. Silverlight, once touted as Microsoft’s answer to Adobe’s Flash, has been retooled from its original purpose. Microsoft is betting big on HTML5 instead, turning Silverlight into the development platform for Windows Phone, and that’s it. So… Silverlight is dead – long live Silerlight?
ZDNet got a chance to speak with Bob Muglia, the Microsoft President overseeing Redmond’s server and tools business, and he was pretty clear about it: Silverlight is Windows Phone’s development platform, while anything cross-platform on the web will be all HTML5, all the time.
“Silverlight is our development platform for Windows Phone,” he said. Silverlight also has some “sweet spots” in media and line-of-business applications, he said.But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.
Silverlight will continue to be a cross-platform solution, working on a variety of operating system/browser platforms, going forward, he said. “But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform,” Muglia said.
Good news for HTML5, I suppose, and for the web as a whole, of course. Silverlight made no sense anyway, since it’s pretty much Windows-only; Moonlight barely works, and the Mac version didn’t really go down well either.
Does this mean that in the near future we wont have to use silverlight for netflix on mac or windows? And maybe just maybe it will finally work on linux??
Nope. HTML5 has no support for DRM. This is the reason YouTube mentioned that Flash is here to stay. The rented content on YouTube is delivered through Flash.
It is unlikely that Netflix will use HTML5 video in its current state, so they will probably continue with Silverlight.
I think he was asking if Netflix will abandon Silverlight/PlayReady, and use something that has proper Linux support, like Flash, which Hulu uses.
He never mentioned the video element or HTML5 support. It’s funny how you could miss that considering it was only two sentences.
Edited 2010-10-29 21:41 UTC
Yeah, of course he was talking about flash in an article about Silverlight and HTML5. Lol.
The article was about Microsoft abandoning Silverlight as a cross-media runtime (which the Flash Player is).
Until Flash reaches the performance of Silverlight in video playback, I don’t think it would happen.
Yes it’s not really cross platform (Moonlight is halfway there), and not gained very high traction, however there are quite a few areas where Silverlight is ahead of competition. One is multimedia, the second one is language support (C#, VB, F#, Python, Ruby, JS, and more), and of course another one is performance – the code is JIT’d most of the time.
So it won’t be the flash replacement, but will probably stay in its (small) market for a while.
But I suppose it’s bad news for Silverlight devs, unless they’re coding for Windows Phone. Is it just me, or does Microsoft have a habit of changing their minds about which of their technologies that devs should be using. Whatever happened to the .NET compact framework?
And getting slightly off-topic, how is WPF coming along? I mean, is it really taking off? I can’t recall sampling any apps that use it, unless they’re so close to the native Win32 look & feel that I didn’t recognize it. I heard they retooled the code editor in VS 2010 to use it, but besides that?
This has been the trend Silverlight has been going in for a while. Moving from a web based flash competitor, to a client side technology. It’s going to converge with WPF and become the One UI Toolkit To Rule Them All.
I don’t know of anyone who still uses Silverlight for pure web content in Microsoft shops, at work we do all our work Out of Browser. It’s a cross platform CLR.
“This has been the trend Silverlight has been going in for a while. Moving from a web based flash competitor, to a client side technology. It’s going to converge with WPF and become the One UI Toolkit To Rule Them All.”
that’s been the plan since before 2.0 was released. after version 1 and around the time 2 was about to be deployed to the world Microsoft realized that Silverlight could be better poised than a flash competitor and quite frankly silverlight is wonderful to work with. i look forward to it’s further integration into windows and windows CE
So it’s just like a Java applet is what you are saying? Strange how similar ideas/solutions come around from time to time.
Meh, Nokia and Novell have done same thing numerous times.
It’s been dumped for Silverlight lol. I think it was mostly used by CE devs who they want to move to WP7. There is also .net micro.
Like ASP AJAX it probably didn’t gain enough of a following to encourage further development.
It’s a two-fold problem of XP users having a large presence and most applications being started before WPF. A lot of the big Windows programs were started in C++ before .NET existed and would be very expensive to convert to WPF. For a program like winzip it wouldn’t matter but itunes would look great in a wpf rewrite.
The decision to use WPF often looks like this:
1. Build a great looking program for Win7/Vista users, but then tweak it so it looks average in XP.
2. Build an average looking program that doesn’t need to be tweaked for XP and also doesn’t require a newer .net pack.
So if you want to see more #1 then get people off XP. Mono also encourages #2 since it doesn’t use WPF.
Silverlight on WP7 uses the .NET Compact Framework. So it’s still alive.
Desktop SL uses full .NET Framework, minus a lot of class libraries.
the performance is pretty ass too. I wrote a fairly simple app awhile back, and the ui was rather sluggish when it came to dynamically updating it, and I was on a quad core with 8 gigs of ram. It also had a really long start time, noticably longer then winforms. Finally, it was virtually unusable over terminal services.
It is a really cool idea, but I wouldn’t do anything serious in it for another few years when either it gets more mature, or average hardware outpaces it.
I’d chalk this as a failed experiment (broken test case?) – I imagine WPF should be pretty fast, since SL gets 60fps on WP7 .
WPF performance can be terrible on older version of Windows i.e. older than Windows 7.
In XP I had dog slow performance with VS 2010 (which is in WPF), I researched the problem and came across the solution … these APIs can be installed on VISTA and XP. Once these were install performance was as comparable as 2005 and 2008.
Yeah, VS2010 is WPF.
In my hobby project I use WPF. I know, it’s not a big project but you can see for yourself that it looks very native: http://code.google.com/p/yet-another-music-application/
How hard is it to create WPF apps… I mean, the ones that look native? Do you have to be a web/graphics designer to make them look decent, or do they have a ‘generic’ mode where you can just layout the controls like windows forms?
WPF apps have default templating to match OS look and feel. You can even switch resources and use the XP look and feel on Vista/7, or the Vista/7 look and feel on XP or vice versa.
WPF is a complex beast, with 10 ways to do the same thing, but it’s the most powerful framework I’ve ever used.
Silverlight is WPF’s less complex distant relative, instead of 10 ways to do something, there’s 2-3.
It’s pretty easy. Most of my design I do in XAML which is very efficient. But sometimes I need to handle the controls in code which works just as you would expect if you are used to WinForms. You can actually access WinForms from within WPF application _exactly_ as you do in your normal WinForms app. Just be careful what namespaces you include so you don’t confuse your compiler.
One thing I love is the ease of modifying controls. You can put a style on it, or completely remake a control just by using templates. This is how I made those playback buttons which were supposed to look somewhat like the buttons in Windows Explorer (in fact I have tried to mimic Explorer pretty much). However, when it’s easy to style your app, some people/corporations will abuse that ability and create computer-vomit, but that’s life.
I used Glade before when doing GTK+ apps, which I enjoyed, so WPF with XAML felt natural for me.
However, I love the Qt toolkit and how easy and powerful it is. When I port my app to Linux I hope to be able to do a Qt and a GTK+ version (because integration is extremely important IMO), so I hope that WPF can give me that separation that I need as well.
Oops! This seems to have gotten out of hand. I should’ve stayed on topic… *flees*
Edited 2010-10-30 04:39 UTC
You will feel pretty stupid after doing both Qt and Gtk uis and seeing that they are identical under Gtk theme.
So what you are saying is that there is absolutely no reason to do GTK+? Remember that there’s not only looks, but also feel. I believe that there’s a need to actually create two versions, since KDE and Gnome are very different in that regard.
Right, unless you absolutely want to use C instead of C++.
Gtk has no different look or “feel” (whatever that means) from Qt when running under Gnome.
Really, they are not. If you find a difference it Qt app look and/or behavior compared to Gtk app, you should file a bug in QGtkStyle.
Can always use mm bindings for gtk (everyone says that they are “better” than pure gtk anyway). Not that I’m defending the need to do a gtk version. Seems superfluous.
Edited 2010-10-30 16:04 UTC
What I meant is, Gtk makes sense if you dislike C++ and want to stick to “pure C”. Qt has no maintained C binding.
I’d go as far as to say preferring GObject to C++ has got to be some kind of yet-unknown mental disorder, but that does happen.
Quite true. I really like C and it is what I have most experience with (programming mcus etc.) but looking at GObject makes me want to puke so I would only consider doing OO with it in the most dire of circumstances.
Yeah, but what about C#? I know Gtk has Mono and Gtk# but what’s the status of QtSharp or Qyoto/Kimono? How are they coming along?
Anyway, I won’t get doing the Linux version this year so I’ll wait and see what approach I will take. But if Qt can give me what I need then maybe I will use only that.
Richard Dale is an osnews regular, if he pops up he can comment in detail.
That said, you don’t really need C# bindings as “training wheels” to enjoy Qt programming – the code reads out basically the same in C++, due to memory management facilities provided by Qt itself (QObject hierarchy, implicit sharing).
With C++, you get the best tooling support (Nokia Qt SDK/Qt Creator). I’m sure you’ll enjoy the experience. I’d go as far as to recommend C++ for beginners instead of various bindings for “easier” languages (Python, C#) for the sake of tooling alone.
That would be the logical route to take.
Problem is: my project is written in C# and I don’t want to rewrite it in C++.
Depending on how many of the .net libraries you used, you might have to write the app again.
If you did consider it’s portability then it might run under mono. Then you’re limited to using it on systems with the mono runtime installed and using the gtk# bindings for the UI.
I don’t quite know how Qymono interacts with Qt and/or mono or if it is more like vala (I don’t know of any app that uses Qymono).
Edited 2010-10-30 18:52 UTC
Exactly. That’s why I am a bit skeptical about Qt since I am not sure how well it supports C#. For Gtk, as I said, there is Mono and Gtk#. But Qt is a different story. :/
Ok, investigating the bindings makes sense in that case.
I developed both http://www.muvaudio.com/ and http://www.muvunder.com/ in WPF. WPF definitely has a learning curve but it allows for some amazing things. Think of it as being similar to the the switch from MFC to Windows Forms.
Also, Blu, another twitter client, was created in WPF.
Developers are learning. Traction is building. Just give it time. HTML5 will be the same. It’s hard to put a lot of effort into learning a new technology until you feel like it’s where it needs to be and won’t just disappear.
What’s with the “Mac version didn’t really go down well” FUD? Seems like a line you threw in just for the hell of it.
As for HTML5 being the future of all app development, I have to thank my lucky stars that I retired from professional programming a few years back.
Edited 2010-10-29 23:29 UTC
Yeah, as someone who routinely needs to make sure Mac perf is the same as PC perf, I’ll just say it right now that the job is made really easy. Performance is nearly identical.
It wasn’t always, but Silverlight 4 has really made it truely cross platform.
Back in my day, the target was to make performance as good as possible, not identical to some other platform.
That being said – I guessed the threat of SL was over after Apple refused to have flash for iOS. It did very little for Flash, but it finally sealed the fate for SL (if even Flash is not ubiquitous, what chance does SL have?)
Identical performance, providing a consistent experience is arguably more important. With that said though, we achieved over 60fps in all scenarios.
Hey, can someone fill me in as to why this isn’t being marked as a landmark change? I don’t mean that in a snide way, I’m genuinely wondering why the reaction seems to be muted, and I’m wondering if I’m missing something. Or why people are considering Silverlight seriously…?
I mean…Microsoft so openly touting an open web standard?? Congratulations, I say! A sure sign that they’re worried, despite their recent quarterly statement.
Because anyone who knows anything about web dev, knows this isn’t a big deal. Silverlight’s huge presence outside of Netflix, is in Out of Browser apps, or WP7 apps.
And lol, Microsoft will use HTML5 alright, to push more Windows lock in. It’s interesting you shun the .NET Developer divisions in Windows (which are more open to standards and interoperability, look at WCF, ADFS, Silverlight for Mac and Symbian) for the Windows division (with notorious history of lock in, who are all salivating to get your HTML5 web app to run better on Windows, faster on Windows, and eventually, only on Windows.)
There are two cultures inside Microsoft, and you’re about to be reintroduced to the one you thought Silverlight masqueraded as for so long.
Good luck.
No, appearances would have it that Silverlight was just as much an attempt to gain lock-in to Microsoft products (so that users had to run Windows in order to be able to access the Internet) as any other ploy Microsoft has used.
Perhaps this article might help to explain the acute image problem that Microsoft now has:
http://www.acrossad.org/node/70
Microsoft’s behaviour is arguably driving whole countries to adopt the very platform that Microsoft are trying to suppress. Microsoft has a long history of this:
http://www.theregister.co.uk/2004/11/18/ballmer_linux_lawsuits/
Perhaps dropping Silverlight and adopting HTML5 is the first tentative move on Microsoft’s part to try to repair this disastrous PR image problem they have generated for themselves.
Who knows? If it is, only good things can come of it.
Edited 2010-10-30 12:20 UTC
Prove it.
Silverlight is not available on Linux, and is a second class citizen anywhere other than on Windows.
It works rather well on Macs, in the Browser and outside it.
Silverlight is not available on Linux, and is a second class citizen anywhere other than on Windows. [/q]
Yes but tbh … I don’t bother writing stuff for a platform that isn’t going to represent less than 5% of the market.
e.g. We have a second mobile website which is going to be deployed sometime at the end of the this month. We need to redirect visitors who are on a mobile to the mobile website. We could have used http://wurfl.sourceforge.net/ this to do the redirect, however we have a CMS from 2001 that is very fragile if the ISAPI rules are changed (i.e. it falls over).
The other route was a JS redirect when the page loaded, by looking at the user agent (a dirty hack I know, but the current website is going to be around for another few months and we are migrating to a newer CMS, this will make do in the meantime).
Obviously phones that had browsers that did not support JS would not be redirected … when I warned my manager of this, he told me not to worry because we don’t have any visitors using a handset that doesn’t have a JS capable browser i.e. iPhone, Android handsets and modern Blackberrys.
The same I expect happens at microsoft, why would they bother supporting a platform that has such a small % of the market? They cannot justify the use of resources.
I do agree though that if they are going to support MacOSX they should make sure that it is of acceptable quality.
Edited 2010-10-31 11:45 UTC
Silverlight for Linux is Moonlight. Officially. Microsoft officially sanctioned the port and gives them interoperability tests and ahead of time information on some subjects.
Silverlight for OSX works just as well as the Windows version. I don’t get the “second class citizen” bullshit, stop making shit up.
Silverlight is not available on Linux. (Moonlight is available, but it is barely useable and even then only for x86 and x86_64, and only after downloading binary-blob codecs from Microsoft).
Silverlight is not available for a whole host of web-connected devices and platforms:
– ARM
– Android
– Symbian
– Palm
– Blackberry
– PPC
… to mention only a few.
This is a sizeable percentage of machines that can otherwise fully participate in the open web.
QED.
Edited 2010-10-31 11:25 UTC
Wrong.
It is available for symbian. But while you’re at it why not add QNX,BeOS, OS/2.
Just because it was unavailable on certain platforms does not invalidate its (ex-) stated mission to be cross platform. Maybe if the strategy had not changed it would eventually get to those platforms.
It is not nearly cross-platform enough, that is the problem.
Also, it is a proprietary technology, which makes it totally unsuitable for use as a web standard.
http://www.w3.org/Consortium/Patent-Policy-20040205/
Why write a web technology that can’t be used on the web by a hefty percentage of web-connected devices, such as some phones, tablets, smartbooks and netbooks, and even some desktops?
BTW – being a “standard” hasn’t anything to do with the bare number of devices that can or cannot use it. A “standard” is meant to enable interoperability across the board for any device from any manufacturer.
Standards are about wide interoperability, not popularity.
“Windows + Mac” just doesn’t cut it. Not by a loooooooonnnng shot.
I doubt that microsoft ever intended to make it a standard. It was always going to be a runtime embedded on a page. If people wanted something more advanced for things like live streaming etc they could use SL. Additions of other platforms would then come as demanded.
If they wanted interoperability with all pcs then they would go someplace else. Either way looking at the development of SL since 2.0 it appears that the narrowed focus has been in effect for a long time.
Edited 2010-10-31 12:15 UTC
They did in fact try to make it a “standard” … or at least a requirement for rendering rich multimedia content over the web … and they failed miserably.
http://www.pcworld.com/article/143232/silverlight_helps_bring_strea…
http://team.silverlight.net/announcement/the-xxi-olympic-winter-gam…
Except that IIS7 smooth streaming is not exclusive to Silverlight. HTML5 can make use of it, and there are instances where it does, like the iPhone streaming Microsoft showed off at MIX09.
KNOW what you’re talking about. Jesus christ, you’re embarassingly clueless.
Many people have tried similar ad hominem attacks before and it has not worked. Don’t bother.
Microsoft’s clear ambition was to make it a requirement for users to have Silverlight installed in order to be able to watch rich multimedia, such as the olympics coverage, over the Internet.
In that ambition they clearly failed. Despite Microsoft repeatedly offering significant incentives, very few content providers have decided to constrain their audiences to just those people with up-to-date Windows by going with Silverlight.
Microsft’s own-the-web ambition for Silverlight has been a clear and pointed failure.
So now they are relegating it to a minor role and to save face they are pretending that this was always its only intended role.
Pfft.
Edited 2010-10-31 21:44 UTC
Don’t go off on a tangent, you’re like a goddamn robot, you don’t respond to points made, you just regurgitate the same misinformation.
Nothing regarding Silverlight streaming was particularly closed. HTML5 can, and did do the variable bitrate streaming that you criticized as a Silverlight only construct. Microsoft themselves in fact pushed this for the iPhone.
The VC1 codec is closed. The licensed H.264 codec is closed. Both of them are available only from microsoft, only as x86/x86_64 binary blobs, and only for SLED.
Parts of the Mono platform, required to run Moonlight on Linux, are closed. The license to run those is available only to SLED customers.
Quote, please.
The VC1 codec is closed. The licensed H.264 codec is closed. Both of them are available only from microsoft, only as x86/x86_64 binary blobs, and only for SLED.
Actually they’re far from requirements, hence why they’re optional additional downloads.
The same way some HTML5 video is H264, other is WebM, and other is Theora, that’s how Silverlight streaming works.
Again, I’ve asked you multiple times, to quit passing judgement on Silverlight as a whole based only on it’s multimedia subsystem which is a very small slice of the pie.
Why not talk about XAML, or the C# language or runtime itself? All which have explicit non aggression promises from Microsoft. Why not talk about those?
Oh, doesn’t fit your narrative, gotcha.
Because they aren’t entirely relevant to this thread.
Put it this way, to try to get through to people that are slow on the uptake: It isn’t the acceptable parts of Silverlight that have caused it to be shunted into a background role out of the main web, it is the unacceptable parts.
If Microsoft were to simply make the restricted parts unrestricted, and able to be implemented by any party for any platform without costs as is the case for XAML, or the C# language or CLI (or indeed as is the case for the competition, HTML5/WebM/CSS3/Javascript/Canvas/SVG), then there would be no issue, and Silverlight would be wholly acceptable and could have become widely implemented and widely used.
Microsoft’s dog-in-the-manger “this bit is for us only” attitude is what has killed, and is still killing, Silverlight. It won’t be widely accepted until Microsoft drop that position.
Actually, belay that. It is probably too late now. Given their previous attitudes, Silverlight will probably never be widely accepted (due to lack of being able to trust what Microsoft say) no matter what Microsoft do now.
It doesn’t matter. As a webprogrammer, you can’t deliver it anyway to all web participants from any host if you use Silverlight.
Edited 2010-11-01 04:54 UTC
I don’t think the restricted portions are restricted at all. Simply write a decoder for your favorite open codec, and your problems are solved. They are bridges you’ll need to cross with HTML5 anyway, so the pain is unavoidable.
The web is just a tangled mess of garbage, slow progress, and backwards programming models. Silverlight on the Web(specifically as a Flash competitor) was not killed by a lack of openness, it was killed by the stupidity of Microsoft. Silverlight on the Desktop (Full trust OOB) and as a WP7 dev platform, is alive and kicking.
The web needs a massive redesign. It will be on the shoulders of a sweeping, pragmatic, and breaking change. It won’t be piecemeal or in any iteration of HTML/CSS/JS. I had hoped Silverlight would be it, but as Silverlight’s ex Product Manager put it, Microsoft has a shiny object syndrome, in which it changes focus really rapidly.
I made no such statement.
If someone had wanted me to make a statement on variable bitrate streaming for open codecs, I would have referred them to this recent blog posting:
http://blog.gingertech.net/2010/10/09/adaptive-http-streaming-for-o…
(also posted on planet.xiph.org)
Yes you did. You mentioned Silverlight being pushed as the defacto multimedia platform. The only differentiating feature in Silverlight for streaming media is IIS smooth streaming.
Aside from that, it’s your run of the mill hardware accelerated H264, VC1, or with SL3+ OGG Vorbis.
The only differentiating faeture of Silverlight that matters to users is when a user encounters a website that says “Silverlight required”. Said user cannot participate in said website without running Windows and downloading Silverlight for that platform.
That requirement is too restricting on users and on client machines. Web content providers will no tolerate it (since it restricts their potential market).
Even a requirement that web content is hosted on IIS is too strict a rquirement to be attractive to many.
If there was a way for users of any browser on any platform to acquire “IIS smooth streaming” for their browser client without necessarily having to be running Windows or x86 or x86_64, and without fear of being sued for it, then that would be acceptable and in line with the requirements of web standards.
Since there is no way to do the latter, then IIS smooth streaming is unacceptable, and hence so is Silverlight.
Microsoft specifically pushed Silverlight Smooth Streaming, which is the main benefit of Silverlight video streaming. That’s the biggie. And it does not require Silverlight. Case closed.
The argument was whether or not Silverlight was using vendor lockin as a result of this push, and the conclusion is that it was not.
It’s perfectly possible for non-IIS servers to implement the technology, it does nothing particularly proprietary, it is a novel idea. Variable bitrate adaptation.
However, I think it was a problem of reach specifically regarding the varible bitrate adaptation (IIS only) and that is the only valid criticism against it. That however, is not the same as purposely trying to lock users into a single vendor.
Why would they be sued for it? Just wondering.
This was never about your subjective definition of acceptable, it was about vendor lock in. Which there is no evidence of Silverlight explicitly doing so. Could they have been on more platforms? Yes. They got the biggies though. Windows, OSX, Linux, Symbian, Windows Phone.
Would they have done so with time? Absolutely. Silverlight, again I stress, is much more than video streaming.
I can do things in Silverlight that webprogrammers can really, only dream of doing in HTML5. The capability is just not there.
The ones who added silverlight so far tolerated it obviously. It is their choice on whether to add SL or not. Some chose to do so others did not.
So what is the problem here. It is the content providers choice on what to show. You or I may not like it but it is hardly the fault of SL that some chose to use a more robust tech at the expense of limiting their reach.
Also Once again I would remind you that streaming video is just a tiny tiny part of what silverlight does. Going on a rampage against video makes you look foolish..
Edited 2010-11-01 11:24 UTC
Once again I would remind you that your ad hominem attacks won’t work, and I make the observation that they only make your case appear all the much weaker in presentation because you feel the need to embark on such attacks.
The problem is that public broadcasts should be accessible to all of the public. A “web standard” is like the standard for broadcast television transmission and reception … all manufacturers should be able to manufacture equipment for either transmission or reception, and any transmitter should work with any receiver.
There must be no “only works if you have the right equipment (from the ‘right’ supplier)”. That is a no-no.
Silverlight simply isn’t a suitable technology for doing anything via the web. It isn’t a matter of what it can or cannot do … that has nothing at all to do with why it isn’t suitable. It isn’t suitable as a standard because it imposes unacceptable constraints on interoperability. It gives an unwarranted advantage to just one supplier.
Don’t get your knickers in a twist … neither is Flash a suitable technology … sole source supplier … therefore also not at all suitable. Period.
H.264 isn’t suitable for similar reasons.
I remind you, once AGAIN, of policy for web standards:
http://www.w3.org/Consortium/Patent-Policy-20040205/
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing
It wouldn’t hurt you to read and understand this policy. You wouldn’t have nearly so many uninformed questions …
Edited 2010-11-01 12:11 UTC
Just because you don’t like doesn’t mean it is unsuitable for certain applications. Define web.
Surely it is ones choice on whether to deploy silverlight on their site or not. It really doesn’t matter wether you consider it unsuitable. My users clearly disagree (they are not even using a sl client in the browser as it is a seperate app).
The web is not a resource to exclude one set of people or another. The web is not built for the private benefit of one company to enhance its monopoly grip on this or that aspect of IT. The web is a global, collective resource. There is no place for lock-out.
This is not simply my view … it is the common interest of all the people on the planet. “Information wants to be free” and all that.
Seriously, to hand over the keys to establishing a monopoly over any part of web services to a single company is foolishness of the highest order. No (objective) sane person would want that. Knowledge is power. etc, etc. I’m sure you have heard it all.
If you hadn’t, here is a bit of old-fashioned wisdom and historical culture for you to peruse:
http://en.wikipedia.org/wiki/Public_Libraries_Act_1850
and here are a couple of far more recent links in the same vein:
http://en.wikipedia.org/wiki/Freedom_of_information
http://en.wikipedia.org/wiki/Digital_freedom
All good stuff.
These things are in the nature of fundamental human rights. I for one am not going to give them away lightly, just because some American company wants a monopoly so it can rip everyone off.
Edited 2010-11-01 12:29 UTC
So basically I have an app that is only used by a select group of people (i.e. not public) but it works over the internet.
So you’re telling me that I’m doing a disservice to those people by choosing the most appropriate technology for the application just because it is silverlight?
I have heard no complaints from users that it is silverlight. Quite the opposite. I had a pleasant time developing it and I did it quickly.
Just who is loosing out in this particular case? You? I couldn’t give two S**ts about your particular phobias, you’re not my intended ‘market’ so to speak.
Likewise, I couldn’t give a flying f*** about what you do.
Do whatever you want … just don’t expect everyone else to agree that “Silverlight required” or “Best viewed in Internet Explorer” is a good idea. You can shove that notion right up where the sun don’t shine.
This page might give you a flavour of the sentiment:
http://toastytech.com/evil/onlyie.html
“Baw, you need a Microsoft Browser to see my pukey page” … seems to fit your position the best.
Edited 2010-11-01 12:49 UTC
I never said that Silverlight should be everywhere. But I did say that it does have its particular applications.
You then proceeded to rampage on about silverlight and video completely ignoring the original sentiment. I recall saying early on in the comments that it hasn’t been the mission of silverlight to become a universal runtime everywhere for quite some time, which you conveniently ignore or are simply too blind to see.
Instead favouring your soapbox for a redundant crusade that really no one cares about.
My Intent was merely to correct you on points related to technology and the freedom of designers to choose whichever tech they felt was best for the application (and yes user access is a function of its utility).
I give up because you are really not arguing against my point but more against some nebulous threat that does not really exist.
stop shoving random links into your comments hoping they prove your point.
just because nbc decided to use silverlight for the olympics streams it does not mean it was a standard. It was one ONE site. Also as I recall moonlight also worked with those streams.
Just because you put standard in speech marks does not allow you to redefine its meaning.
I don’t have to hope for anything … the message behind the story I linked to was perfectly plain for everyone to follow. It speaks for itself.
Microsoft sponsored NBC to use Silverlight for the Olympics. They made a significant number of similar deals and attempts to make a deal elsewhere as well.
I guess even Microsoft cannot continue to pay everybody to use their stuff forever … even for Microsoft there comes a time when they had to announce a new strategy for their failing products that no-one wants.
Which thought, BTW, handily brings us right back on topic for this thread, doesn’t it?
“Microsoft Changes Silverlight Strategy, focusses on HTML5”.
Indeed. Obvious enough I suppose, but welcome nevertheless.
Edited 2010-10-31 21:53 UTC
Silverlight is not meant to mesh with the web, hence why they made it a browser plugin instead of building it directly into IE. Silverlight is meant to supplement the web in scenarios, but overall, it’s meant to serve as a launchpad to an Out of Browser application.
However, to someone like you who has never used Silverlight, beyond your misconception, all ability to communicate and reason is lost.
Hardly. They made it a browser plugin rather than building it directly into IE because to do the latter would mean that it would take more than a decade before most people had bought a new Windows PC and so had Silverlight.
As a plugin, people can “plug it in” to their existing Windows installation. Thankfully, people were slow to do so, and Silverlight never gained the level of market penetration required in order to make it saleable to content providers. Too many machines and devices connected to the web have no Silverlight capability installed … the majority of web-connected devices cannot work with Silverlight but they can work with Flash and now with HTML5/WebM.
That is the fundamental problem with a strategy where one hopes to make it a requirement to use a particular platform and technology in order to view rich web content … too many devices are not that platform and technology, and content providers will shun your lock-in solution as a consequence.
http://gs.statcounter.com/press
“Microsoft’s Internet Explorer browser falls below 50% of worldwide market for first time”
It is and always was a strategy doomed to fail … as we have seen it fail.
Not a biggy … bound to happen.
Edited 2010-10-31 22:09 UTC
I suspect that the engineering levels of MS already saw this long ago ( can clearly be seen in the way SL developed in 3.0 and 4.0). Only that the executive levels have only made it public or caught up right now.
Either way I don’t see anyone mourning, complaining or even surprised at the announcement both outside MS and inside.
well…possibly..small regret, I would say it would be nice to be able to develop web apps using a c like language for the whole stack. Any alternatives?
Edited 2010-10-31 23:01 UTC
No. Silverlight works on Windows XP, Windows Vista, Windows 7 on the Windows side of thing. Building it into IE would have meant it got pushed to those three OSes with the next IE iteration (and given that Silverlight was announced at MIX, it would have lined up perfectly with an IE release.)
Or as an integral part of the web browser, people would get it when they upgraded IE. Seen IE8’s adoption rate? Yeah, it wouldn’t have been hard.
Silverlight has incredible market penetration and an adoption rate that’s very significant. Only bested really by WPF which is nearly ubiquitous on Windows PCs.
You forget that Silverlight is pushed down via Windows Update.
The HTML5 stuff really varies. A lot of mobile browsers have compatibility with proprietary -webkit- HTML5 feature bits, but beyond that, it’s really a mess.
It’s really, ironically funny you don’t see the insane lock in trap the web has walked into.
You forget that “Windows PCs” is not a good enough share of web-connected devices. “Incredible” market penetration? Pfft.
As I siad;
Back to your claims:
If they are proprietary, they are not part of webkit. Webit is based on KHTML, and KHTML was GPL … so webkit is GPL.
For example, Google Chrome includes a proprieaary H.264 codec, but the open source webkit browser code it is based upon, which is Chromium, does not. Chromium can do HTML5/WebM or HTML5/Theora only.
Actually, Opera can also do HTML5/WebM or HTML5/Theora only, and Opera is not based on webkit.
Actually, Firefox can also do HTML5/WebM or HTML5/Theora only, and Opera is not based on webkit.
In point of fact: HTML5/WebM or HTML5/Theora for multimedia is really the only viable way to approach HTML5 at all.
There is no problem at all if one simply avoids H.264 and any other proprietary bits like it. Such an approach is perfectly sane, and very widely supported in recent web browsers, and it is also perfectly in accord with patent policy for the web:
http://www.w3.org/Consortium/Patent-Policy-20040205/
Cheers.
Edited 2010-11-01 02:41 UTC
It’s obvious that Windows has the lionshare of the market for all web connected devices. At least, the ones where rich multimedia is an expectation. Another huge chunk? Symbian. Silverlight for Symbian offers incredible reach, given Nokia’s position in the global market.
This is incorrect. Flash is no more ubiquitous than Silverlight, at least, not by any damning margin.
Are you kidding me? Half of this new age HTML5 web uses proprietary -webkit- CSS extensions, because they jumped on the HTML5 bandwagon before even the W3C recommended it, so they’re using sometimes nonstandard, often times very buggy and non interoperable implementations of an ambiguous standards where a lot of modules are in working draft.
Is this your idea of a free an open web? A chaotic mess of vendor prefixes because no one took the time to responsibly implement HTML5 features, and instead turned it into a popularity contest race to the bottom?
Look at border-radius, see how it differs on nearly every browser when you do anyting beyond simple. That’s just one example, but it’s a good one.
Now compare it to Silverlight. Uniform (down to the pixel) consistency across every platform, uniform performance, and insane reach.
Windows, Linux, OSX 10.4.8+, Symbian, Windows Phone 7.
The platform transcends the web, and is a general purpose application framework, and has been so since Silverlight 2.0 (Which should really be Silverlight 1.0, and we should forget 1.0 ever existed).
Silverlight was never envisioned as a browser only technology, it just uses the browser as a launchpad into the users machine.
Yeah, with half the pages using HTML5 using -webkit- vendor prefixes, the other half using -moz- vendor prefixes, or -o- and the places where they don’t, the implementation is not interoperable anyway because the HTML5 spec is really one big generalized piece of crap.
You’ve walked into a trap, and now, sure, cheer, embrace IE9 going full throated into HTML5. Then watch as IE10, IE11, and IE12 supplement the HTML5 feature set with irresistable Windows only extensions. IE9 HTML5 Taskbar integration is just the tip of the iceberg.
Wait until there’s “HTML5” and then “HTML5+Windows”. Given the unbearably monolithic process the W3C chooses to go through for standardization, Microsoft will be more nimble, and pump these extensions out quickly.
Especially if Windows Phone 7 is any type of success, they’ll add HTML5 to their browser, and add Windows specific implementation bits there.
Your open web will soon turn into a beautiful disaster. Microsoft is calculating, cunning, and in the internal faction war, the bloodthirsty Windows team, who will stop at nothing too see Windows retain dominance, is your new best friend on the web.
You shunned the pragmatic developer divisions at Microsoft (.NET, Silverlight, et all) and instead embrace the Office/Windows divisions, who are the undisputed kings of vendor lockin.
Congrats, you’re all unbelievably naive.
You see, this is where your misconception begins. Silverlight is not only a streaming technology. That’s maybe 1% of what Silverlight is. Silverlight is a cross platform CLR capable of running under full trust on 3 different platforms. Moonlight does this nearly perfectly. It’s a work in progress, but it’s getting there.
You’re delusional if you think HTML5 is implemented the same, even across Gecko or WebKit, so the point is largely moot.
Silverlight runs on ARM (Symbian and Windows Phone 7)
Also, why are you mixing manufacturers with architectures?
You might as well say Silverlight isn’t available on the following platforms:
– Windows
– Linux
– Hamburger
– Potato
– iPhone
See how long and important my list is? I must be right. You’re not honest at all, please be honest.
A lack of reach is not vendor lock in, it just means they don’t have infinite resources ..
You didn’t prove anything, you just further cemented my belief that you know approximately nothing. You continue to disappoint.
Also I don’t think there is anybody stopping one from adding Moonlight to Android.
moonlight doesn’t work
The codecs required to get Moonlight to work with proprietary formats, such as MP3, VC1 and H.264, are only available from Microsoft as binary blobs. x86 or x86_64 binary blobs. AFAIK one must have a SLED license in order to obtain those codec binary blobs.
What exactly would be the point of proting Moonlight to Android, since the majority of Android installations run on ARM?
you get ffmpeg to work with moonlight.
whats your point? The moonlight runtime would just need to be recompiled to run on arm. And seeing as mono runs on arm there shouldn’t be much of a problem.
Mono is not part of Android.
Parts of Mono (for example, Winforms, ADO.NET and ASP.NET) and some of the codecs in ffmpeg are proprietary and patented. There is most definitely no “Promise” of any kind from the patent holders to refrain from suing any projects that include these functions. Paid licenses from Microsoft and MPEG LA are required to avoid lawsuits, for Mono/Moonlight and ffmpeg codecs respectively.
So, in order to avoid threat of lawsuit and use Silverlight with Linux, one must use it only on a platform licensed by Microsoft to run both Mono itself and Moonlight, and one must obtain the codecs as binary blobs from Microsoft. Any other approach means one could be sued.
The binary blobs from Microsoft are x86/x86_64 only, and they are licensed for SLED users only.
Ergo, there is no way to legally run Mono and/or Moonlight, with anything approaching multimedia and database compatibility, under Android on ARM devices.
That is the point.
HTML5/WebM has absolutely no such restrictions. Google has awarded everyone on the planet the necessary licenses, for no cost.
Edited 2010-11-01 01:17 UTC
Mono on embedded platforms (Moonlight, MonoTouch, MonoDroid, etc..) does NOT include ASP.NET, ADO.NET, or WinForms.
The Moonlight streaming functionality is a small subset of what Silverlight as a runtime does. It is so much more rich than that. It is a complete application platform.
If you want, write a WebM decoder for Silverlight (there’s an OGG Vorbis decoder already), and use it as your safety blanket if you’re as worried about it as you say you are (though I suspect your worry is just really fearmongering to make a point).
Except that WebM is not only worse than H264 (which the MPEG-LA has made royalty free to everyone except for top level encoders, but it is a patent question mark. It is naive to suggest that it doesn’t infringe on anything, given that a lot of the implementation is actually very ridiculously close, and not only that, but they did their research, and any infringement would in fact be willful infringement due to the way US Law works.
How is WebM in any way worse than H.264? that is a beauty, an absolute whopper.
H.264 is only free to end users … everyone else in the chain still has to pay a license fee.
WebM is patented, but only WebM has a universal patent grant for everyone to use the technology for no cost. Everyone has a zero-charge license to use WebM. There are no royalties charged for its use in any context.
There have been no cases of anyone using WebM having to go to court … of the two codecs only cases involving poeple using H.264 in some role or another have ever gone to court.
Industry has enough confidence in WebM for a good many companies and organisations to get directly involved (without paying any license fees).
http://www.webmproject.org/about/supporters/
Please, let us stick to the facts here, and remain talking about the actual real world!
Edited 2010-11-01 02:11 UTC
Lower quality encoding than H264, by a long shot.
Yet.
Confidence is often misplaced, and I wouldn’t have that much faith in the US Legal system to be anything but completely backwards.
The fact is that WebM is a big unknown legal wise, because it is unknown how many patents they violate, and it is a valid question given the closeness to H264. The fact that WebM is a less efficient format shows that they went out of their way to avoid H264 patent infringement, which is good, but did they do so in every instance, did they cover every cornercase? One can never be sure, and so far there’s been nothing really to hedge our bets on.
You have no evidence for that whatsoever. The first versions of WebM had a very slow encoder, but it didn’t lack quality-per-bit.
The recent VP8 Codec SDK “Aylesbury” Release described here:
http://blog.webmproject.org/2010/10/vp8-codec-sdk-aylesbury-release…
… lists amongst the features a 20-40% (average 28%) improvement in libvpx decoder speed, and significant improvements in encoder quality-per-bit especially for very noisy, still or slow moving source video. Even the fist versions of webM beat H.264 in lack of artefacts. VP8 makes fast-moving parts of the image blurry, whereas H.264 gives them artefacts … features that aren’t there. Guess which way the human eye actually sees fast-moving images?
The VP8 encoder is very probably better now than the H.264 encoder. It is still probably horribly slow, granted, but it can probably give better quality-per-bit results.
Indeed. Zero is still zero.
So … I gather you couldn’t come up with a decent response to that one, hey troll.
Ah, one can almost smell the FUD flying here.
It is perfectly well known … there have been no cases of anyone taken to court for their use of WebM. Zero. Fact.
Two points: 1. WebM is not less efficient, it is just different. For example, WebM makes fast-moving parts of the video very blurry … but that doesn’t matter because the eye sees fast motion as a blur anyway. H.264 doesn’t do that, its optimisations have a totally different effect … fast-moving parts of an image are sharp but exhibit artefacts. It doesn’t matter because the eye sees fast motion as a blur anyway. However … H.264 might score higher on a computer score such as PSNR … but it doesn’t matter as the eye sees fast motion as a blur anyway.
Get it? Subjectively, the quality-per-bit of both codecs is fine, and very comparable. But they work in very different ways. Objectively, you might measure a big difference one way or the other … but the eye cannot see it.
2. The WebM video codec is also known as VP8 … it follows on from a long line numbering VP7 before it, and VP6 before that and so on. All along the line On2 technologies patented their methods and studiously avoided any methods claimed by the MPEG LA group. They were long-standing holdouts, and never joined the MPEG LA group.
http://en.wikipedia.org/wiki/On2#History
On2’s long history in video codecs goes back to 1990 or earlier, when it was known as the Duck Corporation. In all that time they have been making codecs and avoiding entanglements with MPEG LA patents.
So, very much against your claim, there is actually a twenty-year history of competing with but never being successfully sued by MPEG LA to hedge your bets on.
Edited 2010-11-01 09:53 UTC
Indeed
As an inheritor to a large SL project, I did not get the choice of framework to use. But learning and using SL has been a blast.
There are some really nice ways that one can abstract the ui from the app logic, and the framework is really easy to learn.
Also there is some really good documentation and examples both from inside ms and outside.
And it goes without saying that being able to use one language (c#) for the backend all the way to the UI is much better than dealing with the mishmash of paradigms and languages that come with other forms of web development.
It’s quite interesting to see that the big companies finally see the HTML5 standards as the way to go for most web experience. If only Microsoft would extend this type of idea for everything else (eg .docx). If only. *sigh*
In Microsoft’s defence, when you run Office 2010 for the first time it asks you if you want to use ODF or DOCX formats.
And what if you want to use DOC 2000/XP in order to be compatible with what most people use ? I mean… Last time I checked, OO compatibility with docx was poor and office compatibility with ODF was awful. Doc is just the universal format of today when you don’t have high demands and can’t send read-only files (otherwise, PDF is the way to go anyway =))
Edited 2010-10-30 12:58 UTC
If one was going to use “poor” to describe OO compatibility with docx (which is possibly fair enough), then one needs a many-times-over stronger word than “awful” to describe MS Office compatibility with ODF.
If two users, one with OpenOffice and the other with MS Office, are exchanging files, then the user with OpenOffice is the one who is going to have a lot less trouble of the two.
Edited 2010-10-30 13:07 UTC
I don’t have Word 2010, but Word 2007 allows the user to set an option indicating what the default “Save” format should be. Including the old .doc format. As well as .rtf, .odt, .docx, .html, .mhtml, .txt, .xml, etc…
It is just a pity that the Word 2007 .odt format doesn’t work with anything but Word. Strangely enough, every other implementation of .odt on the planet is far more interoperable.
In a similar-in-some-ways but different fashion, the Word 2007 .docx format is not OOXML.
Amazing consistency, really. Kind of an anything-but-a-standard approach to non-interoperability. Also a kind of see-if-we-can-get-odt-to-be-seen-as-not-interoperable sabotage. Microsoft do it well.
It is interesting to see what’s going to happen with Moonlight now. At least it doesn’t seem as urgent now that SL as web plugin ends up being less of a requirement than anticipated at the time that project was founded…
If Moonlight isn’t a “requirement” (it never was, BTW), then what of Mono?
Mono has entirely different dynamics from Moonlight. While ML was more of a “browser plugin” / utility thing, Mono is a development environment. Haskell or Common Lisp are not “required” either, but they have a reason to be available because some people like to code using them – and one thing Open Source should endorse is people’s freedom to write code in whatever environment works for them.
I bet most of us agree that Mono should not be a critical part of the free desktop infrastructure (due to the close MS ties), but if it gives us a few cool apps – why not have it around, net benefit is bigger than the small risk it bears.
Edited 2010-10-30 18:02 UTC
It’s still a more advanced desktop UI framework than just about anything else, which was what Miguel was primarily interested in to begin with. He even had it working out-of-browser on Linux before Microsoft added the feature to their own Silverlight.
One one hand I’m really happy that this will FINALLY put an end to the moonlight bashing. On the other hand I’m a bit sad that this will forever make this great platform a niche product.
Although I have some understanding for the “open source” fanboys (most of them seem to be non developers) outright hatred against anything .net I /really/ like the architecture of the silverlight platform. I guess it’s time to move on.
Honestly Silverlight is not that bad, even on a Mac. If I had to choose between flash or silverlight, flash would hit the dumpster. I hate watching videos in flash on my MacBook as it uses so much CPU that the fans kick on and it sounds like my MacBook is going to fly off my desk. OK that is an exaggeration, it’s not that loud, certainly not HP laptop loud! But still it shouldn’t be that way if flash was more efficient and not such a dog.
Silverlight, on the other hand, does not cause my fans to blast up to full. I watched an hour or so of MSDN video in silverlight the other night and it was fine, no airplane on my desk! 😀
Of course, I suppose neither one would be a better choice, but unfortunately that means you don’t get a lot of content on the web. So for now it is life.
Anecdotal evidence (i.e. I heard it on “Linux Action Show” podcast) suggests that the Flash 10 betas for Linux use hardly any CPU when watching video. Same will probably apply for macs.
Edited 2010-10-31 06:08 UTC
If I remember well, on my Athlon 3000+/1GB RAM/7800GT config, it was a bit heavy for video playback but still acceptable (~20-30% CPU on Ubuntu 9.04 vs 60+% on older releases).
On Mac, I heard that there were some major improvements for some Mac hardware using the “Gala” beta, too.
Edited 2010-10-31 09:06 UTC
Major, but still not good.
On the smallest youtube video I get 30% cpu usage. On 720p it climbs up to 50%. This is all with the latest beta flash for mac.
Exactly. Silverlight absolutely crushes Flash when it comes to performance on OSX. It’s not a competition.
If DRM is a barrier to HTML5 and Netflix, then I wonder how Netflix is on so many devices.
iPhone = not using Silverlight
iPad = not using Silverlight
Mac = Silverlight
Wii = ??
PS3 = ??
Anybody know how it’s being technically implemented on the iPhone for instance? The streams have to be H.264 I’m thinking, but how is it being delivered.
Those devices are closed by nature, so I think they can do it without much risk.
There no point in implementing software DRM when the device and firmware DRM.
iPad,iPhone,Wii andd PS3 are all sealed DRM’ed devices.
My question is mainly technical. Does anybody know what codec/mechanism Netflix uses for those devices? Why bury my comment? I’m just asking.