Scott Hanselman

You've made a great argument for chrome frame.

Another thing to consider, regarding older versions of IE and relying on plugins like Flash/Silverlight, is the Chrome Frame plugin. It's not perfect, but it brings IE6+ up to nearly Chrome's level of HTML5 support for selected sites/pages/apps, without sacrificing IE6 compatibility on pages that don't target it. If you're going to use a plugin anyway, might as well use one that helps you develop sites that will be widely-compatible in the future, rather than moving from one lock-in situation to another.

I've made an argument for thoughtful and consciously aware use of Plugins, I think.

This is all good common sense, but ignores the fact that some projects are planned and implemented across multiple years. Selecting a platform isn't a matter of start with technology X, if technology Y gets better then jump over and rewrite for Y. This approach just isn't feasible for large projects.

The evangalizing of IE9 recently has a lot of developers confused, how can Microsoft push a technology that's incompatible with its runtime platform and only very limited support in its developer tools. We've seen the fallout from the PDC last year, and the confusion continues with questions like this. Where's the bridging technolgy? The GWT equivalent? Even Script# looks like it's been pushed into open source pasture.

Is the official position really that HTML5 is the strategic client side target platform and that developers should look at the community for frameworks to support this?

They are definitely making a big bet on HTML5, which seems a safe one. I think you can count on XAML, HTML5 and Win32 as being the choices for the next 5-10 years, no question.

Although not directly applicable to Silverlight. Many of the points made here are applicable to choosing technology. http://www.udidahan.com/2010/04/23/thoughts-on-microsoft-history-and-oss/

In all fairness I think the work the MVC team and WCF team with Glenn Block are leaps and bounds in a better direction, let's hope it continues.

if I was planning to develop a large web application now, a technology that could be EOL in five years doesn't sound like a good bet to me. I think this is why the strategy has a lot of people scratching their heads. We've either only heard part of the story, or Microsoft just gave up on the client and outsourced it to standards committees and the community.

I don't mean to continue to rant, but.... if Microsoft was really serious about HTML/CSS/JavaScript as a strategic client platform then why not encourage a much better client architecture?

I mean, standardize on a bytecode/IL instead of a scripting langauge for runtime execution.

Establish a formal HAL for low-level rendering primitives.

Build all high-level UI constructs on-top of the low-level primitives. This would lead to templated, bootstrapped UI controls and not the separate silos of different UI frameworks that we have now in the browser.

Define browser layout behavior and controls using the above bytecode/IL standard. Just think how much compatibility problems this would solve.

Specify a web application meta-data model for open app-store standard.

I don't see the leadership here.

Joe - Good points, all. There's a lot of work going on in this space, and I think you'll see a more cohesive story soon.

The people who assume it's an "either-or" strategy for Microsoft are falling for that old fallacy. Of course MSFT is trying to show that IE9 runs HTML5 best... and best on Windows. Duh.

Of course there's a place for plugins. All you had to do was pay scant attention to MIX to see where plugins are headed.

It's become so pointless to argue with the group of people that pounce on every new blog post that makes the common sense argument that there are great tools in the toolbelt... use them. I didn't realize the developer community was so hard headed as to want only to have a hammer.

You begin by saying "I don't think it's that hard and I'm surprised there's so much confusion" and then present a rather complex (implied) decision matrix whose criteria are themselves open to discussion and interpretation.

I like where you're going and I think you've made the options clear enough with the obvious cases. I agree also that a SL app that merely tosses some textboxes on the screen might as well be an MVC app.

But once you enter data-driven, interactive application territory ... which I think is the perspective of the folks asking the questions ... I'm not sure you've made the choices less difficult or less confusing. For example, saying "it depends on where you and your company's core skillset lies" is always sound advice ... unless the company is trying to figure out what skill sets it ought to have (or ought to acquire) to be in the "best position" to develop and maintain applications over the next 5-10 years. Just because I'm comfortable in Cobol doesn't mean I should make a career of it ... or build my next application in it.

Shifting gears a bit, I think you could have made an interesting and useful case had you compared MVC with SL as business app development platforms. I am not as comfortable as you seem to be in suggesting that Knockout.JS (way cool, btw) is in the same league as Silverlight ... or that the libraries, tools, patterns and practices for heavy duty JavaScript client app development are anywhere close to par with comparables in the SL eco-system.

I chuckled when I read your conclusion: "Until then, it's simple. Use HTML when it makes sense to your solution." You could just as easily have written: "Until then, it's simple. Use Silverlight when it makes sense to your solution. " 'cause if "it makes sense to your solution", well why would you do otherwise?

While I enjoyed your perspective - as usual - I confess I do not feel any closer to picking the horse to bet on if I'm building an LOB app this year ... or next.

Ward - Sorry this post isn't clear enough. It was my goal, and continues to be, a straight talker. I thought this was pretty clear.

Bet on HTML, no question. The weight of the web and the crowd is heavier than anything else. The avalanche has begun, it's too late for the pebbles to vote. HTML for web apps, yes. That's clear and understood.

When HTML5 doesn't do something you want, use a plugin. Also clear.

One day, what plugins do will show up in HTML, so you don't need to use a plugin for that thing. Then, later, a plugin will do something new. HTML isn't go anywhere for the next 20 years.

My "matrix" was just some examples.

As for Knockout, I'm saying that HTML has databinding and that "Text boxes over data" isn't a good enough reason to switch off HTML.

On your comments on my conclusion. Bet on HTML. HTML drives the web and Silverlight sits on top of it.

Who is your audience? That is the first question, is it corporate windows environment where everything is controlled? Is it the latest buyer of Nike shoes or the greatest new game of Call of Duty... Or are you selling wares where you don't want to risk a buyer not accessing your site or getting turned away because they don't have browser abc or plugin xyz - will they be using an android or an iPad?

