You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Ahh the JS community and it's affinity to bike shed on anything, and terms in particular.)
On the call this afternoon we discussed isomorphic nap; that is, the ability to render things server side and then "pick up" on the client side. As I mentioned, I wrote up a gist on the topic of application views sent across network boundaries which is really a different topic but incidentally discusses the same kind of problems. For that gist, the main topic is how can you define application view without necessarily coming up with a whole new media type; but incidentally because of the virtues of hypermedia you can actually implement a kind of isomorphism by also linking to the function that produced the rendered result in the first place. Hey presto, you end up with some thing (in this case, a component) which can be pre-rendered server side so as to keep client side rendering quick (at the expense of some latency and potentially bandwidth) but also provide the necessary details to allow further operation to carry on client side.
I'm opening up this issue as a discussion piece, but also to offer some ideas of which the aforementioned gist is some food for thought.
Worth noting is the distinction between having something that can be executed both client and server side (javascript using node APIs might have troubles in a browser, for instance) versus something that can "continue on" client side but isn't quite the same code as running on the server. I think trying to aim for all code running everywhere is a bit dogmatic; but I finding ways that nap could help embed additional functionality (and indeed, data) that may or may not run universally is a worthwhile goal I think.
In the gist, I discuss using link headers, which is interesting and well supported and might work really well, but isn't great for performance necessarily. For that reason, we'd need to look into actually embedding things into the response. HTML has good support for this with script tags and what not, but not all representations are HTML, and I don't think it's a good idea to go down a route of wrapping all things in the one media type. Rather, I'd say it might be worth looking into multipart responses, whereby you actually respond not just with the one response, but multiple. In particular, I think [multipart/mixed](for things like embedding client side request handlers along with a resource representation) and [multipart/alternative](for multiple representations of the same thing) are interesting things to explore. Crucially, these are not novel technologies, and should hopefully be well supported in browsers, caches, proxies, etc.
Anyway, food for thought.
The text was updated successfully, but these errors were encountered:
(Ahh the JS community and it's affinity to bike shed on anything, and terms in particular.)
On the call this afternoon we discussed isomorphic nap; that is, the ability to render things server side and then "pick up" on the client side. As I mentioned, I wrote up a gist on the topic of application views sent across network boundaries which is really a different topic but incidentally discusses the same kind of problems. For that gist, the main topic is how can you define application view without necessarily coming up with a whole new media type; but incidentally because of the virtues of hypermedia you can actually implement a kind of isomorphism by also linking to the function that produced the rendered result in the first place. Hey presto, you end up with some thing (in this case, a component) which can be pre-rendered server side so as to keep client side rendering quick (at the expense of some latency and potentially bandwidth) but also provide the necessary details to allow further operation to carry on client side.
I'm opening up this issue as a discussion piece, but also to offer some ideas of which the aforementioned gist is some food for thought.
Worth noting is the distinction between having something that can be executed both client and server side (javascript using node APIs might have troubles in a browser, for instance) versus something that can "continue on" client side but isn't quite the same code as running on the server. I think trying to aim for all code running everywhere is a bit dogmatic; but I finding ways that nap could help embed additional functionality (and indeed, data) that may or may not run universally is a worthwhile goal I think.
In the gist, I discuss using link headers, which is interesting and well supported and might work really well, but isn't great for performance necessarily. For that reason, we'd need to look into actually embedding things into the response. HTML has good support for this with script tags and what not, but not all representations are HTML, and I don't think it's a good idea to go down a route of wrapping all things in the one media type. Rather, I'd say it might be worth looking into multipart responses, whereby you actually respond not just with the one response, but multiple. In particular, I think [multipart/mixed](for things like embedding client side request handlers along with a resource representation) and [multipart/alternative](for multiple representations of the same thing) are interesting things to explore. Crucially, these are not novel technologies, and should hopefully be well supported in browsers, caches, proxies, etc.
Anyway, food for thought.
The text was updated successfully, but these errors were encountered: