Realbasic on the web without plugins

Pete pete at mollysrevenge.com
Fri Sep 23 15:10:14 EDT 2011


I don't know the answers to your questions Richard, except that the demo
application does resize the controls when the window is resized.

As for the other question, you're right none of us have given it a try so
all it's all perception for now.

Pete
Molly's Revenge <http://www.mollysrevenge.com>




On Fri, Sep 23, 2011 at 11:22 AM, 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<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<http://lists.runrev.com/mailman/listinfo/use-livecode>
>
>



More information about the use-livecode mailing list