Developers need to get over themselves - my grandma isn't going to install 'chrome' or silverlight plug in to read the daily news - and (BBC) if you fill your site will flash videos when millions of people are using iPads now .... You get the picture.

Sure, if you are the IT department and in charge of employee machine images, have at it - do your internal app in Silverlight, etc.. Or a hospital medical app that needs more than HTML will provide.

But otherwise think 'I need to be pro-consumer' - don't assume they will have IE9 or any plugin.

That to me is the focus, not 'but I like XAML more than HTML', or 'but C# is so l33t over JavaScript'.

These are some of the variables at play- and don't forget the 'in 5 years when ai have maintain his will MS (or any tooling co) still have what I need to upgrade and maintain this app that cost hundreds of thousands of your companies money to build/buy.


Good post Scott - thank you

Steve - Excellent comment. You're absolutely right.

I am a silverlight/web developer using silverlight for LOB applications. In my spare time, I develop an app for people with spinal cord injury. I have been through the multi platform route developing it for Iphone, Android, Xbox, Windows Phone 7, Silverlight and Web. I am currently redeveloping it using jQuery/jQuery UI/jQuery Mobile and KnockoutJS.

While I love the ability to do so much with silverlight, I can see that the majority of stuff can be done using HTML standards, which gives a really good reach and saves a lot of time overall. Debugging is harder, and writing massive apps seems very daunting.

So yes, it is quite hard picking a route to go. For me, small outward facing apps, go HTML, for complex LOB go silverlight.

Peter - Good summary. Silverlight and its deployment model (as well as COM interop, out of browser, etc) shines on LOB.

I think that Silverlight can be more productive then HTML when your trying to create a rich front end experience. However we only need this on a few of our webpages so we end up just breaking out into full javascript.

Scott, I really liked your point of view and in some cases I agree with some of them, and you made it very clear in your last comment about the "Horse" you think companies should bet on. But there's aleays a "but" some where and in my opinion you need to think of this in two different approaches, since there's no single right answer, because it really depends on who is asking the question and their background, as you said.

If we were talking about a company that usually develops Business Applications (Windows Forms, WPF, MFC, ...), normally they aren't very prepared (from my experience, I can be wrong) to work in a Web Environment, and so Silverlight is a real help in that area, since they can actually leverage they current skills and way of thinking developing the new applications.

If we were talking about a company that is already doing Silverlight in terms of Business Applications, and made huge investments in that area (like for example a customer that I have, that made a several years investment in building a new system in Silverlight), I think that the current Microsoft approach to this is really a problem, since they feel that Microsoft failed them, when "they were encoraged" to go and do Silverlight. I don't think that is the case here, since in there are a lot of cases that Silverlight is the Best Choise. For example if you need a rich User Experience, you can't rely on HTML5 currently to have that UX to all customers, because not all of them have browsers that support HTML5, and using Modernizr you will loose the HTML5 stuff, and so the UX goes away, and in a large amount of customers this was one of the real reasons they went with Silverlight.

If we were talking about a company that has a large knowledge about the Web and how it works, and already is building lots of Business Apps in HTML today, then I think what you said is really true, because they already are used think apps the Web Way, and having the UX being a second choise, and now with HTML5 they will be able to enhance the UX for some customers.

But I agree with you when you say that "HTML drives the Web and Plugins like Silverlight sit on top of it", and I also think that they won't go away. They are only more tools for our toolbelt and it cames up to making a decision based on the real customer need, development team capabilities, and tools available to build them on.

Also I really think that even the people who are used to build Silverlight or other plugin related development should look at HTML5, because this way it will be easier for them to choose what's best for them in a specific point in time.

Lastely I just think that everyone should also be very careful when adopting HTML5, because we don't want the "Cross-Browser Web Development HELL" we just passed because some companies decided to tweak the HTML standard a bit. And IMHO this is happening with HTML5 currently

Hi Scott,

Very interesting post. Thanks.

I noticed you mentioned KnockoutJS for data binding.

What are your opinions about KnockoutJS versus jQuery Data Linking?

Nuno - We are in agreement. Thanks for your comment! Agreed also that HTML5 is early, but it's happening, just as HTML(n-1) before it did.

Adam - I'm more familiar with Knockout than the jQuery one, but they are similar. I suspect they overlap by about 60%. The idea is that 2-way databinding and MVVM *is* possible in HTML.

Scott, you are absolutely right that HTML seems to be in a great position to come and standardize on things that we realize that we want in the browser.

Flash showed us we wanted video... real video. Over time, we've come to see we want to listen to podcasts with media player lite controls right in the browser.

We're getting all of this... and the world at large is trying to get it right before the browsers all implement it differently. But artists ship, so web browsers are going out, and they aren't 110% compatible already

But look at the new frontiers. Silverlight 3D is in its infancy, but it provides for immediate mode 3D graphics in the browser. Minecraft runs in a browser as a Java Applet. Now Silverlight is bringing similar capability to .NET programmers (and DirectX veterans... which is the entire mainstream PC game industry). No one should dismiss this as trivial.

Someday we may want this to be "standard" and 20 years from now we'll see where we're at. In the meantime... we have choices, we have tools. Developers SHOULD learn the HTML "stack" because you really should know what's going on in the web. .NET developers have a powerful productive choice in Silverlight that is a wonderful development environment as well.

Thanks, Scott. You are now clear as a bell.

Mr. Gentile - I regret that I am unable to get over myself. But where did I say anything about preferring one technology over another? I didn't diss HTML or gush about XAML. I did make an indisputable argument about Silverlight's present day advantages in productivity, tooling, libraries, developer skills and practices. That advantage may not last long but it's true today and, I believe, will remain true at least until 2010. If you accept my premise, the calculation about what road to take right now is more complex.

