Their technique for generating the HTML representation of deep-link into a Meteor app is to run the entire client app in a headless browser and serialize the generated DOM?!<p>This is an area of vital importance to public, JS-based RIAs, and needs some real innovation. Why even bother delivering this half-baked solution? The processing cost makes it untenable for all but the tiniest of URL-spaces.
Who really needs this for their web app? Nearly 99% of heavy web apps require a login, so Google is out of the picture anyway.<p>Anyone who is building a content site with DOM-manipulating Javascript doing all the work have completely lost their way. Seriously, just render your templates on the server and deliver them to the client. Why does the world want app-ify everything?
Why is this interesting? Because 1) search engine crawlability matters and 2) the more AJAXy web apps get, the harder it is to make them crawlable.<p>The more we move away from traditional web "pages" to rich web apps that do everything through DOM manipulations on a single page, the harder it is for the search engine robots to crawl what we build.
So after year of developing this product, they finally realized that each page should have an unique URL.<p>It's called lack of vision.<p>ps. ajax content does not rank in Google SERPs at all, it's a typical band aid solution, so websites made with meteor will have some serious issues with monetization and stuff
If they can tell which pages are public vs private (which I think they can) they could just tell the client that they need a copy of the page when they are done rendering it, have it post the serialized DOM back to the server and then cache and serve that until the next redeploy.