JavaScript: It’s Not Just for Browsers Any More • Hacker News Board

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

#21

Post by qjz » Fri, Mar 05, 2010, 8:47 PM UTC

fnid2 wrote: post #12

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.

For me it is about consistency. With javascript on the client and the server, it's easier to write code once and move it around. Compared to having to write perl, java, php, whatever on the server side and javascript on the front. It reduces the learning curve for new developers because they only have to learn javascript, not javascript plus something else.

Innocent question: Won't the server and client side code tend to be so different, they'll appear to be mutually exclusive? I understand that you're referring to basic concepts and syntax, but surely a lot of server side code simply won't execute in a browser's sandbox, correct?

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

#22

Post by zokier » Fri, Mar 05, 2010, 8:54 PM UTC

OpenJS-project http://www.openjs.org/> might be of interest to HN peeps too.

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

#23

Post by Periodic » Fri, Mar 05, 2010, 9:00 PM UTC

IgorPartola wrote: post #7

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.

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 still remember when Javascript was a fairly ugly language that felt like the PHP of client-side programming.

I revisited Javascript a few years ago and I was pleasantly surprised. It's come a long way, and it does make event-based programming easy.

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

#24

Post by allertonm » Fri, Mar 05, 2010, 9:07 PM UTC

swilliams wrote: post #19

mechanical_fish wrote: post #14

Earlier quoted context omitted.

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…

In a talk Yegge gave some time later he did confirm that he was talking about JavaScript. http://vodpod.com/watch/395703-steve-yegge-at-oscon-2007 (at the very end, "NBL is JavaScript 2")

Of course, the language that is now called Javascript 2 is not the same language that Yegge was referring to.

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

#25

Post by Periodic » Fri, Mar 05, 2010, 9:09 PM UTC

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 using prototype.js, and my javascript is a bit rusty)

    wait_list = [];

    function wait_for(entry) {
        wait_list.push(entry);
    };

    function done(entry) {
        wait_list.splice(wait_list.indexOf(entry), 1);
        
        if (wait_list.length == 0) {
            do_C();
        }
    };

    function do_A () {
        wait_for("A");
        // do stuff
        done("A");
    };
    function do_B () {
        wait_for("B");
        // do stuff
        done("B");
    };

    function do_C () {
        // Stuff that comes after A and B
    };

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

#26

Post by hugs » Fri, Mar 05, 2010, 9:21 PM UTC

fizx wrote: post #20

node.js + coffeescript is the new sexy! It's going to kill my weekend :)

Agreed! (It's already killed a few weekends for me. :-) CoffeeScript has "Most Favored Executable" status in my terminal window these days. On a related side-note... here's the "Hello World" Node.js web server ported to CoffeeScript: http://github.com/jashkenas/coffee-script/blob/master/exampl...

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

#27

Post by mbrubeck » Fri, Mar 05, 2010, 9:50 PM UTC

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…

There are a number of libraries that provide useful utilities for controlling parallel execution in JavaScript. Here's one nice one for Node.js: http://github.com/creationix/do

And two more that aren't Node-specific:

http://www.cs.umd.edu/projects/PL/arrowlets/index.xhtml

http://www.croczilla.com/oni

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

#28

Post by Esspe » Fri, Mar 05, 2010, 9:55 PM UTC

qjz wrote: post #21

fnid2 wrote: post #12

Earlier quoted context omitted.

For me it is about consistency. With javascript on the client and the server, it's easier to write code once and move it around. Compared to having to write perl, java, php, whatever on the server side and javascript on the front. It reduces the learning curve for new developers because they only have to learn javascript, not javascript plus something else.

Innocent question: Won't the server and client side code tend to be so different, they'll appear to be mutually exclusive? I understand that you're referring to basic concepts and syntax, but surely a lot of server side code simply won't execute in a browser's sandbox, correct?

When writing code for both client and server, it's difficult to mentally "switch". E.g. after writing some code in client, I'm starting placing curly braces in python's code :)

It would be nice to write both client and server in one language.

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

#29

Post by john_lewin » Fri, Mar 05, 2010, 10:14 PM UTC

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.

Good question. As a server programming language its newish, and all the growing pains (bugs, security holes, standardizations of processes, training documentation) have yet to be realized. Meanwhile mature languages are pushing the envelope in distributed and multi-core programming ...

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

#30

Post by raganwald » Fri, Mar 05, 2010, 10:54 PM UTC

fnid2 wrote: post #12

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.

For me it is about consistency. With javascript on the client and the server, it's easier to write code once and move it around. Compared to having to write perl, java, php, whatever on the server side and javascript on the front. It reduces the learning curve for new developers because they only have to learn javascript, not javascript plus something else.

I run into this all the time. The most common case is form validation. If you want to do some validation on the client side, why are you forced to repeat yourself by writing it once in Java/Ruby/Python/Perl/PHP on the server and then write it again on the client using Javascript/Underscore/JQuery/whatever?

http://github.com/raganwald/homoiconic/blob/master/2010/02/d...