Hacker News Reader

Comment by macspoofing | Hacker News Reader

This approach is very attractive to developers because it makes things so neat and tidy and perfect, but there are two problems that you quickly run into:

1) Search engines can't index your page properly. If you rely on this to drive traffic, you'll have a problem

2) Your page takes a longer load (even more noticeable on mobile), so you will inevitably move some work back to server, whether to render some or all parts of the page, or seed your initial models with current values so that they don't have to immediately call back.

View on HN

1. Not really true nowadays. Google can trawl Javascript sites. Other search engines may be able to as well.

2. Initial page load will be slightly higher (and subsequent pages will be much faster) but I can't imagine it'll be too noticeable. People get away with a lot - even on mobile - loading numerous JS libraries, tonnes of CSS, etc. As long as you go easy in other regards, this shouldn't be a problem.

There's no reason that API driven design has to involve client-side rendering. You can always consume your API on the backend and render on the server.

>There's no reason that API driven design has to involve client-side rendering. You can always consume your API on the backend and render on the server.

I'll give you that I suppose, though I understand it as a lightweight server, and heavier client. On the other hand, splitting up your components into API and page-rendering servers (in addition to your database, caching, messaging servers and your reverse proxies and load-balancers) complicates your deployment and maintenance and you pay for that - so it isn't quite the panacea and now you really have to decide whether it makes sense to go down that route, that early.

It's not really any more or less complicated than doing it on the client-side, especially if you use something like Her (https://github.com/remiprev/her). It's definitely more complicated than just using a database though - whichever way you do it. It's the other advantages that it brings that makes it potentially worth doing.

MVC manages it and is possibly the most common pattern in web dev.

1. Not really true nowadays. Google can trawl Javascript sites. Other search engines may be able to as well.

People have been saying this for a long time, but as of 6 months ago my experience didn't support it (Javascript sites get indexed, but not ranked as well as traditional sites). I haven't tried recently--does anyone have up-to-date information about the effect of client-rendered sites on SEO?

There's a guide here: https://developers.google.com/webmasters/ajax-crawling

If you use a client-side MVC framework, e.g. Ember, it should work out of the box.

I don't think it will, ideally you need to recognise _escaped_fragment_ requests at the server level and respond appropriately.

It would depend how you're serving the static pages. How did you do a fair comparison of a non-ajax/ajax site?

I should note that our logged in application utilizes the API whereas our frontend site is primarily static content for purposes of page speed and to lighten server load.

>whereas our frontend site is primarily static content for purposes of page speed and to lighten server load.

Yeah, that's absolutely the right way to do it. So it's less "API-first", and more "API-first-unless-we-want-it-fast". =)

A more accurate depiction for us is a separation of our public facing website, which is more for marketing, from our backend, logged in customer website, which is what I'd consider our actual application. A few endpoints carry over such as login, logout, forgot password, registration, and contact/support.

Reply on news.ycombinator.com