Silverlight seemed like a smart bet. It let you write code once and run it on the web, Windows, Mac, and even Linux. We needed both a website and a standalone desktop client, and it looked like the way to avoid building two front ends.
So we built the front end in Silverlight.
The bet we made
We made one architectural decision that mattered more than the technology itself. We kept the Silverlight layer as thin as possible. It asked the back end for data, showed the data to the user, collected input, and sent the input back. The complex analytics, statistical processing, business rules, and number crunching stayed behind an API.
The front end was a presentation layer. The brain of the application stayed behind the API.
For years, that worked well. Then Microsoft effectively killed Silverlight. If the application’s logic had been embedded in the Silverlight controls, events, and view models, the death of Silverlight would have meant a full rewrite. Instead, we only had to replace the thin presentation layer. The API, the calculations, the domain rules, and the data stayed where they were.
Why the front end always dies first
Front-end technologies have the shortest lifespan in any stack. In All Front-End Development Technologies Will Soon Perish I pointed out that the devices users interact with change faster than anything else. Screens get bigger, smaller, touchable, and mobile. The frameworks follow. A UI that is fashionable today is a legacy UI in five to ten years.
Keep business rules out of the front end. The user’s experience matters. So do the rules. They are different.
In Beyond Front-End and Back-End: What Developers Really Need Now I argued that the split between front-end and back-end is less important than the contract between them. A well-designed back end can outlive many front ends if the contract is clean. A thin UI can be replaced when a new device or framework arrives without dragging the business logic with it.
The Silverlight project proved that.
The temptation to put the brain in the UI
Silverlight had rich controls, animations, and client-side processing. It was tempting to put more and more into the UI: calculated fields, conditional formatting, validation, even small business rules. We resisted because the team remembered what happens when front-end frameworks die. Every rule placed in a view model is a rule that has to be moved or rewritten later.
I see the same temptation in modern front-end frameworks. The browser is fast, the tools are powerful, and it is easy to convince yourself that a particular rule is “really a UI concern.” If the rule exists to keep the business correct, it belongs on the back end. The front end can enforce it for responsiveness, but the back end still owns it.
We learned that on a FoxPro Interop project: when business logic lives inside the UI, every new front end becomes a rewrite of the business. This time we kept that logic behind the API from the start.
The AI angle
The tools have changed again. In A Year After Our AI Experiment: What Changed and What Did Not I wrote that AI shortens the path from conversation to working solution. The durable part of the architecture is still the back end. AI can generate a new UI in hours (or minutes). It can also generate new back-end logic. The part that survives is the part separated cleanly from the UI.
If your front end is a thin shell, you can let AI rewrite it. If your front end is the whole system, you will spend the AI’s time extracting business rules from code that should never have lived there.
The lesson
No framework lasts forever. The only defense is to keep the UI as thin as possible. Ask the questions on the front end. Run the answers through the back end. Render what comes back.
When Silverlight died, our project survived. The architecture made the front end quickly replaceable. That is the bet that paid off.
This is a post in the series “The Software Does Not Work – Rewrite It: Lessons from Two Decades of Replacing Legacy Software.”
- The Software Does Not Work – Should We Rewrite It?
- The Floppy Disk Handoff: When the Source Code Lies to You
- A 24/7 Operation: The Rewrite That Didn’t Need to Stop the World
- 500 Screens, One Idea: What Users Actually Need
- There Is No Domain (Yes, There Is): Pipeline Inspections and the Dynamic App
- Why Calling FoxPro Forms from .NET Hurts
- When Silverlight Died, We Didn’t: The Thin UI Bet – This post
- Excel in the Browser: A Rewrite That Never Launched
- A Year and a Half Without a Database
- What I Still Believe About Software Rewrites
Leave a Reply