Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

JavaScript Servers Compared

samzenpus posted more than 2 years ago | from the taking-them-for-a-spin dept.

Programming 132

snydeq writes "InfoWorld's Peter Wayner test-drives five leading JavaScript servers and finds the results compelling though still a work-in-progress. 'I enjoyed the challenge and stimulation of rethinking everything I know about the server, but I still found myself hesitant to push these new ideas too far or too fast. The speed of experimentation and development is heady and exciting to the open source crowd, but it will probably seem scary to corporate developers who like the long, stable lives of tools from Microsoft or Oracle. Some of these platforms will probably morph three or four times over the next few years, something that won't happen to the good, old JSP standard in the Java world,' Wayner writes in review of Node.js, Jaxer, EJScript, RingoJS, and AppengineJS."

Sorry! There are no comments related to the filter you selected.

Second post! (4, Funny)

Anonymous Coward | more than 2 years ago | (#36243186)

Second post! Would've been first if slashdot had a faster javascript server.

Third post (3, Funny)

Anonymous Coward | more than 2 years ago | (#36243196)

Third post! Would've been first if slashdot had a faster javascript server.

First post! (2, Funny)

Anonymous Coward | more than 2 years ago | (#36243210)

First post! Good thing slashdot has a fast javascript server.

Burn the bible (1, Interesting)

Anonymous Coward | more than 2 years ago | (#36243220)

Burn the bible [goo.gl]

The only good JavaScript is a contained JavaScript (2)

VortexCortex (1117377) | more than 2 years ago | (#36243268)

Or, i dunno... maybe we could use JavaScript to add flexible dynamic scripting to our existing stable Java platforms? ...otherwise what's the point? To use a domain specific language for tasks it wasn't designed for or is very good at?

Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.

Hint: Just use Rino [mozilla.org] and be done with this nonsense.

Re:The only good JavaScript is a contained JavaScr (0)

Anonymous Coward | more than 2 years ago | (#36243332)

Shhhh.... (quietly) every generation has to reinvent the wheel so they can have a job. Don't tell anybody. Just keep your mouth shut.

Re:The only good JavaScript is a contained JavaScr (1)

Fusselwurm (1033286) | more than 2 years ago | (#36243348)

To use a domain specific language for tasks it wasn't designed for or is very good at?

JavaScript works very well as something it wasnt designed for every time you use GMail, Meebo or any other application that's running within the browser these days.

Re:The only good JavaScript is a contained JavaScr (0)

Anonymous Coward | more than 2 years ago | (#36243426)

just because of historical accident...thats the only extension mechanism available

if i were going to design a full featured application i wouldn't choose javascript

hmm, maybe thats why the google applications are actually compiled into javascript instead of
being written in it

Re:The only good JavaScript is a contained JavaScr (1)

GooberToo (74388) | more than 2 years ago | (#36244254)

hmm, maybe thats why the google applications are actually compiled into javascript instead of being written in it

No idea why this was posted anonymously.

+1 Profoundly Fucking Insightful

Re:The only good JavaScript is a contained JavaScr (2, Interesting)

Anonymous Coward | more than 2 years ago | (#36244592)

Hi. We (I'm a google employee) have GWT [google.com] , which compiles java to javascript, but we don't actually use it much. Most projects I'm aware use Javascript written as javascript. We do use build scripts to pre-process, include dependencies, and minimize/obfuscate, though.

JavaScript is usable, but.... (1)

Sloppy (14984) | more than 3 years ago | (#36246954)

if i were going to design a full featured application i wouldn't choose javascript

Nobody would.

Javascript is adequate. I am never going to complain that Javascript somehow keeps me from doing my job. I can do anything in Javascript. I have bigger fish to fry and the need to occasionally write Javascript doesn't make the list of my "real" problems.

But Javascript sucks. It is wrong. I would rather program in PHP (!) than Javascript. (Maybe even perl? Well, no. I would rather program in Javascript than perl.) But anyway: Classes. Prototypes are lame. Anyone who starts a new project involving Javascript in any situation other than running in a web browser, is totally fucked in the head. Someone has so many choices and they pick Javascript? Please. Yes, it can function as a general-purpose programming language, but it's not one, and it is very sad that the world is possibly going to be forever burdened by it.

Damn you, Netscape. You may end up being a longer-lasting plague than Microsoft.

Re:The only good JavaScript is a contained JavaScr (1)

omfgnosis (963606) | more than 2 years ago | (#36243946)

Why wasn't it designed for those applications? It's a general purpose programming language. Perhaps the browser's APIs (DOM) weren't designed with those applications in mind, but even the first standardization of the DOM (DOM Level 1) APIs could implement most if not all of those applications' features, one way or another (eg. submitting forms to a frame—a feature introduced with JavaScript in Netscape 2—and periodically appending new scripts which contain server data).

There's a lot of reasons that those kinds of applications didn't appear until later, but they could have been made much sooner. But poor standards support in browsers made interoperability a nightmare, slow client hardware made performance questionable, and ultimately poor understanding of JavaScript and the DOM delayed serious uptake among developers for about a decade.

Re:The only good JavaScript is a contained JavaScr (1)

davester666 (731373) | more than 3 years ago | (#36247474)

Guess what.

The leading proponent of all 5 Javascript Server projects is....Intel!

Re:The only good JavaScript is a contained JavaScr (1)

BitZtream (692029) | more than 2 years ago | (#36244834)

uhm, thats pretty much EXACTLY what Javascript was intended for ... you do know where it came from ... right?

Re:The only good JavaScript is a contained JavaScr (2)

bmuon (1814306) | more than 2 years ago | (#36243420)

Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.

That is the whole idea. Write processor intensive tasks in a fast compiled language (C or whatever) and glue them with a server that is good at handling asynchronous requests. That's what Node.js is about and JavaScript is actually a good fit for it because of closures.

Re:The only good JavaScript is a contained JavaScr (1)

tixxit (1107127) | more than 2 years ago | (#36243510)

Except that JavaScript, today, is not a slow dynamic scripting language. The latest JS engines in IE 9, FF 4, and Chrome are lightning fast. You'll be hard pressed to find a faster dynamically typed scripting language today. Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS. Also Rhino IS slow (compared to most other JS interpreters) and has been included with Java by default since Java 6.

Re:The only good JavaScript is a contained JavaScr (2)

the linux geek (799780) | more than 2 years ago | (#36244428)

The Javascript engines in browsers come nowhere close to the runtimes for the mainstream server-side platforms (J2EE, .NET, etc) in performance. It's not always orders of magnitude difference anymore, but one of those runtimes will still reliably be several times faster than the fastest JS engines.

Re:The only good JavaScript is a contained JavaScr (3, Interesting)

GreyLurk (35139) | more than 2 years ago | (#36244900)

In terms of numerical computation? Probably. In terms of actual useful web applications, Node.js meets or beats compiled Java in the benchmarks that I've seen, even with the Java Code using esoteric and not commonly used behaviours like Non-Blocking IO: http://www.subbu.org/blog/2011/03/nodejs-vs-play-for-front-end-apps [subbu.org]

V8 is actually really damn fast.

Re:The only good JavaScript is a contained JavaScr (2)

Billly Gates (198444) | more than 3 years ago | (#36247448)

The bottleneck on a dynamic webserver is either network or SQL access times. It does not matter if you have the fastest web server software in assembly when it takes 1,000 ms to access a SQL query to display for a client's browser.

Static it is a different story, but who besides a small mom pop page uses simply static pages anymore? So this is why Java took off a decade ago while slashdotters scratched their head wondering why could something so slow and slugish could ever scale. It is about SQL

Re:The only good JavaScript is a contained JavaScr (1)

BitZtream (692029) | more than 2 years ago | (#36244864)

Your definition of 'lightning fast' is my definition of 'painfully slow language' even in the new JS engines.

Re:The only good JavaScript is a contained JavaScr (1)

Transfinite (1684592) | more than 2 years ago | (#36245216)

I assume you write all your web apps in machine code then?

Re:The only good JavaScript is a contained JavaScr (1)

GreyLurk (35139) | more than 2 years ago | (#36245386)

I prefer my webservers to run purely on ASICs. Sure, updating the web site is a little costly, but I can handle more traffic than Amazon.

Re:The only good JavaScript is a contained JavaScr (1)

tixxit (1107127) | more than 3 years ago | (#36247030)

I guess it wasn't obvious, but I was comparing JS to other dynamically typed scripting languages. I'm also talking in respect to tasks that scripting languages usually tackle. If JS is painfully slow for you, I'm just assuming you are using it for something you probably shouldn't be using ANY scripting language for.

Re:The only good JavaScript is a contained JavaScr (2)

CapOblivious2010 (1731402) | more than 2 years ago | (#36245392)

Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS.

Honestly? Well, honestly, the more code I write/debug in dynamically-typed interpreted languages, the more I like statically-typed compiled languages (and it has nothing to do with execution speed)

Re:The only good JavaScript is a contained JavaScr (1)

tixxit (1107127) | more than 3 years ago | (#36246784)

My favourite language, by far, is Scala, so don't think I don't know where you are coming from. And, honestly, my favourite dynamic language is Python, though I am using JS on occasion now.

Print version of the article (5, Informative)

Kenz0r (900338) | more than 2 years ago | (#36243304)

Read the print version of the article in one page:
http://www.infoworld.com/print/161969 [infoworld.com]

Awful Article (0)

Anonymous Coward | more than 2 years ago | (#36243356)

Just the tip of the fudberg:
- States 2MB for each Java thread created (WTF... Where did they pull this number? Isn't the default stack size for each thread 512KB?)
- "Just as businesses try desperately to avoid tying up capital in inventory, a programmer's job is to think like a factory boss, treat RAM as capital, and avoid consuming any of it." (Holy Crap, don't know where to start! Aren't we in the age of memory is the new disk? Use it wisely, don't avoid using it all together!)

Re:Awful Article (1)

dgatwood (11270) | more than 2 years ago | (#36243432)

While we're at it, the JavaScript engines are all single-threaded per server? So you get no benefit from having multiple cores or multiple CPUs in your server? What a colossal train wreck of a design.

Re:Awful Article (1)

badboy_tw2002 (524611) | more than 2 years ago | (#36243642)

That should be solved in the next version of the Linux kernel which allows you to run multiple processes _per machine_. Think of it! "Multitasking" is the future!

Re:Awful Article (1)

Transfinite (1684592) | more than 2 years ago | (#36243660)

Oh god! that's why you have such projects as multi-node. If you bothered to figure it out for yourself you might realise why single threaded apps can be good in the right situation.

Re:Awful Article (2)

dgatwood (11270) | more than 2 years ago | (#36244062)

The article made it sound like you have one instance of a JavaScript server that runs as part of your web server (Apache, presumably) and all JavaScript requests get funneled into a handler, all within a single thread. Apparently, that's not the case. Thus further emphasizing the point that the article doesn't describe things too well. :-)

Re:Awful Article (1)

omfgnosis (963606) | more than 2 years ago | (#36244030)

Node is working on adopting Web Workers, but it already has the ability to spawn new processes.

Re:Awful Article (1)

DrXym (126579) | more than 2 years ago | (#36244758)

While we're at it, the JavaScript engines are all single-threaded per server? So you get no benefit from having multiple cores or multiple CPUs in your server? What a colossal train wreck of a design.

Fire up a different process per core and route each request through a load balancer. Alternatively use web workers to service the requests with the main thread acting as the conductor which spins them up and services common functionality.

Re:Awful Article (1)

Guspaz (556486) | more than 3 years ago | (#36246228)

PHP is also single-threaded per server; PHP doesn't jive well with multithreading. So what we get is mpm_prefork with one instance of mod_php per process, or alternatively, a web server using fastcgi that spawns multiple PHP processes.

Re:Awful Article (1)

gilleain (1310105) | more than 2 years ago | (#36243654)

Just the tip of the fudberg: - States 2MB for each Java thread created (WTF... Where did they pull this number? Isn't the default stack size for each thread 512KB?)

Default is 512k, yes. But there are some extra details: 'Java stack size myths' [www.odi.ch]

Re:Awful Article (1)

Transfinite (1684592) | more than 2 years ago | (#36243796)

Yes, generally "The default thread stack size varies with JVM, OS and environment variables. A typical value is 512k". However one approach is to have a single thread and use that more efficiently. Nothing wrong with that. NodeJS along with nginx can solve the C10K problem out of the box, Tomcat can be tuned to deal with more than 10K concurrent connections, but eventually your multi threaded app *could* eat up all you memory.

Next comes JavaScript Artificial Intelligence (-1)

Anonymous Coward | more than 2 years ago | (#36243358)

The referred-to article talks about the Google App Engine and does not mention the new possibility of creating AI Apps [blogspot.com] in JavaScript [google.com] to serve up artificial intelligence [scn.org] to desktop computers, laptops, smartphones and netbooks. The JavaScript [blogspot.com] AiMind [scn.org] is just a tutorial but fully functional version of a much faster and more powerful AI known as MindForth [scn.org] in Forth for autonomous robots. An AI Mind residing on a JavaScript server flits across the 'Net to take up residence as a client-side AiApp on any stationary or mobile computing platform.

No real comparison. (0)

Anonymous Coward | more than 2 years ago | (#36243392)

They are all slow, insecure, malware engines.

You are a renegade. (5, Funny)

not already in use (972294) | more than 2 years ago | (#36243408)

Remember when javascript had a terrible rep? Then people were all like, "No! It's totally awesome! It has first-class functions and prototypal inheritance!" Yeah, you remember. You read all the blogs. You had flashbacks to your not-so-pleasant encounters with javascript while developing client-side web applications. Then, all the sudden, prototypal inheritance became the in-thing, like popped collars. No matter how ugly or ridiculous it looked, you didn't want to be the only one who didn't think it was cool. You started writing gobs of hard to organize, impossible to refactor serverside javascript code. You convinced yourself, somehow, that you saved time by not having to issue some "compile" command. No, it just starts, DYNAMICALLY! What a cool word, dynamic -- like Ugg boots! And like wearing Ugg boots in the summertime, you tortured yourself searching for simple runtime errors. Static checking? Compiling? These are the things of white-collared enterprise folks.

You are not a white collared enterprise guy. You are a renegade. With a popped-collar. And ugg boots.

Re:You are a renegade. (1)

cyfer2000 (548592) | more than 2 years ago | (#36243450)

Ever wrote something in Perl?

Re:You are a renegade. (1)

vlm (69642) | more than 2 years ago | (#36243482)

Ever wrote something in Perl?

Even Perl, believe it or not, actually has Test::Unit, Test::Simple, Test::Harness, and about eighty zillion logging and debugging systems.

Javascript, thats got... uh...

Re:You are a renegade. (1)

timothyf (615594) | more than 2 years ago | (#36243568)

Perl does not have Test::whatever. CPAN has it. And there's nothing preventing anyone from implementing test frameworks in JS. In fact there are already a number of them out there, jsUnit to name an example off the top of my head.

Re:You are a renegade. (1)

Transfinite (1684592) | more than 2 years ago | (#36243624)

Uh... is got https://github.com/joyent/node/wiki/modules [github.com] and that is just for starters

Re:You are a renegade. (0)

Anonymous Coward | more than 2 years ago | (#36243944)

Uh... is got https://github.com/joyent/node/wiki/modules [github.com] and that is just for starters

watch out everyone! this guy wrote a web framework for node.js!!

Re:You are a renegade. (2)

ya really (1257084) | more than 2 years ago | (#36243672)

Apparently you have never googled for javascript testing [google.com] There's quite a few organized testing and unit frameworks for javascript out there and there are even IDEs that have support for them, such as Intelij IDE [jetbrains.com] and its primarily php/web cousin, PHP Storm. I've use both of them on a regular basis and they both support NodeJS and have have built in javascript debugging/unit testing.

Re:You are a renegade. (1)

Transfinite (1684592) | more than 2 years ago | (#36243900)

While not as full featured as Intelij..... cloud9 http://cloud9ide.com/ [cloud9ide.com] which is actually written in NodeJS

Re:You are a renegade. (1)

Roachie (2180772) | more than 2 years ago | (#36243986)

Firebug.

Re:You are a renegade. (1)

Inda (580031) | more than 2 years ago | (#36244130)

...Microsoft Script Editor.

You know, even being forced to use it wasn't so bad... for small jobs... in the corporate environment.

That was about 8 years ago too.

JS has tools.

Your dad's ass was hot (0)

Anonymous Coward | more than 2 years ago | (#36244020)

No, but I fucked your dad's ass 5 minutes ago.

Re:You are a renegade. (1)

lennier (44736) | more than 2 years ago | (#36244176)

Ever wrote something in Perl?

Only once, and I took fifteen showers afterwards and still felt dirty.

Re:You are a renegade. (1)

maraist (68387) | more than 3 years ago | (#36246342)

If you learn the syntax inside and out, perl has some of the most concise verbs I've ever used. 90% of the perl scripts I've written were 1 liners (where a line can exceed 200 characters).

perl -ne 'chomp; (/start/ ... /end/) && $words{$_}++; END { print join "\n", map { "$_ : $words{$_}" } keys %words }' file.txt

Re:You are a renegade. (4, Informative)

tixxit (1107127) | more than 2 years ago | (#36243844)

Prototypical inheritance didn't make JS cool, and JS wasn't the reason we hated JS 10 years ago.

The reason JS was hated so much 10 years ago was because of the DOM. That's it. Every browser had close enough implementations that you thought mucking about with the DOM would be simple... but they were different enough to cause endless headaches and hardcoded hacks to work around all sorts of quirks. Making a simple drop-down menu meant coding everything from scratch, maintaining essentially 3 different versions of the same code for different browsers.

JS is cool today because of many things.

The convergence of browser features and DOM implementations towards the standard. Coding JS to work cross browser has definitely gotten easier.

The proliferation of browser libraries that abstract the browser away from us developers and handle all the little DOM implementation differences for us.

There is a solid (and growing) set of best practices for client-side programming (eg. progressive enhancement, event-driven programming, etc.). This has dramatically cut down on the amount of time spent (re)writing JS and let's people create better abstractions that work well with JS.

The functional aspect of JS is definitely nice, and allows for some very concise code (considering) to be written. However, it can also be eschewed for those that are not comfortable with functional programming.

JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.

However, I don't think people think prototypical inheritance is really all the grand. It's simple, is what it is and that fits well with JS (simple). When most the original crop of modern JS frameworks came out, the first order of business was to build a more traditional class-based inheritance approach. I know it doesn't fit well with your "renegade" theory, but it's true. People now seem to be getting comfortable with prototypical inheritance, but I don't think you'll find many people willing to extol its virtues.

Also, JS has first class functions, yes, but so do LOTS of other languages. I'm not sure why you're picking on JS developers for liking some aspects of functional programming.

Re:You are a renegade. (1)

eigenstates (1364441) | more than 2 years ago | (#36244284)

Uhh, I quite like how the module and 'require' patterns work in JS. <-- read: I am extolling their virtues. I am a big fan of quick and dirty object decoration as well (as long as you keep it in the closure). Webworkers do processing in other threads. And V8 has a whole debugging API.

Never have been entirely sure why people are so quick to pee all over JS. After having done Perl, Python, C# and Actionscript for corporate production as well as private there are benefits to all of them (less so Actionscript after learning how to deal with the wild nature of JS). I guess it'a all about knowing when to hold them, when to fold them and when to walk away.

Re:You are a renegade. (1)

Transfinite (1684592) | more than 2 years ago | (#36244744)

People generally 'pee' over things when they don't understand them or can get their heads around thinking in different ways for different problems. After all single threaded has to worse than multi-threaded, right? I mean why would you want to use Javascript for the 'web', I mean it's not like it's suited... Oh wait. Anyway we should all be using languages that were solely designed for the web, like Java... Oh hang on...

Re:You are a renegade. (1)

tixxit (1107127) | more than 3 years ago | (#36246846)

I'm not sure what the "module" and "require" patterns have to do with prototypical inheritance. Ruby, Python, and Groovy (for example, there are many others) are all class based and allow metaprogramming and/or "monkey patching," so "dirty object decoration" is not a trait only found with JS.

Web workers are very restricted. They run in a completely different scope and can merely pass messages to the main UI thread.

I wasn't peeing on JS. I love Javascript. The only negative thing I mentioned was that prototypical inheritance isn't something people usually fawn over. However, I also mentioned that it IS in keeping with Javascript's simplicity. For note, I LIKE simple. Simple is good. Simple and powerful are not mutually exclusive.

Re:You are a renegade. (1)

jdoverholt (1229898) | more than 2 years ago | (#36244306)

You make several good points, I only take exception to one small part.

JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.

C (or most any other language) is single threaded too, and you don't have to worry about concurrent programming. That is, until a single thread just isn't good enough anymore and it's time to break out a threading library. Then you have to worry about concurrency, blocking, etc. Incidentally, this has a tendency to come about when you're writing server software.

Re:You are a renegade. (1)

eigenstates (1364441) | more than 2 years ago | (#36244476)

Yes- I agree with you on this. JS is simple but you should always be concerned with handling data asynchro- especially with JS where one frozen or busy thread will bring the whole thing to a halt. <Ballmer>Callbacks, callbacks, callbacks</Ballmer>

And if anyone is up for some reading this series is pretty nice:
http://howtonode.org/object-graphs

As well as 'JavaScript: The Good Parts'- Douglass Crockford

Re:You are a renegade. (1)

MobyDisk (75490) | more than 2 years ago | (#36244516)

The key difference is that it is not even possible to spawn a thread in a browser. But you are right, that isn't a benefit.

Single threaded is actually harder - you still have concurrency issues because even simple operations must be done using an asynch event pattern. Multithreading was created because simulating concurrency in a single-threaded app is hard.

Re:You are a renegade. (1)

eigenstates (1364441) | more than 2 years ago | (#36244738)

http://www.html5rocks.com/tutorials/workers/basics/

There's probably a lot of concurrency one could get away with using workers.

Re:You are a renegade. (1)

dodobh (65811) | more than 3 years ago | (#36247478)

Threads were a lightweight fork(2) replacement.

Re:You are a renegade. (1)

tixxit (1107127) | more than 3 years ago | (#36246770)

The difference is that JS can appear to be multi-threaded. For instance, I can set a function to run after a set amount of time (setTimeout). In the browser, this function will be run in the same thread as all the other code and it will be atomic. The same goes for all the UI events and the like. If I wanted to set a timeout in C that would run a function after 1 seconds, while doing some other stuff in the mean time, threads would be what I'd grab for first. However, JS promises to be single threaded, so you never have to worry about the underlying implementation.

Re:You are a renegade. (1)

not already in use (972294) | more than 2 years ago | (#36244928)

JS is SIMPLE.

Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.

In the browser it is single threaded. You don't need to worry about concurrent programming.

Well played, sir. Pretend that an inherent limitation is somehow a feature. As if, if I were to choose another language, I would be forced to write multithreaded code.

Also, JS has first class functions, yes, but so do LOTS of other languages.

Exactly. I was never "picking" on first class functions. It was part of all the hubbub when some random group of hipsters suddenly thought javascript had enough redeeming qualities to make it worth using outside the browser, as if it was somehow unique, or in the case of prototypal inheritance, actually useful in any sort of practical sense.

Re:You are a renegade. (1)

tixxit (1107127) | more than 3 years ago | (#36246732)

Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.

Undefined vs. null is nuanced? Hardly. And == vs. ===? Pretty much every language defines a difference between equivalence and object identity, whether its Python (== vs. is), Java (equals vs. ==), or Javascript (== vs. ===). What I meant by simple is that there aren't a whole lot of "extras" in the language. Every language is nuanced to the extent you are describing.

Well played, sir. Pretend that an inherent limitation is somehow a feature. As if, if I were to choose another language, I would be forced to write multithreaded code.

It's a design decision, there is no reason they couldn't have allowed threads. Also, it is a design decision that isn't always immediately apparent when dealing with event driven UI code. This includes setTimeout/Interval. The functions that run on this timer are atomic. Again, this is not immediately apparent if you aren't familiar with JS. And, yes, this is a nice feature, as having all even driven UI code, timers, etc. run in the same thread is not as easy as it seems.

like Netscape FastTrack & LiveScript in '96? (2)

darkeye (199616) | more than 2 years ago | (#36243546)

wow, how is JavaScript on the server side new?

anyone remember the Netscape FastTrack server, and the LiveWire environment, where LiveScript was used to code both server & client side of a web application. LiveScript being of course the original name of JavaScript. this was back in 1996, merely 15 years ago...

history seems to repeat itself...

Re:like Netscape FastTrack & LiveScript in '96 (2)

betterunixthanunix (980855) | more than 2 years ago | (#36243626)

We used to call it "SSJS" -- server-side Javascript. Times really have not changed, but why would you expect them to? Despite the superficial changes, the underlying structure of the Internet and the Web has not really changed. We have not really seen much in the way of "revolution" in the past 15 years, just incremental changes (or if you would prefer, "improvements") to the way everything works.

Re:like Netscape FastTrack & LiveScript in '96 (1)

RussellSHarris (1385323) | more than 2 years ago | (#36243684)

Or .jsp, which has been around for quite a long time.

Re:like Netscape FastTrack & LiveScript in '96 (1)

BitZtream (692029) | more than 2 years ago | (#36244902)

jsp is java, not javascript, which is entirely different other than the name.

Re:like Netscape FastTrack & LiveScript in '96 (1)

Transfinite (1684592) | more than 2 years ago | (#36243922)

really it's not changed. I'd think about that again? Where have you been?

Re:like Netscape FastTrack & LiveScript in '96 (1)

betterunixthanunix (980855) | more than 2 years ago | (#36244732)

I said the underlying structure has not changed much, but that there have been superficial changes. Can you please point out where the underlying structure of the Internet or the Web has undergone a significant change? When last I checked, we are still using IPv4 and we are still using HTTP, and we are still using a client-server model. This most significant change that I can think of is AJAX, and that is not a terribly significant change (it really just means that things people would have done in an applet can now be done by the browser itself).

Yes, things look a lot different now, and we are making more sophisticated use of the underlying technology (sometimes), but for the most part we are still talking about the same system.

Re:like Netscape FastTrack & LiveScript in '96 (1)

Transfinite (1684592) | more than 2 years ago | (#36245040)

Yes the underlying structure is much the same. But our paradigms have changed a lot. The early web was request response, with very little focus on the client at all. That's changed, there is now far more parity between what happens on the server and client. This is only going to increase. The point is this, if you have a common language (Javascript) that fits the web, very, very well and you have browser vendors implementing features in HTML5 that encourage distributed, real time apps. Together with improvements in HTTP1.1 (which is really one of the main drivers). Then you have a web that in reality looks nothing like the one we had 15 years ago. What I don't understand if the fear people seem to exhibit with stuff like this. There is absolutely nothing wrong with a modern implementation of server side Javascript. There is nothing wrong with single threaded apps, there is also nothing wrong with multi-threaded. Single threaded systems can have certain qualities that perhaps multi-threaded apps don't. They certainly use resources in a much more effective way. We don't need multi threaded-ness everywhere. These are tools. Use them. Technology changes, embrace that.

Re:like Netscape FastTrack & LiveScript in '96 (0)

Anonymous Coward | more than 2 years ago | (#36245494)

The desktop computer hasn't changed much in the past 30 years. I mean, we still have a keyboard, a monitor, and some little collection of copper and silicon connecting the two and it still uses the same ol' electricity. Sure the operating systems have changed, the applications have changed, the keyboard might be virtual, the monitor might be 3 inches tall, and you might be using 5 different computers throughout the day for so many different/diverse tasks that your life is rather different from what it would have been 30 years ago. But it's still just superficial changes, we're still talking about the same system.

</rant> Yeah maybe a bit over the top there. I actually agree with you to some extent, but then most every advance in technology just comes at incremental steps. It's not like Swan/Edison/Others went from the light bulb to the iPad over a fortnight. And sometimes some overlooked technology which wasn't up to the challenge 10~15 years ago could suddenly be useful in the more modern Web X.0 era.

Maybe it's not a whole new wheel, but the fancy round shape has worked pretty well for us for a while.

Err, did I just compare the buzz of server-side Javascript with the jump from incandescent light bulbs to tablet computers? I apologize. I did not get enough sleep last night, and my AC died this morning so it is ridiculously hot in my house right now.

Re:like Netscape FastTrack & LiveScript in '96 (0)

Anonymous Coward | more than 2 years ago | (#36243658)

You must not remember anything from having read about it, given that the first line of TFA is "in 1996 ... Netscape took its shiny, new JavaScript language from the browser and stuck it in the Netscape Enterprise HTTP server."

Re:like Netscape FastTrack & LiveScript in '96 (1)

badboy_tw2002 (524611) | more than 2 years ago | (#36243682)

We do remember it. Probably because it was the first line of the article.

Re:like Netscape FastTrack & LiveScript in '96 (1)

shutdown -p now (807394) | more than 2 years ago | (#36243752)

history seems to repeat itself...

This [habreffect.ru] .

Don't worry - I'm pretty sure that, 10 years down the line, they'll be touting the addition of static typing to JavaScript as the next big thing to improve productivity etc.

Re:like Netscape FastTrack & LiveScript in '96 (1)

Transfinite (1684592) | more than 2 years ago | (#36244112)

What like when they added closure support for Java. Yawn!

Re:like Netscape FastTrack & LiveScript in '96 (1)

JonySuede (1908576) | more than 3 years ago | (#36246696)

they are supposed to add statically typed closure you insensitive claud !

Re:like Netscape FastTrack & LiveScript in '96 (1)

Transfinite (1684592) | more than 2 years ago | (#36243816)

Not really. 15 years is a long time in technology.

Re:like Netscape FastTrack & LiveScript in '96 (1)

sproketboy (608031) | more than 2 years ago | (#36244460)

Yup mod parent up.

Re:like Netscape FastTrack & LiveScript in '96 (1)

icebraining (1313345) | more than 2 years ago | (#36245060)

You could use JScript in ASP too. Thankfully I never had to.

Re:like Netscape FastTrack & LiveScript in '96 (1)

GreyLurk (35139) | more than 2 years ago | (#36245268)

Ah,

It meant I didn't have to bother learning VB in order to write ASP Pages, and it looked a lot closer to the PHP, C and Java I was used to writing.

Re:like Netscape FastTrack & LiveScript in '96 (1)

GreyLurk (35139) | more than 2 years ago | (#36245276)

Err... <%@ Language=Javascript%>

Re:like Netscape FastTrack & LiveScript in '96 (0)

Anonymous Coward | more than 2 years ago | (#36245314)

"They'll come back. Technology is cyclical"
-- The beeper king

Callbacks and Promises (1)

otakuj462 (1071510) | more than 2 years ago | (#36243662)

"I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage," Robinson said. "Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform." What's next for him? He sees the older framework being rethought and reworked using the best ideas from Node.js. In place of callbacks, he sees ideas like "promises," "co-routines," "actors," and other objects that hang on to the information in the variables for use later. These objects may be easier to juggle than the callbacks.

Callbacks and promises are not mutually exclusive. In particular, a promise API can be built on top of callbacks. This has been well-understood for a long time in both the Ajax world (e.g. dojo.Deferred [dojotoolkit.org] ), and in Node.js development (e.g. node-promise [github.com] module by Kris Zyp). So, I think this critique is a bit unwarranted.

Re:Callbacks and Promises (1)

shutdown -p now (807394) | more than 2 years ago | (#36243840)

Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version, with marker keywords to identify "points of asynchrony" (where the rest of the code path is an implicit continuation, and a closure is generated for it under the hood). Kinda like this [msdn.com] in the (yet upcoming) C# 5.0.

Good thing is that there is a proposal [ecmascript.org] for this feature for the next major EcmaScript version. Hopefully it'll end up in the spec.

Re:Callbacks and Promises (1)

Animats (122034) | more than 2 years ago | (#36244568)

Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version,

There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.

There's something to be said for this. I've written hard real-time code and OS internals code where timing really mattered and concurrency was crucial. But the typical web developer doesn't do anything that tough. Nor should they. They need an environment which doesn't have potential race conditions.

(Misery is writing for a callback environment without continuations, like background code for the original MacOS. With continuations, it works much better.)

Re:Callbacks and Promises (1)

shutdown -p now (807394) | more than 2 years ago | (#36245654)

There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.

I thought that's an established wisdom by now? I mean, that's why most server-side frameworks are embracing the continuation model (and most of current JS-on-the-server hype is more about such frameworks, which just happen to be written in JS). You still have code running concurrently there, though - the point is to get it running into much smaller chunks, such that, as soon as one task blocks on something, the thread can be immediately reused for another task.

It's more than just supporting high load, though. It's also a way to get responsive UI. If all potentially blocking platform API calls are removed, and only async-callback versions of those are provided (e.g. no open() or read(), but only open_async() and read_async() etc), it forces the programmer into a model where any lengthy task he is performing can be pre-empted by UI to paint or respond to user actions - but without the need for the programmer himself to explicitly spin off background threads, and do cross-thread synchronization (indeed, his code still runs entirely on the same single main thread! - just interleaved with UI).

Node.js user here... (0)

Anonymous Coward | more than 2 years ago | (#36243690)

There is definitely a "fanboy" mentality among Node.js programmers, which is really irritating.

I use Node.js to create command-line scripts, similar to bash scripts. It's great! The secret is to install the Fibers package, which can help turn all those annoying asynchronous Node.js calls into synchronous calls.

Asynch is great for building web servers... not so much when you just want to run a script from top to bottom, and don't care about blocking the thread.

Also, you'll notice that if you use Node.js for web application development, you will be tabbing over quite a bit as the asynch functions are nested inside each other.

JavaScript is a nice language (0)

Anonymous Coward | more than 2 years ago | (#36243782)

But there's something just worrisome in my mind to be using dynamic typed functional languages. I get bugged out by Python and JavaScript because they offer too much flexibility. Try debugging lower levels of SproutCore without mountains of headaches. I'm going to plug Scala, just because the contract for functions is clearer than in Python or Javascript.

V8 :( (1)

StripedCow (776465) | more than 2 years ago | (#36243876)

Too bad that chrome's V8 javascript engine does not support multithreading, thereby making itself unsuitable for server-side scripting.

(Of course, you can run each script in a separate process, but that is way too expensive)

Re:V8 :( (1)

Guspaz (556486) | more than 3 years ago | (#36246334)

PHP doesn't properly support multithreading. It must also be unsuitable for server-side scripting. And because running each script in a separate process is way too expensive, nobody would ever try to use something like mpm_prefork or fastcgi to get around that limitation. That'd be silly.

Re:V8 :( (0)

Anonymous Coward | more than 3 years ago | (#36247464)

"A Computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox

Ouch (1)

StripedCow (776465) | more than 2 years ago | (#36243962)

It seems the author of the article knows little about how real servers use multithreading to reduce latency.

From the article:

Node.js is one good solution. It uses only one thread for your server and everything runs within it. When the requests come flying in, Node.js takes them one at a time and hands them to the single function that was specified when the server is invoked.

Sadly, one of the best javascript engines is V8 (used in google chrome), and it does not support multithreading.

Re:Ouch (1)

ChunderDownunder (709234) | more than 2 years ago | (#36245436)

one of the supposed benefits of stateless monadic code is that it is somewhat more parallelizable than traditional imperative or stateful OO paradigms.
Could 'clean' js be marked with annotations and magically threaded behind the scenes by the javascript runtime?

(above is hearsay - i am not a functional programmer)

ASP (0)

Anonymous Coward | more than 2 years ago | (#36244564)

so someone has re-invented ASP (with Jscript) and its now cool?

Server side ActionScript ? (1)

cr_nucleus (518205) | more than 2 years ago | (#36244742)

I've been intrigued by this whole serverside js thing since i started doing a lot of flex and therefore using actionscript a lot.
Callbacks are so cool :)

But thing is js is still a mess if you have a lot of code.
What we really need is server side actionscript to get proper OO syntax, strong typing and namespaces.

If i ever got that, i'd be a happy camper !

Re:Server side ActionScript ? (1)

GreyLurk (35139) | more than 2 years ago | (#36245326)

Adobe showed off a demo of this at MAX 2009, so I suspect that they're going to be pushing for it at some point in the near future. AS is annoying though, when you have to switch between AS and C# or Java, and muscle memory throws your type declarations into the wrong syntax.

Clarification Needed (1)

Nexzus (673421) | more than 2 years ago | (#36245398)

I'm about 8 years out of date on my web development, but can someone give me a quick rundown on the subject of the article vs. what I know as server side javascript, aka ASP classic?

Node.js is fast, BUT... (0)

Anonymous Coward | more than 3 years ago | (#36246608)

Unless it's been updated recently it's still single threaded. So, if you have a multicore server - as I'm sure most do, it'll only be using 1 of those cores in its single thread. Of course you could fire up 4 instances for a 4-core machine, but then the threads can't communicate, so you lose one of its advantages (being ideal for chat/game servers, or anything that uses real-time message passing between clients.)

On my own dev server - (Core 2 Quad, 2.5ghz, 4GB, RAID) Node.js can handle around 8000 requests per second, when just outputting a simple text message. In comparison, PHP can handle around 12,000 requests per second to return the same text. However, PHP/Apache is using all 4 cores for this, and Node.js just 1. So it's doing over half the work with 1/4 the resources. The tests were conducted using ab with 100 concurrent requests.

I can definitely see a case being made for using Node.js to handle AJAX requests from a page served via Apache (or some other webserver.) It seems absolutely ideal for this - also for a site offering realtime chat, since at worst it will only take up a single core, and not cause too many problems with the rest of a site.

Re:Node.js is fast, BUT... (0)

Anonymous Coward | more than 3 years ago | (#36246680)

Ok I'm tired - I meant HTML, not PHP there. A flat HTML page was being served at 12,000 requests per second. PHP manages only 400 requests per second (single echo statement)

Re:Node.js is fast, BUT... (1)

dodobh (65811) | more than 3 years ago | (#36247494)

You can't make method calls. You can communicate via explicit message passing, like a Unix pipeline. That's why we have bidirectional sockets.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?