I must agree. If I want to create web forms I can use a zillion tools. No, I want to create graphically rich apps that are multimedia driven or games. It's great that I can use live code for more mundane database programming as well, but I need the more complex stuff to work on mobile devices and the web.
Mike Sent from my iPad On Sep 23, 2011, at 2:22 PM, Richard Gaskin <ambassa...@fourthworld.com> wrote: > Pete wrote: >> I guess that's what's been in my mind throughout this thread - we're all >> pointing out how difficult it is to do this but RB have done it. I know >> nothing about other limitations of RB vs LC but it appears they have taken >> the lead in this one area. > > In terms of perception, unquestionably. > > But in terms of actually moving projects to the web, it would require that > one of us here use it to determine the degree of flexibility it provides. > > The video on the page linked to in the OP showed a relatively simple example, > a master-detail form. > > How many of us *haven't* done that? Yes, that sort of thing can definitely > be generalized easily. > > But then we have things like the stuff folks build using Malte's excellent > Animation Engine. Can you write stuff like that in RB and have it > automatically output the corresponding HTML/JavaScript/CSS to make it happen > in a web browser? > > Or consider Jim Hurley's wonderful rainbow refraction stack. Or Richard > Herz' Reactor Lab? Or Glenn Fisher's RobinHood? > > How much gets done on the server, and how much is done in the browser? > > To what degree can we fulfill expectations of "putting LiveCode stacks on the > Web" if all that happens is that the server reproduces static layouts as > minimally-interactive pages? > > Heck, how do you write a JS equivalent of LC's Geometry Manager to reposition > things when the window gets resized? And how to do translate the thousands > of resizeStack handlers we've all written? > > Doable, but not trivial. Very, very expensive, and responding to resize > events is just a small corner of the breadth of tasks such a translation > system would need to address. > > There are limits to what seems to be RB's approach. The server is only half > of the equation. The user experience takes place in the browser, and all > interactivity there is driven by only one language, JavaScript. > > Confining the range of interactions that can take place in pages generated by > such a system is easily doable by anyone with time and motivation using > nothing more than the tools we have in our hands right now. > > But to reproduce the full range of user experiences we can build in LiveCode > inside of a browser is not a trivial task. > > I could be wrong, but I'd be very surprised if that's what RB/Web attempts. > > -- > Richard Gaskin > Fourth World > LiveCode training and consulting: http://www.fourthworld.com > Webzine for LiveCode developers: http://www.LiveCodeJournal.com > LiveCode Journal blog: http://LiveCodejournal.com/blog.irv > > _______________________________________________ > 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 _______________________________________________ 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
