Realbasic on the web without plugins

Mike Felker admin at mfelkerco.com
Fri Sep 23 13:49:07 CDT 2011


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 <ambassador at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



More information about the use-livecode mailing list