5 ms·

Speaking of backend DOM awareness, have you seen this? https://github.com/tblobaum/nodeQuery https://github.com/tblobaum/nodeQuery

jokull 15y ago
Seems like quite a feat has been accomplished. But it also feels like it was simply done for the sake of it, instead of creating a framework that addresses real problems. Will have a close look however, correct me if my 2 second impression is completely off.
- funthree 15y ago
  You are right, at first I did do it just to see if it was possible. I've been meaning to write in more detail about some of the implications, clean up some of the code, etc. I've also experimented with the API to feel out how it could work with other client side stuff in an isomorphic way, url routes, and other frameworks (https://gist.github.com/1336381 https://gist.github.com/1336381), but havent released any of that.
- maratd 15y ago
  > instead of creating a framework that addresses real problems. If you need to protect code that is currently client-side while retaining responsiveness, this will solve that problem. In my opinion, the price for that is too high. You are significantly increasing the traffic between the server and the client. On top of that, you are forced to do all your work on the server, which to me feels like a step back to the way we used to do things a decade ago. Beefy servers handling a few clients, rather than light servers handling thousands of clients.
  - funthree 15y ago
    Without going into too much detail about it your assumption is only partly true. It depends on how many API calls you make to jquery from the server, but also sending your realtime data in HTML actually doesnt suck (your server already renders html like this for http requests) and you also dont have to serve up any client-side assets -- the total number of KB transferred is likely to be less with nodequery even after x amount of time on the site because you keep everything but arbitrary strings of HTML on the server. You could make a 10,000 loc app, and you wouldnt even have to serve up a line of it to run it (in realtime) with a browser. EDIT: After looking through Flatiron/Plates, I'm really interested in seeing how I might be able to get them to work together.
    - maratd 15y ago
      > your server already renders html like this for http requests This hasn't been the case for me for literally years. Everything is pretty much dynamically loaded into the DOM by javascript. The server just pushes raw data to the client via XHR. If you're still rendering HTML on the server, then yeah, this would be a drastic improvement. Absolutely.

jokull 15y ago

Seems like quite a feat has been accomplished. But it also feels like it was simply done for the sake of it, instead of creating a framework that addresses real problems. Will have a close look however, correct me if my 2 second impression is completely off.

funthree 15y ago
You are right, at first I did do it just to see if it was possible. I've been meaning to write in more detail about some of the implications, clean up some of the code, etc. I've also experimented with the API to feel out how it could work with other client side stuff in an isomorphic way, url routes, and other frameworks (https://gist.github.com/1336381 https://gist.github.com/1336381), but havent released any of that.
maratd 15y ago
> instead of creating a framework that addresses real problems. If you need to protect code that is currently client-side while retaining responsiveness, this will solve that problem. In my opinion, the price for that is too high. You are significantly increasing the traffic between the server and the client. On top of that, you are forced to do all your work on the server, which to me feels like a step back to the way we used to do things a decade ago. Beefy servers handling a few clients, rather than light servers handling thousands of clients.
- funthree 15y ago
  Without going into too much detail about it your assumption is only partly true. It depends on how many API calls you make to jquery from the server, but also sending your realtime data in HTML actually doesnt suck (your server already renders html like this for http requests) and you also dont have to serve up any client-side assets -- the total number of KB transferred is likely to be less with nodequery even after x amount of time on the site because you keep everything but arbitrary strings of HTML on the server. You could make a 10,000 loc app, and you wouldnt even have to serve up a line of it to run it (in realtime) with a browser. EDIT: After looking through Flatiron/Plates, I'm really interested in seeing how I might be able to get them to work together.
  - maratd 15y ago
    > your server already renders html like this for http requests This hasn't been the case for me for literally years. Everything is pretty much dynamically loaded into the DOM by javascript. The server just pushes raw data to the client via XHR. If you're still rendering HTML on the server, then yeah, this would be a drastic improvement. Absolutely.