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

Experimenting with Node.js

jeffkreeftmeijer.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Experimenting with Node.js

#81

Post by c00p3r »

_urga wrote: post #78
c00p3r wrote: post #70

Earlier quoted context omitted.

Good points, thank you! The problem is that they do not even understand that it is ridiculous to compare someone's hobby-project (actually a bunch of hacks - just read the source) and well-designed (all papers are available) battle-tested and widely used in telecoms (not in browsers) solution. ^_^ So, you're right - "It is Javascript". Same as for Clojure "It is JVM!"

You may be surprised. Hobby projects have a knack for turning out to be more interesting than not.

I know. Look at nginx.

It is actually not just a hobby, it was sponsored and actively used by it's author's employer - Rambler.

Re: Experimenting with Node.js

#82

Post by _urga »

allertonm wrote: post #80
_urga wrote: post #79

Earlier quoted context omitted.

Firstly, most web applications to date do not: 1. Work offline. 2. Provide sub-20ms interface switching response rates. 3. Protect the interface against extended network or server failure. 4. Buffer against poor network performance. So I would agree with you that they have "managed to do without it" (code-sharing) so far. But they have done so only by avoiding responsibility for these goals, by considering them a con…

I simply do not see why your goals 1-4 require a) the same language on the server as the client and b) the use of a non-blocking I/O model at the server. It appears to be a leap of faith on your part. While marshalling of model objects to JSON is obviously going to be easier to achieve if your model objects are Javascript objects, marshalling to JSON is trivially achieveable in almost all programming languages. To su…

Re: "I simply do not see why your goals 1-4 require a) the same language on the server as the client"

Have you ever done 1-4?

Re: "marshalling to JSON is trivially achieveable in almost all programming languages"

Code sharing and JSON serialization/deserialization are not the same thing.

Re: "To suggest that developers should - to achieve this microscopic payoff - choose to build servers using a language with a crippled concurrency model (i.e none) is laughable."

Ships will sail around the Earth but the Flat Earth Society will continue to flourish.

Re: Experimenting with Node.js

#83

Post by spc476 »

silentbicycle wrote: post #72
spc476 wrote: post #64

Earlier quoted context omitted.

Really? I recently wrote a framework to do networking with Lua. The network code itself is event based, but each TCP connection is handled by a Lua coroutine which makes it easy to write straightforward code such as: function main(socket) io.stdout:write("connection from " .. tostring(socket)) while(true) local cmd = string.upper(socket:read()) if cmd == "SHOW" then socket:write("show me some stuff\n") elseif cmd ==…

Rather than socket:sleep(), you probably want to use socket.select to multiplex IO. (I'm assuming you're using LuaSocket, though that's not entirely clear.) As with select(2) in general, this doesn't scale up past 100ish idle sockets - it has to do a full scan over all sockets to check which are ready for IO, and the latency eventually dominates. (Not a big deal for most uses, but problematic for web applications.) I…

I'm not using LuaSocket but my own homegrown code based off epoll() (it was a learning experience in embedding Lua). It could probably be adapted to libev if I had the interest in doing so.

Re: Experimenting with Node.js

#85

Post by silentbicycle »

spc476 wrote: post #83
silentbicycle wrote: post #72

Earlier quoted context omitted.

Rather than socket:sleep(), you probably want to use socket.select to multiplex IO. (I'm assuming you're using LuaSocket, though that's not entirely clear.) As with select(2) in general, this doesn't scale up past 100ish idle sockets - it has to do a full scan over all sockets to check which are ready for IO, and the latency eventually dominates. (Not a big deal for most uses, but problematic for web applications.) I…

I'm not using LuaSocket but my own homegrown code based off epoll() (it was a learning experience in embedding Lua). It could probably be adapted to libev if I had the interest in doing so.

Ok. What you wrote would adapt to select and nonblocking sockets in LuaSocket pretty easily, FWIW. Using epoll / kqueue (directly or via libev/libevent) scales better, but you're blocking on the sleep, so it wouldn't matter.

Re: Experimenting with Node.js

#86

Post by IsaacSchlueter »

jamwt wrote: post #50
IsaacSchlueter wrote: post #44

Earlier quoted context omitted.

I've heard this before. "Oh, callbacks are fine for little things like this hello world demo, but for Big Programs, you need (threads/coroutines/etc.) because they're Serious Business." That might be true. Maybe for Big Programs, something else is better. But I think the problem is that setting out to build a Big Program for Serious Business is Doing It Wrong. The best frameworks (or, at least, my favorite frameworks…

I don't know how to completely address your post b/c it responds to assertions I didn't make. I said nothing about "Serious Business"--and bundling threads and coroutines together is like bundling horseshoes and bicycles. I made no defense of threads. Callback style, within an I/O handler, is (almost always) a concession to the event loop. When I'm writing a program, I write: routine(): result = do_one_thing() do_nex…

Why not something like this?

    function routine () {
      doIOForMe(function (resp) {
        doMoreIO(resp, function (nextResp) {
          transform(nextResp)
        })
      })
    }
    
    // or with a little helper function:
    
    function routine () {
      chainTogether
        ( doIOForMe
        , doMoreIO
        , transform
        )
    }
The "Step" library from Tim Caswell (creationix) lets you do a LOT of very interesting parallel/serial stuff. In npm, I have a few helper functions that make it easy to do serial "this then that" stuff.

It would be nice to have something in the language that does this. Maybe something for the Coffeescript guys to check out. For me, plain old JavaScript is enough, I guess.

Re: Experimenting with Node.js

#87

Post by nhnifong »

jkreeftmeijer wrote: post #20
nhnifong wrote: post #16

It a strange mix of disappointment and excitement to find out someone has just released a better finished version of what you were working on. Oh well, I guess I'll finish it anyways.

Please let me know when you finish it. I would love to see your code. :)

It has mutated quite a lot since I started... I'm taking the positions of everyone's mouse and feeding them to Fortune's sweep line algorithm to make Voronoi diagrams. I've made it look like you are a cell squeezing through layers of tissue. http://uncc.ath.cx/applets/Voronoi_Standalone/

Re: Experimenting with Node.js

#88

Post by lenary »

aslakhellesoy wrote: post #53
user24 wrote: post #52

Earlier quoted context omitted.

corporate firewalls blocking nonstandard ports, you running other apps on those ports, your firewall throwing a wobbly, general nonstandardness. if 80 is impractical, many people suggest running off 443 as that (the https port) is unlikely to be filtered.

It's not hard to serve both regular http requests and web socket requests on the port 80 on the same host. Just use a special context path for web socket requests, for example /websocket/* Some of the node.js websocket impls let you do this easily while others don't. Don't use the ones that require a separate port. Nobody behind a corporate firewall will be able to use your app if you do.

I think it is possible to have a ws server listening on the same port (and even path) as an http server, hence it shouldn't really matter.

And if you really care, you could make a http forwarding proxy with node to forward normal http requests through to your app if it's written in something else, but deal with websockets itself.

Post reply on HN