Lots of people tried to fix deployment of thick client apps, but the dependencies of those were such a mess. In fact, I’d largely blame Microsoft for that. Breaking out DLLs separately, having them initially identified only by name (even across versions), and then putting them in the same folder. What could possibly go wrong with that?
It’s not that it’s just deployment. Couldn’t we have come up with an app building strategy where deployment was easy? I’m not suggesting making deployment of the existing ones easy. I’m saying designing for ease of deployment. And if Google was 100% happy with email in the browser, they wouldn’t have responded by adding offline editing of the documents (which is just another form of thick client). Regards, Greg *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Ken Schaefer *Sent:* Wednesday, 22 November 2017 1:28 PM *To:* ozDotNet <[email protected]> *Subject:* RE: Creating a browser-based product Deployment is part of TCO, and the TCO sucks when you have lots and lots of thick client apps. And you can’t just say “that’s deployment” – lots of people have tried to solve the deployment problem, and no one has. Web-based isn’t driven by “IT sick of deploying apps” – web based is driven by the people who pay the bills. Whether that be the buyer, or the producer. Google sees no value in writing a thick-client email client, and CIOs see Gmail as working just fine without one. *From:* [email protected] [mailto:[email protected] <[email protected]>] *On Behalf Of *Greg Low *Sent:* Tuesday, 21 November 2017 7:26 PM *To:* ozDotNet <[email protected]> *Subject:* Re: Creating a browser-based product Again all of that is largely about deployment Ken. Yes thick client apps were a pain in the neck to test and deploy. But surely we could have improved the dev experience even further, while building something trivial to deploy. Web apps were largely driven by IT admin folk who were sick of trying to test and deploy apps. But for example, if you sat a user in front of say Outlook thick client and the Outlook web apps, it’d be a rare person who’d choose the web version for the UI. And how many business apps are built better than Outlook OWA? It’s not great but it’s better than the web based business apps in most companies. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com On Tue, Nov 21, 2017 at 7:11 PM +1100, "Ken Schaefer" <[email protected]> wrote: We used to have everything as thick-client apps. And then every time we had to upgrade an OS, we have to regression test, and sociability test 1000+ apps. That’s a huge waste of time. Then there’s the deployment issues of pushing thousands of apps out to thousands/tens of thousands/hundreds of thousands of endpoints. When you talk about building a LoB app – well, that works when you have 1, or 2 apps. It doesn’t scale. Instead, we’re now using a browser as a virtual OS (with hardware, networking etc. abstracted away to the real OS), with an application UI and some logic delivered as text at run-time, and the non-GUI parts centralised. And when we look at all the possible ways of building apps, and the choices being made by both developers of apps, and buyers of apps, it seems the market’s been pretty unequivocal about the preferred method. Why it’s not much better/faster than before, is probably down to immaturity. If you want an app that does something that we were able to do 20 years ago, then that’s trivial to implement. But what the market wants is apps to do things that haven’t been done before. *From:* [email protected] [mailto:[email protected] <[email protected]>] *On Behalf Of *Greg Low *Sent:* Tuesday, 21 November 2017 5:51 PM *To:* ozDotNet <[email protected]> *Subject:* RE: Creating a browser-based product But when a business just wants a line of business app, are these good answers now? Do they care if it could be used by billions of people? The odd one might care. Most won’t. Won’t they be more concerned with taking 6 or 8 times longer, and costing proportionately more? Not every app is at the high-end. Most aren’t. And now I watch daily nightmares around deploying web apps too. What exactly have we done to ourselves? Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com |http://greglow.me *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Craig van Nieuwkerk *Sent:* Tuesday, 21 November 2017 4:46 PM *To:* ozDotNet <[email protected]> *Subject:* Re: Creating a browser-based product I'm not sure this is much more of an issue now than it was. Back in the day we had to decide between Delphi, VB, Powerbuilder, C++ among others when building a Windows app. And once we decided that we had to work out which third party libraries we wanted to use with them. If I take an old 15 year old Delphi app I have it would take me the best part of a week to get it compiling again now if I had to build the dev machine from scratch. On Tue, Nov 21, 2017 at 3:53 PM, Greg Low <[email protected]> wrote: So then we’re back to why business apps take so very long to build nowadays, and why no-one can seem to decide which tools to use. Either way, as an industry, our productivity when building apps is poor.
