Re: [ASJS] debugging output JS?
On Tue, Jan 29, 2013 at 9:38 AM, Roland Zwaga rol...@stackandheap.comwrote: We have 2 camps now, performance vs debugging features. I believe you are incorrect. The debugging features are only relevant when compiling in debug mode. Every camp here agrees that release mode should output the most optimized JS possible. Totally agree with Alex and Roland. Daniel, did you have a look at Erik's demo? http://people.apache.org/~erikdebruin/vanillasdk/ It is not a performance demo, but what you can see is that, from the same AS sources, the compiler produces a debuggable version (intermediate JS version) and a minified version (release JS version) which packs the whole application into merely 11.5 kb. While this is only a small demo application, it shows that there is no bloat or large overhead. So the solution to first create debuggable code, then minify for production, seems to work well. We'll do performance tests later, when we have a larger example working. Greetings -Frank-
Re: [ASJS] debugging output JS?
To give an impression of how you could switch between different debug levels and also to see how the AMD approach compares to the goog approach, I re-compiled Erik's VanillaSDK demo with Jangaroo 3 to AMD-style JavaScript output. This is the output format Mike Schmalle will be implementing as an alternative emitter for FalconJx. (Sorry I had to use Jangaroo to build this demo now; Mike is working hard on the FalconJx AMD emitter and eventually, the result will be much better than Jangaroo, since Falcon is the better AS3 compiler.) Here is the result: http://www.jangaron.net/vanilla-sdk-poc/ In total, there are four variants. The first and last version correspond to Erik's intermediate JS and release JS versions. To show the full bandwidth of debug levels, I added linked and linked and minified ... (bootstrapped). The former is a build where all AMD modules are merged into a single file, but not minified. The latter is a build where all AMD modules are merged and minified, but this one file is still loaded via RequireJS. So if you really want only one big JS file loaded with one request, you have to use the release JS version. The resulting release version (9.5 kb) is quite similar in size to the goog version (11.5 kb), although it has only been minified with SIMPLE_OPTIMIZATIONS, while the goog version uses ADVANCED_OPTIMIZATIONS. I think this underpins my point that starting from standard JavaScript code respecting rules like avoid accessing global variables, you can do without Google Closure Compiler's ADVANCED_OPTIMIZATIONS. But of course, we need a larger example before I'd dare to generalize this conclusion. All three debuggable versions actually load the same HTML page debug.html, the difference is coded into the URL hash joo.debug and evaluated by the bootstrap script new.js: - #joo.debug=true or #joo.debug -- load each class by a single request, so that you can easily find them in any (good) JavaScript debugger. Each file contains full white-space, comments, and non-minified JavaScript code. - #joo.debug=linked -- load all classes by one single request, but still with full white-space, comments, and non-minified. - #joo.debug=false or no hash -- load all classes by one single request, minified. All corresponding artifacts are automatically created as part of the build process. Of course, you can choose to only build the ones you actually need. *Source Maps* For the #joo.debug=true versionhttp://www.jangaron.net/vanilla-sdk-poc/debug.html#joo.debug, Jangaroo's experimental JavaScript source map support has been used. As far as I know, the only browser that currently supports source maps is Chrome. So if you want to see it in action, please use Chrome. And you might have to enable it first: 1. In the developer tools (F12), click on the button with the gear icon on the bottom right 2. In the settings dialog that appears, set the check mark in section *Sources*, labelled Enable source maps 3. Reload the page Now, in the Sources tab, when you open the navigator (arrow button top left), you'll find an *.as file next to each *.js file that has been generated from AS. Try and set a breakpoint e.g. in Example.as, line 66, inside the first click handler method. Then click on the demo button labelled Click me. The debugger should stop at your breakpoint and show the corresponding Call Stack, Scope Variables, and so on. You can now step through your ActionScript code, and the corresponding JavaScript code gets executed. Magic, isn't it? And it can be done for FalconJx, too! The vision is to combine the minified or at least the linked version with source maps, so that actually only one JS file is loaded, but is appears in the debugger as many AS files. To achieve this, we will have to combine the source map generated by our compiler and the source map generated by the JS minifier into a direct mapping. Using the source maps API that GCC provides, this should be quite straight-forward. Have fun! -Frank-
RE: [ASJS] debugging output JS?
Big yes, that's impressive :) -Fred -Original Message- From: Frank Wienberg [mailto:fr...@jangaroo.net] Sent: Tuesday, January 29, 2013 5:04 PM To: dev@flex.apache.org Subject: Re: [ASJS] debugging output JS? To give an impression of how you could switch between different debug levels and also to see how the AMD approach compares to the goog approach, I re-compiled Erik's VanillaSDK demo with Jangaroo 3 to AMD-style JavaScript output. This is the output format Mike Schmalle will be implementing as an alternative emitter for FalconJx. (Sorry I had to use Jangaroo to build this demo now; Mike is working hard on the FalconJx AMD emitter and eventually, the result will be much better than Jangaroo, since Falcon is the better AS3 compiler.) Here is the result: http://www.jangaron.net/vanilla-sdk-poc/ In total, there are four variants. The first and last version correspond to Erik's intermediate JS and release JS versions. To show the full bandwidth of debug levels, I added linked and linked and minified ... (bootstrapped). The former is a build where all AMD modules are merged into a single file, but not minified. The latter is a build where all AMD modules are merged and minified, but this one file is still loaded via RequireJS. So if you really want only one big JS file loaded with one request, you have to use the release JS version. The resulting release version (9.5 kb) is quite similar in size to the goog version (11.5 kb), although it has only been minified with SIMPLE_OPTIMIZATIONS, while the goog version uses ADVANCED_OPTIMIZATIONS. I think this underpins my point that starting from standard JavaScript code respecting rules like avoid accessing global variables, you can do without Google Closure Compiler's ADVANCED_OPTIMIZATIONS. But of course, we need a larger example before I'd dare to generalize this conclusion. All three debuggable versions actually load the same HTML page debug.html, the difference is coded into the URL hash joo.debug and evaluated by the bootstrap script new.js: - #joo.debug=true or #joo.debug -- load each class by a single request, so that you can easily find them in any (good) JavaScript debugger. Each file contains full white-space, comments, and non-minified JavaScript code. - #joo.debug=linked -- load all classes by one single request, but still with full white-space, comments, and non-minified. - #joo.debug=false or no hash -- load all classes by one single request, minified. All corresponding artifacts are automatically created as part of the build process. Of course, you can choose to only build the ones you actually need. *Source Maps* For the #joo.debug=true versionhttp://www.jangaron.net/vanilla-sdk-poc/debug.html#joo.debug, Jangaroo's experimental JavaScript source map support has been used. As far as I know, the only browser that currently supports source maps is Chrome. So if you want to see it in action, please use Chrome. And you might have to enable it first: 1. In the developer tools (F12), click on the button with the gear icon on the bottom right 2. In the settings dialog that appears, set the check mark in section *Sources*, labelled Enable source maps 3. Reload the page Now, in the Sources tab, when you open the navigator (arrow button top left), you'll find an *.as file next to each *.js file that has been generated from AS. Try and set a breakpoint e.g. in Example.as, line 66, inside the first click handler method. Then click on the demo button labelled Click me. The debugger should stop at your breakpoint and show the corresponding Call Stack, Scope Variables, and so on. You can now step through your ActionScript code, and the corresponding JavaScript code gets executed. Magic, isn't it? And it can be done for FalconJx, too! The vision is to combine the minified or at least the linked version with source maps, so that actually only one JS file is loaded, but is appears in the debugger as many AS files. To achieve this, we will have to combine the source map generated by our compiler and the source map generated by the JS minifier into a direct mapping. Using the source maps API that GCC provides, this should be quite straight-forward. Have fun! -Frank-
Re: [ASJS] debugging output JS?
On Tue, Jan 29, 2013 at 7:52 PM, Erik de Bruin e...@ixsoftware.nl wrote: It seems you needed to make changes to VanillaSDK to make it work with Jangaroo. What alternative for the 'goog' UI framework will you be using on the AMD side? The only change to VanillaSDK is that I removed the dependency on the goog library. I didn't need to make that change to make it work with Jangaroo, it just didn't seem to make much sense to remove goog for the class setup, but keep it just to create a DOM element and attach an event listener (VanillaJS can do that quite well). And since your prototype didn't work in IE8 (mode) anyway, nothing was lost. As discussed in the thread [ASJS] Integration with existing JS libraries and components, the AMD solution integrates well with *any* JavaScript library. So if you wanted to use AMD plus goog UI, that would be possible, too. The other thread contains some details on what possibilities you have to shim an existing library that does not natively support AMD, and discusses proposals for a [Native] annotation. I also mentioned on that thread that we (= CoreMedia) use Ext JS as the UI component library (and DOM abstraction). It is possible to instantiate Ext JS components (or any other Ext JS objects) from ActionScript and MXML, as well as to subclass existing components. You virtually do not notice that Ext's components are implemented in JavaScript, not in ActionScript. One thing I asked myself when I looked at your VanillaSDK code is why you checked in the JavaScript code of the framework classes (everything but Example.as). Aren't they written in AS3 and cross-compiled, too? At least that's how I thought you'd do it, even if this code is never compiled to run in the FlashPlayer or AIR. Take into account that you are intending to implement a complete UI component framework, you wouldn't want to do that in JavaScript directly, would you? Greetings -Frank-
Re: [ASJS] debugging output JS?
One thing I asked myself when I looked at your VanillaSDK code is why you checked in the JavaScript code of the framework classes (everything but Example.as). Aren't they written in AS3 and cross-compiled, too? At least that's how I thought you'd do it, even if this code is never compiled to run in the FlashPlayer or AIR. Take into account that you are intending to implement a complete UI component framework, you wouldn't want to do that in JavaScript directly, would you? No, I don't. I will use the Closure Library on the JS side. I am not even going to implement a framework on the AS side. I use the Flex SDK. The VanillaSDK JS framework is just a very thin wrapper around these frameworks. It have the same API on the JS side as on the AS side: the only thing I need to compile to JS is the project AS and MXML. All development takes place on the AS/MXML side (e.g. in Flash Builder), no need for current Flex developers to learn anything new. JS is a release format, for when your project is ready to be deployed. The idea is: low learning curve, easy acceptance, high impact, good marketability. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] debugging output JS?
On Tue, Jan 29, 2013 at 3:13 AM, Daniel Wasilewski devudes...@gmail.comwrote: I do understand that Frank might have personal interest in getting Flex close to Jangaroo for compatibility purposes, or maybe I am wrong and this just came from experience building that very tool. Dan, to put that right, my personal interest, as you call it, is actually to open up the possibility for Jangaroo developers to one day migrate to Apache Flex without too much headaches, and, that is the point in bringing in my experience, without the feeling that this is a step backwards in any way. If you accept that developers will be using Apache Flex to develop primarily or solely for JS/HTML5, you can imagine that once you got used to source level debugging in the browser, you wouldn't want to miss it when using the successor tool. -Frank-
[ASJS] debugging output JS?
Hi Roland (et al.), No, I don't think you misunderstood, you seem to grok our positions correctly. What I don't see in the 'debug JS' approach is what do you do with the bugs you find in JS? Any changes you make in the JS will get overwritten the next time you compile the AS, correct? Or am I missing something? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] debugging output JS?
On 28 January 2013 10:51, Erik de Bruin e...@ixsoftware.nl wrote: Hi Roland (et al.), No, I don't think you misunderstood, you seem to grok our positions correctly. What I don't see in the 'debug JS' approach is what do you do with the bugs you find in JS? Any changes you make in the JS will get overwritten the next time you compile the AS, correct? Or am I missing something? Oh no, changing the generated JS would be futile, but having clear access to through, for example, source maps would be really important for being able to pinpoint what is going wrong. I'm sure that once Apache Flex starts churning out projects that are being cross-compiled we're going to run into edge cases where the generated JS doesn't work, or doesn't work as expected. And especially in the latter case you'd probably want to be able to play around with the JS to see what the problem is exactly. Am I making sense? Roland
Re: [ASJS] debugging output JS?
What I don't see in the 'debug JS' approach is what do you do with the bugs you find in JS? Any changes you make in the JS will get overwritten the next time you compile the AS, correct? Or am I missing something? Oh no, changing the generated JS would be futile, but having clear access to through, for example, source maps would be really important for being able to pinpoint what is going wrong. I'm sure that once Apache Flex starts churning out projects that are being cross-compiled we're going to run into edge cases where the generated JS doesn't work, or doesn't work as expected. And especially in the latter case you'd probably want to be able to play around with the JS to see what the problem is exactly. Certainly, which is why I 'keep' the intermediate JS, which is not optimised or minified at all. I think the JS output I create is very readable and matches the original AS structure reasonably well. Not line for line, to be sure, but close enough to be able to match it back to the AS code. In case you missed it in the flood of emails I sent the last couple of days: I've uploaded the output of my concept so everyone can view the results without having to set up the whole project. Please look at: http://people.apache.org/~erikdebruin/vanillasdk/ EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] debugging output JS?
Certainly, which is why I 'keep' the intermediate JS, which is not optimised or minified at all. I think the JS output I create is very readable and matches the original AS structure reasonably well. Not line for line, to be sure, but close enough to be able to match it back to the AS code. In case you missed it in the flood of emails I sent the last couple of days: I've uploaded the output of my concept so everyone can view the results without having to set up the whole project. Please look at: http://people.apache.org/~erikdebruin/vanillasdk/ Yea, I definitely checked out your examples. Still, the ideal situation would be a working source map between JS and AS. While it might not be essential immediately, I think eventually the type of bugs we run into on the JS side of things will dictate whether such granular mapping is necessary. And looking even further into the future, where some folks might not even debug in the flash player, but purely in the browser then this type of mapping is indeed required just because they'd need to debug their AS business logic. So, it that case it wouldn't even have to do with the correctness of the JS output, but simply the correctness of the logic. So, perhaps the discussion is premature.
Re: [ASJS] debugging output JS?
So, perhaps the discussion is premature. Well, maybe a little, but I agree that given the use cases you site, it will become important sooner rather than later. I don't have the cycles to think about this now, as there are other, more pressing issues remaining with my proof of concept. But as always, if anyone feels brave enough to think about a AS - VanillaSDK source map and how that should be used in an everyday workflow, I'm certainly open to accepting patches. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: [ASJS] debugging output JS?
Look at Frank's prior emails for details. We will do something, but first, I want to make sure there is enough other stuff that works such that folks even want to try to use this technology and have an issue with debugging. Just my 2 cents. This hasn't been a major issue for us with other cross compilation. We debug with verbose non-minified JS. We have the ability to use sourcemaps, and they are a cool demonstration feature, however, day to day debugging has been such that almost everyone here has just preferred to debug with the JS which was clear 'enough' on how it mapped back to the source. Mike
Re: [ASJS] debugging output JS?
Here we go again, I have to say from my stand point, thumbs up for the Erik approach. I also believe and think about JS output as optimised result of whatever compiler can do with source code written in AS3. I can't see any benefit in having mimic of AS3 in JS to the accuracy of every single line of original code. The only reason to use Flex for this kind of job would be to have a better tools for debugging and developing my application. I don't care how ugly the output code will be as long as it just works and performs with acceptable performance level. Otherwise I would forget about AS3, Flex, all tooghether and pick one of hundreds JS frameworks that are closer to vanilla JS, will produce understandable and debug-able output for me. That very scenario is a Flex Doomed for me. If Flex will output slow, over-bloated stuff, I already have lists of JS frameworks as my candidates to do the job. I am not saying that disregard with any effort being made by Alex or Frank here. I think you both doing great job. I do understand that Frank might have personal interest in getting Flex close to Jangaroo for compatibility purposes, or maybe I am wrong and this just came from experience building that very tool. But is always like that, there is bunch of developers who cares and those who doesn't. Within those who do, the do care about different things sometimes. We have 2 camps now, performance vs debugging features. Don't forget this is Flex, not JS people but AS people counting on this project to stay relevant on the market. And we have to give them a reason for that. Creating Yet-Another-Framework/Interpreter will not make it different from all (put your favourite language here and bunch of new coming up by this occasion like DART) - JS solutions that we already have plenty on the market. And when comes to Flex more challenges are on the way with MXML. Nobody want to realise after all that effort that after months of development you can't move a box around smooth enough that even jQuery looks like a rocket next to it. I will repeat myself from the very beginning of that conversation, do it right or don't even start it. What is already done right is what Michael have done on AST level, it is abstract enough to try out many concepts for JS output. I would love to compare Alex and Frank results or anybody who can join and take it to another level, see how it works in practice, what advantages are and let community and market decide. See in practice if my Flex/AS tools are sufficient enough to rely on, if I can trust output doing a job without diving deep into the language that by nature, every single person on Earth may create his own way of doing the same thing. But hey! Some people love it for that freedom of expression! Sorry for that wall of text, but I limited myself to just one post per month by now :) On 1/28/2013 10:08 AM, Erik de Bruin wrote: What I don't see in the 'debug JS' approach is what do you do with the bugs you find in JS? Any changes you make in the JS will get overwritten the next time you compile the AS, correct? Or am I missing something? Oh no, changing the generated JS would be futile, but having clear access to through, for example, source maps would be really important for being able to pinpoint what is going wrong. I'm sure that once Apache Flex starts churning out projects that are being cross-compiled we're going to run into edge cases where the generated JS doesn't work, or doesn't work as expected. And especially in the latter case you'd probably want to be able to play around with the JS to see what the problem is exactly. Certainly, which is why I 'keep' the intermediate JS, which is not optimised or minified at all. I think the JS output I create is very readable and matches the original AS structure reasonably well. Not line for line, to be sure, but close enough to be able to match it back to the AS code. In case you missed it in the flood of emails I sent the last couple of days: I've uploaded the output of my concept so everyone can view the results without having to set up the whole project. Please look at: http://people.apache.org/~erikdebruin/vanillasdk/ EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [ASJS] debugging output JS?
On 1/28/13 6:13 PM, Daniel Wasilewski devudes...@gmail.com wrote: We have 2 camps now, performance vs debugging features. I don't think it is one vs the other. There are trade-offs to be made. First we have to get enough stuff working to see what the trade-offs are. Yes, Jangaroo is already working so folks can always go there, but as far as Apache Flex goes, a bunch of us are trying to get stuff up and running and a lot of this email debate is premature. I'm all about performance. That's one of the key drivers in writing a new framework from scratch. The current SDK is laden with just-in-case code. And maybe folks will be able to debug the output without any other assistance, but I'm pretty sure the Adobe Flex team needed help from the AIR/IOS team on occasion to debug stuff that worked fine in the emulator but not on the device, and I have trouble believing that there won't be a need to occasionally step through the JS code in any of the approaches we're coding up. And to me, it is this 'last mile' that is also a key to success. If it isn't efficient to find that last nasty bug, or make that one last UI tweak, or optimize some code or memory usage, then it doesn't matter how fast it would've run if you can't actually finish it. Do I think line-for-line AS to JS is needed for debugging? No, but I think we'll have to let any users we get dictate that. My current thinking is that we'd add comments to the JS source (in debug mode, not in release mode) about what line of AS you're looking at, but if it turns out we don't even need that because folks can understand the debug JS output, then great, we'll have saved ourselves some time. But first, we need to get some users... -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