I admit to narrowing Scott's question to "HTML5 or SL for business apps". I suspect (without evidence) that most professional developers using Microsoft technologies are building business applications. They tend to be business-to-employee, business-to-field-agent, and business-to-business apps. In any case, I'm not talking about consumer facing apps.

The latest crop of business apps are web apps, typically run over the internet on devices that the company does not control. No one has the budget or appetite for deploying machine images. True, such apps target a somewhat captive audience. As a rule they don't have to reach everyone on every device. Mandating the Silverlight browser plug-in may be less of a burden than either requiring a browser / operating system upgrade or wasting precious development resources figuring out how to degrade gracefully (the euphemism I prefer to "progressive enhancement"). Reaching your grandma on her iPad is an unlikely priority.

Here is the crux of the matter. These applications are due "today". We are looking down the road for sure ... but we get paid to make good decisions about the technology we use today. We're not supposed to get misty eyed about HTML5 ubiquity tomorrow.

My corporate sponsor has a lot more to worry about than the remote possibility that Microsoft, Visual Studio, Silverlight, and the the .NET community will magically disappear in five years. The greater danger is the app that never ships, is missing features, is plagued by errror, and performs poorly,

In short, we are charged with delivering well-tested, maintainable applications that satisfy the requirements and we strive to do so on time on budget with the available human resources. Under these circumstances - which are not everyone's circumstances - Silverlight can be the more prudent choice ... today.

In this regard, I respectfully disagree with Scott's conclusion, at least as it applies to the complex, data-intensive, richly interactive applications that are the mainstay of clients in my corner of the universe.

Scott - sorry for hijacking your post; I hope I have not strayed too far from the kind of commentary you intended to invite. In any case, I've had my say.

Aaargh ... I meant to say that Silverlight's advantages would persist "at least until 2012".

Scott,

I am going to share this with other team members, but your thought here are the same as mind. Microsoft sime MVC 1 and Silverlight 2 feels like a start-up company to me, a whole new set of tools focused on making developer happy (productivity comes from that). Me, I have 3 or 4 major projects going on that are planned to have both a MVC3 / html5 and Silverlight 5 component. Use the right tools, not every problem is a nail.

@Chris Gomez: Not to take away from your overall point, but standards-based 3D acceleration is already here, via WebGL, in the latest versions of Chrome and Firefox (and in the dev builds of Opera and Safari). Take a look at Google Body for a live example.

I'm not sure we should be looking beyond 2015 for Web Apps. If HTML cannot do a function that a plugin can, will that functionality simply move to an app on an app store. Will HTML web apps become a light-weight version of a native app installed from an app store?

If this becomes the case, then HTML5+ becomes one of many cross-platform library frameworks, and probably not the most productive or effecient. It would still be advantageous for any native (or cross plaform) framework to make use of HTML/Web resources (CSS styles, etc...), or in reverse, any framework that can generate HTML5 assets.

Ward, not sure why you think my comments were directed toward yours - they were not - I was responding to Scott's blog post

Windows 8 is expected to greatly lever Silverlight's immersive interface potential in exciting new ways:

http://www.zdnet.com/blog/microsoft/more-on-microsoft-jupiter-and-what-it-means-for-windows-8/8373

http://www.winsupersite.com/article/paul-thurrotts-wininfo/New-Tile-Based-Shell-App-Model-and-App-Store-Coming-in-Windows-8-

http://www.zdnet.com/blog/microsoft/ces-will-jupiter-be-key-to-microsofts-windows-8-app-stores-future/8322?tag=mantle_skin;content

Silverlight is the competitive advantage for building killer immersive apps. Rest assured, Silverlight will be shaking the tree for at least another decade.

Steve - Your perspective, widely shared and seemingly Scott-approved, helped me clarify my views. I apologise to you - and all - if I gave offense where none was intended. I fear we'll all be writing in JavaScript ere long and wondering why we every did otherwise. :D.

Hi Scott,

Funny how you can start a heated debate for stating the obvious!

I maintain and develop an application that's 4+ years old, that started as a collection of Infopath forms and is now an elaborate asp.net webforms application with 20+ screens. The Infopath forms are now gone. Three years ago when we started pulling the Infopath forms out we used ASP.NET AJAX library in the webform replacements, then users came up with a requirement that needed multiple files be uploaded to the web application through the browser. I threw silverlight in the mix for it because that was the best option possible (flash being flash and we were a .NET team so writing a Java plugin wasn't really enticing).
ASP.NET AJAX has fallen out of favor now and jQuery is the in-thing, does that change the application in any way? No, it simply means in the upcoming releases we'll introduce jQuery as and where required and in cases where jQuery does better than ASP.NET AJAX we'll update it.

So for all those looking for a silver bullet, sorry no one will do your work for you. Find out what's best for you, yourself (don't blame Scott or MS), and remember... Enterprise applications evolve (or die)... Consumer Applications evolve (or die). Scott is bang on the money when he says use silverlight where required and HTML5 where required TODAY. If Microsoft stopped upgrading Silverlight 5 years from now, it won't pull a plug somewhere that all Silverlight functionality will break overnight. And if HTML X started supporting something silverlight does, that wouldn't break Silverlight functionality either.

Cheers,
Sumit.
P.S. Once again Scott, thanks for stating the obvious :-)...

I think the upset around HTML5 vs Silverlight is not about what to do with the upcomming project. Look around and notice all the different platforms you need to target and you will come up with HTML5, even if this means major investment in skills, etc..

The big upset around HTML5 vs Silverlight is all about huge investments already made. I've been working on a LOB in Silverlight sinse 2008, starting in Silverlight 2 and altough we are happy with the result, if presented the choice today, we would not go with Silverlight, period. But now we can't go back, as it would cost to much.
More over, we are now forced to invest more in providing RESTful webservices for mobile platforms on one side, and trying to integrate stuff like Reporting Services into Silverlight on the other side, without a clear statement from Microsoft saying that they will come up with ways to make our LOB lives easier.
Sure, there are some improvements in this area in Silverlight 5, but I feel it could have been a bit more convincing if there was more support for things like reporting (and perhaps even Report Builder?).

