You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2015/10/21 09:19:07 UTC

Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Changing the subject…

Here’s a real-life scenario which I’m not sure how it’s going to work:

I expect to spend the next many months building a JS version of my PrintUI WYSIWYG web app. Many parts of the the code maps pretty well to JS, especially when using EaselJS. However, I think it’s unreasonable to expect that the app can be compiled to both a Flash target as well as a JS one for the following reasons (and probably more).
1) EaselJS is not a 1-to-1 mapping to the Flash drawing APIs. It’s similar, but there’s enough differences that I don’t see how to target both. Maybe we can build some kind of class which handles conditionals and edge cases. I don’t know.
2) I’m not sure how targeting API requests will work with both targets. I have to handle custom response codes and the like which required building some custom classes which acted as a proxy for the URLLoaders.
3) There’s lots of XML processing needed. I’m not sure how to handle the XML processing in a multi-target way.
4) The biggest kicker is text editing. I’m going to have to do a LOT of work getting text to render exactly in the HTML. I’m likely going to use txtjs to help, but that’s really only a start. Besides the actual text problem, trying to target both Flash and HTML seems like a total nightmare.

Am I missing something, or will this require browser debugging?

Here’s my question:
Jetbrains seems to have worked out integrated debugging of JS[1]. If I understand correctly, the Falcon compiler has symbols that map the code. Is there any way of mapping the ActionScript code to the compiled JS code, so it’s possible to maintain links between the code similar to how debugging works with ABC code and ActionScript? Or is what I’m suggesting completely non-sensical?

I think having a really smooth debug experience on the JS side will help immeasurably in terms of FlexJS adoption.

[1]https://www.jetbrains.com/webstorm/features/

On Oct 21, 2015, at 9:50 AM, Alex Harui <ah...@adobe.com> wrote:

>> 2) How does debugging work? Assuming you are targeting only JS, is it
>> necessary to debug in the compiled JS in the browser or is it possible to
>> debug in the source code somehow using code mapping?
>> 
> 
> Well, my vision for FlexJS was that folks would build a SWF and debug the
> SWF since, IMO, there are better debugging tools in Flash Builder, and the
> Flash runtime will catch errors that the JS runtime will not.  There would
> still be times when you have to debug the JS and if the error reproduces
> in the bin/js-debug version then you can use whatever JS debugger you
> want.  If the error only reproduces in the bin/js-release version, then
> yes, you have to try debugging with the source maps.  I’ve found debugging
> the js-release version to be painful even with source maps, especially
> when minification is on.


Re: Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Posted by Harbs <ha...@gmail.com>.
I don’t remember the list off-hand, but a lot is related to language specific features. There’s also 3 or 4 levels of ligatures. There were some features I wished it supported (maybe it was contextual alternates?), but the OpenType support in general is not bad. There’s definitely missing pieces in Japanese composition, but there’s also a lot of support.

I think native browser support is pretty good, and for basic text rendering you can probably fall back to default browser support and for text in FlexJS components that’s the way to go, but for pixel-perfect composition, browser rendering of text is not going to cut it.

There’s been some efforts to do some OpenType rendering using Javascript, most notably Bram Stein's work[1] There’s also opentype.js[2]. But, everything that I’ve found which was done to date is really basic. Any of the more advanced OpenType features are not supported at all. Some GSUB support, but not even basic GPOS support, etc.

It’s kind of scary how hard it’s going to be to really do text right in the browser. Getting even close to FTE is really hard. And I haven’t a clue what performance is going to be like in JS. I would have to guess that it’s going to be a sore point…

[1]https://github.com/bramstein/opentype
[2]https://github.com/nodebox/opentype.js

On Nov 2, 2015, at 3:07 AM, Alex Harui <ah...@adobe.com> wrote:

> 
> 
> On 11/1/15, 10:26 AM, "Harbs" <ha...@gmail.com> wrote:
> 
>> Not just RTL. There’s an awful lot of OpenType features that it supports.
>> (Of course It would be great to support even more…) ;-)
> 
> I wasn’t aware of that.  What kinds of things and how do the browsers do
> it?
> 
> -Alex
> 


Re: Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Posted by Alex Harui <ah...@adobe.com>.

On 11/1/15, 10:26 AM, "Harbs" <ha...@gmail.com> wrote:

>Not just RTL. There’s an awful lot of OpenType features that it supports.
>(Of course It would be great to support even more…) ;-)

I wasn’t aware of that.  What kinds of things and how do the browsers do
it?

-Alex


Re: Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Posted by Harbs <ha...@gmail.com>.
Not just RTL. There’s an awful lot of OpenType features that it supports. (Of course It would be great to support even more…) ;-)

On Nov 1, 2015, at 5:06 PM, Alex Harui <ah...@adobe.com> wrote:

>  IMO, TextLine was primarily there to do right-to-left text.


Re: Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Posted by Alex Harui <ah...@adobe.com>.

On 11/1/15, 3:21 AM, "Harbs" <ha...@gmail.com> wrote:

>I forgot to respond to this.
>
>Yes. I could be a candidate to work on this. If I get some help, I’d be
>more inclined to work on a public port of TLF. If not, it’ll be MUCH
>easier to just hack together some code that I could use internally.
>
>FWIW, I’m not totally thrilled with Flash’s TextLine. The biggest problem
>with it is the fact that there’s no line return in the API. Another
>problem is there’s no way to do paragraph composition a la the Knuth and
>Plass line breaking algoirthm[1] using TextLine. (Well actually you
>probably could, but not exactly the way that Adobe has the APIs. You need
>to create lines one at a time.) I think there were other things that I
>wished were different when I was deep into TLF. If I do something akin to
>TLF for Javascript, I’d probably want to make it different. I guess there
>would be ways to abstract the differences, but it would be more work…
>
>
>[1]http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/abstract

