Richard, If it were only JavaScript, I'd say, SURE, I'll take that bet!
But it's not. It's the ever-changing landscape of xHtml, HTML5, JavaScript, various DOM versions, and it's about the vagaries and hassles in trying to create actual working decent cross browser CSS. Its about learning Apache components, and understanding caching techniques, and how to connect to different databases, each requiring their own flavor of SQL or other language. And learning about schemas and relational databases, how to set them up, how to access and optimize them. It's about learning when and how to write stored procedures, and in what language. It's about deciding what framework is best, and what other client side AJAX APIs you need to learn. And most importantly, it's about the full time job of trying to keep up with all this technology and the HUGE and RAPID changes that are being made. There are individuals whose full time job is just keeping up with CSS. There are companies who ONLY purpose is to convert a Photoshop layout to HTML/CSS. That's the beauty of LC. You only have to learn a single IDE, and you CAN develop for all these other platforms. If I thought it was as simple as typing a few lines of JavaScript, then I'd be there. Sadly, it's not. But, look what RB is doing. They allow you to create a RB application which runs fine on your desktop, then wrap it in a binary exe and run it AS IS on a server as a CGI. And it returns a perfectly formatted HTML, JavaScript, CSS full-featured cross browser solution, without the dreaded plugin. And without the need for me to be on top of the latest CSS browser hack which makes something look right in iOS Safari. Now, I know RB is nowhere near as flexible as LC, Jerry tells me you can't even change the color of the the text on a button without having to write a C-plugin, and don't even think about "rolling your own controls," BUT... If they can figure out how to take a subset of their functionality and build a full functioning web app, then surely it's in the realm of possibility for LC? Just sayin'. On Thursday, September 22, 2011, Richard Gaskin <ambassa...@fourthworld.com> wrote: > Keith Clarke wrote: > >> But even if it isn't easy, if RunRev don't grasp the nettle on >> this, developers who must deploy standards-based rich apps into >> cloud and locked-down Enterprise environments will be forced >> elsewhere, which would be a shame. > > I wrote about this last year: > <http://lists.runrev.com/pipermail/use-livecode/2011-June/157979.html> > > Like too many of my posts that's a long one, but it represents pretty much everything I came up with that's relevant to the discussion, and I've been thinking about this a long time since two of my biggest projects are all about the web and are based in LiveCode. > > In short: > > There are two sides to this, client and server. > > On the server side RunRev has already provided what may be the most cost-effective solution for that with RevServer. > > But the client is a whole other game, fully immersed not only in a very different language but also in a deeply well-defined object model that, in many respects, bears little resemblance to LiveCode's. > > We use LiveCode because a good scripting language lets us build things more quickly than we could do in a lower-level language like C. > > But JavaScript is not a low-level language. It's almost as high-level as LiveCode, and as well integrated into the object model it supports as LiveCode is with its own. > > But the object models are very different. > > Attempting full translation of LiveCode to JavaScript would not be impossible, but very expensive. IMO, when you consider the limitations inherent in such a task, it's probably much more expensive than just learning JavaScript. > > That said, there are many opportunities for using LiveCode to generate some portions of the client-side experience for the web. A starting point was outlined here in 2006: > <http://lists.runrev.com/pipermail/use-livecode/2006-June/083956.html> > > I haven't used the RB/web implementation, but I'd be surprised if it did full RB->JavaScript translation; my guess is that the server side is very much like RevServer and the client side is like the ToolBook approach I outlined in 2006. > > We can have that too, and we needn't wait for anything from RunRev - anyone with sufficient time and motivation can build this today. > > But somewhere along the way you'll eventually find limitations between what LiveCode can do on the desktop and what a translation to a different object model will be able to do on the web. There's more to apps than forms. > > And for those you'll want to use JavaScript. > > Fortunately, it's kinda fun to learn and there are orders of magnitude more resources for that than we have for all the things we've learned about LiveCode. > > Dive in, the water's fine. > > -- > 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 > -- Chipp Walters CEO, Shafer Walters Group, Inc. _______________________________________________ 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