I think that Microsoft should invest more to push the LOB-part of Silverligth - like security and reporting to separate Silverligth from HTML 5.
As mentioned here before, Silverlight should sit on the top of HTML 5. So it's konsequent to push the LOB-part.

...but only my few cents...

Stone

This is all so sad. We all know what everybody wants. It's the ability of Silverlight being used absolutely everywhere.
Why a so BIG mess with all this ? The way it's all done is wrong.

HTML/Javascript/CSS = Lots of work for LOB and very nice interactive web.
Silverlight = Shines on all side, except not accepted on all platformw which today and tomorrow will be the world of MOBILE and tablets even for business.

At 45 years, which 25 of them are developping applications, I'm now facing a huge wall. Well, there's some holes in it but I can't seem to be able to pass in one of them.

The tools that the one will make which will provide what todays Xaml + C# + Blend + VS does but giving the result of HTML X / Javascript / CSS to be seen everywhere = WINNER

Thanks Scott, great article with a great debate. Well done people.

Essentially, the job of us developers is to choose the right tools for the job and I'm glad to hear it.

I tend to find that people who are entirely "pro-Silverlight" or entirely "pro-HTML" is that their position is overly polarised, but if you think of things more in terms of your points in this article, you suddenly realise that Silverlight and HTML5 are "checkboxes" not "radio buttons"! You can use whichever ones best suit your purpose and that includes both!

Some great comments here.

One of the issues that continues to frustrate with Microsoft UI stacks is that they offer no migration strategy from one UI stack to another. We have built a huge LOB app (thousand's of forms) based on Winforms and now that Winforms is at the end of it's lifecycle ... we have nowhere to go in terms of an easy migration to the next best thing. Moving to WPF or Silverlight requires a complete re-architecture/re-implementation of our entire client stack ... a non-trivial exercise at best. Also the current feature set in Silverlight, while getting better, still offers a fraction of the functionality available in Winforms. And even if we were to migrate to Silverlight, what happens in 5 years from now when Silverlight reaches the end of it's lifecycle .... we have to do the whole thing all over again.

The one thing that I can count on with HTML/Javascript is that a client application I develop today is pretty much guaranteed to work in a browser 10 years from now, just as the original web pages from 15 years ago still work today.

I get the development story with Visual Studio and the power of the .Net platform, although nothing about Silverlight convinces me that it won't simply be another Winforms in 5 to 10 years, or even worse ... what ActiveX is today.

Yes, there is a standard and plugins! I agree, you should not use Silverlight for simple animations, but consider it an alternative to replace flash. If there was not a question html or flash? Why should we ask html5 or silverlight?

One of the advantages that proponents of SiIlverlight continue to talk about are it's performance advantages over HTML/Javascript.

The following simple test demonstrates otherwise. It does a load of 1000 controls (not uncommon for a rich LOB app). Click through each of the tests a few times ... (D)HTML is many, many times faster at load and rendering than either Silverlight or Flash

http://www.bulkdatafeeds.com/rendertest/rendertest.htm

@Mike Parsons,

Speaking of performance in Silverlight I can use up to 8 logical cores to scale out my work like so....
http://silverlighthack.com/post/2008/09/07/Silverlight-MultiThreading-with-a-Computational-Process-(Counting-Primes).aspx

Also you have functional language like F# that can do units of work using asynchronous workflows:
http://silverlighthack.com/post/2009/11/04/Silverlight-3-and-FSharp-Support-in-Visual-Studio-2010.aspx

You have been able to do this for 2 years now in Silverlight. JavaScript is getting some basic multithreading with Workers now, but performance I doubt will be as good as Silverlight.

BTW....in your link you show 1,000 UI controls...wouldn't virtualization in Silverlight only render a small fraction of those (not sure how the sample is implemented).

@Bart Czernicki ... thanks for the response

RE: Speaking of performance in Silverlight I can use up to 8 logical cores to scale out my work like so.... http://silverlighthack.com/post/2008/09/07/Silverlight-MultiThreading-with-a-Computational-Process-(Counting-Primes).aspx

Web workers could accomplish the same and depending on the scenario, the recent Javascript engines in all the major browsers are pretty darn fast, with Chrome V8 approaching native C in some instances.

The Silverlight example does uses virtualization using a listitem view :-)

Talking of misconceptions...
I find it very frustrating when non-technical tech bloggers talk about HTML5 as a cloud application. In reality, a web application written in HTML needs to be as functional as its competing desktop application - which includes offline capabilities. If this were true of an HTML5 application, then all we're really talking about is rewriting the desktop application using JavaScript and HTML/CSS. We're really just talking about using the cloud for storage and collaboration, and not functionality.

Are we really sure the current web platform is really up to the job?

good Scott.

you said... I couldn't disagree with you about it
I had already this doubt...just some good experience able to resolve this doubt for me.

I appreciate the clarification and am clear on your opinions re: 'in browser' and I see Silverlight as a 'complimetary extension'. For me, what I really need to decide upon is Microsoft's client UI technology for tablets. So far it's an HTML5, Silverlight, WPF continuum (and a bit of C++ thrown in) which is really a cop out. My guess is WPF is at the end of the road, is being leap-frogged by Silverlight but MS are going to re-purpose SL as the front end for Azurre. So SL as a de facto, 'standalone' UI on a sleek Windows tablet (the desktop of the future) is going to happen.

...should have read 'is NOT going to happen'.

The sure bet when it comes to the Web is HTML/JavaScript and any framework built on top of that. Period.

Non-standard web features should be used on a per-case basis. Which tech you choose at this point is moot because none of them are standards.

