Sorry, another Greg rant to follow…
Web based apps are a slightly better form of dumb terminal app that you could have had running on your DEC VT-100 ( https://en.wikipedia.org/wiki/VT100) or IBM 3270 ( https://en.wikipedia.org/wiki/IBM_3270) terminal in the 1980’s. I first used a VT-100 in 1979, the modern browser has added graphics and Javascript. We have not moved that far forward in 38 years! I have used reasonable interactive programs on VT-100 and 3270 terminals, but programs that use the full power of the client machine’s power, provide a significantly improved end user computing experience. Plugins like Silverlight and Flash made web apps open to using a lot more of the client machine’s resources to provide an interactive experience. But, the industry has not supported these plugins for some reason I fail to fully understand. If we cannot use Silverlight or Flash and fat clients are too hard / expensive to install, you are back to the dumb terminal browser plus Javascript again. Look at compute intensive apps like 3D modelling or video editing, they could never be done properly with today’s browser technology! Web Assembly (https://en.wikipedia.org/wiki/WebAssembly) may be a logical sandboxed solution to these problems. But I see Web Assembly as an immature technology that needs evolution to be production application ready. In the meantime, I will continue to program as much as I can, with as much of the logic as possible running on the server where I have 100% control. The client can ask for additional chunks of UI (html) to be sent down the wire (AJAX) and I will avoid as much logic as possible in the client UI. Or maybe even a win forms app, because it is fast, I have 100% control *and it is not really that hard to install*! Silverlight looked like such a logical solution to this problem. Ten years after Silverlight, we are not yet at the point where we can provide a solution anywhere near as good. Frankly when I look at the way this technology has moved in the last 20 years, I am very *VERY* disappointed by our industry! All the best Greg Harris On Wed, Nov 22, 2017 at 3:34 PM, Tony Wright <tonyw...@gmail.com> wrote: > 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" <k...@adopenstatic.com> wrote: > >> Inline >> >> >> >> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ozdot >> net.com] *On Behalf Of *Greg Low >> *Sent:* Wednesday, 22 November 2017 2:09 PM >> *To:* ozDotNet <ozdotnet@ozdotnet.com> >> *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:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on >> behalf of Ken Schaefer <k...@adopenstatic.com> >> *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:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ozdot >> net.com <ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Greg Low >> *Sent:* Wednesday, 22 November 2017 1:35 PM >> *To:* ozDotNet <ozdotnet@ozdotnet.com> >> *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 >> >> >> >> >> >> >> >>
