Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meteor 0.3.9 adds search engine optimization

meteor.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Meteor 0.3.9 adds search engine optimization

#21

Post by jarcoal »

mattacular wrote: post #20
jarcoal wrote: post #18

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. 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?

Because server architecture and rendering is really expensive to scale whereas a client-side-dependent app could be supported for much less. It is a trade-off. The presentation layer has been moving to the client-side for the past few years, where have you been?

Rendering templates on the server is not expensive at all, that is completely untrue.

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.

Re: Meteor 0.3.9 adds search engine optimization

#22

Post by [deleted] »

tomku wrote: post #11
mcgwiz wrote: post #9

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?! 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.

Seems like this would be a very easy way to DoS a Meteor app, if it's really spawning a PhantomJS process for each request.

[deleted]

Re: Meteor 0.3.9 adds search engine optimization

#23

Post by mattacular »

jarcoal wrote: post #21
mattacular wrote: post #20

Earlier quoted context omitted.

Because server architecture and rendering is really expensive to scale whereas a client-side-dependent app could be supported for much less. It is a trade-off. The presentation layer has been moving to the client-side for the past few years, where have you been?

Rendering templates on the server is not expensive at all, that is completely untrue. 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.

>Rendering templates on the server is not expensive at all, that is completely untrue.

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.

Re: Meteor 0.3.9 adds search engine optimization

#24

Post by geoffschmidt »

mcgwiz wrote: post #9

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?! 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.

> Why even bother delivering this half-baked solution?

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.

Re: Meteor 0.3.9 adds search engine optimization

#25

Post by mnutt »

mcgwiz wrote: post #9

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?! 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.

It actually is possible to render those pages in phantom at scale, but it's not very elegant. It seems like something like env.js would be sufficient to render the page, though. I think other people have done that, although I haven't seen a framework that makes it natural. Meteor and others would be in a great position to build such a framework.

Re: Meteor 0.3.9 adds search engine optimization

#26

Post by mnutt »

jcoglan wrote: post #15
mcgwiz wrote: post #9

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?! 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.

Never mind the cost. They are proposing that you run your app, with its 3rd-party jquery/facebook/twitter/google code loaded dynamically over non-SSL connections on a platform with filesystem-write-access to your server.

It's no less safe than loading hostile 3rd-party web pages on your browser at home.

Re: Meteor 0.3.9 adds search engine optimization

#27

Post by arohner »

jarcoal wrote: post #18

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. 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?

Fat client apps are fantastic for making some kinds of UI interactions trivial.

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.

Re: Meteor 0.3.9 adds search engine optimization

#29

Post by jarcoal »

arohner wrote: post #27
jarcoal wrote: post #18

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. 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?

Fat client apps are fantastic for making some kinds of UI interactions trivial. 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 w…

I completely agree with you that in some (many) cases it's useful.

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.

Re: Meteor 0.3.9 adds search engine optimization

#30

Post by gaius »

geoffschmidt wrote: post #24
mcgwiz wrote: post #9

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?! 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.

> Why even bother delivering this half-baked solution? 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 work…

Above, you know, actual meteors :)

Elegant proof if any were needed that so-called SEO is merely tricks for polluting search indexes. As bad as spammers.

Post reply on HN