Well in the javascript world we don't have dll hell so much anymore, we have package hell.
On 22 Nov 2017 2:43 PM, "Ken Schaefer" <[email protected]> wrote: > Inline > > > > *From:* [email protected] [mailto:ozdotnet-bounces@ > ozdotnet.com] *On Behalf Of *Greg Low > *Sent:* Wednesday, 22 November 2017 2:09 PM > *To:* ozDotNet <[email protected]> > *Subject:* Re: Creating a browser-based product > > > > Agreed but you’re running it in the environment provided by your thick > client (ie the browser) which you did already deploy and which continues to > be patched. > > > > I didn’t say thick clients don’t work – I said that they don’t work “at > scale” > > If you have just one, (or maybe two or three) clients, then life is > manageable. > > > > The browser provides a kludgy sandbox for apps to run in. The browser was > never designed for this purpose and does it pretty poorly. Surely we could > have had a better purpose built sandbox. > > > > Then we’re back to something David touched on earlier. The idea that a > small group of people can build a universally used system, that will work > for the varied use cases of the entire world, both now and into the future, > resulted in something we call “Microsoft Windows”. Think of this as a > centrally planned economy > > > > The only other alternative we have is an imperfect, un-optimised, > de-centrally built system, like web delivered apps that run in browsers. > Think of this as “the invisible hand of the free market” > > > > I think the real free market has spoken as to what model it finds more > attractive, regardless of its imperfections. > > > > > > Regards, > > > > Greg > > > > Dr Greg Low > > 1300SQLSQL (1300 775 775) office | +61 419201410 <+61%20419%20201%20410> > mobile│ +61 3 8676 4913 <+61%203%208676%204913> fax > > SQL Down Under | Web: www.sqldownunder.com > ------------------------------ > > *From:* [email protected] <[email protected]> on > behalf of Ken Schaefer <[email protected]> > *Sent:* Wednesday, November 22, 2017 2:00:21 PM > *To:* ozDotNet > *Subject:* RE: Creating a browser-based product > > > > I think people have been looking to make deployment viable, and we’ve > ended up at the best solution we’ve been able to come up with. A server > delivers text to a pre-installed presentation/execution engine > > > > Offline document editing: what do I need to deploy to get that working? It > works within the existing client I already have, doesn’t it? > > > > > > > > *From:* [email protected] [mailto:ozdotnet-bounces@ > ozdotnet.com <[email protected]>] *On Behalf Of *Greg Low > *Sent:* Wednesday, 22 November 2017 1:35 PM > *To:* ozDotNet <[email protected]> > *Subject:* RE: Creating a browser-based product > > > > 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 > > > > > > > >
