Re:Server-side view or client-side MVC?
by mckoss on Tuesday February 26, 2013 @02:49PM
(#5287997)
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.
[ Parent
| on HN ]
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.
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.
Re:Server-side view or client-side MVC?
by mckoss on Wednesday February 27, 2013 @12:01AM
(#5290743)
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.
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.
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.