Fogus: Node.js should become its own language

http://blog.fogus.me/2011/04/12/node-js-is-dead-long-live-node/

by evjan • 15 years ago

83 73 15 years ago

blog.fogus.me

I'm all for a new version of Javascript that eliminates the junk and keeps just the "Good Parts", but I'm averse to anything that serves to abstract away the bad parts by building a subset of functionality on top of the existing version javascript for a niche application (server framework in this case, other cases include cappuccino for UI, coffeescript for...everything? etc.)

The Javascript that can be used only via add-ons is not the eternal Javascript...

KeithMajhor5• 15 years ago

"My problem with Javascript has always been that expertise is defined more in terms of understanding its faults rather than its features."

That's mostly just true for browsers. Javascript itself has very few faults.

My biggest annoyances with the language are: Lack of lexical scope, no trailing commas and semicolon usage that differs from C.

I could complain all day about my annoyances with browsers (or just IE).

wladimir2• 15 years ago

My most common annoyance about Javascript is the lack of bound methods like in Python Ruby etc. When you specify callbacks, you always have to provide the value of 'this' as well. If you forget, it's basically random and you're in for some heavy debugging.

Cushman4• 15 years ago

You should also try CoffeeScript.

  dosomethingasync =>
      #etc

will automagically bind the closure to the current value of this.

demallien2• 15 years ago

'this' is evil in Javascript. The very first line in any constructor function that I write is: var that = this;

From then on, I use 'that' instead of 'this', relying on closure magic to make things work. You never have to worry about how the function is bound thereafter.

pygy_• 15 years ago

Except that Javascript has lexical scope. Use the var keyword to define local variables.

    foo = function(){
        var bar=0
        return function(){
            bar=bar+1
            return bar
        }
    }
    baz=foo()

    baz() // => 1
    baz() // => 2
    baz() // => 3
    bar;  // => ERROR: bar is not defined

udp3• 15 years ago

They're "hoisted" and only local to the function, though. I'd (personally) prefer it if it worked like C, and a variable was defined from the "var" statement until the next closing brace. Then you could have a variable local to one branch of an if statement, etc, without faking scopes by abusing closures (eg (function() { })(); ).

And nested loops that both use "i" would work.

KeithMajhor5• 15 years ago

Try this: for ( var i = 1; i < 10; ++i ) setTimeout( function( ) { alert( i ) }, i * 250 )

You might expect it to alert 1..2..3..etc. It actually alerts 10..10..10..etc.

swannodette• 15 years ago

> Javascript itself has very few faults

Having coded JavaScript professionally and enjoyed it thoroughly for 6+ years now, I respectfully degree. The Harmony project shows just how much work there is to be done to make JS more fun/practical to use day in and day out.

fogus2• 15 years ago

    Javascript itself has very few faults.

We disagree.

Signed,

Douglas Crockford, Jeremy Ashkenas, and Brendan Eich

KeithMajhor5• 15 years ago

Could you elaborate?

dionidium3• 15 years ago

I think maybe you mean to say that you wish JavaScript had block scope. Lexical scope, it has.

Cushman4• 15 years ago

Why would you write this: [long_io_operation with callback] When you can instead write this: [long_io_operation without callback]

Off the top of my head, I'd say because "var result = long_io_operation(req);" is not only not self-documenting but actively deceptive if long_io_operation is an asynchronous call.

I'm not sure I see what's to be gained by pretending closures don't exist.

fogus2• 15 years ago

It's not closures that I hope to avoid, but callbacks.

metabrew• 15 years ago

It's not deceptive if you have a preemptively multitasking runtime that you trust (like the Erlang VM); it's a much more natural way of writing code. Single-threaded, event-driven callback spaghetti makes code harder to read, and inherently means more code.

If someone took v8, added lightweight coroutines, and wrote a preemptive scheduler for it, I bet you could massively reduce the SLOC count for large node.js apps.

sovande3• 15 years ago

> It's not deceptive if you have a preemptively multitasking runtime that you trust

That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.

d0mine2• 15 years ago

Python's twisted library supports both styles:

  d = long_io_operation()
  d.addCallback(callback)
  d.addErrback(errback)

