3 ms·

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 hid

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.

cobrabyte 15y ago
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.
- funthree 15y ago
  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.
wanorris 15y ago
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?

cobrabyte 15y ago

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.

funthree 15y ago
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.

wanorris 15y ago

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?