This morning, Mozilla shared their feelings on IE9 with a post that claims to answer the question, “Is IE9 a modern browser?” While they grudgingly concede that IE9 is “a step in the right direction”, they seem to be operating under a very narrow definition of what “modern” means, that I don’t think matches the dreams that web developers and end-users actually have.
Let me help them with a definition for what we believe users and developers should expect from a “modern browser”:
It seems that others share this view. The discussion on YCombinator starts with this comment:
Maybe I'm just weird, but I consider issues like performance, reliability, and having a stable foundation to build on to be far more important than supporting your own browser's take on some hypothetical future "standard", which is just IE vs. Netscape all over again. On that basis, IE is currently the only one of the big three that is actually going in the right direction.
And Download Squad concludes its analysis of the Mozilla article with the following:
Don't get us wrong, [Firefox] is an excellent browser -- but more stuff doesn't necessarily equate to better stuff.
To our friends at Mozilla, we admire your passion for the open web, and we look forward to continued competition.
The world’s ability to communicate with one another is a key factor in its rapid evolution and economic growth. The Esperanto language was invented last century as a politically neutral language that would foster peace and international understanding. Since the launch, we’ve seen first-hand the benefits of a constructed language:
We expect even more communication between people in the coming year and are therefore focusing our investments in languages that are created based on constructed language principles. To that end, we are changing the spoken and written language of this nation to make it consistent with the form of speech already supported by the Language Creation Society. Specifically, we are supporting the Esperanto and Klingon languages, and will consider adding support for other high-quality constructed languages in the future. Though English plays an important role in speech today, as our goal is to enable open innovation, its further use as a form of communication in this country will be prohibited and our resources directed towards languages that are untainted by real-world usage.
These changes will occur in the next couple months but we are announcing them now to give citizens using other languages an opportunity to translate the libraries of the world into Esperanto.
Dankon, nedankinde!
While my job here at Microsoft consumes much of my waking life, I spend a little of my spare time volunteering with a small charitable organization called HEAL Africa. They do work in the Democratic Republic of Congo healing victims of sexual violence from the ongoing civil war there. It’s a compelling story of how an organization is changing lives in an appalling situation, but I digress from the purpose of this entry.
One area they asked me to think about is how they can use social media effectively – a question that many charities and non-profit organizations wrestle with. And of course, it’s an area of great interest to evangelists like myself: an area that is a daily focus as we attempt to change perceptions of emerging technologies like IE9 and Silverlight.
So I thought I’d share a few thoughts here, both as a forcing function for me to distil a few ideas and hopefully as something that might be of interest to others.
What do you think? What would you add? What are your most effective strategies? Have you seen good counter-examples where the “accepted wisdom” is in fact the wrong way to engage?
At PDC 2000, we rolled out the .NET platform, including a new language called C#. A lot has happened since then! Each release has had a theme – in C# 2 we added generics; in C# 3 it was LINQ. Most recently in C# 4 with VS2010 we introduced deeper dynamic language support and expressed a commitment to feature parity across VB and C#.
Language designers need to observe and integrate major trends into their work. Over the last few years, we’ve seen several major trends: (i) declarative styles – where you say more about the ‘what’ and less about the ‘how’, e.g. DSLs, functional programming; (ii) the resurgence of dynamic languages like Ruby and JavaScript, and how that affects static typed languages; (iii) concurrency.
In the last major editions of the language, there has been significant investment in declarative styles and dynamic programming. But there isn’t heavy language support for concurrency today, even though there is good support in the framework through the likes of the Task Parallel Library.
One reason for the rise in concurrency is the rise in connected applications: it’s almost impossible today to build an application that doesn’t talk to a service, or indeed to build a service that doesn’t talk to another service. This increases latency – for example, it is just not acceptable for a UI to freeze while it waits for a service to return. As a result, we all practice the art of asynchronous programming. It is starting to become the norm, and we’re even starting to see the rise of async-only APIs in languages like JavaScript and Silverlight.
As a result, we’re looking at making concurrency the theme of the next release of our C# and Visual Basic languages.
In a synchronous call, the act of invoking a method and waiting for the result are fused: you can’t separate the two. With asynchronous programming, that changes. You can call the method and it will return immediately; later, it will deliver the result, so the two operations are separable.
There are a few problems with today’s model: (i) that the function can’t return the result, since the code is asynchronously executing, so it has to use a callback instead; (ii) it can be complex to update the UI without marshaling data back from a background thread; (iii) in a server setting, you don’t really want unconstrained thread creation because of the increased competition to the thread pool.
Anders demonstrated a simple example that shows how complex the asynchronous model quickly becomes. The code fragment below downloads and display movies based on a query of the NetFlix OData feed:
Movie[] QueryMovies(int year, int first, int count) {
var client = new WebClient();
var url = String.Format(query, year, first, count);
var data = client.DownloadString(new Uri(url));
var movies =
from entry in XDocument.Parse(data).Descendants(xa + "entry")
let properties = entry.Element(xm + "properties")
select new Movie {
Title = (string)entry.Element(xa + "title"),
Url = (string)properties.Element(xd + "Url"),
BoxArtUrl = (string)properties.Element(xd + "BoxArt").Element(xd + "LargeUrl")
};
return movies.ToArray();
}
But this code is synchronous – the UI will hang while waiting for the call to return. Let’s follow through the steps needed to fix this:
void LoadMovies(int year) {
resultsPanel.Children.Clear();
statusText.Text = "";
var pageSize = 10;
var imageCount = 0;
while (true) {
var movies = QueryMovies(year, imageCount, pageSize);
if (movies.Length == 0) break;
DisplayMovies(movies);
imageCount += movies.Length;
statusText.Text = string.Format("{0} Titles", imageCount);
...
action = movies => {
if (movies.Length > 0) {
QueryMovies(year, imageCount, pageSize, action);
else {
As shown in the code above, you can do it – but it’s unwieldy, and the flow of the code gets lost. And this is before we’ve dealt with error handling! Clearly we can do better.
The Visual Studio Async CTP, announced at PDC, introduces some new extensions to VB and C# to support a simpler, more declarative approach to asynchronous development.
The Task Parallel Library introduced a Task<T> type, which is used to represent an ongoing operation: a value that is currently being computed and will be delivered at some time in the future. We can use this as the return type along with a new async keyword to let the compiler know how it will be used, as follows:
async Task<Movie[]> QueryMoviesAsync(int year, int first, int count) {
We now can add some asynchronous work to the class. The CTP introduces a number of Task<T>-centric extension methods that will eventually be added into the core framework, which enable us to compose and call other asynchronous methods seamlessly. For example, the call to DownloadString() in our original method can be replaced by a call to DownloadStringTaskAsync(), which returns Task<string> instead of just string. (This is something you can offer for your APIs too, of course.)
And we can now use the await operator, as follows:
var data = await client.DownloadStringTaskAsync(new Uri(url));
The compiler rewrites your code (as it does for iterators), to use a continuation and then return, executing the rest of the code when the result becomes available.
Now the LoadMovies() method is really simple. Starting with the original code above, we can again mark the header with the async keyword and then we can call the new async version of QueryMovies using the same await operator:
var movies = await QueryMoviesAsync(year, imageCount, pageSize);
That’s all you have to do! As you can see, the new syntax preserves the logical syntax of the code. Exception handling requires no additional work: we don’t need to worry about callbacks, for instance.
It’s relatively easy to cancel an asynchronously executing task: you use the .NET 4 cancellation types, specifically CancellationToken and CancellationTokenSource, to indicate a request to cancel the task. The token can be passed into the DownloadStringTaskAsync() method. Everything here is just as before.
It’s important to note that the example shown above does not use a background thread – the async calls are happening on the UI thread. They aren’t computationally expensive; they are just blocking on a network call.
What if there is something that is computationally expensive that you do want to run on a background thread? You can simply use a lambda within an await context, for example:
async void ComputeStuffAsync() {
double result = 0;
await TaskEx.Run(() => {
for (int i=1; i < 500000000; i++) {
result += Math.Sqrt(i);
});
MessageBox.Show("The result is " + result, "Background Task",
MessageBoxButton.OK, MessageBoxImage.Information);
The HTML5 family of specifications provide two different models for vector graphics: canvas and SVG. Why have both? What is the difference between them, and how do you use them?
It’s important to start by understanding the difference between retained mode and an immediate mode graphics models:
More information on retained and immediate mode models can be found on MSDN.
SVG is a retained-mode graphics model. To build a scene graph in SVG, you write declarative markup to create an in-memory tree structure that lives in the HTML DOM. You can manipulate the scene graph through code or through CSS. SVG markup can be generated from a variety of tools, including Adobe Illustrator and Microsoft Visio.
Canvas is the immediate-mode graphics model. Because it doesn’t store the graph in memory, it takes less memory overhead to use, and can be faster for intensive use. Unlike SVG, it is programmatic in nature – there is only one parent <canvas> element, and code is used to populate it. While you draw primitive objects on a canvas, the only thing that is stored is the generated bitmap surface. In general, canvas is a lower-level API than SVG because of these constraints.
A quick tabular comparison of the two technologies:
Given these characteristics, what is the best technology to use for a specific scenario? SVG is perfect for high-fidelity documents and graphics for viewing and printing, and for interactive charts and maps. On the other hand, canvas is perfect for mathematically-intensive operations and complex scenes. However, there are a lot of cross-over scenarios where there’s no clear winner at this point in time, and as browsers evolve and improve, it seems that the performance characteristics of both technologies are starting to converge. Both technologies are clearly valuable!
[Session CD53 | presented by Patrick Dengler]