You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Imagine I'm doing an app in GS, and then I decide a portion of functionality should be extracted into a standalone lib in the same language. Now, for the purposes of my app, it might be good for both the lib and the main app to use a runtime.js common dependency. The runtime file could merely expose the utils in a global 'gorilla' property of the window object, or something like that. So load it first, then the lib(s), then the app.
As for the compiler option, I'd think something like --no-runtime could then be used to compile my lib and app, and then I'd run gorilla --create-runtime so as to just create the runtime.js file (and in the future, you could supply 'gorilla --create-runtime' with files so that the runtime created would be as slim as possible, only with the union of things needed by the files passed)
Or does it all sound unnecessary? How big are all the runtime helpers created by GorillaScript?
My use case for this is a software with a plugin architecture, where they can be written in anything as long it's compiled to javascript. If written in gorillascript, the person should compile the plugin without the runtime, since the main software (written all in gs) already would provide it.
The text was updated successfully, but these errors were encountered:
I had rather thought GorillaScriptHelpers would be prepended to every __to-array call. It would work more or less the way jQuery and other dependencies have a global object and you just reference it every time. But then your solution could be better, I wouldn't know.
Imagine I'm doing an app in GS, and then I decide a portion of functionality should be extracted into a standalone lib in the same language. Now, for the purposes of my app, it might be good for both the lib and the main app to use a runtime.js common dependency. The runtime file could merely expose the utils in a global 'gorilla' property of the window object, or something like that. So load it first, then the lib(s), then the app.
As for the compiler option, I'd think something like --no-runtime could then be used to compile my lib and app, and then I'd run gorilla --create-runtime so as to just create the runtime.js file (and in the future, you could supply 'gorilla --create-runtime' with files so that the runtime created would be as slim as possible, only with the union of things needed by the files passed)
Or does it all sound unnecessary? How big are all the runtime helpers created by GorillaScript?
My use case for this is a software with a plugin architecture, where they can be written in anything as long it's compiled to javascript. If written in gorillascript, the person should compile the plugin without the runtime, since the main software (written all in gs) already would provide it.
The text was updated successfully, but these errors were encountered: