Meteor 0.3.9 adds search engine optimization
meteor.com
meteor.com
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.
I think people's confusion lies in the fact that there are actually two separate areas where javascript is run in Phantom: one is the javascript that controls Phantom and has a filesystem API; the other is the javascript that gets run inside the browser sandbox as part of the web page, just like any other javascript run in any other browser. It is possible to set up a bridge between the two such that the latter can issue commands to the former, just as you can curl sites and pipe them into bash. The point is that with default settings you can use PhantomJS to load a website without any danger whatsoever.
If you disagree, please write a more worthwhile comment showing me which part of the API is dangerous.
The "real solution" is coming, and we will get it right. It's connected to URL routing, and sending down initial HTML on page load. We're all excited for the day when Meteor apps initialize the client session on the server. It will look at first glance like a traditional server-side app. :)
I have tried zombie but there were various issues with getting it to work. Phantomjs was just much more painless.
Because we used it for our funding announcement at the end of last month -- a full press cycle, where the Andreessen Horowitz and Matrix Partners press machine pushed our story out to all of the tech blogs, with all of the traffic that that implies -- and not only did it work fine, it got us to #1 on Google for "meteor." Above, you know, actual meteors :)
It works fine for us as a stopgap measure and we wanted to share it with others. We put it in a optional smart package that isn't included in new projects by default.
We're near the end of a major rewrite of Meteor's page update engine. You can see the latest progress on the 'spark' branch. One thing that happened during this rewrite was the conversion of Meteor's templating to be 100% string-based. Check it out: go to meteor.com/faq, open your browser console, and evaluate "Template.faq()".
This means that the server can render the templates for your app without having a DOM implementation of any kind (much less a headless client.) 'spiderable' doesn't do this yet, but it will by Meteor 1.0 (if 1.0 even has a separate package.)
For the record, the ratio of our investment in auth and accounts, to our investment in Spark, is about 2:1.
Elegant proof if any were needed that so-called SEO is merely tricks for polluting search indexes. As bad as spammers.
If you really want the Wikipedia page for meteors, nothing's stopping you from going straight there.
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?
The presentation layer has been moving to the client-side for the past few years, where have you been?
I've been keeping up like any developer, in fact I'm writing a Backbone app as we speak. But like all of the apps I write, Google doesn't need to crawl it.
Vaguest statement ever. It depends on the complexity of the template and the templating system, also then that file has to be served either directly or through a cache. complexity++ It is harder to scale a server-side presentation layer.
If you don't think that is the case please expand on your statement...
edit; please don't cite Twitter as a case, they are not the norm.
The simplest example is the checkout form, or any kind of wizard linking multiple pages together. In a fat client app, all state for all N pages of your checkout cart are in the same page, with 5 lines of code to switch between them. Doing that in standard MVC "fat server" model is annoying, and about 10x more code.
> Why does the world want app-ify everything?
Think about GUI applications pre-web. They weren't written as servers that generate PDFs, with an embedded scripting language. The current webapp technology stack is a complete accident, and if we had actually sat down to design the "optimal" stack, it would look nothing like what we have.
But your checkout example proves my point; you wouldn't want a bot crawling through there.
Bots should be crawling content-rich pages (blogs, articles, marketing pages), and IMO those should rarely be handled by fat clients.
It works very well for a human visitor. The page loads extremely quickly and the widgets rendered using javascript and ajax are below the fold anyway so it doesn't matter that they are visible 500 ms later than the initial page load. Unfortunately it is crap for Googlebot which never runs the ajax calls and never "sees" my pretty graphs which leads it to think I have a much more boring site than what it really is.
So that is my need to "app-ify" my site and my, as of yet unfulfilled, need for a framework that is able to provide Googlebot with an accurate view of my appified site.
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.
https://github.com/meteor/meteor/wiki/Getting-Started-with-A...
It's called lack of vision.
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