3 ms·

The search engines complicate the design choice of client-side vs. server-side MVC. While there are ways to hint search engines to retrieve searchable views of

by mckoss 14y ago

The search engines complicate the design choice of client-side vs. server-side MVC. While there are ways to hint search engines to retrieve searchable views of our application data, it adds an additional layer of complexity to your application. From my experiments, Google (or Bing) has yet to make a truly agnostic search engine when it comes to the design choice of client-side vs. server-side rendering. To do so, they would need to routinely emulate the full browser stack and javascript rendering on every page crawl. They do not yet do this. This is especially true when client-side anchor tags are used in URL's to represent client side navigation.

Joeri 14y ago
You have to discern between web sites and web applications. For example, it's not useful to make a todo app SEO friendly. Basically, anything beyond a login form is a candidate for client-side rendering.
bdicasa 14y ago
I wouldn't use a client side MVC framework for pages that need to be crawled. I find them great for webapps that require a user to login.
- mckoss 14y ago
  It's a shame to have to arbitrarily make this tradeoff. There is nothing inherent in saying that apps that desire rich client-side navigation are 100% the apps the DON'T require search engine support. Google does have a spec for hash-bang URL's to enable both to be present in a single app. Unfortunately, it's clunky and not universally implemented.
wmf 14y ago
The newest frameworks (Derby/Meteor) can execute JS on the server side to generate crawlable pages while serving client-side JS for regular browsers. Also, anchors are obsolete; people should be using real URLs.
- mckoss 14y ago
  I think there is a place for anchor URLS - they make sense as a means of expressing purely client-side navigation. Note that, by design, they will never be transmitted to the server - so there is no need to mirror the client-side navigation implemented in JavaScript within the server implementation. I think this factoring of the server-space navigation and client-side navigation is sometimes useful and keeps the two separated.

by mckoss 14y ago

Joeri 14y ago

You have to discern between web sites and web applications. For example, it's not useful to make a todo app SEO friendly. Basically, anything beyond a login form is a candidate for client-side rendering.

bdicasa 14y ago

I wouldn't use a client side MVC framework for pages that need to be crawled. I find them great for webapps that require a user to login.

mckoss 14y ago
It's a shame to have to arbitrarily make this tradeoff. There is nothing inherent in saying that apps that desire rich client-side navigation are 100% the apps the DON'T require search engine support. Google does have a spec for hash-bang URL's to enable both to be present in a single app. Unfortunately, it's clunky and not universally implemented.

wmf 14y ago

The newest frameworks (Derby/Meteor) can execute JS on the server side to generate crawlable pages while serving client-side JS for regular browsers. Also, anchors are obsolete; people should be using real URLs.

mckoss 14y ago
I think there is a place for anchor URLS - they make sense as a means of expressing purely client-side navigation. Note that, by design, they will never be transmitted to the server - so there is no need to mirror the client-side navigation implemented in JavaScript within the server implementation. I think this factoring of the server-space navigation and client-side navigation is sometimes useful and keeps the two separated.