I don't think it takes 3-4 times longer to do something in a web app versus a WinForms app. It all depends on what you are doing of course. Simple grids and data entry type input stuff is simple to do in web apps.
I'm mainly a web developer, so I'm biased towards that stance, but I've had to work on LoB programs in web (mvc), winforms, and wpf. Winforms was the worse. I hope I never have to work with one again. WPF was a lot better than winforms.
But it still couldn't compare with the simplicity of the web. It could have been because I was trying to write a WPF app that acted like the web app. WPF can be nice, and it's definitely nicer than winforms, but web apps are so incredibly simple that I really don't see an advantage. Especially when you consider deployment issues (WPF you need to keep deployments synchronized etc. Web app => single deployment and done).
My experience is exactly the opposite - winforms were a joy to use, and I barely had any success with WPF. But I had a lot of experience with MFC which were extremely close to winforms.
Agreed. I do a lot of graph visualization and find the immediate rendering model of GDI a lot easier to work with. Also, WinForms is an object-oriented UI, which just makes more sense in my head than the XAML/document/delayed rendering model. But this is just my personal preference.
Imho, WinForms had a lot of nasty bugs and counterintuitive messes - the databinding thing was clumsy, and the tabular data control has a lot of warts.
But still, there was a lot to like in the simplicity of OOP Widgets.
At least there was databinding and it worked (more or less; but binding a complete database row to a window was easy and worked well – having to hand-hold the framework in where to put values and how to write them back is quite painful in comparison).
> Simple grids and data entry type input stuff is simple to do in web apps.
Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I mean, if all you're talking about is "input number/text into box, press 'Save'" then sure, that's "simple."
I don't think I've ever witnessed a business web app with such trivial requirements, though. After they've been through the "me, too!" (e.g., for "visibility", people will insist on the inclusion of feature X, even if it's not really necessary) and political/gossip/clique infighting grinders most such apps have ridiculous requirements that blow the complexity way up.
Well, for an appropriately narrow and trivial sense of "simple" I'd agree.
I think the biggest lesson we've learned from the rise of web apps is that most business applications are simple. They come down to some sort of database, some sort of guided processes for using it, and some sort of structured user interface for data entry and reporting. These systems are inherently centralised anyway because of the shared data store that they are built on, so running the whole thing centrally and using dumb(ish) clients is a natural fit.
This doesn't mean that all business software is suitable for running as a web app. If you're creating material rather than merely entering data -- writing a report, drawing a diagram, anything like that -- web apps are still many years behind native applications in what they can do. The more significant the creation, the more this effect takes over: when was the last time you saw a professional architect or engineer doing their CAD and rendering work in a web app, or a programmer working on a million lines of code in Google IDE? But it turns out that a lot of what people do with computers is more about simple data entry and then information consumption, and you don't need all the downsides of native applications for that.
In a way, Microsoft and the like decided their own fate, because they made deployment and maintenance of native applications so onerous. If they'd had a standardised and robust deployment/upgrade facility for third party software on Windows years ago, including good support for centralised management by IT departments in the professional levels of Windows used by organisations, we might have had a different picture today. If they'd also maintained the focus they used to have on trying to provide backward compatibility at almost any cost, and developed new technologies incrementally rather than making big announcement where you just assumed their new thing would be dead in 3-5 years, I'm pretty sure they'd still be a leading business in the software industry. But they didn't, so the Web and the iPad came along, and now Microsoft are just trying to keep up.
True, but in that case an Excel or Access "front end" is almost certainly more than sufficient and where it isn't, whatever built-in system for writing "front-end forms" for the DB backend would be.
Web applications are certainly overkill for these use cases, and native applications are even more so. However, few who use these applications are interested in thinking of their jobs as rote and easily automated, and even those who recognize and are comfortable with it will likely have managers who want to increase their visibility.
So many problems with this article. For starters, he gives apple way too much credit. He also nitpicks about RT not being able to run .net apps. So what? Get a non-RT tablet. Can you run mac programs on any iPad version? No.
Enterprises need a platform that they can invest thousands, if not millions, of man-hours in. Explaining to upper management that a very expensive application will no longer work due to an upgrade that doesn't benefit the company is a career limiting event. Not to mention why there are some instances of Windows 98 still running.
Even though it is only implied by the article, Microsoft's business model is in jeopardy if the most future-proof method of application development/deployment becomes the web.
The phrase isn't "Nobody has ever been fired buying Apple." Apple is unapologetically a consumer-oriented company. Which allows them to behave differently than Microsoft.
>>>> Apple is unapologetically a consumer-oriented company. Which allows them to behave differently than Microsoft.
This a thousand times.
Microsoft is essentially stuck between servicing the enterprise segment whilst still trying to behave like Apple. They're trying to build a walled garden and shim everybody into it - including their enterprise products and customers.
In short, they are in the midst of a HUGE identity crisis.
The sad part is Apple has a more consistent message even between iOS and MacOS, that is Cocoa, and they show no sign of abandoning it anytime soon for a new framework.
> Even though it is only implied by the article, Microsoft's business model is in jeopardy if the most future-proof method of application development/deployment becomes the web.
Luckily, if you compare the life of the article to what would work reliably on the web, we're talking an order of magnitude difference.
I just checked : a win3.1 .exe runs fine on my win8 test VM, and displays exactly as intended (well, a bit smaller than intended I guess due to the ridiculous resolution of my screen, oh well). A webapp made just 3 years ago doesn't display correctly on anything more recent than IE7.
Seems like windows tech is still by far the safer bet.
I think the author is experiencing and commenting on the challenge of building business apps for mobile in general - not just Windows/WinRT. WinRT suffers from the same limitations as iOS and Android when it comes to servicing business' needs. The good news is that WFP is going to be supported and improved upon (despite what the author says) until WinRT is a viable alternative.
In the future I can see a small business owner linking all his computers together with a master Microsoft account and then buying a POS app that's downloaded to all of his computers linked under that account. If that can be done, it'd be a major leap from where we're at right now.
Cringe, laugh or cry if you will, but LoB development has essentially moved to the web.
Overall I think Microsoft's metro/winrt/client focus really abandoned their position of strength in the enterprise. This essentially forces existing Microsoft-friendly enterprises to switch technology stacks (WinRT is a non-trivial migration target) and at the same time gives a significant boost to HTML- the long trail of abandoned platforms should give everyone pause when considering a new one.
I'll put much of the responsibility (blame?) of this on Sinofsky who essentially wanted a clean slate for WinRT to ensure apps were designed for Metro and not half-assed ports. This strategy was fairly cocky and I'll argue could have been done with more finesse to not destroy as much marketshare- right now Win8 needs every inch it can get.
For most companies, its either Microsoft or Java stack. There isn't too much in between. And frankly its not a bad stack when money is not a factor in deciding the stack.Most companies whose core business isn't software just want to get their job done. Microsoft works well in this space and will continue to do so. Frankly, with Java being part of Oracle, I feel there is an even more push to Microsoft.
Obviously this is my opinion but I don't believe I will running out of work any time soon on the Microsoft stack.
So which of them work well with Oracle, SQL Server, and DB2 drivers? Your average fortune 500 company isn't moving to PostgreSQL for the hell of it.
They're running on top of unix, but it all comes down to the database. And the java and .NET drivers are the best options. Rails has oracle and DB2 options, but how many people are using them? How well are they supported? How many people are around if you run into problems? What list of consultants can you hire when an advanced problem comes up?
Otherwise, you're stuck with a labyrinth of ETL jobs between the main DB and your internal app. That's not going to bode well, especially with JRuby around.
The other option is writing your business logic in the JVM and doing rest calls between that and your front end. I've heard multiple discussions of this (and even seen it done a few times.) But that's not getting rid of the JVM.
I think they had a chance with microsost lightswitch , which looked like a pretty good LoB dev environment, But it only supported windows UI. I they had supported HTML5 + windows from the start(not just recently), they might have kept some users using windows UI.
Now everybody is doing html5. There are even good tools for LoB(like alpha five) on html5 , so lightswitch has little advantage.
Which makes me think lately: why do I even need Microsoft's stack for HTML5 as an employee? I bet that by choosing Scala instead of C# I would gain both in terms of salary and in terms of re-usability of skill across different platforms. And JavaScript/HTML5... well I guess these are just crappy times and we have to bite the bullet of using outdated crappy languages for client-side...
Because XAML: 1) is a limited subset of WPF; 2) an intentionally chosen confusing name; 3) can't be used for desktop development (AFAIK) - and that is what a typical enterprise wants.
Is this correct? It is my understanding that XAML is the client language that is used in WPF and Silverlight (which is a subset of WPF). Both WPF and Silverlight can be used for desktop or web development (although WPF leans to desktop and SL leans to web).
XAML is not a layout engine, it's a language for instantiating objects. It does not even have to be used for GUI objects, just look at workflow foundation or BizTalk transforms.
No its simply not an engine, you are wrong. WPF or WPFe (Silverlight) or WinRT have layout engines, XAML can instantiate objects that call into the respective layout engines. Those same object can be created with normal code as well, no XAML at all.
First of all XAML is a language. Second of all Microsoft is now avoiding saying WinRT explicitly, for example: http://msdn.microsoft.com/en-US/library/windows/apps/hh87219.... Third of all "set of available UI components" kind of matters when you are building certain LOBs.
XAML is a xml language for instantiating objects, whether it be a one of 3 similar but different GUI frameworks (WPF,Silverlight,WinRT) or say a workflow run-time (WWF).
Saying "XAML is what counts" is like saying "XIB is what counts" in the Apple world.
XAML is almost the same API, with differences in terms of where it is implemented (WPF, Silverlight, WinRT implementations have different sets of C#/C++ code), the available components and some classes.
However, it does share quite a lot across all frameworks where it is used.
Incorrect WPF, Silverlight, and WinRT are similar GUI frameworks much in the same way Cocoa is similar between iOS and MacOS. In Windows XAML can be used to instantiate objects from those frameworks, on the Apple side XIB's provide the same function.
I lack XIB experience. Can you also fully define GUI widgets just with XIB code like in XAML, where the whole graphic behaviour, transitions, events, skinning and themes is fully defined via XAML only?
WinForms are still an option in VS 2012-how are they not supported? Is this just an alarmist piece of writing, or are WinForms no longer around in VS 2013?
WinForms is still there. I don't understand why the author dismisses WinForms. I also don't understand why the author feels WinRT is the way forward. Sure, WinRT confused people about Microsoft's strategy, but saying this is the only route left is, well, stupid. Especially when you consider the huge industry investment in legacy tech (WinForms and WPF). There's no way Microsoft will just abandon support for it.
Many of these technologies are certainly supported (WinForms, WPF, Silverlight, etc). It's just that there isn't and won't be any new development on these products in the future. Microsoft is putting all of their focus into WinRT and Web development. On the one hand, yeah it kind of sucks that the platforms they built over the last 10-12 years are obsolete. On the other hand, they're moving an incredible pace around developing tools for WinRT and Web development (especially Web, which I keep up with in my day job).
MS went through a terrible process of whipping up and discarding frameworks a few years back... the churn of Linq2SQL being abandoned almost as soon as it was launched, Silverlight, all those rapid-fire dead-ends. Plus there were some horrible false-starts - EF3.5 was nightmarish, as was ClickOnce, and I've been less-than-impressed with SqlCE. I love the newish linguistic features of C#, but I've seriously slacked off in learning the new libs after being burned so many times. I still use WinForms for Pete's sake.
Has it settled down enough? Is it safe to start learning about WinRT? To actually figure out how MVC actually works instead of doing my best to ignore it while I do everything in Javascript and the Controllers?
All of the web stuff (ASP.NET MVC, etc) has the advantage of being open source (real open source, Apache 2 licensed, and accepts contributions). The team is also very open with the community and releases frequently. They're also working with with the OWIN (http://owin.org/) standards so that these projects don't have to be tied to Windows/IIS. It all moves very fast however, which might not necessarily be a good thing for LOB developers.
I can't really speak for WinRT. I've never touched or looked at the developer tools. And I've not ever really used an app as a user. The only reason I think it's here to stay, for a little bit anyway, is that it's the _only_ way to develop software that runs on Windows Phone or Windows RT tablets (other than Web apps).
Perhaps this could be retitled "Having cake and eating it too: No good options."
Big companies want technologies they can invest in that will remain stable and supported for a decade or more. Hell, many of them are upset that XP isn't being supported for longer than that.
If as a big company you had been a leader and built a web-based app in, say, 2005, it would most likely be a mess of hand-built DOM libraries that sniffed for specific browsers and most likely were wired to IE6 or IE7 (remember, jQuery didn't even exist yet). The "good options" that corps are choosing to use today mainly involve forcing newer versions of Internet Explorer into IE7 or IE5-Quirks mode so they don't have to lift a finger to change that festering pile of custom JavaScript.
I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. But that's what they've demanded of the last generation of apps they built.
> I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade.
Perhaps not, but there probably should be. A lot of LoB applications don't really need to keep up so to speak. Employees learn how to use them, and they accomplish whatever business process goal they are supposed to accomplish. Yes maybe they look or feel terribly old fashioned (curses anyone?) but as long as they get the job done, why should they need to be re-written every 10 years at considerable expense and risk?
I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade.
I think you're making an implicit assumption that a LoB application must be built with a single technology.
The recent fast pace of technology development has demonstrated that specifics come and go, but foundations can remain stable for much longer. Data portability matters more than code portability. Open formats matter more than open source. Communication protocols matter more than whatever is on either end of them.
If I were trying to implement a major LoB application with reasonable longevity today, I'd go back to basics and plan the software architecture with that goal in mind. Ideas like modular design and separating interface from implementation might not be trendy in a world of web frameworks and "living standards" and processes that are described as "Agile" but really just mean not bothering to plan anything properly. However, those basic principles are as valuable today as they ever were.
There is no reason an LoB application using a SQL-based data store running on Linux servers and accessible using tried and tested mechanisms like sockets shouldn't easily remain viable for decades. Probably the most you'll ever have to do is upgrade some front-end technologies to keep up with whatever devices and software platforms your people use to access the system, but that's easy.
The problem with a lot of these legacy intranet applications that have relied on successive generations of proprietary browser plug-ins isn't the dependence on the plug-ins themselves, it is that they didn't really have that kind of clean separation of responsibilities. Business logic was coded up in the front-end, so when the plug-in became obsolete, a core part of the application's logic was left in limbo. Communication was done by sending custom formats over home-grown protocols, so when new technologies came along, all of these formats and protocols had to be reimplemented from scratch and often without a proper spec.
It's not like it's ever been a secret that these tactics were likely to cause maintenance problems sooner or later. The people who planned ahead still have in-house applications that work just fine. Hopefully the people who didn't will at least learn from their mistakes and know better next time.
I'm pretty sure curses-based form "GUIs" delivered over terminal connections (now, terminal emulators) have survived the last ten years, and will survive the next. That's what you'll see carrying on, just as it has since the 1980s, at airports and banks.
Um, there is Adobe AIR which seems like a very reasonable option for building Line of Business Apps on Windows, Mac, Linux, whatever. I know it's not cool to like Adobe AIR/Flash but it would certainly get the job done and allow for easy updates, etc. outside of the Windows Store.
You could always build your apps in IronPython with GTK#.
Or even straight Python with QT. Or Java or Groovy or...
If Microsoft doesn't provide a tool that does what you need, then choose another tool. There are an awful lot of choices out there and you gain greater control over your destiny.
51 comments
[ 3.4 ms ] story [ 111 ms ] threadBut it still couldn't compare with the simplicity of the web. It could have been because I was trying to write a WPF app that acted like the web app. WPF can be nice, and it's definitely nicer than winforms, but web apps are so incredibly simple that I really don't see an advantage. Especially when you consider deployment issues (WPF you need to keep deployments synchronized etc. Web app => single deployment and done).
But still, there was a lot to like in the simplicity of OOP Widgets.
I jumped into web development with both feets back in 2000, nowadays I jump of joy every time we get to do a native application.
Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I mean, if all you're talking about is "input number/text into box, press 'Save'" then sure, that's "simple."
I don't think I've ever witnessed a business web app with such trivial requirements, though. After they've been through the "me, too!" (e.g., for "visibility", people will insist on the inclusion of feature X, even if it's not really necessary) and political/gossip/clique infighting grinders most such apps have ridiculous requirements that blow the complexity way up.
I think the biggest lesson we've learned from the rise of web apps is that most business applications are simple. They come down to some sort of database, some sort of guided processes for using it, and some sort of structured user interface for data entry and reporting. These systems are inherently centralised anyway because of the shared data store that they are built on, so running the whole thing centrally and using dumb(ish) clients is a natural fit.
This doesn't mean that all business software is suitable for running as a web app. If you're creating material rather than merely entering data -- writing a report, drawing a diagram, anything like that -- web apps are still many years behind native applications in what they can do. The more significant the creation, the more this effect takes over: when was the last time you saw a professional architect or engineer doing their CAD and rendering work in a web app, or a programmer working on a million lines of code in Google IDE? But it turns out that a lot of what people do with computers is more about simple data entry and then information consumption, and you don't need all the downsides of native applications for that.
In a way, Microsoft and the like decided their own fate, because they made deployment and maintenance of native applications so onerous. If they'd had a standardised and robust deployment/upgrade facility for third party software on Windows years ago, including good support for centralised management by IT departments in the professional levels of Windows used by organisations, we might have had a different picture today. If they'd also maintained the focus they used to have on trying to provide backward compatibility at almost any cost, and developed new technologies incrementally rather than making big announcement where you just assumed their new thing would be dead in 3-5 years, I'm pretty sure they'd still be a leading business in the software industry. But they didn't, so the Web and the iPad came along, and now Microsoft are just trying to keep up.
True, but in that case an Excel or Access "front end" is almost certainly more than sufficient and where it isn't, whatever built-in system for writing "front-end forms" for the DB backend would be.
Web applications are certainly overkill for these use cases, and native applications are even more so. However, few who use these applications are interested in thinking of their jobs as rote and easily automated, and even those who recognize and are comfortable with it will likely have managers who want to increase their visibility.
Even though it is only implied by the article, Microsoft's business model is in jeopardy if the most future-proof method of application development/deployment becomes the web.
The phrase isn't "Nobody has ever been fired buying Apple." Apple is unapologetically a consumer-oriented company. Which allows them to behave differently than Microsoft.
This a thousand times.
Microsoft is essentially stuck between servicing the enterprise segment whilst still trying to behave like Apple. They're trying to build a walled garden and shim everybody into it - including their enterprise products and customers.
In short, they are in the midst of a HUGE identity crisis.
Luckily, if you compare the life of the article to what would work reliably on the web, we're talking an order of magnitude difference.
I just checked : a win3.1 .exe runs fine on my win8 test VM, and displays exactly as intended (well, a bit smaller than intended I guess due to the ridiculous resolution of my screen, oh well). A webapp made just 3 years ago doesn't display correctly on anything more recent than IE7.
Seems like windows tech is still by far the safer bet.
In the future I can see a small business owner linking all his computers together with a master Microsoft account and then buying a POS app that's downloaded to all of his computers linked under that account. If that can be done, it'd be a major leap from where we're at right now.
Overall I think Microsoft's metro/winrt/client focus really abandoned their position of strength in the enterprise. This essentially forces existing Microsoft-friendly enterprises to switch technology stacks (WinRT is a non-trivial migration target) and at the same time gives a significant boost to HTML- the long trail of abandoned platforms should give everyone pause when considering a new one.
I'll put much of the responsibility (blame?) of this on Sinofsky who essentially wanted a clean slate for WinRT to ensure apps were designed for Metro and not half-assed ports. This strategy was fairly cocky and I'll argue could have been done with more finesse to not destroy as much marketshare- right now Win8 needs every inch it can get.
The default question is now, why not Web? A justification needs to be made as to why its not web based.
With ASP.NET MVC I feel there is better control of large datasets so that the whole set isn't loaded at once which WebForms made so easy to do.
1. Why not Web? 2. Why not NoSQL? 3. Why Microsoft?
Large teams drive make typed languages attractive and C# does it without leaving behind a lot of the functional (like) and dynamic (like) features.
C# and Office are the reasons there is still a microsoft, but those are pretty decent reasons.
For most companies, its either Microsoft or Java stack. There isn't too much in between. And frankly its not a bad stack when money is not a factor in deciding the stack.Most companies whose core business isn't software just want to get their job done. Microsoft works well in this space and will continue to do so. Frankly, with Java being part of Oracle, I feel there is an even more push to Microsoft.
Obviously this is my opinion but I don't believe I will running out of work any time soon on the Microsoft stack.
I find it odd that the "Unix stack" isn't considered a horse in this race.
They're running on top of unix, but it all comes down to the database. And the java and .NET drivers are the best options. Rails has oracle and DB2 options, but how many people are using them? How well are they supported? How many people are around if you run into problems? What list of consultants can you hire when an advanced problem comes up?
Otherwise, you're stuck with a labyrinth of ETL jobs between the main DB and your internal app. That's not going to bode well, especially with JRuby around.
The other option is writing your business logic in the JVM and doing rest calls between that and your front end. I've heard multiple discussions of this (and even seen it done a few times.) But that's not getting rid of the JVM.
Now everybody is doing html5. There are even good tools for LoB(like alpha five) on html5 , so lightswitch has little advantage.
XAML is what counts in these stacks and it is still there.
There are only differences in the amount of C# and C++ code in the XAML stack, and the set of available UI components.
We are discussing its place in GUI Frameworks.
Saying "XAML is what counts" is like saying "XIB is what counts" in the Apple world.
However, it does share quite a lot across all frameworks where it is used.
Has it settled down enough? Is it safe to start learning about WinRT? To actually figure out how MVC actually works instead of doing my best to ignore it while I do everything in Javascript and the Controllers?
I can't really speak for WinRT. I've never touched or looked at the developer tools. And I've not ever really used an app as a user. The only reason I think it's here to stay, for a little bit anyway, is that it's the _only_ way to develop software that runs on Windows Phone or Windows RT tablets (other than Web apps).
Big companies want technologies they can invest in that will remain stable and supported for a decade or more. Hell, many of them are upset that XP isn't being supported for longer than that.
If as a big company you had been a leader and built a web-based app in, say, 2005, it would most likely be a mess of hand-built DOM libraries that sniffed for specific browsers and most likely were wired to IE6 or IE7 (remember, jQuery didn't even exist yet). The "good options" that corps are choosing to use today mainly involve forcing newer versions of Internet Explorer into IE7 or IE5-Quirks mode so they don't have to lift a finger to change that festering pile of custom JavaScript.
I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. But that's what they've demanded of the last generation of apps they built.
Perhaps not, but there probably should be. A lot of LoB applications don't really need to keep up so to speak. Employees learn how to use them, and they accomplish whatever business process goal they are supposed to accomplish. Yes maybe they look or feel terribly old fashioned (curses anyone?) but as long as they get the job done, why should they need to be re-written every 10 years at considerable expense and risk?
I think you're making an implicit assumption that a LoB application must be built with a single technology.
The recent fast pace of technology development has demonstrated that specifics come and go, but foundations can remain stable for much longer. Data portability matters more than code portability. Open formats matter more than open source. Communication protocols matter more than whatever is on either end of them.
If I were trying to implement a major LoB application with reasonable longevity today, I'd go back to basics and plan the software architecture with that goal in mind. Ideas like modular design and separating interface from implementation might not be trendy in a world of web frameworks and "living standards" and processes that are described as "Agile" but really just mean not bothering to plan anything properly. However, those basic principles are as valuable today as they ever were.
There is no reason an LoB application using a SQL-based data store running on Linux servers and accessible using tried and tested mechanisms like sockets shouldn't easily remain viable for decades. Probably the most you'll ever have to do is upgrade some front-end technologies to keep up with whatever devices and software platforms your people use to access the system, but that's easy.
The problem with a lot of these legacy intranet applications that have relied on successive generations of proprietary browser plug-ins isn't the dependence on the plug-ins themselves, it is that they didn't really have that kind of clean separation of responsibilities. Business logic was coded up in the front-end, so when the plug-in became obsolete, a core part of the application's logic was left in limbo. Communication was done by sending custom formats over home-grown protocols, so when new technologies came along, all of these formats and protocols had to be reimplemented from scratch and often without a proper spec.
It's not like it's ever been a secret that these tactics were likely to cause maintenance problems sooner or later. The people who planned ahead still have in-house applications that work just fine. Hopefully the people who didn't will at least learn from their mistakes and know better next time.
Or even straight Python with QT. Or Java or Groovy or...
If Microsoft doesn't provide a tool that does what you need, then choose another tool. There are an awful lot of choices out there and you gain greater control over your destiny.