You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2013/01/28 10:51:23 UTC
[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?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Big yes, that's impressive :)
-Fred
-----Original Message-----
From: Frank Wienberg [mailto:frank@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
version<http://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?
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Tue, Jan 29, 2013 at 8:55 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > 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.
Yes, I got that, but my proposition is to use the goog library *from AS* to
create the wrapper code.
That's what we do with Ext JS successfully.
> 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.
Even if you only have to implement a thin wrapper, my experience is that
this always becomes more code that you first expected. It would just be a
better means to code JavaScript that stays completely "under the hood".
Have a look at the "native JavaScript" thread, the idea would be to define
a [Native] wrapper for goog and use that to implement component rendering
and event transformation.
Just think "there is no -spoon- JavaScript", only ActionScript... ;-)
My 5 Cents
-Frank-
Re: [ASJS] debugging output JS?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> 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?
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Tue, Jan 29, 2013 at 7:52 PM, Erik de Bruin <er...@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: Performance expectations for Flex JS
Posted by Alex Harui <ah...@adobe.com>.
On 1/30/13 1:12 AM, "Roland Zwaga" <ro...@stackandheap.com> wrote:
> I'm pretty sure that the snappiness of HTML5 applications has little to do
> with the execution speed of JS.
> In most modern browser VM's JS actually is faster than AS3, the trouble
> starts when dealing with UI stuff,
> which is more DOM or Canvas related.
I've seen some information that implies that execution speed of AS and JS
depends a lot on how strongly typed it is (for JS, I think that includes
both type hints and type inference) and how often that code runs. In AS,
just about everything gets JIT'd, and for Flex, we have lots of code that
runs once (or relatively few times) and despite the fact we use strict-mode
compilation, is not nearly as strongly typed as as it could be.
One of the things I'm trying to do in my rewrite is create more re-usable
chunks of code and allow for more strong typing.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Performance expectations for Flex JS
Posted by Roland Zwaga <ro...@stackandheap.com>.
I'm pretty sure that the snappiness of HTML5 applications has little to do
with the execution speed of JS.
In most modern browser VM's JS actually is faster than AS3, the trouble
starts when dealing with UI stuff,
which is more DOM or Canvas related.
another 2 cents...
Roland
On 29 January 2013 21:24, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > How would AS3 and JS versions of a typical app perform? If the AS3
> version
> > is running 100% at 30fps, could the JS version keep up? Or do you expect
> the
> > JS version to out-perform?
> >
> > I guess its too early to answer these questions with any degree of
> > certainty, but what are the expectations?
>
> I think the current state of JS VMs will ensure at least comparable
> performance.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
Re: Performance expectations for Flex JS
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> How would AS3 and JS versions of a typical app perform? If the AS3 version
> is running 100% at 30fps, could the JS version keep up? Or do you expect the
> JS version to out-perform?
>
> I guess its too early to answer these questions with any degree of
> certainty, but what are the expectations?
I think the current state of JS VMs will ensure at least comparable performance.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Performance expectations for Flex JS
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Tue, Jan 29, 2013 at 9:00 PM, Lee Burrows
<su...@leeburrows.com>wrote:
> 2) JS performance varies widely across browsers and even for best
> performers, its not that snappy.
>
> Well, compiling AS3 to JS solves #1 but what about #2?
>
I'd expect that at least it doesn't make #2 any worse. The minimum overhead
introduced to simulate some AS3 language features is usually negligible or
even overruled by the cleaner application design.
Building snappy HTML5 applications is still a challenge, but this is true
for any application.
The story of Sencha re-building Facebook's mobile client in HTML5
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ shows
that a) performance can vary across platforms, even or especially when
implementing native (Facebook's original Android client was less snappy
than Sencha's HTML5 counterpart) and that b) it was rather a question of
software engineering to end up with a snappy client, not a question of
technology.
Another aspect is that I expect Flex to be used rather for business
applications than for, e.g., games. In contrast to 3D or particle
simulations, the things that have to feel snappy in business applications
are well supported in the browser, e.g. smooth scrolling (e.g. through CSS3
transforms).
When doing graphically rich stuff, it is also rather the browser's canvas
or SVG implementation that is the limiting factor, not the JavaScript
engine. My experience from converting some 2D Flash retro games to HTML5 is
that on a desktop browser, they are probably factor 3 more CPU-intensive,
but still fast enough. WebGL might even totally change this.
So it is really hard to say right now, but I'm sure that if we always take
performance into account and in an opt-in fashion use the latest browser
technologies, it is possible to build Flex so that it allows you to produce
JS applications that are sufficiently snappy on every reasonably new device.
Greetings
-Frank-
Performance expectations for Flex JS
Posted by Lee Burrows <su...@leeburrows.com>.
Hi all,
I've been following with great interest the possibility of compiling
Flex to JS.
After flash armageddon, i started looking into HTML as an option for
building RIAs but decided there were two problems:
1) JS isnt exactly OOP friendly and there's a lack of suitable tooling,
which makes building and maintaining a complex application tricky.
2) JS performance varies widely across browsers and even for best
performers, its not that snappy.
Well, compiling AS3 to JS solves #1 but what about #2?
Consider the hypothetical scenario where there are enough resources to
get a fully working, polished compiler finished by next week... ;)
How would AS3 and JS versions of a typical app perform? If the AS3
version is running 100% at 30fps, could the JS version keep up? Or do
you expect the JS version to out-perform?
I guess its too early to answer these questions with any degree of
certainty, but what are the expectations?
Re: [ASJS] debugging output JS?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
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?
EdB
On Tue, Jan 29, 2013 at 7:48 PM, Frank Wienberg <fr...@jangaroo.net> wrote:
> Hehe, "competition is good for the business"... buts really let's focus on
> the debugging part here, as VanillaSDK is not yet really a big code base to
> compile.
>
>> Clever use of comment to
>
> Looks like something's missing there?
>
> What do you think it would take to introduce source maps to FalconJx?
> I guess Falcon already keeps the source code file positions (line/column)
> in the AST nodes, e.g. for error messages?
> From my experiment, I have a simple class
> PositionTrackingWriter<https://github.com/CoreMedia/jangaroo-tools/blob/source-maps/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/util/PositionTrackingWriter.java>
> which
> extends java.io.Writer and simply counts characters and new lines while
> outputting them, so always knows the current line / column.
> Then, the Google source maps API (part of closure.jar) can be used along
> the lines of
>
> import com.google.debugging.sourcemap.SourceMapFormat;
> import com.google.debugging.sourcemap.SourceMapGenerator;
> import com.google.debugging.sourcemap.SourceMapGeneratorFactory;
>
> SourceMapGenerator sourceMapGenerator =
> SourceMapGeneratorFactory.getInstance(SourceMapFormat.V3);
>
> // for each generated piece of code:
> sourceMapGenerator.addMapping(
> sourceFilename,
> null,
> sourceFilePosition,
> outputFileStartPosition, outputFileEndPosition);
>
> sourceMapGenerator.appendTo(new FileWriter(outFile.getAbsolutePath() +
> ".map.json"), outFile.getName());
> codeSuffix = "//@ sourceMappingURL=" + outFile.getName() + ".map.json";
>
> Simple enough, isn't it?
>
> Greetings
> -Frank-
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] debugging output JS?
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hehe, "competition is good for the business"... buts really let's focus on
the debugging part here, as VanillaSDK is not yet really a big code base to
compile.
> Clever use of comment to
Looks like something's missing there?
What do you think it would take to introduce source maps to FalconJx?
I guess Falcon already keeps the source code file positions (line/column)
in the AST nodes, e.g. for error messages?
>From my experiment, I have a simple class
PositionTrackingWriter<https://github.com/CoreMedia/jangaroo-tools/blob/source-maps/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/util/PositionTrackingWriter.java>
which
extends java.io.Writer and simply counts characters and new lines while
outputting them, so always knows the current line / column.
Then, the Google source maps API (part of closure.jar) can be used along
the lines of
import com.google.debugging.sourcemap.SourceMapFormat;
import com.google.debugging.sourcemap.SourceMapGenerator;
import com.google.debugging.sourcemap.SourceMapGeneratorFactory;
SourceMapGenerator sourceMapGenerator =
SourceMapGeneratorFactory.getInstance(SourceMapFormat.V3);
// for each generated piece of code:
sourceMapGenerator.addMapping(
sourceFilename,
null,
sourceFilePosition,
outputFileStartPosition, outputFileEndPosition);
sourceMapGenerator.appendTo(new FileWriter(outFile.getAbsolutePath() +
".map.json"), outFile.getName());
codeSuffix = "//@ sourceMappingURL=" + outFile.getName() + ".map.json";
Simple enough, isn't it?
Greetings
-Frank-
Re: [ASJS] debugging output JS?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Excellent work Frank, I love seeing what your approach does. Clever
use of comment to
> 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.
I agree that a larger example is better, we need to be able to compare
apples with apples. In my example I used the Closure Library for event
handling, a forward looking action designed to accomodate non-DOM
based events later on in development. To make my orange look more like
your apple, I removed that code and it's dependencies and re-wrote the
components to use DOM based event handling, like you did. When using
ADVANCED_OPTIMIZATIONS, this resulted in a single file of around 3kb.
This appears to be 3 times smaller than your output. I'm sure this
doesn't mean anything in the long run, don't get me wrong, but you're
right to not generalize your conclusion just yet ;-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] debugging output JS?
Posted by Frank Wienberg <fr...@jangaroo.net>.
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
version<http://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?
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Tue, Jan 29, 2013 at 9:38 AM, Roland Zwaga <ro...@stackandheap.com>wrote:
> > 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?
Posted by Roland Zwaga <ro...@stackandheap.com>.
> 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.
cheers,
Roland
Re: [ASJS] debugging output JS?
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Tue, Jan 29, 2013 at 3:13 AM, Daniel Wasilewski <de...@gmail.com>wrote:
> 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-
Re: [ASJS] debugging output JS?
Posted by Alex Harui <ah...@adobe.com>.
On 1/28/13 6:13 PM, "Daniel Wasilewski" <de...@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
Re: [ASJS] debugging output JS?
Posted by Daniel Wasilewski <de...@gmail.com>.
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?
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>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?
Posted by Alex Harui <ah...@adobe.com>.
On 1/28/13 2:19 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> 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.
Several approaches have been discussed:
1) matching AS lines with JS lines
2) source maps
3) source annotations
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.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [ASJS] debugging output JS?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> 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?
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
> 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?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> 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?
Posted by Roland Zwaga <ro...@stackandheap.com>.
On 28 January 2013 10:51, Erik de Bruin <er...@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