Re: [JSPreflight] - First Draft of JavaScript Preflight Injection online

On Mon, Aug 26, 2013 at 1:15 AM, Reitbauer, Alois <
Alois.Reitbauer@compuware.com> wrote:

>  On Wed, Aug 7, 2013 at 12:36 AM, Reitbauer, Alois <
> Alois.Reitbauer@compuware.com> wrote:
>
>> [Alois] If it were that simple :-). In the general case you are right and
>> that's what we do today. However, there are tons of cases where this breaks
>> the page. I can provide some real world examples where this gets really
>> tricky to impossible.
>>
>
>  Please do, curious...
>
>  [Alois]
>
>  There are a lot of examples and we needed to build an extensive rule set
> to cover this at first sight simple problem. First of all you will have to
> wait after all meta tags. Executing JavaScript before meta tags might break
> the page. Another problem are base tags. You have to wait until after the
> base tag as it would not work any more otherwise. This means you have to
> block flushing the content until you reached a point where you are sure
> that these cannot occur anymore.
>

This doesn't explain why you need to come after meta tags - do you intend
to rewrite all following resources? If so, you may want to take a look
at Navigation
Controller <https://github.com/slightlyoff/navigationcontroller> instead
(and note that even there, we explicitly do not block on first load of
controller.. exactly for the reasons I've raised earlier).


>   This approach is also not applicable to the case where the page cannot
>> be loaded.
>>
>
>  Correct. I do agree that we need an error reporting mechanism, but (in
> my opinion), this proposal couples error reporting with a much heavier and
> unnecessary injection mechanism - we're adding another cookie mechanism, a
> full blocking JS resource, and a bunch of other complications. Which is why
> I'm suggesting a simpler, CSP-like implementation: on error, beacon some
> predefined error report to provided URL.
>
>  [Alois] The CSP case is very different from performance monitoring. How
> would this be able to cover single-page web apps?
>

Once again, I think this proposal mixes two completely distinct use cases:

*#1 Error Logging*
We want the client to beacon the NavTiming data if the navigation fails
(e.g. DNS lookup succeeded, TCP handshake timed out). In this instance,
simply beaconing the NavTiming object to some endpoint would be enough -
caveat: if TCP failed, how do I even know where to beacon it? This is where
we either get into some persistent settings (e.g. first you would have to
have a successful navigation to get this instruction, and then persist it
(ugh)), or we're into store-and-send-later type of semantics. In any case,
this gets complicated quickly.. and I'm skeptical that new 'cookie-like'
mechanisms are going to get us far -- this opens privacy holes, etc. There
is just not much appetite for that nowadays. But.. this would be great to
solve.

Also, if possible, I would also think about "incomplete" loads and not just
errors - e.g. I click on a link, the new page is rendering, the user
navigates back before onload is fired. In many cases, if you're following
best practices and doing async load / deferring your analytics, you'll miss
this pageview (bounce) and RUM sample. To "fight this" some large sites
still put their analytics in the head (ugh) - this is a big problem. I
don't have hard numbers, but my intuition tells me that this may actually
be a larger problem than failed connections.


*#2 Instrumenting client-code (single page apps, etc). *
This is completely orthogonal to error logging, and I think this should be
split into a completely different discussion.

First, there is no reason why your script needs to block all others -- in
this day and age of fighting against blocking resources, this is also a
deal breaker. For example, consider GA, which has to deal with this very
problem: the client code may be loaded first and it pay issue GA commands
before GA is loaded. The solution is simple.. create a "_gaq" command queue
object and push commands in there. Then, once GA loads, it inspects the
object and does what it needs to do -- convention works.

Similarly, it seems like if the intent is to instrument JS frameworks like
Angular, Ember, JQuery, then this is a conversation that should be had with
all of them to see if there is some convention or shared API that can be
used to emit common events: startup events, user initiated events, etc.
This would solve the problem in a much better way: any vendor could then
pop the events from the queue and apply its logic. No blocking resources,
no need to hijack and rewrite client-libraries on the fly, and an API that
everyone can use.

</hand waving>

Q: Have you approached any of the large frameworks to discuss anything like
this?

ig