> The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper".
Expecations have changed.
It is 2004, your company needs a simple CRUD app so your employees can work with some structured data in a DB somewhere, let's say so sales can check inventory levels in an existing database.
A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004.
2022, your sales team needs to access inventory levels in a database. Assuming you haven't already been sold some multi-million dollar solution to do this (and you likely have, multiple times, and at least some of the implementations have failed), you now have the following requirements:
1. Some of your employees use Apple laptops, some use Windows.
2. People want to be able to access the data on their phones as well, which adds another 2 OSes to the mix.
3. Restricting the app to being onsite in the office doesn't cut it.
So, you can write 4 (!!) native apps. The ugly WinForms one is still simple, but you can either adopt a proprietary "simple app building" solution for the other 3 OSes (or just use it for all 4 OSes), and have serious issues finding devs who know the niche tech you've picked, or you can make a website.
Now, native apps on smart phones are a constant maintenance headache. Major OS releases break things on mobile all the time, and entire APIs get deprecated. (Another reason why writing against Windows is good, that Winforms app from 2004 probably runs just fine with 0 changes in 2022) It is easier to maintain 1 website than 2 mobile apps and 2 desktop apps.
So, website it is.
What framework are you going to use? Whatever one is stable, easy to hire for, and has the best tooling. OK so I wouldn't call React "stable", hopefully it has undergone its last major redesign for awhile (LOL), but there is tons of tooling for it. Of course the docs suck compared to what Microsoft had in 2004, because it turns out part of that $500 per seat license for Visual Studio went towards amazing documentation and example code. And because Web you'll get breaking changes now and then, but it still is easier than maintaining 4 native apps.
People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.
>A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004.
...
>People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.
I was doing this exact work during this time and things weren't that easy back then either. Does anyone remember DLL Hell[1]? Even if everyone was running Windows on an corporate machine, it was still more difficult to deploy new code than it is today. Being able to deploy the same code to a wide variety of different machines is a huge cost saver today.
I was doing that exact work back then, as well, and DLL hell was mostly gone by then. If you had a dependency, you simply packaged it alongside your main binary, and it wouldn't affect any other app on the system. DLL hell only arose when apps would try to install their dependencies globally (i.e. into \WINDOWS or \WINDOWS\SYSTEM32), but it was already rather uncommon by early 2000s, except for the most foundational runtimes like the C++ one.
.NET pretty much solved the problem even for globally deployed dependencies by imposing physical versioning, and added file signatures for good measure, so that your dependency would literally be on that exact copy of the DLL.
I had direct experience with some apps in VB6, some in Delphi, some in .NET/WinForms, and even one in C++/wxWindows. None of them had any DLL hell issues. Not as in I dealt with them, but as in they simply never arose in the first place.
> Even if everyone was running Windows on an corporate machine, it was still more difficult to deploy new code than it is today
Is that true? As someone who was also doing native Windows desktop applications back then (C# and VB in .net from 2006-2010), ClickOnce handled everything pretty reliably for Windows XP/Vista/Server (even with weird DLL requirements -- for example, I had to ship a QuickBooks Desktop API wrapper and propritary Epson drivers in our .net desktop app)
Yes, it's not quite as reliable as "go to my-app.com". But it was way more reliable than Electron's current self-updating (.net ClickOnce loaded in a tiny fraction of the time that Slack and Discord's Electron apps take to check for updates on every launch)
Well that Wikipedia page exists so I wasn't the only one running into the issue. I will note that the time period you listed is a few years after this problem peaked. These issues were a lot more pronounced in the VB Classic era and were greatly improved in the first few releases of the .Net Framework. Your timeframe is just after that.
I cut my teeth during that era and the level of complexity asked for from those apps was minor compared to what people will demand today. Your native app will also require every machine to install a bunch of extra libraries before they can even run your little CRUD app.
At some point you maybe wrote a cute little auto-update function that let you update the application automatically... until IT slapped your hand and told you never to do that ever again.
You could write a similar web app in any modern framework in just a few days as well, and have it work on any device with a browser. It updates automatically and IT doesn't give a shit. Yay!
I have a pet theory that one of the big things that drove SaaS adoption was that people didn't need to deal with IT gatekeeping. You could get the latest software RIGHT AWAY! As soon as the devs finished it! Incredible!
Wow! I remember working for a company having to deal with your 2022 scenario way back in 1997! Only back then we didn't have npm, react, or any other of a dozen Javascript frameworks I've forgotten the name of.
Oh, and we did it without Visual Studio as well. Kids today.
> So, you can write 4 (!!) native apps. The ugly WinForms one is still simple, but you can either adopt a proprietary "simple app building" solution for the other 3 OSes (or just use it for all 4 OSes), and have serious issues finding devs who know the niche tech you've picked, or you can make a website.
Or you can adopt a free software / open source simple app building solution for all four OSes (or, hm, at least three of them -- not quite sure about iOS) that compiles natively on these and many other OSes. Sure, the UI would preferably be designed differently for desktop vs small-screen mobile, but you have that problem with Electron too, don't you?
> OK so I wouldn't call React "stable", hopefully it has undergone its last major redesign for awhile (LOL), but there is tons of tooling for it.
I'm not sure what you're talking about. The last major feature addition to React was Hooks in 2018. But that didn't break stability at all - you can still use all of the old React APIs and ignore that Hooks exist entirely. The React team has actually been incredibly thoughtful about introducing new APIs, rarely break backwards compatibility, and it's a library I generally trust _not_ to break anything on updates.
If you work somewhere that insists on flavor of the month development using the shiniest libraries and the newest features, yeah, there's a lot of churn, but that's a very different complaint from "I wouldn't call React stable".
> The last major feature addition to React was Hooks in 2018. But that didn't break stability at all - you can still use all of the old React APIs and ignore that Hooks exist entirely.
Yes, except that hooks completely changed how React is written, and most libraries and code samples now days use hooks. You basically had to learn a brand new way of writing React. I learned react pre-2018 (tens of thousands of LOC written) and I basically "don't know React" now.
Then there is the ecosystem churn. I got tired of my routers breaking, all the bloody time. In 2 years I had to rewrite the routing for my code twice, each time took multiple days of frustration[1].
There has been the rise and fall of Redux, which again, massive churn in the ecosystem.
[1] In defense of React I was using React Native Web which, at least at the time, was a pile of many small disasters combined into a single code base. Also it wasn't as well documented as I'd like, and eventually I had to scrap it and move to regular React, which solved many of my issues.
> And unless you were writing drivers, that major OS version wasn't going to break anything.
Just a minor nitpick, but the NT device driver API has in fact stayed largely the same since Windows 2000 and in comparison to the various technologies that came and went in userland.
And then MS got pissed at Creative for having drivers so bad that crashes from Creative sound card drivers accounted for a non-trivial % of all Windows crashes. The result was MS changing the entire Windows audio stack and eliminating Creatives most lucrative product line.
I don't have much to add, except that WinForms was an absolute dream to work with. I was literally illiterate in any kind of programming and I was able to build stupid little apps that actually did things.
I remember writing one utility that would turn off the monitor with a global key shortcut. It had a little window with just one button, and would minimize to tray.
I was able to build it just by downloading the free version of Visual Studio and reading the docs. The extent of my programming knowledge at that time was doing some silly LOGO stuff in school.
And internal websites are a direct competitor to Winforms.
Every year someone telling me Xamarine forms is better now, but every year someone tells me that they tried Xamarine forms the year prior and it still wasn't any good. My one experience with Xamarine forms was watching 3 apps teams (WinPhone, Android, and iOS) all struggle to write an app. Given that it took 3 teams, and it was a large effort, I wasn't impressed, but this was 6 or so years ago. I hope things have improved since then!
Fun fact, for awhile Silverlight was huge in the internal website world, and Microsoft could have easily had another decade of lock-in going on, but then MS killed Silverlight due to internal politics, and even the most loyal MS customers saw the writing on the wall and redirected their internal development efforts elsewhere.
90s Microsoft would never have abandoned a technology stack that had wide spread internal corporate adoption. :/
Expecations have changed.
It is 2004, your company needs a simple CRUD app so your employees can work with some structured data in a DB somewhere, let's say so sales can check inventory levels in an existing database.
A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004.
2022, your sales team needs to access inventory levels in a database. Assuming you haven't already been sold some multi-million dollar solution to do this (and you likely have, multiple times, and at least some of the implementations have failed), you now have the following requirements:
1. Some of your employees use Apple laptops, some use Windows.
2. People want to be able to access the data on their phones as well, which adds another 2 OSes to the mix.
3. Restricting the app to being onsite in the office doesn't cut it.
So, you can write 4 (!!) native apps. The ugly WinForms one is still simple, but you can either adopt a proprietary "simple app building" solution for the other 3 OSes (or just use it for all 4 OSes), and have serious issues finding devs who know the niche tech you've picked, or you can make a website.
Now, native apps on smart phones are a constant maintenance headache. Major OS releases break things on mobile all the time, and entire APIs get deprecated. (Another reason why writing against Windows is good, that Winforms app from 2004 probably runs just fine with 0 changes in 2022) It is easier to maintain 1 website than 2 mobile apps and 2 desktop apps.
So, website it is.
What framework are you going to use? Whatever one is stable, easy to hire for, and has the best tooling. OK so I wouldn't call React "stable", hopefully it has undergone its last major redesign for awhile (LOL), but there is tons of tooling for it. Of course the docs suck compared to what Microsoft had in 2004, because it turns out part of that $500 per seat license for Visual Studio went towards amazing documentation and example code. And because Web you'll get breaking changes now and then, but it still is easier than maintaining 4 native apps.
People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.