NodeQuery is a realtime server-side DOM API(github.com)
github.com
NodeQuery is a realtime server-side DOM API
https://github.com/tblobaum/nodeQuery
8 comments
I could be wrong but I think ICEfaces [1] for Java does something like this. I remember seeing a presentation on it at a Rails vs Django vs Java "debate" a few years ago.
It may not be quite the same thing, and I can't really parse the website very well for how it really works. I do remember it holds a copy of the DOM server side then manipulates it over HTTP.
So if you want it in Java, there's that.
[1]http://www.icefaces.org/main/home/
It may not be quite the same thing, and I can't really parse the website very well for how it really works. I do remember it holds a copy of the DOM server side then manipulates it over HTTP.
So if you want it in Java, there's that.
[1]http://www.icefaces.org/main/home/
It looks like it's using Dnode and a hard-coded list of jQuery methods to expose RPC back and forth between the server and browser, so theoretically you could create a very similar binding in any language that has a Dnode binding.
Why would you want to add 100-500ms of latency to every single DOM manipulation? Realtime means I click on something and something else happens, immediately, not a 1/2 second later.
All this to just save having to load jQuery in the client? Not sure I get the advantage.
All this to just save having to load jQuery in the client? Not sure I get the advantage.
You still have to load jQuery through the client. What it does is expose RPC.
So in your situation I'd believe what you'd see is the server sending the command to attach event handlers to the elements you're clicking before you start interacting with it.
So in your situation I'd believe what you'd see is the server sending the command to attach event handlers to the elements you're clicking before you start interacting with it.
Your concern is valid and you probably wouldn't want to program every DOM manipulation with nodequery, and that isnt required. Yes, you would theoretically want to limit the number of calls to the server the same as you would in any paradigm, and hopefully that would be the same as or fewer than an equivalent client-side application. Currently this is just an experiment and I dont recommend it for production.
This appears to solve a major problem with web apps - exposing your entire front-end code to everyone. Very exciting.
Is it production ready? (Edit: Duh, says "beta")
Is it production ready? (Edit: Duh, says "beta")
can somebody provide a real-world example where you'd want to manipulate the DOM from the server?
I'm not sure I really see the benefit of this. Not to say it isn't cool, just wondering where it would be useful over client-side DOM.
My understanding of node is that the benefit is in the lack of thread locking, not specifically that it runs javascript.
I'm not sure I really see the benefit of this. Not to say it isn't cool, just wondering where it would be useful over client-side DOM.
My understanding of node is that the benefit is in the lack of thread locking, not specifically that it runs javascript.
You would use it for testing your pages or for screen scraping. Having the DOM server side allows you to use most client side JavaScript libraries such as jQuery.
Off the top of my head, crawlers or html fragment caching and or/rendering.
There are many benefits to node. Not specifically that it runs Javascript, but that is still one of the benefits - since Javascript is such a popular language and also because it is nearly mandatory to use anyway (client side).
There are a number of reasons why you might want to use jquery directly from the server. Some off the top of my head...
-You can keep your application code hidden from prying eyes
-You only serve up ~120kb of javascript to the client no matter how intense your application is
-You can get better response times for realtime games and apps since what your user is doing is tightly coupled with what actually needs to react (the server).
-You can write 3,000,000 or 10 lines of application logic and it will not affect the speed of the client's device.
One flaw is (potentially) in coming up with a new way to cache redundant requests properly.
-You can keep your application code hidden from prying eyes
-You only serve up ~120kb of javascript to the client no matter how intense your application is
-You can get better response times for realtime games and apps since what your user is doing is tightly coupled with what actually needs to react (the server).
-You can write 3,000,000 or 10 lines of application logic and it will not affect the speed of the client's device.
One flaw is (potentially) in coming up with a new way to cache redundant requests properly.
I think points 1 and 2 are pretty strong. I've always felt reluctant about having your entire code base available to whoever opens the JS file. Maybe I'm just paranoid.
The real strength is reducing the transfer size. You're only sending what's needed by the client. Nice stuff, if it works as-advertised.
The real strength is reducing the transfer size. You're only sending what's needed by the client. Nice stuff, if it works as-advertised.
Also noteworthy is the new ability to treat the DOM as a resource from the server point of view. Extracting information and rendering view partials in realtime as well as placing event listeners for the DOM on the server can help get things done quite a bit faster. This is especially true since you can now work with the DOM near the scope of other server-side only resources making it easier to create prototypes and apps that have a high level of user interaction with them.
I'm comfortable in Javascript, but not a ninja with it or anything. How do you effectively use this to keep what would be client side code on the server side?
You can already write code in server side frameworks and only ship as much code to the client side as actually needs to be there, but surely this isn't what you're talking about.
What am I missing?
You can already write code in server side frameworks and only ship as much code to the client side as actually needs to be there, but surely this isn't what you're talking about.
What am I missing?
Initial reaction: issuing server-side calls to manipulate client-side DOM is a gross violation of the principles of separation of logic/duties. Why is this desirable?
What is limiting this to be jQuery/Zepto specific? Is it possible to write a generic server-side remote control so that other libraries can be used?
Thank you for this. jsDom was the only other server side DOM implementation, and it's garbage (buggy).
This is not a server side DOM. It's an rpc system that acts like a jquery remote control.
That's an awesome summary - they should use it on the site.
Yeah. You just summed up in 2 sentences what I couldn't figure out from the entire readme!
tmpvar (jsdom author) has worked really hard on jsdom. turns out implementing DOM levels 1, 2 and 3 in pure JS is a hard problem. patches welcome, buddy!
We think of js as being of paramount importance in web development because it's the only way to interact with the DOM, so we've mostly come to terms with it and its flaws (which are manifold, even though I happen to think it's a nice language in lots of ways). But if we put all DOM manipulation on the server-side with a very thin client-side javascript communication and manipulation layer, this isn't necessary.
You could write your entire application in Ruby, Haskell, Forth, whatever floats your boat, against a standardized, cross-browser, and improved DOM.
This is powerful and intriguing.