HTML5 deployment: progress comes into sight

[jonathandlynch at gmail.com]

A native svg object that accurately displays all svg files is essential. I strongly support Mark's point on that issue. This is not reinventing the wheel - it's attaching the already invented wheel to the wagon.

Sent from my iPhone

> On May 31, 2017, at 4:26 AM, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
>> On 2017-05-31 09:01, Dan Brown via use-livecode wrote:
>> I'll also add that for all the wonderful possibilities that LCB brings
>> there is a very real danger that countless hours will be spent using it to
>> re-invent the wheel.
> 
> That is true of every language ever implemented ;)
> 
> However, one of the goals of LCB is to allow it to be used as the 'glue' language allowing LiveCode Script to access 'things written in other languages' with (eventually) as much syntactic fidelity as you get with builtin-in engine functionality. Hopefully, reducing the need to re-invent the wheel to the minimum required to make other-world libraries look more LiveCode like.
> 
> i.e. One of its main goals is to rid ourselves of the need to 're-invent the wheel'.
> 
>> Take for instance the displaying of svg's. This is a solved problem in the
>> browser and has been for a long time but in native livecode it's still in
>> the infant stages of implementation (to put it mildly). The best solutions
>> for user interface "widgets" are arguably being created in the form of
>> javascript libraries. To me it makes total sense to integrate with that
>> ecosystem and free up LCB / livecode developer hours for solving other
>> problems
> 
> True - but then if I want SVG icons in my app, and I don't need the browser widget at all then I might balk at the 70-100Mb bloat I have to add to Windows / Linux apps to get it. Furthermore, I might balk at the start up time of my app on mobile devices, whilst I use the browser widget to load all my SVGs and render them into PNGs at various sizes (unless you instantiate a browser widget for every SVG icon you want to use and want to put up with the restrictions that places on you, and the overhead in terms of use).
> 
> Certainly we need to be careful about 're-inventing the wheel' but that just means making good choices. In this case, the case for 'native' SVG support in LiveCode is overwhelming - the more lightweight it is, the faster it is, the more utility it has. (Also, the main problem here is 'SVG as a replacement for PNG icons' which is a much smaller problem to solve than an editable SVG canvas - which is what you get if you go the via-browser route).
> 
> In terms of JavaScript 'widgets' in general, then we already have a reasonable strategy for using them now - you use a browser widget and load it in there. For example, FileMaker has a BrowserView element and there is a plugin 'React' which allows you to defined JavaScript controls and have them rendered in the browser. Admittedly using such things is a little trickier than we'd like at present - due to the lack of synchronous 'do as javascript'.
> 
> Anyway, I agree that using existing libraries and code as much as possible is probably the best way to expand LiveCode's capabilities - hence LCB :)
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> _______________________________________________
> 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