Server-Side Javascript: Back With a Vengeance
readwriteweb.com
readwriteweb.com
Proto = Class.new(Class) # Beware: magic.
def Proto.clone
Class.new(self)
end
However several other languages have implementations. For a random example see http://search.cpan.org/~teverett/Class-Prototyped-1.11/lib/C....
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.
Is that what you had in mind, or am I mistaken?
http://www.techworld.com.au/article/260022/-z_programming_la...
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.
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.
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.
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.
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.
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.
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?
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.)
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.
* Mental context switch between server/client languages.
* Better code reuse, i.e. the same model class can be used on the server and client side.
Those things you're talking about are just protocols: storage protocol, transfer protocol, etc.
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.
As for context-switch on server/client... if you use something like underscore on both ends, lots of things end up looking the same.
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.