LC7 vs LC8 – The Browser Challenge. Sample Stack Included!

Mark Waddingham - March 2, 2016 reply

Hi Matt. The comparison is intended to show how much easier it is using a browser widget in LC8 compared to what you need to do prior to LC8 to embed a browser in your app. Whilst it might only be ’40 mins’ in LC7 to write that code to do the same thing (assuming you know precisely what code to write!), that is then 40 mins worth of code in your app which you have to maintain and keep functioning.

The browser widget means you can literally just drag-and-drop an embedded browser onto any stack and any card you need and it will work cross-platform out of the box. Whilst that might be only 40 mins saved for a particular instance of an embedded browser, it soon adds up when you consider all the other components apps tend to contain. (Also, revBrowser is definitely not the easiest part of LiveCode to use – particularly as you currently have to use divergent code for Desktop and Mobile).
Of course, for a widget-based development model to be successful there needs to be a wide range of widgets which people can use – we are very much at the start of this journey with LiveCode 8, but it is a start.

In terms of developing widgets then that is certainly a great deal easier than writing similar components in C++ (which the current existing LiveCode controls are), but perhaps a little more complex than writing LiveCode Script. This is a direct result of LiveCode Builder needing some of the ‘lower-level’ features present in other languages in order to be able to build high-quality, reusable and easy to use components that can be trivially used at the script level.

One of the hardest things in programming is finding the right dividing lines between components in an application (there’s that old quote – programming isn’t just about finding abstractions, it is about finding the right abstractions) and the black-box model offered by widgets is designed to help with that. Generally speaking, it is easier to modify existing solutions than it is to build from scratch; and if the modifications you need to make are completely contained in an encapsulated element then finding and fixing any problems in a whole system becomes a great deal easier.

At the end of the day, I don’t expect that it would be very hard for anybody who takes the time to learn LiveCode Builder (and has an interest in doing so) to tweak widgets they have the source (and rights) to modify for their own ends. In the case you give, for example, then you could either amend the widget to give you the nearest location on the current graph at a given position and then display an overlay using LiveCode Script, or put the display of the overlay into the widget – either would be perfectly suitable. However as your request sounds like quite a reasonable and useful one, it would be more than likely you would be able to find a component which did do precisely what you needed as the widget ecosystem grows.

The point of widgets is not in any way to replace LiveCode Script, but instead to give LiveCode Script a hugely powerful arsenal of reusable components which can be used to build better apps faster. The goal is that by raising the level at which engine-like controls can be written (i.e. in a language not too dissimilar from LiveCode Script rather than C++) the range of options open to any LiveCode developer will expand substantially.

You can take a look at what the code for widgets looks like by dipping into our GitHub repo:

https://github.com/livecode/livecode/tree/develop/extensions/widgets

There are more here than we will ship as supported widgets in LiveCode 8 (we are currently going through all of them and assessing what needs to be done to make them release-worthy) but all server as useful examples of how widgets are written.