Maybe we’ll get a few more folks to chime in here.  IMO, we don’t really
have to work with TLF in FlexJS unless there is some
backward-compatibility reason to do so.  If there is some other JS text
library you’d rather work with, that would be fine with me.  Then the
question becomes: what do you need for text management on the SWF version?

You could just use TLF as a “mock” and know that the layout may not match
between SWF and HTML/JS/CSS but you don’t care because you are just using
the SWF version for testing and not deployment.

Or we could examine back porting that JS text library to AS.

If we do port TLF to JS, we have to abstract TextLine and could do so in a
way that makes TextLine replaceable by TextField on SWF and something else
in HTML/JS/CSS.  IMO, TextLine was primarily there to do right-to-left
text.

-Alex


Re: Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Posted by Harbs <ha...@gmail.com>.
I forgot to respond to this.

Yes. I could be a candidate to work on this. If I get some help, I’d be more inclined to work on a public port of TLF. If not, it’ll be MUCH easier to just hack together some code that I could use internally.

FWIW, I’m not totally thrilled with Flash’s TextLine. The biggest problem with it is the fact that there’s no line return in the API. Another problem is there’s no way to do paragraph composition a la the Knuth and Plass line breaking algoirthm[1] using TextLine. (Well actually you probably could, but not exactly the way that Adobe has the APIs. You need to create lines one at a time.) I think there were other things that I wished were different when I was deep into TLF. If I do something akin to TLF for Javascript, I’d probably want to make it different. I guess there would be ways to abstract the differences, but it would be more work…


[1]http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/abstract

On Oct 21, 2015, at 4:17 PM, Alex Harui <ah...@adobe.com> wrote:

>> 
>> 4) The biggest kicker is text editing. I’m going to have to do a LOT of
>> work getting text to render exactly in the HTML. I’m likely going to use
>> txtjs to help, but that’s really only a start. Besides the actual text
>> problem, trying to target both Flash and HTML seems like a total
>> nightmare.
> 
> IMO, you would be a candidate to try porting TLF to JS.  Most of the code
> doesn’t care too much about Flash.  I think if you abstract the TextLine
> you can get quite far.


Re: Debugging (was [DISCUSS] Release Apache FlexJS 0.5.0)

Posted by Alex Harui <ah...@adobe.com>.
For sure, FlexJS is not so far along that you won’t have to use browser
debugging.  More thoughts inline.

On 10/21/15, 12:19 AM, "Harbs" <ha...@gmail.com> wrote:

>Changing the subject…
>
>Here’s a real-life scenario which I’m not sure how it’s going to work:
>
>I expect to spend the next many months building a JS version of my
>PrintUI WYSIWYG web app. Many parts of the the code maps pretty well to
>JS, especially when using EaselJS. However, I think it’s unreasonable to
>expect that the app can be compiled to both a Flash target as well as a
>JS one for the following reasons (and probably more).
>1) EaselJS is not a 1-to-1 mapping to the Flash drawing APIs. It’s
>similar, but there’s enough differences that I don’t see how to target
>both. Maybe we can build some kind of class which handles conditionals
>and edge cases. I don’t know.

Om has successfully abstracted a lot of FXG and SVG and flash.graphics.*
as well.

>2) I’m not sure how targeting API requests will work with both targets. I
>have to handle custom response codes and the like which required building
>some custom classes which acted as a proxy for the URLLoaders.

FlexJS is all about abstraction replacement.  There is already an
HTTPService that works well with JSON so you get the same experience
whether on SWF or using XHR in JS.

>3) There’s lots of XML processing needed. I’m not sure how to handle the
>XML processing in a multi-target way.

You sure you can’t switch to JSON?  If you must use XML, I still think
there is a common API you could come up that uses XMLDocument in Flash and
something in JS.  E4X would be a ton of work.

>4) The biggest kicker is text editing. I’m going to have to do a LOT of
>work getting text to render exactly in the HTML. I’m likely going to use
>txtjs to help, but that’s really only a start. Besides the actual text
>problem, trying to target both Flash and HTML seems like a total
>nightmare.

IMO, you would be a candidate to try porting TLF to JS.  Most of the code
doesn’t care too much about Flash.  I think if you abstract the TextLine
you can get quite far.

>
>Here’s my question:
>Jetbrains seems to have worked out integrated debugging of JS[1]. If I
>understand correctly, the Falcon compiler has symbols that map the code.
>Is there any way of mapping the ActionScript code to the compiled JS
>code, so it’s possible to maintain links between the code similar to how
>debugging works with ABC code and ActionScript? Or is what I’m suggesting
>completely non-sensical?

It might be possible, but is a lot of work.  If you want to work on it, I
will definitely be supportive. Getting line numbers in AS to match up in
the JS isn’t a priority for me right now because for me, when I open the
JS debugger, it is generally quite obvious what line of AS the JS came
from.

>
>I think having a really smooth debug experience on the JS side will help
>immeasurably in terms of FlexJS adoption.

Well, I can’t argue with that, but I hope it isn’t a critical feature
because I think we currently don’t have enough person-power to create what
you want soon.  Hopefully we can get some momentum from early adopters
without having to make FlexJS 1.0 feel as smooth as Flex 4.  IMO, it isn’t
really possible for two full-time developers and some part-time volunteers
to quickly re-create what dozens of developers did over 8 years.  I don’t
know if you remember Flex 1.0, but it got traction without being Flex 4.x.

-Alex