Client/Server are always separated! Or are they?

Question

Its amazing how many programmers in the greater community of programmers ask questions like "How do I do an EXTJS backend?" or "How do I integrate jQuery with Java?", not understanding the distinction between the client and the server. Then I got to thinking, are there frameworks where the server actually sends JS or something to the client to be executed? What are philosophical thoughts around such approaches?

edit -- to clarify:

im not asking if its possible, I am asking if its a good strategy or frownded upon. I am not asking if client side languages can run on the server. I am asking if there are frameworks that are built around dynamically serving dynamic client side code.

Answer 1

Sending JavaScript to the client is trivial. Simply point the URL in the script tag to a dynamic script instead of a static .js file.

As for running JavaScript on the server side, things like Node.js let you do so, although they don't have the same level of interaction with the browser.

Answer 2

The physical barrier is definitely there. The HTML/JavaScript/ActionScript will run in the client space and will (in essence) be making remote procedure calls to the back end. Because of this rift you won't be able to eliminate the client/server architecture.

That being said Pierreten makes a good point that Microsoft's ASP.NET API makes heavy use of automatically generated JavaScript to interface with server-side components. That is, you add a form control to your project and both the server and client side code are generated for you.

Answer 3

The Google Web Toolkit comes to mind.

When you're ready to deploy, GWT compiles your Java source code into optimized, stand-alone JavaScript files that automatically run on all major browsers, as well as mobile browsers for Android and the iPhone.

Answer 4

Many different frameworks do this, when you're doing ASP.NET work, you'll constantly be seeing POSTBACK calls in the client, this is generated by the framework and is a Javascript call. In the Java world, most JSF frameworks to this to a greater or lesser extent. I see no harm in this as long as you remember the "never trust the client" rule. So if you are going to do a field validation in Javascript on the client, that does NOT release you from having to do the same check on the server end. I did a largish Flex application not too long ago, and as part of it I started down the road of creating a module that would read Hibernate Validation annotations and automagically create the same validation on the Actionscript, deadlines killed that before I got too far, but I do like the idea of being able to set validations once on the back end and have them checked on the client, saving the round-trip to the server.