It’s a bit of a tradition over here at Young Coder to spend the month of Halloween thinking about the developer technologies we’ve lost. In the past, I’ve written about dead-as-a-doornail products (like Web Forms and Expression Studio), others in terminal decline (VB), and at least one that’s trapped in an eternal state of waking dead (hello Access).

But these days, what interests me most is how quickly we pronounce the cause of death when a product fails. We immediately think that we know the fatal mistake. We have a post-mortem story ready to tell.

But are we right?

We’re not all the way wrong. Many problems are obvious by the time a once-promising technology shudders to a stop. But with the benefit of a little time and a little space, a different story can appear. And with it is a lesson we need to learn, if we hope to avoid hurling more products into the void.

This rush to tell a simplified story has happened, to some degree, with VB, Access, HTML5 microdata, and many more dying developer technologies. But if I’m going to talk about sudden, disastrous product death in Microsoft land, then you know where I’m going to start.

Silverlight.

After eight years, an official death

Nothing from Microsoft has died quite as spectacularly as Silverlight, an ambitious platform for programming rich client-side web apps. Officially, Silverlight died just days ago, with the October end of support date coming just in time for Halloween. Did you even notice?

Probably not. For Silverlight, everything was over except the waiting roughly eight years ago, when development froze and browser support tumbled off a cliff. In fact, Silverlight’s abrupt shift from being Microsoft’s next-big-thing to a barely mentioned embarrassment was so traumatic for some Microsoft developers that they now refuse to trust Microsoft for any new boundary-breaking technology, including today’s innovative Blazor framework. That’s a long time to harbor a grudge.

The myth of the open web

The reason for Silverlight’s death was obvious — or was it? Critics pointed out that Silverlight’s architecture ran roughshod all over the open standards that proper web developers treasure. There was no HTML and CSS, no plaintext code, no DOM or extensibility. (It feels slightly unfair to complain about patchy support for accessibility when Silverlight predates WS-ARIA.) The developers who hated Silverlight were nearly united in one belief: the web model was supposed to take us away from proprietary black boxes and into a new world of transparency and extensibility. Silverlight couldn’t do that, and it didn’t try.

Every bit of this is true — but it doesn’t tell the real story. Even though the open model of web standards is the utopia we all want, we’re still headed sharply in the other direction, even without Silverlight. If you look around at the cutting-edge innovations of web technology today, you’ll see plenty of closed models and walled gardens. We’ve got dense libraries of minimized and obfuscated JavaScript code, which are more like a compilation target than an programming language. (Or actually are a compilation target, if you’re using TypeScript.) We’ve got a technique for rendering web interfaces that bypasses the DOM and draws everything on a virtual paint surface (the HTML <canvas> element). You might use this approach because HTML manipulation and CSS formatting just aren’t precise and performant enough. Or you might use it just because you want to bypass ad blockers, users be damned. It’s the Wild West all over again.

Modern web development that adheres to open standards (nominally), while drifting away from the original philosophy of the open web.

The most innovative parts of web development aren’t connected to JavaScript at all. They use WebAssembly and WebGL to build browser-hosted games with near-native performance. You can even emulate old DOS games and Windows 95 software in your browser. Standards-based? Yes. Near universal browser compatibility? Yes. Open? Transparent? Here’s a snippet of WebAssembly for you to decide yourself:

(func (param i64) (result i64)
  local.get 0
  i64.eqz
  if (result i64)
      i64.const 1
  else
      local.get 0
      local.get 0
      i64.const 1
      i64.sub
      call 0
      i64.mul
  end)

That’s a few lines of compiled code calculating a factorial, shown before it’s been converted to WebAssembly’s compact but opaque binary format. Here’s the source:

int factorial(int n) {
  if (n == 0)
    return 1;
  else
    return n * factorial(n-1);
}

It doesn’t matter if you use these techniques. It doesn’t matter that we’ll continue building HTML pages with framework-free JavaScript long into the future. (After all, we can still send letters in the mail, even though that’s not what pays the bills at the post office any longer.) The point is that the future is about delivering web-hosted app-like products that are no more extensible, understandable, or open than a Silverlight assembly.

Plugins and gatekeepers

Now, Silverlight had some other issues, some which were products of the time (like mediocre support for mobile layout), and others which were baked-in design flaws. The biggest problem was Silverlight’s reliance on a plugin-based architecture. Plugins are terrible in lots of ways, including the fact that they can break security sandboxes and depend on one company to support all platforms, a responsibility that few people really wanted to entrust to Microsoft. But a decade ago, that was a solution that HTML couldn’t provide. (The first release of Silverlight predates HTML’s <video> element, after all.)

However, a plugin-based web framework isn’t really that far from a native app store on a mobile device or desktop computer. The advantages and risk profile are similar. There are ways that browser-makers could have sequestered the Silverlight plugin and evolved the platform, if that was the goal back in 2012. But at the time, the success of Silverlight would have been to the detriment of the evolving ecosystem of native app stores. When Apple banned Flash and Silverlight because of stability issues and high battery consumption (hah), it was really just an opportunity to start over with their curated, controlled app store model. And when Google Chrome disabled the Silverlight browser plugin, it was just another competitor who could conveniently act as a gatekeeper for the web. It turns out the browser wars weren’t for nothing.

If future imitates the past, is the past really dead?

None of this is an attempt to argue that Silverlight should still be around. It was the wrong solution in several ways. But when I look around at the modern development environment, I often think we’re intent on recreating something similar to what we’ve already rejected. Consider Microsoft’s Blazor. It’s technical underpinnings are soundly based in WebAssembly, guaranteeing it broad compatibility and cross-platform support. It’s toolchain is completely free. But it’s key feat — porting the .NET runtime engine to compact binary code — isn’t that different from the way Silverlight packed a micro .NET distribution into a plugin. It’s another new branch off the web development tree, into a highly refined and somewhat proprietary environment. The more things change, the more they stay the same.

Web standards are an increasingly low-level consideration. They’re the protocols that keep our apps talking to search engines and browsers and screen readers, but they have less and less influence over application design at the top of the stack.

Today, we’re turning the web into an app-delivery system and treating the web browser as just another rendering surface. Big tech companies seem eager to get back to the black-box development system that was so convenient in the past. Which, to be fair, isn’t the worst possible outcome. But do you really want to go back?

Which leads me to a final thought. The future is still hazy. In the past, Silverlight is long gone. But maybe its ghost isn’t done haunting us just yet.