On 12/6/16, 8:36 AM, "Josh Tynjala" <joshtynj...@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. True. 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, -Alex