Personally, for features (and support) that have not made their way into the HTML/JavaScript standard the only technology I would bet my time on would be Silverlight.

As a side note: Microsoft threw way too much money into Silverlight (and WP7) to let it die within the next 5 or even 10 years. I wouldn't be worried about using it in my LOB apps. Just use it sparingly if you're super worried about long-term support.

Anybody think WPF should be used in the enterprise over Silverlight? I'd like a clear answer from Microsoft on this.

Frank - I think Pete Brown would be the best person for that. Personally, if you are targeting Windows and want the full power of the local machine, including the full CLR, total control, Win32 P/Invoke support, etc, use WPF and ClickOnce. Otherwise, if Silverlight does what you want use that. Know XAML.

Lots of people have been wrestling with this issue and by no means is it a simple one.

What does programming in HTML5 even mean?

Is it using (essentially) Notepad and writing support functions in JavaScript? Really? Or some fancied up version of Notepad called Visual Studio giving the developer some goodies like Intellisense and some prepackaged code blobs that they can drag off a toolbox?

I’d hate for that to be the case because I was doing that 12 years ago and I don’t want to repeat that experience.
HTML is a Presentation layer technology, and it shouldn’t be polluted with Business Logic and Data Access code buried in a wall of JavaScript.

So assuming that future versions of ASP.Net will then start emitting HTML5 code the plan seems to be to continue on with business as usual. Select your UI technology, WebForms or MVC or some other variant, and let that technology generate your HTML5 for you. Then the developer can layer the rest of the application the same as they always have and nothing really changes much.

If your application requires a spiffy UI then code it in Silverlight, here’s a pseudo code fragment to help decide what to use:

IF APP REQUIRES SPIFFY UI THEN
USE SILVERLIGHT
ELSE
USE WHATEVER YOU USED BEFORE
END IF

One of the advantages often touted of Silverlight and the .Net platform over Javascript is performance.

I put together a simple test that refutes that hypothesis. It renders a simple MandelBrot Set, which is often used to benchmark runtime performance.

The code and the executables are here ... http://www.bulkdatafeeds.com/mandelbrot.zip


The results on my Windows 7 x64 AMD 3.7 GHz processor with 8 gigs of memory are as follows (smaller is better)

Python-> 1700ms (Python.exe Mandelbrot.py)

C-> 345ms (Mandelbrot.exe)

Java-> 261ms (Java.exe Mandelbrot)

C#-> 215ms (MandelbrotCS.exe)

Javascript-> 47ms (Shell.exe Mandelbrot.js)


The Javascript engine is Google's Chrome V8


We've come a long way in terms of what a Javascript runtime is capable off.

Funny, the great success story for iPhone and iPad apps are native apps, not web apps. The highly profitable iPhone app store is all about premium user experience, and these apps are essentially all native apps.

Bing "Windows 8 Jupiter" and voila, the future UI model for immersive Windows 8 apps is pointing towards Silverlight. Clearly, MS is following the iPhone/iPad immersive user experience business model. HTML5 cross-browser apps with the polished, high performance appeal of native or SL apps are years away. Even multi-touch is far from being uniformly implemented in browsers.

Interesting times, these. Choose your horse wisely.

Scott,

This video brilliantly sums the whole discussion in a humorous light:

http://www.youtube.com/watch?v=sQ-vlJv2dWE

Worth viewing!

Cheers,
Phil

To Mike Parsons:
Your performance test is not correct. Just remove Console.Write from C# code and output from JS code. And please don't forget compile Release build of C# code (not Debug one). After that performance of JS code will be THREE times worse than C# (on my computer it's 33ms for JS, and 11ms for C#). So what you are actually testing it's just performance of console output :-) And I bet if we change tests to allocate huge memory chunks and manipulate them, then performance of JS will be even more worse (from ten to hundred times worse I suppose).

While I think your advice is good, the more you guys talk about this, the more you muddle the waters.

Well, "C" is the foundation of all computer programming, and is truly the only cross platform language.

So you recommend that we write in "C" as well?

I know it's not an exact analogy, but just because something is foundational, doesn't mean it's not time to abstract to a higher level.

It's as simple as using the right tool for the job! In my experience, even when we do Silverlight, we also have to do HTML for parts of the job, especially if there is anything internet facing for a customer.

BTW, anybody using HTML5 right now is either experimenting, or doing way too much work. Far too many people can't do HTML5, so if you REALLY want maximum reach, stick with HTML4.x.

A good whitepaper on this subject ...

http://www.scottlogic.co.uk/blog/colin/wp-content/uploads/2011/05/Flex-Silverlight-HTML5.pdf

@Mike Parsons,

Your tests are terribly flawed (see Slava Pankov above). We started building a math/graphic intensive enterprise app in HTML/JS several years ago and moved to Silverlight simply because performance was literally orders of magnitude faster. Your postulate that HTML/JS is faster than SL is simply false --- in fact, the opposite is dramatically correct.

@Mike Parsons

Sorry to single you out but your Silverlight rendering test is just plain wrong.

You mentioned that your Silverlight example uses virtualization, but looking at your xap this just doesn't seem to be the case - you certainly haven't set the following in the List control.

<ListBox.ItemsPanel>
<ItemsPanelTemplate>
<VirtualizingStackPanel />
</ItemsPanelTemplate>
</ListBox.ItemsPanel>

In addition to this you should really declare your ItemTemplate as a StaticResource rather than inline, there were a few bugs in SL4 which have been fixed but the general guidlines are to reference the template like below.

ItemTemplate="{StaticResource ItemTemplate}"

Also looking at your code behind the controls are added into the list one at a time in a for loop. I can't imagine why you'd do this in a real LOB App - you'd most likely leverage the power of Silvelight and it's databinding support.

I'd say a truer representation of performace would be given by replacing your MainPage.xaml with the following:

<UserControl
x:Class="SilverlightRenderTest.MainPage"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">

