Responding to you and Justin in this post... On 4/10/17, 1:55 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>Actually I wasn't sure whether the compiler eliminated the dead js code. >But we know that it can. > >I get the point about the 'swiss-army-knife' but I don't think that >applies >here, because I think this is more a 'standard tool'. I can only directly >recall one Flex project in the last 6 years that did not require the swf >crossdomain security model. Perhaps I have forgotten some, but I suspect >that the world is becoming more interconnected, not less. I know there >will >definitely be some who don't need this, and I guess there are certain >types >of application that always will be single-domain. But unless I >misunderstand, it sounds like this need might be more for the majority >than >the minority. > >The point about the GCC stuff though I think is a little contrasting to >the >PAYG philosphy elsewhere. Because AS allows you to write: myHttpService["withCredentials"] = true; Our tools currently add @export to all public APIs. And thus, the code Justin added is not eliminated. I just compiled FlexJSStore and the string "withCredentials" is in the optimized JS twice. Certainly, the tools could become smarter, but they aren't now, and we have a pattern and protocol for adding features, which is to use beads. And even then, we want the framework to scale to supporting really large enterprise apps where not all files are compiled at the same time and APIs are referenced and shared across these compilation sets. And I don't really think it is practical to create a tool chain that will ever figure out what is dead code across compilation sets. I believe the bead pattern will be great for optimizing in these development environments. > >"AFAIK, public APIs have @export and are kept around. Which will be a >good thing >in multi-module apps some day." > >It sounds like we are keeping a lot of code that could be optimized or >automatically excluded because it will be a good thing "some day" (the day >when we support module loading). That sounds like the opposite of PAYG to >me, because many projects may not need 'module loading' (and we don't have >this yet anyway). I'm just trying to throw a potentially different way of >looking at this in here, because, in theory at least, the closure compiler >should be able to make a whole bunch of stuff go away in the release build >if it is not used (dead code elimination, DCE). In practice, I have not >tried it with any sizeable codebase, but I know other typedLanguage-toJS >compilers get the job done here, and I know that things like including >reflection data or not are also choices included in the options for output >in at least one other toJS compiler. > >If this can work properly then we could actually have our cake and eat it >too. And yes the future might mean other things for modules, but perhaps >there are ways to get that working even with the renaming (DCE maybe not >so >much, I agree). > IMO, we would provide different compiler options for those who can compile everything at once. I think what would be required at the simplest level is some promise from the developer that they did not use any bracket access (myService["withCredentials"]) in their code, and I suppose that would mean we couldn't use bracket access in the framework code either (which I hope we don't do much of, if any. And maybe we could get smarter and find bracket access and inform GCC which APIs to void renaming, but then you couldn't do "string math" in bracket access or use string variables without code-flow analysis in the compiler. myService["with" + "Credentials"] var foo:String = "withCredentials"; myService[foo]; But again, those doing really big apps where they don't compile everything at once will need some other way to optimize and being able to choose what beads they want to composite is the best plan I can think of so far. >On Mon, Apr 10, 2017 at 8:32 PM, Justin Mclean <jus...@classsoftware.com> >wrote: > >> Hi, >> >> > And the net result should be that code you didn't in your app, isn't >>in >> your app. >> >> As Greg pointed out the compiler can removed unused JS code i.e. methods >> that are not called. See for instance [1] for details. So in this case >>if >> you don’t use it will not end up in the AS code (as it’s JS only) and >>will >> not end up in production JS code. This is not currently true, and probably can't be true for some development environments. See my response to Greg above. >> >> > So when you break stuff out into a bead, we want the net code size and >> performance for >> > someone not using the bead to be the same or better. >> >> In this case it is the same, if it was moved to a bead it would be worse >> for people who needed it. Only by tiny amounts but that’s the point >>you’re >> trying to make i.e. slow dead by a 1000 tiny additions, and as you say >>lots >> of people will need CORS support. Yes. That is what Pay-as-you-go (PAYG) means. >> >> > It is certainly worth revisiting the code we've written to see if >>other >> > stuff can be pulled out into beads, so thanks for reviewing >>HTTPService. >> > It is one of the early classes and probably needs a review. Given the >> > above, my responses are inline below. >> >> We should provide clear documentation on this, currently there is none? >> Having our own code not following the same philosophy is a barrier for >> people contributing. In most other Apache projects if someone submits a >> patch that may not be “perfect” other committers will help to improve >>it. >> Pull request welcome and all that. I saw you do your "Intro to Flex" at ApacheCon Portland. It was well done. You might be a good candidate to produce introductory learning content for FlexJS. So maybe if we can get you to understand the value of beads and PAYG you can help us produce this documentation. Again, this is a new effort. It isn't regular Flex where we had a whole team of developers and testers and doc writers. This is just a small team of volunteers. There are no paved roads with signs. You have to follow the wagon wheel ruts and figure stuff out. We need more volunteers to help pave the roads and post the signs. >> >> > Possibly. As long as the implementation for folks not using headers >> would >> > be smaller/faster. >> >> That is likely to be the case, but it will be slower for people who do >>use >> headers. How do we determine what is the most common use case? Isn’t >>that >> going to vary by use / customer so we going to end penalising someone no >> matter which way we go. I'm sure I've written this in past emails, but basically, PAYG is all about it being slower for those who use more code. But beads and composition also attempts to avoid the entire "which is more common" debate. At least in hardware stores in the US, when I need to buy a screwdriver, I am confronted with dozens of choices each with slightly different set of features. Thank goodness there isn't only one screwdriver with the replaceable tips. Because that one doesn't work in a few cramped places in my house. I have a small one for that. So, if you put your CORS code in a bead, folks who need it but are using the Basic HTTPService will add it to their HTTPService. And the HTTPService in Express (or maybe a new ExpressJS set that has code without SWF equivalents) will have your CORS bead baked in. And if folks complain that it the bead overhead is too high, then you can inline some of the beads and offer that as well. FlexJS just wants to offer choices to people. Old Flex was trying to make everyone use that one screwdriver. It didn't work well for enough folks. I don't want us to make that mistake again. Old Flex, we wasted time debating what the "right way" was. We can avoid that debate as well. Just provide different ways. The customers will decide. >> >> > Possibly, but I claim that nobody should go into production without >> > supporting timeouts, so I would leave that baked in. >> >> So why does this not apply to the method I added? Every single project >> I’ve worked on has made cross domain calls. It's very uncommon for web >> applications to have their database, rest services, API calls on the >>same >> domain and quite common to call 3rd party services. Very uncommon means you agree it isn't everybody. So we give folks choices. >> >> And I’m sure no one would go into production without supporting security >> of some form. I’m concerned her that we are making security an optional >> feature here and not having it supported by default. If you aren't going across domain, you don't need CORS, AFAIK. >> >> > Again, if you can find a way to refactor that out without making the >> > HTTPService bigger/slower, then great. >> >> Anytime you place something in a bead it is going to be bigger and >>slower >> for the people that need that functionality. It will be faster/smaller >>for >> the others who don't. So again how do we determine what is the most >>common >> use case? Do more people use AIR status code than don’t use them? I >>would >> guess not in this case and it should be a bead but it’s just a guess. >> >> > Like Timeout, I claim that nobody should go into production without >> > handling errors. So probably, the JS errors need to be handled right >>in >> > HTTPService or HTTPServiceBase. >> >> So you're saying that HTTPService is where JS security errors should be >> handled and not in a bead? That's where I'd put it. Others may have a different opinion. Thanks, -Alex
