On Sun, Jan 27, 2013 at 1:03 PM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> >> Please take a look at the proof of concept (both the intermediate and > >> release code) before making these kinds of statements. > >> > >> I'd like to, but you admitted yourself that it has quite an initial > > overhead to set up. Could you perhaps set up an online demo where one can > > observe a running system? Or a download of the compiled application? At > > least that's what I did for the AMD approach: > > Excellent idea. Here is the full Flash version (+ view source) and > both the 'intermediate' and 'release' output of the proof of concept: > > http://people.apache.org/~erikdebruin/vanillasdk/ > > A bit of view source will show you why I've been saying what I've been > saying. The 'getting started' page for the Closure Tools, as its name > implies, only covers the basics. There is, however, a bit more to the > story, as you can see ;-) > Thank you Erik, for providing a running version so quickly. That really helps! I think I can now pinpoint the difference to RequireJS: It is in the existence of deps.js. deps.js says it's generated, and seems to be the extracted dependencies of all the other JS files, right? Aha, so this is how the necessary scripts get loaded in advance. And this is where you need the build tool: To extract the dependencies and generate this additional file deps.js. RequireJS has a similar mechanism, called "shims". You can "shim" any JavaScript library that was not made for AMD by specifying dependencies in an additional configuration file. See http://requirejs.org/docs/api.html#config-shim But for modules written in the AMD style, a "deps" file is not necessary. What I criticize is that dependencies have to be specified twice. Granted, the second occurrence is generated by a tool, but that means you have to use the tool. It just makes things more complicated and more dependent. Why should this be necessary, when there is another solution that works without this redundancy and build step? Especially in development mode, when I change a single AS source file, it would be great if it would suffice to re-generate only the corresponding JS file. But when you add a dependency to your AS code, deps.js would have to re-generated, too, and as it looks quite monolithic, this operation might be expensive. With the AMD approach, you can re-generate exactly one file and reload in the browser, and everything will work. I know that for some Flex folks, development turn-around to the browser is not such an important issue, as they see the JS output more like an alternative deployment format, so they'll test in Flash or AIR and only deploy and QA in HTML5. I see a different scenario, where Flex is used to develop primarily for HTML5, which makes fast development turn-around to the browser a necessity. One more thing, something I didn't find out is how deps.js gets loaded. It has to be triggered by base.js somehow. Can you please explain? > > I'm looking forward to seeing the Falcon implementation of your > AMD/RequireJS ideas and it's output, so we can compare the various > suggested approaches on their technical merits as well as their > theoretical underpinnings. > > Okay, we can wait for that, but since Michael says what I did with Jangaroo 3 is easily re-implemented in Falcon, why not compare now? The output will/should be very very similar to what the Jangaroo 3 output looks like now, e.g. the one of the Open Flash Chart example. Another idea would be I take your example code (or any other code you want) and compile it with Jangaroo 3 and also deploy the output. What do you think? Greetings -Frank-
