LiveCode Forums.

First, let me be clear - I do not intend this as a flame bait type of post. I don't want to ruffle any feathers. I actually need good quality perspective from LiveCode professionals to steer me in the right direction. I apologize if I step on any toes.

I am an application developer for a telecom company. I'm sort of a "department developer" vs. an "enterprise developer". I've developed some pretty cool stuff that includes automating and controlling telecom equipment, productivity apps, metrics and charting dashboards, etc. All of this was done with the traditional web development LAMP stack.

So, I'm very much stuck in the "open" web mindset. The tools I use to develop with are all open source, I don't have vendor lock-in issues. Almost anyone with moderate LAMP experience could come in and work on my code. My users don't need plugins or OS based executable files. I can change the backend and web based GUIs without having to distribute executables.

However....I am developing an application right now on a LAMP stack with the entire web GUI based off ExtJS. It's quite nice looking. It's also slow as sin. Because I have many data grids, panels, tab panels, etc, the GUI is dragging big time. I also have huge datasets that are bogging the DOM down like crazy. Yes, I COULD use pagination to limit the size of the data grids and make the app more responsive. However, it really is important for the user to see all 300 or 999 or 3000 or 9500 records all at the same time. Pagination would really kill the usability of this app. At the same time, taking 5 minutes to scroll to the end of such a datagrid is also killing the usability of this app. So, I have literally reached the limits of a browser I believe.

Then, I discovered LiveCode. I put a few datagrid examples together. 3 grids with 3000+ records each side by side = scrolling nirvana. I whipped this together in just a few minutes - literally vs. several hours with LAMP stack and ExtJS.

So, here is my dilemma. Can I really throw away the freedom and openness of web based development for something like LiveCode? I'm not even sure my company would allow it.

If someone could comment on the specific issues listed below, I'd really appreciate the feedback. I'd love someone to convince me that LiveCode is the way to go. But I need to overcome or at least alleviate my concerns.

• Vendor Lock-in
  • With LiveCode, I don't have a choice of IDEs (really).
    If RunRev goes out of business, I have an unsupportable, non-future proof app
  ExtJS Looks Great vs. Rather Sparse LiveCode Interfaces
  • ExtJS has great visual GUI and layout options.
    I haven't seen particulary nice examples of Windows/Mac based LiveCode business applications.
    Yes, LiveCode can be skinned, but I'd like a very nice off the shelf skin for LiveCode.
  Experienced Developers
  • If I leave my company, and am using a LAMP web based GUI, my employer could find someone to replace me quite easily. The talent pool is quite large.
    If I develop in LiveCode, my employer is going to have a much harder time finding a capable replacement.
  Browser Plugins
  • I just tested the browser plugin for FF and IE. My little test app worked fairly well.
    However, there is no support for Safari or Chrome.
    Everyone hates plugins( see Flash )
    My test app on FF on Mac doesn't work quite right. How to resolve.
  Standalone Executables
  • The idea of distributing applications for the desktop has really fallen out a favor.
    Having to distribute updates for every application change seems a real burden vs. instant deployment via the Web.
  Version Control.
  • With my apps in PHP, JavaScript, HTML, etc, version control is a breeze. Each file can be easily tracked, branched, committed, rolled back, etc.
    Version Control in LiveCode seems quite painful. It seems everything is kept in a singe binary file. How can this be dealt with?

My next question is not really LiveCode vs. Web. It is more related to the methodology of developing in LiveCode. What is best practice for LiveCode development?

• Hard coded
  • In my datagrid example, I coded the db connections and queries directly into LiveCode.
    Development was quick and easy.
    It's not very maintanable.
  
  API
  • Alternatively, I could have avoided all database interaction and used a web based API.
    This is very maintainable.
    It would allow someone to scrap LiveCode and choose some different GUI (web or desktop based).
    It would allow other departments to access the application data via whatever means they'd like.
    It is SLOWER because I have to develop a web based API AND the interaction with it in LiveCode

Wow! That's a lot of ground to cover. Let me take on a little bit of it, and say that I share some of your concerns in other areas.

I've been an xtalk developer since 1987 and discovered runrev circa 2001. I've had the same concerns about single-sourcing the development platform, but I've been quite happy with the way the team has run the company, developed and upgraded the core products, and been supportive of developers. Fortunately they don't take my ideas about how to run things very seriously <g>. If your license expires or something happens to runrev, you still have a working IDE and your use of the engine doesn't expire.

I wouldn't put database access into a LiveCode app. Yes, it's very maintainable that way and easy to code, but very insecure. I'd do what you were suggesting: put a middleware layer on a web server, have the LC app talk to it, and have access to the database itself entirely on the web server in a protected cgi directory, out of sight and under the hood. It's not that much more coding, you only have to do it once, and once it's done it's as maintainable as the desktop version.

