Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: It’s Not Just for Browsers Any More

pragprog.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: JavaScript: It’s Not Just for Browsers Any More

#41

Post by rapind »

mechanical_fish wrote: post #14
Ygor wrote: post #5

Why do we want javascript on the server side, when we already have so many other options? I'm not trying to imply something against this aproach, this really is a question.

Here's Yegge on the topic: http://steve-yegge.blogspot.com/2007/02/next-big-language.ht... ... though he doesn't explicitly say he's talking about Javascript, it's pretty likely that he's talking about Javascript. 1) It's got C-like syntax. 2) It's got the dynamic- and functional-language features that make people happy. 3) We're stuck with it no matter what. Changing the world's installed base of web browsers takes…

I have to completely disagree with IE 6 being the model for future browser upgrade timelines. That's a very limited data sample and the willingness to upgrade your browser is going to be significantly faster as time goes on.

IE6 continues to be a pain for sure, but the mindset behind this is changing as the web and it's users evolve.

Re: JavaScript: It’s Not Just for Browsers Any More

#42

Post by ryah »

jerf wrote: post #37
IgorPartola wrote: post #7

Earlier quoted context omitted.

It's a nice clean language that fits the event-driven paradigm better than most. When every function is an automatic closure, things are much easier.

I'm really at a loss as to how people seem to just swallow this claim without question. What's so special about Javascript's closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}? What's Node.js got over Twisted, POE, EventMachine, or every single thing ever written in Erlang? Most languages used in web development have closures. A large number of them have event-base…

Something that's different, at least from POE, EventMachine, Twisted is that it is attempting non-blocking purity. You can snub your nose at this but it turns out to be very important. It ends up abstracting away a problem in a way that EventMachine or Twisted will never be able to do simply because of the existence of massive amounts of blocking Ruby and Python libraries. The programmer simply doesn't have to know what non-blocking I/O is - they don't have to know that if they do "node script.js Erlang is different. Node presents a different programming model than Erlang - Node handles thousands of connections per process - and keeps itself close to the metal. Erlang is it's own operating system handling one connection per processes but allowing very many processes. Is Node's model better? Well at the moment it's incomparable since Erlang is very much a solid, production ready system and Node is not more than some dude's hack. But supposing that Node becomes stable and usable at some point, a major advantage of the Node model is that for the first 10,000-1,000,000 concurrent connections the programmer doesn't have to know anything about concurrency - a single process will just handle it. There is no forking or IPC - it's just synchronous events and callbacks. In Erlang you have to think about about IPC on the first connection. The Erlang-model might turn out to be the wrong level of process granularity. Maybe the right level of process granularity is how computers are already designed: 10,000-1,000,000 connections per process, use one per core.

I also wish for less hype around the Node project but I think you're short changing it by saying it's same thing as Twisted but in Javascript instead of Python. The main selling point is not that you can run the same code on browser and server. The main selling point is that you don't have to know what you're doing, at least for the first 10,000 concurrent connections.

Re: JavaScript: It’s Not Just for Browsers Any More

#43

Post by tumult »

CoreDumpling wrote: post #8
Ygor wrote: post #5

Why do we want javascript on the server side, when we already have so many other options? I'm not trying to imply something against this aproach, this really is a question.

Because it's actually a decent language when you take away the DOM cruft? It's actually remarkably similar to Scheme [1] with very flexible arrays and real first-class functions. [1] http://www.crockford.com/javascript/little.html

JavaScript programmers who have never used Scheme frequently repeat this patently false claim. Scheme has nothing in common with JavaScript other than that JavaScript has first-class functions.

Re: JavaScript: It’s Not Just for Browsers Any More

#44

Post by grayrest »

ryah wrote: post #42
jerf wrote: post #37

Earlier quoted context omitted.

I'm really at a loss as to how people seem to just swallow this claim without question. What's so special about Javascript's closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}? What's Node.js got over Twisted, POE, EventMachine, or every single thing ever written in Erlang? Most languages used in web development have closures. A large number of them have event-base…

Something that's different, at least from POE, EventMachine, Twisted is that it is attempting non-blocking purity. You can snub your nose at this but it turns out to be very important. It ends up abstracting away a problem in a way that EventMachine or Twisted will never be able to do simply because of the existence of massive amounts of blocking Ruby and Python libraries. The programmer simply doesn't have to know w…

> I also wish for less hype around the Node project

I'm tremendously amused that you write this when every other poster on HN is desperately trying to generate hype for their project/company.

Re: JavaScript: It’s Not Just for Browsers Any More

#45

Post by blasdel »

jerf wrote: post #37
IgorPartola wrote: post #7

Earlier quoted context omitted.

It's a nice clean language that fits the event-driven paradigm better than most. When every function is an automatic closure, things are much easier.

I'm really at a loss as to how people seem to just swallow this claim without question. What's so special about Javascript's closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}? What's Node.js got over Twisted, POE, EventMachine, or every single thing ever written in Erlang? Most languages used in web development have closures. A large number of them have event-base…

