What Silverlight Taught Me (That Still Applies Today)

Silverlight is long gone. Officially deprecated, removed from modern browsers, and largely forgotten by the wider tech community. But for me, it remains a defining chapter in my career—not because of what it was, but because of what it taught me.

When I worked at Lyons Davidson Solicitors, Silverlight was our front-end technology of choice. It came with all the challenges you might expect from a tightly-coupled, browser-dependent framework. But it also came with surprising opportunities to think differently.

Silverlight forced me to think in components. We didn’t use the term "micro frontends" back then, but that’s essentially what we were building. Each application was composed of individual modules that worked together to form a user experience. That early exposure to isolated, interchangeable UI elements planted the seed for how I would later approach modular systems and microservice design.

It was also where I first started building shared frameworks—creating reusable packages for authentication, layout, and data access. Silverlight didn’t make it easy, but it taught me something invaluable: when developer experience is painful, good abstraction matters even more. I didn’t just want to reduce code duplication; I wanted to make the experience of working in that codebase better for everyone involved.

Of course, there were lessons in what not to do. Silverlight was proprietary, locked into the Microsoft ecosystem, and required a plugin that eventually became obsolete. That experience made me more mindful of technology choice and long-term viability. It taught me to favour open standards, build with portability in mind, and design systems that can evolve rather than rely on a fixed platform.

In many ways, Silverlight taught me to think like a framework developer before I even knew that term existed. It laid the groundwork for my views on componentisation, dependency injection, and developer empathy.

So while Silverlight has been swept into the dustbin of web history, its lessons remain. It shaped how I think about architecture, how I lead teams, and how I build systems that are designed to last.

Because even obsolete tech can leave behind durable principles—if you’re willing to learn from it.