{"action":"created","issue":{"url":"https://api.github.com/repos/chiquitinxx/grooscript/issues/16","labels_url":"https://api.github.com/repos/chiquitinxx/grooscript/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/chiquitinxx/grooscript/issues/16/comments","events_url":"https://api.github.com/repos/chiquitinxx/grooscript/issues/16/events","html_url":"https://github.com/chiquitinxx/grooscript/issues/16","id":46640856,"number":16,"title":"Integration with UI frameworks: packaging and classes","user":{"login":"pioneer","id":200538,"avatar_url":"https://avatars.githubusercontent.com/u/200538?v=3","gravatar_id":"","url":"https://api.github.com/users/pioneer","html_url":"https://github.com/pioneer","followers_url":"https://api.github.com/users/pioneer/followers","following_url":"https://api.github.com/users/pioneer/following{/other_user}","gists_url":"https://api.github.com/users/pioneer/gists{/gist_id}","starred_url":"https://api.github.com/users/pioneer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pioneer/subscriptions","organizations_url":"https://api.github.com/users/pioneer/orgs","repos_url":"https://api.github.com/users/pioneer/repos","events_url":"https://api.github.com/users/pioneer/events{/privacy}","received_events_url":"https://api.github.com/users/pioneer/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/chiquitinxx/grooscript/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":41,"created_at":"2014-10-23T15:49:33Z","updated_at":"2015-08-12T16:17:01Z","closed_at":"2015-08-12T16:17:00Z","body":"**_Note:_** This issue was posted first here - https://github.com/chiquitinxx/grails-grooscript/issues/1. This is just by occasion, so it was closed there and reopened here.\r\n\r\n#### Introduction.\r\n\r\nThere are several UI frameworks on JavaScript market, such as [Dojo Toolkit](http://dojotoolkit.org), [Ext JS](http://www.sencha.com/products/extjs/), [Qooxdoo](http://qooxdoo.org/), [Google Closure Library](https://developers.google.com/closure/library/). All of these listed products provide two important means, which are absent or have no estabilished standard in pure JavaScript: _packages_ and _classes_. The purpose of this feature request is to add as seamless as possible configurable and pluggable integration of Grooscript with specific packaging and classes mechanisms present in a framework which is chosen for a project.\r\n\r\nThis will significantly help in writing large client applications using such a pleasant language as Groovy is, by reusing a lot of well-proven JavaScript code with huge amount of already implemented components and tooling.\r\n\r\n**Please note:** I'm still a beginner in Groovy (mostly with 6 years of Python/JavaScript experience), so some of my suggestions can be naive.\r\n\r\n#### Packages.\r\n\r\n**Problem:** there are many packaging systems in JS world: [AMD](https://github.com/amdjs/amdjs-api/wiki/AMD), NodeJS-style require, Ext.require, goog.require etc. Some of the languages which compile to JavaScript introduce their own packaging (GWT, Scala-JS, Dart) or force to use an existing one (CoffeeScript, ClojureScript). When using a compiler and UI framework which have different packaging systems, it's always tricky to do integration, combine both paradigms etc.\r\n\r\n**Suggested solution:** configurable and pluggable packaging system for a compiler, so JS code can be easily imported and used within Groovy, as well as Groovy code within JS, using single selected packaging system, which is the most comfortable to use in given project.\r\n\r\n**Ideal implementation:** `import some.package.name.Class` in Groovy code translates to `require('...')`, or `Ext.require('...')`, or AMD construct; `package some.package.name` translates to `goog.provide(\"...\")` or whatever.\r\n\r\n**Possible implementation:** maybe annotations, like `@Grab`.\r\n\r\n**Potential tricky things:** AMD allows to \"import\" not only JS code, but also modules which should just be loaded (i.e. ensuring DOM is loaded), or even requiring an HTML template as if it's a module (AFAIK Groovy doesn't allow to do something like `import dojo.text(\"./templates/SomeWidget.html\") as template`).\r\n\r\n#### Classes.\r\n\r\n**Problem:** in JS world, there are no classes, but OOP concept is still very usable thing. That's why many JS frameworks introduce their own OOP implementations, as well as some languages which compile to JavaScript, including Groovy. When using multiple implementations of objects and classes in one project, it may become very clumsy to deal with both styles (consider an example of creating a Dojo Toolkit/Ext JS/Qooxdoo widget completely in Groovy).\r\n\r\n**Solution:** I don't really know what'll be the best way. Maybe a set of intermediate integration libraries, each for specific framework (i.e. Ext JS), which contain special Grooscript class (maybe classes?) with the following characteristics:\r\n* should be the wrapper for any existing JS class from the framework, allowing to reuse all the code from given class and all its parents, Groovy way\r\n* should be the base for any Groovy class intended to be used along with given JS framework\r\n* if used as a base for a component, written in Groovy, should be able to export itself to JS in given OOP style\r\n\r\n**Note:** due to very different OOP implememtations, I doubt about an idea to replace Grooscript classes implementation with one from a JS framework, even in pluggable way, because of different logic behind Groovy's OOP and other OOPs. However, in ideal world it would be really beautiful to just import a JS class in Groovy or import some Groovy class in JS."},"comment":{"url":"https://api.github.com/repos/chiquitinxx/grooscript/issues/comments/130359449","html_url":"https://github.com/chiquitinxx/grooscript/issues/16#issuecomment-130359449","issue_url":"https://api.github.com/repos/chiquitinxx/grooscript/issues/16","id":130359449,"user":{"login":"chiquitinxx","id":879681,"avatar_url":"https://avatars.githubusercontent.com/u/879681?v=3","gravatar_id":"","url":"https://api.github.com/users/chiquitinxx","html_url":"https://github.com/chiquitinxx","followers_url":"https://api.github.com/users/chiquitinxx/followers","following_url":"https://api.github.com/users/chiquitinxx/following{/other_user}","gists_url":"https://api.github.com/users/chiquitinxx/gists{/gist_id}","starred_url":"https://api.github.com/users/chiquitinxx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chiquitinxx/subscriptions","organizations_url":"https://api.github.com/users/chiquitinxx/orgs","repos_url":"https://api.github.com/users/chiquitinxx/repos","events_url":"https://api.github.com/users/chiquitinxx/events{/privacy}","received_events_url":"https://api.github.com/users/chiquitinxx/received_events","type":"User","site_admin":false},"created_at":"2015-08-12T16:17:00Z","updated_at":"2015-08-12T16:17:00Z","body":"I'm going to close this issue. It seems with this require.js improvement is enought. With the number of packaging solutions out each day in javascript, I think we lost time supporting a specific package system. Feel free to reopen or create a new issue if you miss something or need an improvement in require.js support."}}