With defer.inlineCallbacks:

   try:
       result = yield long_io_operation()
       callback(result)  
   except Exception, e:
       errback(e)

It is not necessary to use functions in the second case.

cdavid2• 15 years ago

It is not that simple in real life, unfortunately. Even ignoring the fact that inlineCallbacks's overhead is significant, inlineCallback forces you to serialize things which may be run in parallel. If you do

    yield f1()
    yield f2()

You force f1 to finish before being able to start f2, which goes against the whole point of using something like twisted in the first place ! I have also noticed that inlineCallback screw up the traceback (e.g. http://twistedmatrix.com/trac/ticket/3622 - I still see this with twisted 10.0.0).

While I am no genius, I am a decent programmer, with quite a few years of experience in python, and I still can't read most non trivial async code in twisted with confidence. It is almost impossible IMO to get a clear idea of the codeflows and especially error flows to ensure error handling is done right. Error handling is already difficult as is, adding exception made it that much harder, but adding async makes it basically impossible except for Vulcans.

ericmoritz• 15 years ago

all I'm asking for with Javascript is a shorter function keyword. Let me have

dosomethingasync(f() { });

With a language so dependent on callbacks, anonymous function are so verbose.

Cushman4• 15 years ago

Try CoffeeScript.

  dosomethingasync ->
      #etc

balakk• 15 years ago

Is it ML week on HN? Sounds like everybody has got ML envy now..

hasenj2• 15 years ago

I prefer coffee-script. It also works in the browser.

http://jashkenas.github.com/coffee-script/

raganwald2• 15 years ago

The good news for fogus is that everyone who prefers CoffeeScript validates the idea that an alternative syntax is enough of a win to be worth the adoption headaches.

hasenj2• 15 years ago

It's not just syntax, but some semantics too.

Last expression in a function is returned. This includes assignment statements which are in fact expressions.

  foo = () ->
    a = bar()
    z = () ->
      if a
        b = fu()
      else
        b = kar()

Here, foo returns the function z, and z returns either fu() or kar() while assigning the value to b

One could argue this is just syntax but I think this way beyond the kind of thing that comes to mind when somebody thinks of "syntactic sugar".

irahul• 15 years ago

But whatever he is after have to be much more lucrative than writing coffeescript.

Apart from pleasant syntax, coffeescript also improves upon semantics where it can - this binding, lexical scoping etc etc. People are willing to adopt Coffeescript because it compiles to javascript, it has improved semantics and clean & mostly familiar syntax.

To sum it up, the inertia is small when moving from JS to cofffeescript. That doesn't look like the case with funode.

illamint• 15 years ago

Seriously, CoffeeScript is amazing. I've been working on a large client-side project in CoffeeScript for the past few weeks and every time I look at the resulting JS output I can't imagine having written it by hand; it's been a massive boon to my productivity. I wrote JavaScript for years before this and hated it at times, and now I can't ever imagine going back if given the choice.

messel• 15 years ago

CoffeeScript is much easier to read than javascript, that alone is a blessing. Admittedly I haven't used coffeescript much yet, I just cranked it up with nodemon a couple of weekends ago. I need a good starter coffeescript project that works on the backend with node, and the client side.

jarin• 15 years ago

It kind of says a lot about the language when you need to invent another language to make it safer and more enjoyable to use.

joelangeway• 15 years ago

My greatest hope is that the makers of node.js will continue to abstain from language changes. Some inconvenient syntax is a small price to pay for the confidence that node.js isn't going to get turned into another regurgitation of Java meets Perl by hordes of perfectly well meaning but unsatisfiable programmers who want everything to work like the things they know. I don't mean to insult the makers or users of other languages, just to highlight the distinction of Javascript.

moomin• 15 years ago

Don't get me wrong, this could end up being the best thing since sliced bread, but the advantage of closures is that a higher-order approach can work wonders. Just take a look at async.js.

For me, more interesting than a pure assault on callbacks would be to see if you could handle more asynchronous scenarios, using async.js as a baseline.

e.g. callback waterfall, callback when all children are finished, callback when any children are finished

randylahey• 15 years ago

I wish this was rated higher. I don't understand the fuss about "spaghetti code". Do all those people write spaghetti code in other languages? Because I see that not as a language failing but as sloppy programming.

What's so hard about this to get a sequential execution of functions/blocks, error'ing out on the first error:

    async.waterfall(
      [ function (callback) {
          // do thing 1
          callback();
        }
      , function (callback) {
          // do thing 2
          callback();
        }
      , function (callback) {
          // do thing 3
          callback();
        }
      ]
      , function (error) {
          if (error) {
            // ohnoes errors
          }

          // all done!
        }
      );

travisglines• 15 years ago

As someone who has spent the last six months coding in Node.js, I completely disagree with this notion.

One of my favorite advantages of Node is in fact that it is based on javascript. When building my application I can share code between client/sever side (string formatting methods for example) and don't need to do any mental context switching when it comes to languages. I've developed in javascript for years and all that I have learned doesn't go out the window here, all I need to do is learn how to use a few libraries.

The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks (people complaining about having to use callbacks and the spaghetti code messes they make), people remembering the past horrible browser implementations of it (where something would work/be fast in one browser and not another ... Internet Explorer I'm looking at you) and confusion over how prototypical languages work vs. standard OOP.

Callbacks aren't that bad and a few extra nesting levels shouldn't create chaos in your code. Since its based entirely off of one javascript implementation (V8) the cross browser stuff is gone. How it handles OOP is different, just watch these videos first and you'll be fine: http://www.yuiblog.com/blog/2007/01/24/video-crockford-tjpl/

As far as speed goes it gets huge benefits by being javascript. Every time the Google coding machine feels like making V8 a little faster, Node gets faster too.

Yes its different, no its not worse ... its better but takes some getting used to.

scott_s3• 15 years ago

I think the fundamental objection fogus has is that the language does not support the programming model. For example, I can program object-orientedly in C, but that language does not help me do it. I have to do much of the work myself. So you can program in JavaScript in an event-based way using Node.js, but JavaScript itself does not help you much in doing so. It requires that you do most of the work yourself - work that is mechanical, and basically requires that you be a human compiler.

Disclaimer: I don't program in JavaScript or Node.js. So I'm talking from conceptual understanding, not experience.

DTrejo2• 15 years ago

It requires that you do most of the work yourself - work that is mechanical, and basically requires that you be a human compiler.

It would be a good idea to write some JavaScript before you make statements like these with so much conviction.

dkersten3• 15 years ago

"The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks"

Maybe for a lot of people this is true, but for me the faults of javascript are ingrained language "features". Actually, I'm not the only one who thinks so, because theres a website dedicated to it[1].

[1] http://wtfjs.com/

dionidium3• 15 years ago

The latest example on that blog (from Feb. 5th) examines the unexpected effects of type coercion when using double-equals for comparison. That's fine, as far as it goes, but, like most of these examples, it's a WTF that experienced JavaScript developers know how to mitigate (triple-equals) and not that big of a problem in practice. I'm trying to think of a time that JavaScript's wacky coercion rules actually bit me and I can't.

DTrejo2• 15 years ago

Not sure why he uses this as a code sample, as it's also not how someone would write code (though I suppose he is entitled to his style).

The original from the article

  function do_request(req) {
    return long_io_operation(
    req, 
    callback=function(results) {
      return create_something_from(results);
    });
  }

How it might be written if you saw it in a codebase

  function do_request(req, callback) {
    long_io_operation(req, function(err, results) {
      callback(err, create_something_from(results));
    });
  }

It seems like the article is not finished, so I can understand that there might be questionable sections. Also you'll note that he forgot the `error, results` argument pattern for callbacks, making me think that he is not terribly familiar with node.

Fester• 15 years ago

Fix the language, then fix event processing approach, then spend 10 yeard maturing in the highly concurrent environments and end up being Erlang. w00t.

jerf4• 15 years ago

Since fogus is responding here: Other than hitching your wagon onto the fantastic hype storm that Node.js has generated, which I must say is a good move overall, reading your target description, why not start with Haskell or Erlang? You could start from there and mutate out but actually have a library base to start from. Or one of the languages sitting on top of Erlang like Reia. (Or discover that you don't need to mutate away after all.)

Starting from scratch is going to be difficult at this point; by the time you even have a half-decent stack you're going to be way behind.

(At the very least... you do realize this has been done and you don't have to start from scratch, right? Rather a lot of Node.js users have exactly the cognitive holes I'd expect from not knowing that Node.js is at best "keeping up", rather than being anything like cutting edge. And I'd say this style of programming was actually on its way to the dust heap of history before being brushed off and gotten a shiny new coat of paint sprayed on... it really doesn't work very well....)

MrMan3• 15 years ago

I will upvote you if you explain what you mean by the last part about "this style of programming" previously being on its (it's? anyone) way out. Do you mean an asynchronous style using callbacks?

jerf4• 15 years ago

Yes. Asynchronous style using callbacks has been done many, many, many times, and it really doesn't work very well. It does small things quickly, but have you noticed the number of complaints about how Node.js produces spaghetti code increasing lately, quietly and slowly but steadily? It's still buried under the hype, but expect it to get worse. And not "get worse before it gets better", just... get worse.

I laid it out more at http://news.ycombinator.com/item?id=2370303 .

Javascript doesn't particularly bring any abstraction capabilities to the table that Perl (POE, Event::Lib, IO::Async), Python (Twisted), or Ruby (EventMachine) doesn't, and current Javascript is actually deficient in the abstraction department by comparison. (The latest ECMAscript spec can compare to them, so Javascript will get there. Something like Python generators allow you to string together a couple more tricks together before the complexity becomes a problem, and Javascript will eventually have this.) They all result in programs that end up the same way. There are some tricks you can play that improve the situation a bit over raw callbacks, like trying to sequence them, but composing these tricks together gets harder and harder the fancier you get.

None of those libraries really took off and some of them I know had way more effort poured into them than Node.js has seen yet, like Twisted. And it's because the style, combined with language runtimes that can't manage the scheduling for you while retaining the code context, has certain inevitable results. You can (and should!) delay the inevitable, but it's still inevitable.

At the very least, I would suggest that if you going to consider using Node.js you should be aware of the fact that it's not a blindingly new thing, it's a relatively well-explored space being translated into a new language, and you can get a good sense of the tradeoffs from the many previous explorations of this space. There are still places where it may be the right choice; as I said in that other message, I have chosen event-based coding in another context because it was still the right choice. But I knew the tradeoffs going in, and took steps to mitigate them, rather than being blindsided by them.

nollidge• 15 years ago

> its (it's? anyone)

"way out" belongs to "it", so you're looking for the possessive form. English pronoun possessives do not use apostrophes (whose, mine, his, her, their, its), while everything else DOES (the dog's, Steve's, Portugal's, the crowd's).

tl;dr: it's "its".

kreek• 15 years ago

How about Node.as? Flash doesn't get much love these days but I've always thought ActionScript 3 would make a great server side language. It's more like other OOP languages, has an event model like JavaScript (sync or async), and doesn't have many of JS's idiosyncrasies.

Edit: http://haxe.org/ is based on AS3

jpravetz• 15 years ago

I agree. I had to go back from AS3 to AS2 for a project and it felt like a step backwards, and AS2 is more like Javascript. Adobe has also open sourced the AS3 runtime. But of course the practicality is that we have Javascript in browsers, and there's a big get-the-job-done benefit to using a common language.

faceplant• 15 years ago

AS3 is based on ECMAScript 4, which was expected to become the new standard many years ago but became a dead-end after the ECMAScript committee abandoned it. That's why there's no "4" anymore between ES3.5 and ES5... ActionScript is it.

MrMan3• 15 years ago

Take a look at this, I am sure it has been posted on HN before: http://beamjs.org/

This allows you to trade off all the cool speed of V8, but running node.js singlethreaded, for running on an alpha port of V8 for the Beam VM. If you want to sidestep the problems with Node.js, but keep the good parts, this might be a way forward. Additionally, JS on the Beam VM can seamlessly interact with any other Erlang code, so you get all kinds of other benefits that are erlangy.

Fogus: Node.js should become its own language

Related Stories