I'm confused, I regularly read talk of server-side JS, why would I want to use that? It seems like it would execute way slower than pretty much any other language, it also lacks many conventions that more sophisticated languages have.
Is it possible to hand entire objects from the client to the server, manipulate them and return them back?
Just struggling to understand the concepts of it.
Server side JScript is just another language in .NET family of languages. In terms of syntax and features it is pretty much the Javascript we know from working client side with one obvious and very significant difference it is executed on the server.
Therefore the environment is the standard .NET environment you would expect for a program in any .NET language, and, in particular there is no DOM. The server side JScript is subject to the same limitations any other server-side program would be. In particular there is no way to directly pass a client-side JavaScript object to a server side program.
Performance wise JScript code is on par with any other language, because server side JScript is compiled, not interpreted. There is some overhead introduced by type coercions, but it is minimal.
As to why would you want to use JScript - primarily because it is a scripting language. If you need a language to be used by the users of your program to express some simple conditions and/or calculations you might find that giving them JScript as a way to provide this expressions is an attractive option. At least for me it worked out really well
If you know the language and can operate with it at really high level, why would you want to switch to some other language? At this moment there is really nice and fast server-side JS, which is called nodejs. In my opinion nodejs proves that server-side JS is not fare-tale but reality.
So why not?
Interesting links: v8cgi, nodeJs, wxJavaScript and last but not least CouchDB (a JavaScript powered database server)
Yes, you can hand entire objects from the client to the server, manipulate them and return them back, using JSON. You can also share code between the client and server.
why would I want to use that?
It reduces the number of languages your projects use. For a modern webapp, you need developers with some JavaScript knowledge anyway, and if you need only JavaScript expertise, you'll have a bigger labor pool to choose from than if you need JavaScript+Java or JavaScript+C#, or JavaScript+anything.
It seems like it would execute way slower than pretty much any other language,
Can you give any reason why you believe so? Surely this is entirely a matter of VM implementation and thus not something you can make definitive statements about. Besides, it's almost a truism that webapps are usually bottlenecked on DB access rather than CPU.
it also lacks many conventions that more sophisticated languages have.
Um... No? Nowadays, JavaScript (or, properly, ECMAScript) is a quite sophisticated language of its own. It has exceptions, closures, associative arrays... really, all you need.
Is it possible to hand entire objects from the client to the server, manipulate them and return them back?
Not the objects as such, since the underlying protocol is still HTTP, but using JSON is really almost the same thing.
Don't forget you can get all your client-side goodness that Mootools et al give you but on the server side, make coding a sheer joy when you get that up and running. As for speed, depends what you what it to do. We have a site running 1000's of lines of code in JScript ASP per page request, 60K users per day, 1000's of pages. Its is lightening fast! So fast that the case for re-coding it in .net is just not strong enough as the current code handles it perfectly well.
Writting Javascript client side can hurt your head a bit at first, no elements to mess with just nice coding style with some really quirky feature (we pass an annoymous functions/closures into our DB code like so for instance:
var hotels = DataLayer.FindByHotelByStarRating( 4 )
hotels.each( function( hotel ) {
%>
<li><%= hotel.name.htmlEncode() %> is rated as <%= hotel.star_rating %> star</li>
<%
}, this );
Now thats pretty powerful and damn fun too, and the time spent learnng Mootools or advanced JS is not wasted as we can use it both Server-side and client side.
We can use the same validation logic, the same JSON funcitons, the same Objects (if your careful) and so on. ASP with JScript is 100 times better/cleaner/simpler/nicer than VBScript and makes my job a joy rather than a VBScript head ache.
Plus most importantly, its damn fun!
I'm confused, I regularly read talk of server-side JS, why would I want to use that?
So that you could write all your apps in a single language. So that you could share objects between server and client without going through serialization/conversion/etc. So that you could write code onetime (eg. field validation)
It seems like it would execute way slower than pretty much any other language,
Not true. The perception of JS being slow is due to being used client side. Engine implementations were quite slow and there was also the DOM issues. It has been shown[1] that JS can come close to C in performance. And this was last year. There have been further performance improvements. Also check out the [benchmarks of Node.js webserver agains others[2].
it also lacks many conventions that more sophisticated languages have.
You mean stuff like [closures, generators, map/reduce[3], [higher order functios, dynamic typing and a prototype based OO paradigm, more flexible than class-based OO[4]?
Is it possible to hand entire objects from the client to the server, manipulate them and return them back?
It[5] is[6].
-- MV
1: shaver.off.net/diary/2008/08/22/the-birth-of-a-faster-monkey/ 2: four.livejournal.com/1019177.html 3: ejohn.org/blog/javascript-18-progress/ 4: www.ibm.com/developerworks/java/library/j-cb12196/index.html 5: www.jaxer.org/ 6: juicejs.org/
ah however aren't those interpreters part of the clients browsers, they probably won't have those available to their server
Check out www.commonjs.org
-- MV
Hmm.. you say all of the client side goodness, but really most of the client side stuff these libraries provide is mostly DOM manipulation, yah?
They do. But you could use jquery (for example) to generate HTML serverside.
-- MV
Having used nodejs for a while now and having written a mongodb driver for it I have to say that I'm very impressed. First of all since I'm using mongo which stores JSON objects I have a client to db pipeline, that's all javascript.
So while I'm still using ruby at work I have moved to Javascript for all personal projects because I'm lazy and can't stand the constant context switching between SQL, Ruby, Javascript.
And if for nothing else. NodeJS is a fantastic way to re-learn a language few of us ever invested much energy in, and that can only make you a stronger web developer :D
Hi Joe,
I came in late. JavaScript / ECMA-Script is a basic language that can be bound to any library. When used in a browser, it exposes several browser level objects (window, document, etc) to the language. The scripts that you embed in .html files or link as .js files are programmed to perform desired operations upon those objects.
The same concept applies on the server-side. For example, NodeJS exposes HTTP Server and Client objects and you can do the same sort of things that you would in PHP, CGI scripts, Python or Ruby frameworks or Apache modules.
Google's V8 JavaScript engine with JIT is very well optimised. It is used in both Chrome (browser) and NodeJS (server).
I used to use JavaScript in the browser making AJAX calls and Python / WSGI for the server. This mixed mode of programming annoyed me. Since I've discovered NodeJS I can do both Server-side and Client-side programming in the same language. Surprisingly, NodeJS throughput is more than double that which I achieved using Python. There are some more detailed analyses at nodejs.org. The simple take-away is that JS when using V8 comes very close to C/C++ speeds.