<UserControl.Resources>
<DataTemplate
x:Key="ItemTemplate">
<Grid>
<Grid.RowDefinitions>
<RowDefinition />
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<TextBlock
Text="{Binding ID}"
Height="19"
Width="128"
Grid.Column="0" />
<TextBox
Height="22"
Width="147"
Grid.Column="1" />
<TextBox
Height="22"
Width="147"
Grid.Column="2" />
<TextBox
Height="22"
Width="147"
Grid.Column="3" />
<CheckBox
Height="20"
Width="20"
Grid.Column="4" />
<TextBlock
Text="CheckBox"
Height="19"
Width="65"
Grid.Column="5" />
<RadioButton
Width="20"
Grid.Column="6" />
<TextBlock
Text="RadioButton"
Height="19"
Width="76"
Grid.Column="7" />
<Button
Content="Button"
Height="24"
Width="55"
Grid.Column="8" />
<ComboBox
Height="22"
Width="91"
Grid.Column="9" />

</Grid>
</DataTemplate>
</UserControl.Resources>

<Grid
x:Name="LayoutRoot"
Background="White">
<Grid.RowDefinitions>
<RowDefinition
Height="Auto"/>
<RowDefinition
Height="*" />
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition
Width="Auto"/>
<ColumnDefinition
Width="Auto" />
<ColumnDefinition
Width="*" />
</Grid.ColumnDefinitions>

<Button
Grid.Row="0"
Grid.Column="0"
Content="Reload"
Click="ReloadButton_Click" />

<TextBlock
Grid.Row="0"
Grid.Column="1"
Padding="8,0,0,0">
<Run>Total Time taken :</Run>
<Run
Text="{Binding TotalMilliSeconds}" />
<Run> (MS)</Run>
</TextBlock>

<ListBox
x:Name="ControlsBox"
Grid.Row="1"
Grid.Column="0"
Grid.ColumnSpan="3"
Padding="0,8,0,0"
ItemsSource="{Binding Controls}"
ItemTemplate="{StaticResource ItemTemplate}"
VerticalAlignment="Stretch">
<ListBox.ItemsPanel>
<ItemsPanelTemplate>
<VirtualizingStackPanel />
</ItemsPanelTemplate>
</ListBox.ItemsPanel>
</ListBox>
</Grid>

</UserControl>


And replace your MainPage.cs with the code below

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Windows.Controls;

