3 ms·
That hits close to home. I recently built a single page app with Backbone and SEO traffic is non-existent. So now I'm dynamically generating pages on the backe
by freyr 12y ago
That hits close to home. I recently built a single page app with Backbone and SEO traffic is non-existent.
So now I'm dynamically generating pages on the backend, and serving them along with the javascript app so there's some some indexable static content. There are a few ways to directly reuse your client-side code on the server, but they all seem pretty hacky and convoluted.
I bought into the notion that the backend should just be a client-agnostic API, but that's an extreme position that should be considered when your site/app doesn't have any indexable content to begin with. If I could only go back in time...
- Gigablah 12y ago> I bought into the notion that the backend should just be a client-agnostic API There can be more than one backend -- your API is a microservice and you can have another backend that proxies this service and renders templates server-side. This also means you can define SEO-friendly URIs as opposed to your presumably RESTful API endpoints.
- freyr 12y agoYeah, this is the approach I've transitioned to. It's certainly better overall, but there's still an issue of maintaining some duplicated code on the server side and the client side. There are some projects that specifically address this (Rendr, Lazo, Ezel), but I haven't made the switch to one of those yet.
- arianvanp 12y agoReactJS is awesome here. You write clientside code but you just run that clientside code on the server on request to prerender an initial DOM. And then your client hooks into that DOM. It has worked like a charm for me.
- freyr 12y agoI tried an early version, and I was impressed, but my app relied on an CSS transition that was causing an issue with React. It looks like they've improved on that with ReactTransitionGroup, so I'll check it out again. Thanks!