Webifying livecode is a real mystery to me

Igor de Oliveira Couto igor at superstudent.net
Fri May 25 05:14:56 EDT 2012


I am coming to LiveCode from a web development background. I must say, that my point of view may differ from what has been presented so far.

First, I find web programming quite enjoyable. I use a very, very powerful and little-known text editor called 'Sublime Text' (http://www.sublimetext.com/), which makes writing HTML, CSS, Javascript, PHP and SQL quite enjoyable. Because web projects are usually rather complex, you often have to deal with other programmers, and because of that I have become quite comfortable with group-based version control systems - I use GitBox on the Mac, a beautifully simple front-end for Git - and have also leaned to programme using techniques like 'test-driven development'. This not only ensure a higher stability and quality in my code, but also help prove and document just how well your code works.

Unfortunately, there is no denying that web development IS a complex and ugly beast. You *are* dealing with a variety of languages, both on the client side, and on the server side. You deal with a variety of frameworks. And you have to use a variety of programming techniques, philosophies and approaches. Some of the frameworks worth mentioning:

ON THE SERVER
* SlimPHP (http://www.slimframework.com/) - makes it *super* easy to setup RESTful services and interfaces on your server
* RedBeanPHP (http://redbeanphp.com/) - an incredibly flexible and stupidly easy ORM framework which makes using your backend database a true pleasure

ON THE CLIENT
* LESS (http://lesscss.org/) - you will *never* look at css the same way again
* AngularJS (http://angularjs.org/) - there are, literally, hundreds of javascript frameworks out there that propose to be *the only one* you will ever need. IMHO, *this* is 'the one': funded by Google and based on JQuery, this is absolutely awesome, thoroughly documented and tested, can handle all your RESTful server communications and user interactivity, and can turn your HTML into an interface language. 

Using all these different technologies *is* a challenge, but for me, that is not the problem.

For me, the main problem is that the BROWSER was never designed to be a platform for application development in the first place. It was meant to be only a content-delivery tool. We are using all these tools to try to make the browser 'turn' into a platform for delivering 'desktop-quality' app - and, honestly, the browser can get close to it, but it is just not the same. Just because you *can* programme a solution as a web app, does not mean that it is the best solution. In my experience, it very rarely is. There *are* problems, always, even if you follow all the 'best-practices'. The common problems - which are well documented - include:

-- incompatibilities between platforms, between browsers and between browser versions - see http://caniuse.com/.
-- incompatibilities between different frameworks and technologies used in the same project - I typically use 3 to 5 frameworks in every project, sometimes more. There is always a breaking problem that pops up somewhere, whenever a framework needs to be updated with an 'urgent security fix'.
-- many security issues that arise if you have exposed business logic code on the client-side
-- many responsiveness and speed issues that arise if you have too much of the interface logic on the server-side
-- extremely fast technological evolution, which requires constant updating and refactoring

I have found that, although I have managed to design and produce some beautiful and functional web sites and apps - which have left me feeling quite fulfilled professionally - the truth is, that in many, many cases the client would have been better served by having a desktop or iPad/iPhone app instead.

See, I don't want to get into LiveCode so I can produce web apps. I want to get into LiveCode so I can at least *reduce* the number of web apps I produce, because I honestly feel that they are a poor solution to many of the problems that the clients want to use them to address.

Case in point: a client needs to overhaul their admin system. They are expanding overseas, and a client-management system that used to be lan-based, in-house, now needs to be accessed by their branches overseas as well. They have put some of the data already on a MySQL server (a shared host), and a web developer has already started to create pages that access some of the database information. So, they are basically going to expand their website, so that it will include a full-blown admin system for the entire company. In theory, people will be able to login from anywhere, with whatever device they have, and have full use of their client management system. From previous experience, I know this is going to be a nightmare.

I have been trying out LiveCode for about 3 weeks now, and I think we may be able to offer an alternative to the client, with LiveCode. The client can still keep their database on the shared host, but instead of accessing it with web browsers, we can develop desktop and iOS apps that will access this data remotely. Even on the server side, instead of using PHP or other languages, we can use LiveCode to access the database and dish out the data via a RESTful interface (I believe I've seen some server-side code from the amazing Andre Garzia that does that). Not only would this be a lot less complex to programme and maintain, but IMHO, it would end up being more *secure* for the client.

With this in mind, I have to agree with the original poster, that I do not really see much point in 'Revlets' - because what attracts me most about LiveCode is precisely the fact that I can might be able to get my clients to move their business processes *away* from the browser, and back into a desktop (or an iPad) app, where they belong. I believe browsers will keep evolving, and will become better and better at content delivery, but I don't think my browser will be the development platform of the future. It seems to me that LiveCode already offers a simpler, more manageable and 'sane' way to build apps that offer the same flexibility of web apps, but simpler, easier to develop and manage, and providing results that are often more secure and offer better interactivity to the user.

I hope this info may help some.

Kind regards to all, 

--
Igor Couto
Sydney, Australia





More information about the use-livecode mailing list