namespace SilverlightRenderTest {
public partial class MainPage : UserControl {

public MainPage() {
InitializeComponent();
this.DataContext = new MainPageViewModel();
}

public MainPageViewModel ViewModel {
get {
return (MainPageViewModel)this.DataContext;
}
}

private void ReloadButton_Click(object sender, System.Windows.RoutedEventArgs e) {
DateTime startTime = DateTime.Now;
ViewModel.ReloadControls();
ViewModel.TotalMilliSeconds = DateTime.Now.Subtract(startTime).TotalMilliseconds;
}

#region Models

public class Controls {
// Methods
public Controls(string id) {
this.ID = id;
}
// Properties
public string ID { get; set; }
}

#endregion

#region ViewModels

public class ViewModelBase : INotifyPropertyChanged {
public void NotifyPropertyChanged(string propertyName) {
if (PropertyChanged != null) {
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
public event PropertyChangedEventHandler PropertyChanged;
}

public class MainPageViewModel : ViewModelBase {

private IList<Controls> controls;
private double totalMilliSeconds;
private const int NumberOfControls = 100;

public MainPageViewModel() {
}

#region Properties

public IList<Controls> Controls {
get { return controls; }
set {
if (controls != value) {
controls = value;
NotifyPropertyChanged("Controls");
}
}
}

public double TotalMilliSeconds {
get { return totalMilliSeconds; }
set {
if (totalMilliSeconds != value) {
totalMilliSeconds = value;
NotifyPropertyChanged("TotalMilliSeconds");
}
}
}

#endregion

public void ReloadControls() {
List<Controls> list = new List<Controls>(NumberOfControls);
for (int i = 0; i < NumberOfControls; i++) {
list.Add(new Controls("Label " + i.ToString()));
}
this.Controls = list;
}
}

#endregion

}
}

Appologies if the above code is skewed - the text editor doesn't seem to play nice.

Note I'm using the MVVM approach, you should really look into this if you're serious about writing Silverlight applications, or at least writing these comparison tests.

Using the above code the average time in Silverlight for 100 controls is <50ms when refreshing the ListBox items source.

The times in you're original app are what I get if I set the NumberOfControls variable to 2,000,000 records.

I'd be most interested to see how your HTML page performs with that many records, if it is even functional.

Good post.

HTML,CSS and javascript have been around for years, but I think many programmers still struggle with compatibility issues and layout differences in different browsers.

I've been developing several large (intranet) web applications using jquery, jqgrid, jquery-ui and jquery-ui css framework. Although they have taken much pain away, still HTML, CSS and javascript's different behaviour in different browser keeps productivity at a lower level as it should be, if you're implementing anything more complicated than a simple data entry form. And that even while I've being able to require IE8+, firefox 3.5+ and chrome as the only supported browsers for the application, because the application is used in a intranet environment.

Even skilled javascript/html/css developers, like those implementing jquery/jquery-ui/jqgrid, are having trouble with it.. just look at jquery/jquery-ui/jqgrid forums counting the number of issues related to browser incompatibilities. Every time I update jquery/jquery-ui or jqgrid, I hold my breath, to find out which functionality is broken or which layout does show some small but very annoying changes compared to the previous version.

I have some (non trivial) silverlight components inside my web application as well, and seldom had any issues with them when going from one version of silverlight to the next.

I'm not at all against HTML (I choose to develop web applications)... but something should really be done about those problems, and I sincerely hope, HTML5 will continue the ease the pain, but at the moment, I remain sceptic...

Wow! Probably one of the most interesting posts on the Web I've read in a while. Because, I know a sentence shouldn't start with becasue, but the topic is right area of developing I work with.

I've read about the post and opinions and wanted to bring up the that with IE 9.0 and HTML 5, Xml works quite well and that it should be considered under this post.

At the site I apply http, Xml, inline Xaml(Xml), serialize, apply a client script for Xml to HTML translation for backward capatibility with older browsers. Actually a simple RegExp handles the job for direct serialized translation and completely seamless to end user.

Through the process I've noticed that as I learn Xaml. the same developing model applies to HTML 5 and Xml as is applied through Silverlight and Xaml.

At the site a 6K script takes care of all features. (IE 9.0 and FF tested). I apply about 20 Xml files for now but I'm looking at replacement content in the range of 2,000 files, which is still minimal compared to what would be a requirement of the databased content. The idea includes a sales strategy, Web business development of any size, can also be pushed towards WPF.

All that, to suggest Xml plays a large part in making the Web easy under HTML 5. File rewrites are near zero, based on the script and the idea of moving content to client.

Would really love the feedback especially from such as interesting blog.

I'm simply Peter, email page_programming@hotmail.com
Site link: www.pageprogramming.com.

Hi Scott,

Reading this article, and the current comments, was truly fascinating: I wonder what may, or may not, have happened if John Resig had not created jQuery, and turned the little-Java/EcmaScript doggy into a tiger that had the chutzpah to square-off with Mighty Ajax ?

I was surprised to see no mention of server-side JavaScript here, although perhaps that is implicit in the conversation. It seems to me, that, at this moment in the fuzzily-unfolding matrix of the future of the guts of the web, we are "under the shadow of the cloud," to sound a bit Jeramiah-ish about it: what's on the client, what's on the server: "Who's on first," says Abbot for starters: of course, Costello has the last ... uhhh ... word ... in that famous comedy routine: it ends with Costello's scream.

It seems ominously serendipitous that I read this article using IE9 release, on a fresh install of Win 7 64-bit, and when I went to the web-site (PageProgramming.com) of one of the commentors on this thread, 'Simply Peter,' I was presented with a home page virtually unreadable because more than half of its contents were off-screen horizontally and vertically.

Indeed, only the fragment reading "The Large Scr" from the title of that home page is visible. I resist the temptation to fill in the missing characters following "Scr" with ... well, I leave that as an exercise for the reader. Hint: same-same in "compatibility mode."

Scrolling down that page I found links to install SilverLight: that was baffling, because I had already installed SilverLight when I updated the Win 7 install: clicking the link to install SilverLight then led to a Microsoft page:

http://www.microsoft.com/getsilverlight/get-started/install/default.aspx?reason=64bit&v=4.0:

with this warning: "Microsoft Silverlight cannot be used in browsers running in 64 bit mode. You are running on a browser that may not be fully compatible with Microsoft Silverlight. You can still try to install by clicking below or you can refer to the System Requirements for more information."

So, I think about this discussion of the future of the net-i-verse with a certain bittersweet chagrin: if someone who's been programming for thirty years encounters these strange signs and portents suggestive of malevolent spirits, what do "mere mortals" think; how do they react ? Maybe that's a jejeune argument: "mere mortals" probably just get home and plug their new system, bought pre-configured, in, and it works ?

I write this neither as a critique of 'Simply Peter's' site, or Win 7 64-bit, or any of MS's technologies, including the tools I use now (.NET, C#). And I will resist the temptation to make my last word here, like Abbot's: a scream.

Can we take small comfort in the fact that Abbot's opening line tells Costello that his job as coach with the Yankees is valid as long as Costello stays on the team ?

best, Bill Woodruff

p.s. my bias should be clearly exposed by my stating that I regard having to directly work in XAML to achieve certain WPF or SilverLight functionality as the equivalent of being forced to use paleolithic techniques to start a fire :)

Bill - Honestly there's no reason to be running a 64-bit version of IE. There's no 64-bit plugins, so little will work as you'd expect.

Scott,

Thank you for coming to my rescue.

However I'd like to mention IE 9.0 64 bit also installs IE 9.0 32 bit. For some reason 32 bit added installation is somewhat not obvious but the 32 bit version is installed, as well.

I'd also like to include, if people should continue to follow the blog, where I fall short in programming capabilities, with 33 years retail experience I am use to the idea of retail presentations, 100, 200,000 products, and SL falls into the catagory of the type of tools required when considering the presentation of such a huge mix of product lines.

I was also confused when Microsoft turned around and pushed IE 9.0 Beta towards HTML 5 and a presentation support HTML 5's canvas applications.

On the other hand, I think what Microsoft expected with the integration of Silverlight was that other industry leaders and open source would bounce back, such as with SVG for example, now applied with MVC, but they did not. Doesn't help with the confusion but there are industry markers at Microsoft supporting a Web which might, in 50 years or so, be the next retail and, requiring product presentation methodology, such as the quality of presentation provided through Silverlight.

If I were helpful in decision making I would suggest in market development: One instance of a Silverlight product, transparent background, is an object or tool within a Web page presentation. Many instances of Silverlight product objects, builds an environment. So, who needs to apply Silverlight product objects and similar technologies ready for presentation?

Here's a tip: We only see through retailers, within our locality, approximately 5% of products available through manufactures and suppliers.

For example: All of us have seen wire product applications such as baskets in kitchen cupboards or shelves for closet space. A partial line-up of products available would take 60 x 100 foot shelf space in retail but even partial, the product is bulky and the majority may not warrant dollar per square foot sales at the store level but this limit does not exist with product presentation through the Web.

Similarly, we only see a fraction of available kitchen cupboard door knobs and handles. Truly a huge market.

In any case, in business developing and product presentation, we should do well in pushing presentation at the manufacture and supplier level and Microsoft comes out with Azure database, a perfect tool for manufacturers and suppliers to push the distribution of product presentation content.

In retrospect, if working with Silverlight and Xaml or WPF a business developer specializes in developing presentation tools and/or a channel based on product presentation but based in end-user's home or office design environment, which is also achieved through products they collect, that's a try before you buy sales environment. Xaml objects, once presented, can, with a right click, also link back to a reseller sight or search engine or what ever services the channel provides.

I tend to think that Microsoft would not want to monopolize the presentation market, it just too big. It would be best if manufactures and channel specialized in a many presentation technologies as possible. That I'm looking into Xml database method, just has to do with how to move mixed product database files or librairies direct to the client database.

Thanks. Although not a technology specialist, I hope can be of some help for people looking into market direction.

Scott,

Sorry, there's an error, amoung spelling errors, the shelf space should read 60 x 10 foot shelf space or more accurately 60 feet wide by 10 feet high, which is still a considerable amount of space for one product line and usually not provided for one product line only in retail. The product is of course bulky and there are no limits of the kind with a Web presentations.

Good insight. Can you include samples of presentations that call for MS Silverlight and cannot be implemented at all by web standards?

How about showing cubes on browsers in an interactive way?

Great article, I never read such clear and unbiased article for Microsoft folk.

Very Informative post. Thanks for posting such content :)

Here's my take: Use HTML. Don't use a plug in that relatively few people have plugged in unless you have no other choice. When you don't work for Microsoft, the choice is obvious.

"Don't try to make Silverlight act like it's HTML." I totally agree with this. However, everybody seems to be fine with trying to make HTML act like Silverlight. HTML was never intended to create applications. Remember, what the T in HTML and the A in XAML stands for.

I say everyone just use Silverlight and force html to die. We will all be happier in the end : )

