Server-Side Javascript: Back With a Vengeance

http://www.readwriteweb.com/archives/server-side_javascript_back_with_a_vengeance.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+readwriteweb+%28ReadWriteWeb%29&utm_content=Google+Reader

by alexandros • 17 years ago

55 30 17 years ago

readwriteweb.com

pwpwp3• 17 years ago

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.

lsd5you2• 17 years ago

Well there is the prototype programming model, which in terms of power of expression can be considered an advance over class based models.

pwpwp3• 17 years ago

Prototypes vs classes is a matter of taste, and I don't think "power of expression" can be measured.

buddycasino• 17 years ago

Exactly, like game developers starting to write their 3D engine in Lua. I don't get it.

ludwig• 17 years ago

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.

Is that what you had in mind, or am I mistaken?

_3ex73• 17 years ago

How can you blame them? Game developers typically have insane deadlines. More power to them.

aaronblohowiak• 17 years ago

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.

dutchflyboy• 17 years ago

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.

pwpwp3• 17 years ago

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.

DougWebb• 17 years ago

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.

orangecat• 17 years ago

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.

_3ex73• 17 years ago

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?

pbh• 17 years ago

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.)

grayrest2• 17 years ago

> 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.

old-gregg• 17 years ago

Less context switching probably means two things:

* 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.

_3ex73• 17 years ago

> * 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.

diN0bot• 17 years ago

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)

coderdude• 17 years ago

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.

pufuwozu• 17 years ago

I've been following Narwhal, Jack and Nitro for some time now. I'm very excited!

Server-Side Javascript: Back With a Vengeance

Related Stories