JS has three epic wins going for it, that cannot be matched together by another language:

  * A shitton of people are already using it on the daily
  * All of the existing code written in it is event-driven
  * It's got prototypical inheritance, and some people
    actually use it instead of bludgeoning in classicism

Re: JavaScript: It’s Not Just for Browsers Any More

#46

Post by blasdel »

tumult wrote: post #43
CoreDumpling wrote: post #8

Earlier quoted context omitted.

Because it's actually a decent language when you take away the DOM cruft? It's actually remarkably similar to Scheme [1] with very flexible arrays and real first-class functions. [1] http://www.crockford.com/javascript/little.html

JavaScript programmers who have never used Scheme frequently repeat this patently false claim. Scheme has nothing in common with JavaScript other than that JavaScript has first-class functions.

Eich's original LiveScript had sexpr reader syntax before the attack of the curly braces.

Re: JavaScript: It’s Not Just for Browsers Any More

#47

Post by blasdel »

scotty79 wrote: post #18

If I have: do_thing_A_and_after_that_call(function() { do_thing_B_and_after_that_call(something); } do_thing_C_and_after_that_call(function() { do_thing_D_and_after_that_call(something); } what should I do to execute some E after both B and D is finished? I think that non-blocking effectively means introducing easy syntax for parallel execution while complicating syntax for sequential execution. I think parallel and…

Sounds like someone's got a case of the monads!

Re: JavaScript: It’s Not Just for Browsers Any More

#48

Post by tumult »

blasdel wrote: post #46
tumult wrote: post #43

Earlier quoted context omitted.

JavaScript programmers who have never used Scheme frequently repeat this patently false claim. Scheme has nothing in common with JavaScript other than that JavaScript has first-class functions.

Eich's original LiveScript had sexpr reader syntax before the attack of the curly braces.

Eich's original LiveScript.

We have something else, JavaScript. It does not have sexprs. It doesn't have continuations. It doesn't have tail call optimization. It has mutable array operations, but immutable string operations (got it backwards.) There are no macros, hygienic or otherwise.

The only thing it has in common with Scheme are first-class functions. If you want anything else, you must implement it yourself out of the Turing Tarpit, and it will perform badly, because optimizing JavaScript is difficult due to its mistaken specification.

By any of these metrics, Python, Ruby, Perl, and C# all have more in common with Scheme than JavaScript. I think the people claiming 'JavaScript is like Scheme but with a different syntax' are mistaken from lack of experience.

Re: JavaScript: It’s Not Just for Browsers Any More

#49

Post by rictic »

Periodic wrote: post #25
scotty79 wrote: post #18

If I have: do_thing_A_and_after_that_call(function() { do_thing_B_and_after_that_call(something); } do_thing_C_and_after_that_call(function() { do_thing_D_and_after_that_call(something); } what should I do to execute some E after both B and D is finished? I think that non-blocking effectively means introducing easy syntax for parallel execution while complicating syntax for sequential execution. I think parallel and…

If A, B, C, and D truly are asynchronous then I believe you're going to need condition variables and (at a lower level) locks. I agree that such syntax should be baked in and handled at a lower level. If you can guarantee that a given variable can only be modified by one process at a time, it is easy to do something to take care of this for individual processes, and wouldn't be hard to generalize. (note, I was last u…

Nope, no locks needed in Node. This is one of the little joys of javascript: no threading at all. None. With Web Workers you can have processes, but there isn't shared state; everything is done through message passing.

All parallelism is cooperative in javascript, meaning that you don't have to worry about control flow switching out from under you at arbitrary points, just when you explicitly yield it by returning from an event handler or from the top level of your program.

Finally, to answer the grandparent question, the easiest answer is a promise group. A promise group is basically a promise that emits a success event once all of its child promises have emitted success events. There are a few implementations floating around, though it's just a handful of lines of code to write and makes for a good exercise.

So assuming that A and B are rewritten to return promises (or wrapped, I believe that isaacs has a library which will wrap functions which take a callback to return a promise instead), you can do the following:

    var promise_a = do_A();
    promise_a.onSuccess(do_C);
    var promise_b = do_B();
    promise_b.onSuccess(do_D);

    var promise_group = new PromiseGroup([promise_a, promise_b]);
    promise_group.onSuccess(do_E);

Re: JavaScript: It’s Not Just for Browsers Any More

#50

Post by krainboltgreene »

mechanical_fish wrote: post #14
Ygor wrote: post #5

Why do we want javascript on the server side, when we already have so many other options? I'm not trying to imply something against this aproach, this really is a question.

Here's Yegge on the topic: http://steve-yegge.blogspot.com/2007/02/next-big-language.ht... ... though he doesn't explicitly say he's talking about Javascript, it's pretty likely that he's talking about Javascript. 1) It's got C-like syntax. 2) It's got the dynamic- and functional-language features that make people happy. 3) We're stuck with it no matter what. Changing the world's installed base of web browsers takes…

When was "C-Like Syntax" ever a good reason? I want something I can read naturally, like Ruby or Python.
Post reply on HN