It's not so much about what UI technology you take today - whatever you do it's very likely that you will have to change in the next years. UI frameworks come and go. What stays is the right architecture that makes it as easy as possible to swap UIs as needed without having to rewrite everything. So learn and practice the right architecture and you'll be able to align with whatever UI trends might come in the future.

At the end of the day common sense wins. Having said that; Microsoft has done a poor job of communicating their vision on Silverlight or WPF. Silverlight is great, does a lot of things pretty well - but the companies that have invested in it skillset-wise and otherwise are getting nervous and are beginning to go on hold while looking for alternatives.

UI and UX is very important for some products and Silverlight shines in that area if done right. HTML[5] has limitations, standards are iffy - lots to consider, code for and relatively hard to debug.

In our case we are looking for alternatives to Silverlight where the outcome and UX is the same to what we have developed already. Nothing comes close. A visually appealing heavy sexy infographics centric application does require Silverlight framework. After experimenting with other open standard non-plugin non-OOB technologies Silverlight still comes as a winner. Fortunately or unfortunately our products are not just textbox and data content types. They are rich and heavy on vector graphics and user interactions... so that's why we end up picking Silverlight in the first place, not to mention the managed code and testability part.

I hope Microsoft realizes this and continues to develop, enhance and support this framework for a long time. There is a good market and plenty many use cases for Silverlight. If it takes a class action suit by companies who have made huge investments and massively deployed Silverlight to force Microsoft to stick to it, then that is what its going to take I suppose. Microsoft shouldn't just flip their strategies just coz they feel like it - it hurts the bottom line for the ones who loyally bought into the story initially. If MS continues on this path then they should be prepared to share their dough with the ones who they screw in the process.

Sorry about my rant here, but this is just how things are being felt in this area. Hopefully Balmer resigns by some miracle and some true and consistant visionary takes the bull by the horns! Not holding my breath though ;)

I have been missig great stuffs!!!

I use Silverlight Business Applications at work.
My biggest problem with Silverlight is that it won't run on iPods, iPhones, iPads, etc...

Is it just me, or do others feel that with html, we are stuck with a really crappy technology that has been tweaked/patched/plugged to try and get it to do stuff that its just not well suited for in the first place. I get the idea of a global technology that will work on any browser, but frankly it really sucks that you have to use so many ugly disjointed things (html+css+javascript+asp.net) to get something working well.

To some extent I agree with Jesse. Not sure that Silverlight is the answer (although its close), but Html needs to die, and we need some new global standard that makes developing RIA's a little bit less of a nightmare.

Pfft .. I can dream can't I :p

I am baffled by something. Expression Blend (I use 4) is a powerful tool for designing what a surface should look like. Because I am working on something that requires universal reach, I have decided (and been advised) to use HTML web development as opposed to Silverlight. Why is there no REALLY COOL tool out there with which one can design a surface for HTML, preserve its CSS, and then invent the ASP.Net MVC 3/Jquery/Javascript/HTML code and document structures so that they can be governed by that CSS? If there is one, please someone point me in the right direction. It seems to me that Expression Web is not the answer. MS should separate concernts -- design surfaces for the surface (with differences or nuances where platform demands), and render in the "language" of choice (HTML/CSS or XAML).

Let us assume the following worst case scenario:
Microsoft stops Silverlight after V6.0 (continue to support it until 2020, say).

We have done enough POC's using MVC 3.0 (even 4.0) and jquery/jquery mobile. For a decent sized applcation with certain amount complexity, silverlight beats every other platform (it includes runtime, Development tools, third party tools, available skilled resources etc.) by miles. We have chosen that platform to develop that platform to develop our healthcare system. I am not regretting even a bit.

All this cross platform HTML5 stuff looks good on paper/theory. If you want to provide greater user experience go native period.

This cross platform applies to ecommerce sites (ex: amazon, bestbuy etc). They have to support really wide range of audience (spannning larger geographical areas). They cannot box themselves no matter what.

Our investment on silverlight is paying off on mobile platform as well. We could use most of it for our windows phone development also.