Two words, Richard. IT Departments. Of the 150+clients my client has, 150+ of them would emphatically prefer a web based app than a desktop one. They don’t want stuff ‘installed’ or ‘run’ on their machines that haven’t been thoroughly tested before use. Each and every update. And they really don’t want to have to keep testing each and every update. Using Chrome/Edge-Chromium overcomes all of that.
Having built his business over 10 yrs ago with zero coding experience and learning LC from scratch, to now, remaining his only coding platform/language, he wants a way to continue being able to contribute without having to learn a new language while still taking his maaassive app suite onto the web. Emscripten is (part-way to) a godsend. If only the basics worked as they had before chromium deprecated old event handler syntax. That’s the major crux of its current downfall. Otherwise it’s an incredibly powerful way of coding for the web. And mySQL from LC in the browser is tonnes faster than on the desktop - massively! Because they’re both on the same server. Even though the message path is LC>JS>(AJAX)>PHP>JS>LC! Sean > In my own mind I phrase that differently. Whether it's gentler or more stark > is up to the reader, but for me it's more: > > ...it can't address the fundamental differences between desktop > and web architectures, and the limitations inherent in Emscripten. > > Emscripten is good for what it was designed to do. But look deeply at LC, > consider what Emscripten is, and the more time you spend pondering it the > clearer it becomes how difficult it is to put a desktop app's square peg into > a browser hole. > > Putting an entire scripting engine and object model into a browser > application that already has its own scripting engine and object model cannot > achieve size, performance, and integration features as well as a web-native > implementation. > > If you truly need a browser as your only deployment option, it's kinda hard > to argue against going with the grain of the browser. > > But most apps that might make good candidates for LC's HTML export have > characteristics that lend themselves very well to not doing HTML at all, > instead using a one-time download of an LC standalone which then downloads > and runs stack files (a practice that, in the absence of a more common label, > I like to call "streaming apps"). > > Fits most of the same uses cases, but provides a more focused user experience > that integrates with the OS as only a native app can. > > Extra bonus points that they're cheap and easy to build in LC, fast cheaper > to deliver sophisticated works than even web-native implementations. > > For the sorts of vertical audiences where LC's HTML would seem interesting, I > believe simply streaming stacks in a standalone is the most underappreciated > and underutilized opportunity in our community. > > MetaCard promoted the idea heavily with some nice example downloads, but in > all these years only a few of us make streaming apps regularly. > > If you're waiting for LC's HTML to get good, let's discuss streaming apps for > those where they might be a great solution. We really don't need to wait for > anything to have the benefits of net-distributed apps. You can have it all > today, with the LC you know and love already. > > -- > Richard Gaskin _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
