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 Low1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676
4913 faxSQL 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]]
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.
