
Server-Side Javascript: Back With a Vengeance - alexandros
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
======
coderdude
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.

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

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

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

~~~
grayrest
> Client-side...jQuery...nearly 7K lines

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.

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

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

------
mdg
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?

~~~
old-gregg
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.

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

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

~~~
pohl
I'm surprised to hear WebKit's DOM Inspector being compared unfavorably to
Firebug. What's missing?

~~~
maxwell
At least when I last used it, the error reporting was lacking. Errors'd hang
the page and wouldn't give accurate messages/line numbers.

