Comment by je42
8 years ago
OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty good of MS. I guess the main question is: how do you in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?
Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996.
In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.
Kind of, OWL and VCL were much better technology but Borland's management...
Oh man, I remember those now. You're right - they were better. It reinforces my point about how difficult it is to choose a long-term technology. It feels a little like picking stocks.
Erlang, for instance? Picking up a new shiny thing and complaining that it's not something with a proven track of backward compatibility is not a rational thing to do.
As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name.
If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.
At the mean time we are celebrating 10 years with the same UI engine: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...
The only major thing: added Direct2D H/W accelerated backend to support high-DPI and multi-DPI systems. Yet incremental addition of CSS features.
You couldn't just port from WPF to Silverlight. They took away tons of features. WinRT was even worse. No idea about UWP but I don't care anymore.
That's why I mentioned semver. APIs change all the time, backwards compatibility gets broken. Yes, conversions weren't always straight forward, but often were possible, and there was an evolutionary arc to it all, and a migration story to follow, even when sometimes that story was a bit rougher than anyone wanted.
11 replies →
These frameworks are by no way equivalent. Silverlight was running on multiple versions of Windows and Mac OS. It should have being kept just for that awesome feature.
On the other hand Win8/10 apps don’t run on anything than the OS they were released on. Which is totally laughable because it means choosing the MS stack allow one to target less Windows OSes than third party tools. So these SDK were doomed from the beginning as thay couldn’t leverage the existing Windows userbase.
> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?
If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff?
You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.