4 ms·
I love the benefits on single-page web apps, but the SEO issues associated with them and the current methods to get around it (using selenium to do a render of
by nubs 13y ago
I love the benefits on single-page web apps, but the SEO issues associated with them and the current methods to get around it (using selenium to do a render of the html on the server?!?) keeps me from using them on things.
It seems to me that by using node.js on the server, we should be able to share the application code, including rendering to html/dom. I have a vision in my mind of an http request coming in to the server for a given url, ember.js picking it up and rendering views/templates into html that is sent over the server. On a javascript client, that html/dom would need to be linked into ember.js on the client-side (this could be done be either regenerating the html, or by "deserializing it" in some way). Further actions on the page could be handled by the client-side javascript in normal ember.js fashion.
This approach would have several benefits. Initial response would have working html that could be rendered without having to wait on loading the application's javascript (along with dependencies) and would be workable for non-javascript clients, such as web crawlers and older clients. Links in this html could default to be links back to the server for other full page requests, and only switch to using ember.js on the client if and when the javascript loads. Applications would have even more reason to make their interactions with the page routable via url and therefore easily linkable and sharable.
Normally when developing websites, you shy away from too much in the javascript because of these usability/SEO concerns and the normal approaches involve writing the same logic on the client and on the server (normally not even in the same language). With javascript on the server, why don't we run the same code on both ends, remove this handicap, and use the benefits to offload processing to the clients when possible but still provide a server-based fallback for the many cases when it is necessary?
- wmf 13y agoAFAIK this is solved in Derby.js; it serves fully-rendered HTML to the client and JS kicks in after that.
- nubs 13y agoI haven't come across this before. I will have to play with it and see how it works. It definitely appears to be in alpha status, but then again, so are most javascript frameworks, it seems :)
- sixbrx 13y agoI'm not very familiar with Node, but I had assumed that a more flexible or movable client/server dividing line was the point of Node, and assumed it's what people were already doing... but maybe not. Can any Node afficianados speak to this question?
- nubs 13y agoI am not an afficianado by any means, but it does help in some ways. Many libraries exist that can run on both sides of the connection. Unfortunately, I haven't found much that allow you to modify the DOM/html using the same code on client and server, and even less that allows you to go from an application state on the server into an identical state on the client. Meteor.js, Opa, and Derby.js seem to be the main options in this field, but I'd like to see a simple javascript library that facilitates this so that many other frameworks can take advantage of it.