Note, that both Gmail and Pandora now have a "solution" to the problem of the original load getting out-of-date with a little pop-alert box that says "This page needs to be freshed. _Click here to reload_" (or something like that, can't remember exactly)
Stuff with same–origin policies may not work as predicted.
Web Workers using importScripts require the script be loaded from the same location as the host page.
Last time I deployed a Java Applet, the behavior varied by browser. Some browsers considered the applet "same-origin" if it was loaded off the same domain as the script invoking the embed, while others still required it be loaded from the same origin as the host page. I don't know if this was a bug or expected behavior...
Same story for iframed content. If you need script access between the parent and child frames, they need to share the same protocol and port, at the very least. You can script around the same-domain issue by using CNAMEs and setting the document.domain to a shared superdomain. (So, parent is on www.example.com, iframe docs served off CloudFront via CNAME iframe.example.com, both parent and child frames set document.domain to "example.com" - bam, inter-iframe comm.) Sadly, the moment you want to use SSL, CNAMEs go out the window.
For a crazy example of all of the above things somehow working in tandem, look at the source for AWS's S3 Management Console (and/or Storage Gateway Console) (disclosure: I helped build them). Static assets (including the huge GWT-compiled JS app) served off CF, applets (used for folder upload) and web workers (for MD5 checksums) loaded off normal servers, inter-frame comm for regionalized requests.
I think with the continued development of technologies like CORS and WebSockets, we'll see more and more "smart" client applications - static apps that pull in data via web services and assemble dynamic bits on the client, rather than relying on server-side magic and templating - at which point it'll matter less and less where resources are loaded from, as they themselves will be static. Graphs by region for time-to-first-byte improved pretty significantly after moving to CF, especially for more remote locations where we didn't have AWS data centers, but did have CF PoPs.
However, these types of web applications can be slightly harder to build, as your clients are suddenly hanging on to a bunch of view state and interacting with services directly. We had people leaving the S3 Console open for weeks at a time. That introduces a whole new slew of things you have to think about (rich client side application logging, careful memory management, what to do when an API changes beneath the client, how do you kick a new version of the app to users, etc). New tools and frameworks are starting to come out which alleviate this pain, but they're all still very young.
Once they mature, however, we may find that not only is nginx obsolete, but the whole presentation layer of application servers as well. :)
Comment
Note, that both Gmail and Pandora now have a "solution" to the problem of the original load getting out-of-date with a little pop-alert box that says "This page needs to be freshed. _Click here to reload_" (or something like that, can't remember exactly)
Parent comment
Stuff with same–origin policies may not work as predicted. Web Workers using importScripts require the script be loaded from the same location as the host page. Last time I deployed a Java Applet, the behavior varied by browser. Some browsers considered the applet "same-origin" if it was loaded off the same domain as the script invoking the embed, while others still required it be loaded from the same origin as the host page. I don't know if this was a bug or expected behavior... Same story for iframed content. If you need script access between the parent and child frames, they need to share the same protocol and port, at the very least. You can script around the same-domain issue by using CNAMEs and setting the document.domain to a shared superdomain. (So, parent is on www.example.com, iframe docs served off CloudFront via CNAME iframe.example.com, both parent and child frames set document.domain to "example.com" - bam, inter-iframe comm.) Sadly, the moment you want to use SSL, CNAMEs go out the window. For a crazy example of all of the above things somehow working in tandem, look at the source for AWS's S3 Management Console (and/or Storage Gateway Console) (disclosure: I helped build them). Static assets (including the huge GWT-compiled JS app) served off CF, applets (used for folder upload) and web workers (for MD5 checksums) loaded off normal servers, inter-frame comm for regionalized requests. I think with the continued development of technologies like CORS and WebSockets, we'll see more and more "smart" client applications - static apps that pull in data via web services and assemble dynamic bits on the client, rather than relying on server-side magic and templating - at which point it'll matter less and less where resources are loaded from, as they themselves will be static. Graphs by region for time-to-first-byte improved pretty significantly after moving to CF, especially for more remote locations where we didn't have AWS data centers, but did have CF PoPs. However, these types of web applications can be slightly harder to build, as your clients are suddenly hanging on to a bunch of view state and interacting with services directly. We had people leaving the S3 Console open for weeks at a time. That introduces a whole new slew of things you have to think about (rich client side application logging, careful memory management, what to do when an API changes beneath the client, how do you kick a new version of the app to users, etc). New tools and frameworks are starting to come out which alleviate this pain, but they're all still very young. Once they mature, however, we may find that not only is nginx obsolete, but the whole presentation layer of application servers as well. :)