![Smile :)](./images/smilies/icon_smile.gif)
Successful test
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Re: Successful test
Thanks sparkOut, I've rephrased it ![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
Re: Successful test
Too bad this.
I think i started LC around the same time as Hermann with the difference that my knowledge is going linear at slow pace and his was going at exponential progress and speed.
I understand his feelings and he is totally true.
I think i started LC around the same time as Hermann with the difference that my knowledge is going linear at slow pace and his was going at exponential progress and speed.
I understand his feelings and he is totally true.
-
- VIP Livecode Opensource Backer
- Posts: 9842
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Successful test
I've admired Herman's work, but I don't disagree that perhaps he's driven that train about as far as it can go.
I'm not sure this particular HTML export implementation can ever meet many expectations, no matter how much time/money gets poured into it.
It may be fine for very specific applications, but those looking to make web apps may note that pretty much no other desktop application tool also attempts to produce web apps, with the exception of those based on web technologies and driven by the web's only scripting language, JavaScript.
Look into what Emscripten is and how it works. By translating the entire engine into a JS lib it will always be very large, often prohibitively so, and cannot run as fast as a native stand-alone because it's a scripting language being interpreted by another scripting language on the fly.
There are at least two other approaches to using LC to produce a web app, and both would deliver truly web-native output. But one (the method Toolbook used, with prefab functions written in both languages) is very limited, and the other (direct translation of LiveCode to JavaScript) profoundly expensive and may not even be possible.
And even if the size and speed impediments could be overcome affordably, then what? Given that the desktop and the browser are such fundamentally different platforms, the vision of exporting an existing desktop app to the web is impractical from a design standpoint alone. File I/O, windowing, menus, OS integration, layout flow, etc. - all vastly different, some non-existent on the web altogether given its vastly different role.
So you'd be pretty much limited to using LC only for a subset of things designed specifically for web deployment, provided you can work out the remaining inherent differences between desktop and browser platforms.
About the only thing web apps and desktop apps have in common is that they both exist on a computer. In so many other ways they are fundamentally different beasts.
For myself, even though I helped fund LC's HTML export out of curiosity, my own deployments take either of two different routes:
- use LC to help generate truly native web UIs (ad hoc variants of the Toolbook approach)
- web-savvy standalones ("streaming apps") that download UI along with content/data from the server (more or less else Adobe does these days)
The latter provides the best of both worlds for those apps worth the small cost of a one-time install. Once installed, updates happen automatically with each session, just as they do on the web, but with a much richer UI fully dedicated to the task the app was built for, and with full OS integration including file access, registry, IAC, etc.
Streaming apps are perhaps the greatest untapped potential in our community.
I'm not sure this particular HTML export implementation can ever meet many expectations, no matter how much time/money gets poured into it.
It may be fine for very specific applications, but those looking to make web apps may note that pretty much no other desktop application tool also attempts to produce web apps, with the exception of those based on web technologies and driven by the web's only scripting language, JavaScript.
Look into what Emscripten is and how it works. By translating the entire engine into a JS lib it will always be very large, often prohibitively so, and cannot run as fast as a native stand-alone because it's a scripting language being interpreted by another scripting language on the fly.
There are at least two other approaches to using LC to produce a web app, and both would deliver truly web-native output. But one (the method Toolbook used, with prefab functions written in both languages) is very limited, and the other (direct translation of LiveCode to JavaScript) profoundly expensive and may not even be possible.
And even if the size and speed impediments could be overcome affordably, then what? Given that the desktop and the browser are such fundamentally different platforms, the vision of exporting an existing desktop app to the web is impractical from a design standpoint alone. File I/O, windowing, menus, OS integration, layout flow, etc. - all vastly different, some non-existent on the web altogether given its vastly different role.
So you'd be pretty much limited to using LC only for a subset of things designed specifically for web deployment, provided you can work out the remaining inherent differences between desktop and browser platforms.
About the only thing web apps and desktop apps have in common is that they both exist on a computer. In so many other ways they are fundamentally different beasts.
For myself, even though I helped fund LC's HTML export out of curiosity, my own deployments take either of two different routes:
- use LC to help generate truly native web UIs (ad hoc variants of the Toolbook approach)
- web-savvy standalones ("streaming apps") that download UI along with content/data from the server (more or less else Adobe does these days)
The latter provides the best of both worlds for those apps worth the small cost of a one-time install. Once installed, updates happen automatically with each session, just as they do on the web, but with a much richer UI fully dedicated to the task the app was built for, and with full OS integration including file access, registry, IAC, etc.
Streaming apps are perhaps the greatest untapped potential in our community.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Successful test
@ Post by FourthWorld » 19 Apr 2020
Thank you Richard. You expressed very clearly what to expect now and in future from the HTML "engine". I like to confirm from my very subjective side that those who really need web develop applications need to use JavaScript -- with some exceptions. LiveCode could still eventually support the HTML/CSS/JS coding in the background using it's strong chunk expressions and work as a "coding" engine.
Maybe Mark or Malte could elaborate on the future of HTML as it is in the minds of many of us? I have no idea what the goal is now. It makes not sense to push a product further when it only will hit concrete walls. It is not even clear to me what it could do better compared to just JavaScript and for which specific purpose.
Hermann's work is fantastic. Big thanks to his work. It pushes the boundaries. On the other side, the time it needs working around all the limitations -- often throwing away the work started -- is time that could be spent simply in learning JS as an addition to LC. Ressources put into HTML engine run the danger to just evaporate. I also have supported the HTML development financially, but I can not see where it could go, and there seem to be principle obstacles -- as you state. And good developers do not just limit themselves to one language. I would like to see a lot of JS-LC integration though, whatever that could be. You gave good hints.
Thank you Richard. You expressed very clearly what to expect now and in future from the HTML "engine". I like to confirm from my very subjective side that those who really need web develop applications need to use JavaScript -- with some exceptions. LiveCode could still eventually support the HTML/CSS/JS coding in the background using it's strong chunk expressions and work as a "coding" engine.
Maybe Mark or Malte could elaborate on the future of HTML as it is in the minds of many of us? I have no idea what the goal is now. It makes not sense to push a product further when it only will hit concrete walls. It is not even clear to me what it could do better compared to just JavaScript and for which specific purpose.
Hermann's work is fantastic. Big thanks to his work. It pushes the boundaries. On the other side, the time it needs working around all the limitations -- often throwing away the work started -- is time that could be spent simply in learning JS as an addition to LC. Ressources put into HTML engine run the danger to just evaporate. I also have supported the HTML development financially, but I can not see where it could go, and there seem to be principle obstacles -- as you state. And good developers do not just limit themselves to one language. I would like to see a lot of JS-LC integration though, whatever that could be. You gave good hints.