flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides
Date Tue, 06 Dec 2016 18:07:42 GMT

On 12/6/16, 8:36 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:

>I did a quick test the other day where I tried creating a
>flexjs-config.xml, which used js.swc instead of playerglobal.swc and the
>SWCs in frameworks/js/FlexJS/libs instead of frameworks/libs. When I used
>this new config, it didn't show any Flash APIs in the completion list in
>VSCode, which was better. I don't recall if I had time to test if the
>project would build correctly or not, though. A workflow like this could
>help for people only interested in JS output. It would expose APIs that
>aren't available in SWFs, though, so it's not removing the problem, but
>simply reversing it.


I understand the temptation to claim that if FlexJS isn't as easy to work
with as Flex that we won't succeed, and we want to make the experience as
smooth as possible, but consider that this is still not even a 1.0
product, and that customers are faced with dealing with a few bumps in our
road, or doing a full port to another JS framework.

We are introducing something new: multi-target, multi-platform output.
Such a workflow simply may not be as smooth as a single-target workflow.
Well, we could wrap everything and so there is only one common API, but in
my experience, folks will always point at the additional overhead and
wonder how much better it would work without that overhead.  Many of you
are familiar with this to some degree.  You see your mobile app work on
your laptop, then you try to publish it out to Android or IOS and it
doesn't work or is too big.

As I mentioned upthread, the next step is to be able to have a single
compiler run output more than one target.  Getting this to work is also
key because it enables us to create a set of SWCs with the common API and
no platform-specific APIs and, while the results of that won't run at all,
it will report compile errors on non-common APIs and then output valid
targets that do run.

Or, folks will just learn to live with the fact that the code hinting in
Flash Builder might show something that doesn't exist on a target
platform, but the compile step will report errors when compiling for the
target without those APIs.  You pick one starting target platform, get
code-hinting for it, then find out at compile time that some of it won't
work on one of the targets.  Right now you have to run a different compile
or another whole project.  After the next set of changes, it should all
show up in the problems list.

But the new IDEs have an opportunity to win customers by enhancing
code-hinting to show what APIs exist on certain platforms.  Also, some
folks may need to "cheat" and write platform-specific code inside
conditional compile blocks in order to be successful.  They should have
code-hinting for platform-specific APIs if they want it.  So it probably
isn't true that all app devs won't want to see platform APIs.

The current IDEs seem to only give us control over code-hinting via code
in SWCs.  New IDEs could be smarter and work with metadata, ASDoc comment
tags, etc.

In sum, perfection is a great goal, but we have to find a minimally-viable
1.0 that isn't perfect, so think about what trade-offs are acceptable.
But I think after the next compiler change, we will have the option of
making different kinds of SWCs to hide APIs.  Combining that with this
change that allows us to change the type of APIs, that should get us
pretty far.  Of course, there might be pain in managing the different
types of SWC combinations, so that is a trade-off to consider.

One more note:  I believe we have control over the ASDoc that is part of
FB code-hinting, so we might be able to document what platform an API
works if we decide that we can't or don't want to hide certain APIs.

My 2 cents,

View raw message