From: Dr. Syd Nicholson
The JavaScript is very controllable on the server. Depending
upon the situation the server can dynamically select or create
the required JavaScript and send this to the client.
It sounds like you're saying that the server can still be in control of the application by dynamically generating and downloading JavaScript instead of HTML. While that sounds plausible in theory, can you point to an example?
The toolkits I've been looking at, download a lot of JavaScript. But it's not dynamically generated. In the case of the RSDC client that Chris Laffra built with Joe Pluta, I understand the JavaScript was generated. But that was part of the "build" process. Not part of the request-response cycle.
What I'm seeing on the horizon is more control moving to client devices. Clients generating the UI, controlling application flow, data validation, interfacing with local data stores, and synchronizing with the server at entry points, and various points thereafter.
If the JavaScript is static, it essentially eliminates the appeal of middleware on the server (asp.net, net.data, cgi, j2ee, etc.). And yet it's not quite like client-server of 80's and 90's. A lot of vested interests are being shaken.
Walden mentioned Google Gears in his last message. So I read a little
about it. It sounds like a plug-in that enables data stores to be
persisted locally. What begins as a Web application, may be taken off-line.
Nathan.
midrange.com
