JavaScript is "assembler with closures and broken hashtables", and I don't get why anyone would want to use it on the server, compared to richer languages.
Well, have you ever tried to program in javascript? It's a fantastic language for prototyping. If you want to try an algorithm, you sit down, write an astonishly small quantity of code and it just works. That's just one of the reason why I use javascript.
Another is, that it's a fantastic language to use for hobby projects, because you don't need to think too much beforehand, thanks to the dynamically typed variables, methods and objects.
And last but not least, you don't have any GUI to manage. HTML does it for you, which simplifies matters a bit. You want to dynamically create HTML? No problem. You prefer to prepare the HTML beforehand? No problem at all.
So to answer your question, I use it because it's refreshingly easy to use, more so than richer languages who are sometimes simply too heavy.
That's basically the same reasoning that applies to any server-side scripting language: high level scripting languages are much more efficient to develop with than more structured lower-level languages, and the web-application model lets you use HTML as your GUI which is quick, easy, and flexible (though not as rich or stable as client-side GUIs can be.)
My personal preference for server-side development is Modern Perl, because it lets you develop anywhere along the "highly structured" to "rough scripting" line that you please. Other server-side languages are fine if they suit your development style, but I like to adjust my style to suit the project, and to use a language that can adapt to whatever style I need.
Client-side, Javascript is great especially with jQuery. I couldn't deal with javascript development without selectors; it's far too much effort. I'll have to give Javascript a try for server-side development, but I don't think I'd want to do a large project in Javascript. My current application at work has nearly 7K lines of client-side Javascript, and it's already getting unwieldy.
The reason I only use jQuery for ajax-sprinkles apps (take a static app and make it ajaxy!) is because it provides no tools for dealing with larger size programs. I used to use MochiKit for the Signals module, but I've switched over to yui3. It's roughly the same terseness of jQuery but with an excellent set of tools for organizing/decoupling your code.
Besides using JS on the server with Helma for some time, I even wrote a Lisp->JS compiler (CyberLisp) in JS. This project finally showed me that I don't want to use JS anymore.
I agree with your point about prototyping, but I don't see why one would use a language that's good for prototyping, but sucks in the greater scheme, for web apps.
It's a fantastic language for prototyping. If you want to try an algorithm, you sit down, write an astonishly small quantity of code and it just works.
That's true of Python and Ruby as well, both of which have basic features that Javascript lacks like modules and namespaces, and don't have its silly misfeatures like implied global scope. Javascript may very well end up "winning", but that will be because of its ubiquity in browsers and not on technical merit.
I think lsd5you is probably referring to the fact that you can trivially build classes on top of prototypes, while the reverse is not generally true (as far as I know). So a prototype-based language can easily express both classes and other forms of OO.
Sorry, but it isn't that hard to build prototypes on top of classes in a dynamic language. The cleverest and shortest implementation I've seen is http://snippets.dzone.com/posts/show/3378 where the following snippet of Ruby code does it:
Proto = Class.new(Class) # Beware: magic.
def Proto.clone
Class.new(self)
end
Yeah, although the trade off is that as class construction is procedural with prototypes you know longer have a declarative type system. Any type checking will have to come from type inference (when possible).
Any sources for that? I know Lua is often used as a scripting language in 3D games since it is very easy to embed a Lua interpreter into your game. If you haven't seen it, you should take a look at the lua source code. It's beautiful.
Essentially, you are making a nice internal API to your engine objects that you can manipulate, and experiment with, on a higher level without recompiling your application all the time. Python is also nice for this purpose (see OGRE 3D), but it's not as lightweight as Lua.
So in a sense, it's better to use Lua for parts of your engine that will change a lot, depending on what aspect of the engine you are a focusing on at the moment (like tweaking how the enemy A.I. works, for example). This is especially useful at the prototype stage of your application.
We needed an easy-to-use configuration language, and the only configuration language available at that time (1993) was Tcl. Our users did not consider Tcl an easy-to-use language. So we created our own configuration language.
Given how different Lua ended up, though, I imagine there was more to it than that.
LuaJIT is wicked fast, and being able to have multiple VMs with a single interpreter is very nice as well. With cooperative coroutines, a nice C API (for calling into lua) and C/Invoke for calling out of lua nicesly, it is a very clean and effective way to power your applications.
I just thought about this, but you could (in theory, and limited by certain implementations) execute your tracking scripts serverside instead of on the client. If you do this asynchronously then you can probably eliminate the hit those scripts take on page load time.
Edit: Now all the reasons this wouldn't work are pouring in (mostly for something like Google Analytics). Mixpanel works this way though, and they provide the ability.
in favor or less context switching wrt code reuse: i will say that allowing my firefox extension (client) and django website (server) to share the same templates is pretty awesome. (thx static)
I dont buy that "less context switching using the same language client and server-side" nonsense. Are you storing data in a database? Context switch. Are you outputting HTML? Context switch.
I also dont buy that it makes client-side Javascript better because you are using it on the server as well. The client-side Javascript is probably going to send and receive JSON. When it gets that JSON, it has no clue (and doesnt care) what language or framework generated it.
On a side note - I have been lurking on the node.js mailing list for a while now. Why do people think writing a MVC framework is apropriate? Isn't there something more exciting you can do with node.js?
> * Mental context switch between server/client languages.
Not sure I follow. The client-side Javascript you write will probably interact with the DOM API. The server-side Javascript will probably interact with the filesystem of the server, it is BYOD (Bring Your Own DOM). Plus, no matter what, you will always have that switch between client/server because that switch is what defines client/server.
> * Better code reuse, i.e. the same model class can be used on the server and client side.
Does anyone actually do this? True, it is the same language, but it is not the same environment.
> ...it is the same language, but it is not the same environment.
It is for me. I'm building a framework and enterprise app that just targets V8 (Node server, Chrome client). It's very liberating, to say the least. I still use Firefox (Firebug) for experimental stuff though, as Chrome's dev tools aren't up to par yet.
Sharing models makes doing some form validations MUCH easier. My template language also runs on both server and client making progressive enhancement pretty trivial (in terms of updating dom elements when models change)
As for context-switch on server/client... if you use something like underscore on both ends, lots of things end up looking the same.
I think that the example you give is actually a very good example of a set of context switches that people regularly deal with poorly, even though they are, as you note, very common.
How many server side web developers do you know who can output standards compliant HTML/XHTML that also works on IE6? (In fact, I suppose this is one major reason why templating is so common---so you can separate the web development experts from the web design experts.) How many web developers will have a database enforce their integrity constraints rather than having the logic in their program? How many know how to write PL/SQL? How many compilers are there now from some source language down to JavaScript in order to reduce the number of languages that a developer needs to know and control interactions between?
The danger of these sorts of context switches seems to be difficult project coordination, code redundancy, performance bugs, and logic errors.
(On a side note, it's not that I think that developers are stupid, it's that writing code well in a given language seems to require not just familiarity with that often idiosyncratic language, but it also requires continued knowledge of standard idioms, libraries, frameworks, and sources of answers to common problems.)
> Isn't there something more exciting you can do with node.js?
My goal for node is to push my apps client side. Once you go all the way client side, the server only needs to serve up the static application files so that I can have them application cached, to backup/distribute/contain the localStorage, and to act as a communication channel. Node has the potential to excel at the last two while remaining widely comprehensible since most developers can at least read javascript.
I don't see the need for a django or rails on the platform, but I don't have a problem with the current major efforts of a database abstraction layer or simple DSLs like sinatra.