Personally (this part is quite subjective, YMMV) I wouldn't go the plugin web deployment route. I'm hoping that option will disappear soon. If you're looking for a single point of deployment, you may want to look at the revserver product instead. This allows you to do LiveCode development using scripts that run on the web server and present pages to the client's browser, the same way that php, javascript, etc do, and it's rather blazingly fast because it's using the same xtalk engine running on the server. That also somewhat alleviates your concern about version control, since you'd be using text script files.

Version control for LiveCode stacks is on the way - several folks are working on it, but as you mentioned, the monolithic binary format is a pain. Shoehorning this into something like git is a matter of flattening the monolithic structure into text/xml/whatever files and handing control over to the version control system. If you just need storage and retrieval of previous versions then there's no problem now. But diffing the files is useless without the extra step - something like gitk wouldn't know what to do with a stack format. This isn't by any means an imppossible task, and it can all be done with LiveCode scripting, there's just nothing built in right now.

Oh... and if you're looking around for spiffy commercial products (re: "Rather Sparse LiveCode Interfaces"), try

http://www.tactilemedia.com/

Can I really throw away the freedom and openness of web based development for something like LiveCode? I'm not even sure my company would allow it.

Well, of course you'll need to work that out before anything else can become possible.

But if it turns out they'll consider it, here are my own views on some of this:

Vendor Lock-in

Always an issue with any proprietary tech, but with LC my clients feel comfortable given that there's enough money floating around in the extended ecosystem to keep things moving forward in a worst-case scenario. And as far as I can tell, such a worst-case scenario seems unlikely for the foreseeable future.

That said, it's hard to beat FOSS on this one: no FOSS project can ever really die, since the source is always available.

ExtJS Looks Great vs. Rather Sparse LiveCode Interfaces

Respectfully, you must be new. LC does indeed make it easy to create reasonably HIG-compliant UIs, but is by no means limited to that. With its rich built-in support for both raster and vector graphics, there's pretty much no UI on this earth that can be made with anything else that can't be made with LC.

Experienced Developers

Another point for any FOSS tech. There are many thousands of LC devs out there, and probably hundreds who could lend a hand on your project if needed, but that doesn't begin to compare with the millions familiar with FOSS tech.

Browser Plugins

I'm not a big fan of plugins myself, and about half of my work these days is with open web stuff (JS/CSS, AJAX, Apache, etc.).

But I still make a lot of apps with LC, and some of them have no local UI, downloading everything they need over HTTP.

Standalones have indeed fallen out of favor in some circles, and a big part of the transition of some of my own projects to native web implementations is to bypass recalcitrant IT staff in orgs who want our products but can't get IT to install 'em. With the web we cut IT out of the loop, bypassing them altogether to keep the conversation between the true stakeholders, the customers, and ourselves.

Yet sometimes there are things we can do in a desktop app that would be difficult to do on the web, such as integration with the local files system, other apps, or OS services.

And for those we make standalones, in which stack files are automatically downloaded from a central server on the fly as needed. This lets us update the UI and code whenever we want without having to redistribute the executable itself, providing many of the same benefits of web deployment but with all the advantages a desktop app can enjoy.

Unlike a web app, we can control what gets cached and what doesn't; with a web app the user needs to download the entire UI every time they use it. And for users on the go, a standalone can be used on trains, planes, and other places where there is no connection, allowing an offline mode that can sync with the server later if needed.

Any org that will be willing to distribute a proprietary browser plugin will just as likely be willing to deploy a standalone, provided that - like the plugin - they only need to do it once. A standalone that grabs parts from a web server can solve that problem well, and with LC it can be a simple one-liner:

go url "http://somedomain.com/mystack.livecode"


For more along these lines, this article from many years ago has help up surprisingly well with the advent of the mobile app paradigm, discussing the benefits of web-enabled executables:

Beyond the Browser:
Rediscovering the Role of the Desktop in a Net-centric World
http://www.fourthworld.com/embassy/arti ... tapps.html

Version Control

There are many ways to handle version control in LC. There's one solution in development which translates LC stacks to and from XML for use in industry-standard version control tools.

But far simpler can be just keeping the stacks in separate stack files according to their functionality, assigning them version number properties and doling them out to team members as needed.

Using this latter approach it so easy that many of us have rolled ad hoc systems in a few hours for specific projects, and one of these - Magic Carpet - has been sold as a commercial solution for this and is currently in the process of being revised as a FOSS release.

There are many ways to skin that cat, scalable as team size and project specifics dictate. Not everything need be kept in a single file.

Hard coded/API

How you structure your code is a deeper issue than anyone here can make specific recommendations for without first getting a more detailed understand of the project.

But in general, it's safe to say that good architectural practices aren't limited by one's choice of tools, be it LiveCode or anything else.

Code can be factored into layers quite well with LC, maintaining good separate between the UI and underlying business logic.

In fact, doing so well can make drafing a dual-output API, such as for web and standalone, reasonably cost-effective.

Using this latter approach it so easy that many of us have rolled ad hoc systems in a few hours for specific projects, and one of these - Magic Carpet - has been sold as a commercial solution for this and is currently in the process of being revised as a FOSS release.

Any update on this? Magic Carpet looks like a VERY useful app.

Thanks!