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

71–80 of 88 posts

Re: Experimenting with Node.js

#71

Post by frognibble »

creationix wrote: post #54
jamwt wrote: post #48

Earlier quoted context omitted.

I think javascript is a fine little language. But: I don't make my server-side language decisions based on what happens to be in the browser. To think that a language required for use in such a constrained environment is just _coincidentally_ also the best language to use server-side where people have been doing event-based programming for decades seems... unlikely. It would be as ridiculous as asserting that we shou…

I never said JavaScript is best language to use server-side. That would be insane. I'm just saying that it worked well for the browser (mostly because it was forced on us, but still) and node is an experiment to try the same thing on the server. It's a lot better than writing C, (which is what Ryan was doing before starting node) since JS has closures, anonymous functions and other functional niceties that make event…

Javascript might not even be the best language for the browser. The browser programming model was set in stone years before significant applications were built in the browser. If we had a choice about the browser programming model, then it seems likely that better programming models would have emerged based on the experience.

Re: Experimenting with Node.js

#72

Post by silentbicycle »

spc476 wrote: post #64
tdmackey wrote: post #34

Earlier quoted context omitted.

Coroutines bring their own headaches and baggage. To say that callbacks are behind "state of the art" is a little misplaced,; its just a different way of doing things. With coroutines you have to worry about IO all over the place and have to make your functions coroutine safe and Ryan Dahl, the node.js creator, will argue with you all day long about coroutines vs callbacks. I do agree, though, that developers should…

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.) If that's not an issue, though, it's quite easy. Lua is very underrated, IMHO.

I'm working on a Lua library (octafish) for doing libev + coroutine and/or callback-based servers. It's been on the back burner for a bit, though - a couple other projects have been crowding it out. I'll put it on github once it's further along.

Re: Experimenting with Node.js

#73

Post by silentbicycle »

gcampbell wrote: post #60
folletto wrote: post #37

Earlier quoted context omitted.

Programmer-mentality is somewhat different from other mentalities, but it's still bound to simplicity laws. The technologies you are describing were already there, but it's not just a problem of technology, feature set or execution power. It's also a matter of simplicity. Node.js is working because it gives so much power with a very simple approach. And by approach I mean also how much is simple to understand it and…

How many steps you need to install Erlang on your machine: "sudo apt-get install erlang"?

First off, is everyone running your Linux distro? ("sudo pkg_add erlang" works for me, though.)

Besides, are you seriously implying that the hard part of getting started with Erlang is installing it? A lot of developers aren't willing to sink time into learning a language that actually has new ideas, you know? Hell, it's not even OO. :)

Re: Experimenting with Node.js

#74

Post by ralph »

rictic wrote: post #59
jamwt wrote: post #50

Earlier quoted context omitted.

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…

Could you be a bit clearer about what's going on in your third example?

I think he's saying that the main event loop has called a callback, only to have that callback either call the main event loop, or something similar that processes events until a certain condition, and that in turn may cause other callbacks to be called. Stack depth has increased. And it tends to lead to bugs because sometimes unconsidered things happen in the midst of the first callback's processing.

Re: Experimenting with Node.js

#75

Post by alec »

_urga wrote: post #41
icey wrote: post #30

Earlier quoted context omitted.

I think developers get attracted to frameworks because of fun examples like the one linked in the posting. Until there are multitudes of interesting examples using other tech, I think it's going to be an uphill battle to attract significant numbers of developers to them. Since many of the Node.js demos like this one are open-source it's much easier for developers to download working code and make modifications to see…

Re: "The technically superior solutions often get overlooked for the most accessible ones." Are there any server-side Javascript environments being overlooked? And would it be fair to say that these are technically superior to V8 + Node?

He's not talking about technically superior server-side Javascript environments, he's talking about langauges and frameworks that provide more than just a callback model.

Re: Experimenting with Node.js

#76

Post by _urga »

jamwt wrote: post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

I agree with you that a synchronous programming interface is easier than an asynchronous programming interface.

However, none of the systems you suggest make it possible to write code that can be run by both the server and the browser.

If you were writing web applications, which represent the typical use-case for Node, then this would be a prerequisite.

Re: Experimenting with Node.js

#77

Post by allertonm »

_urga wrote: post #76
jamwt wrote: post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

I agree with you that a synchronous programming interface is easier than an asynchronous programming interface. However, none of the systems you suggest make it possible to write code that can be run by both the server and the browser. If you were writing web applications, which represent the typical use-case for Node, then this would be a prerequisite.

It can hardly be a "prerequisite" given that most web applications built to date have managed to do without it.

It's a convenience, at least intuitively, but in practice one has to wonder what parts of your code run in both browser and server and do async I/O.

Re: Experimenting with Node.js

#78

Post by _urga »

c00p3r wrote: post #70
jerf wrote: post #61

Earlier quoted context omitted.

You need to try Erlang. (Or Haskell, but Erlang is more approachable.) You and every other Node.js partisan keep making criticisms that simply make it clear that you have no clue what you are criticizing and that doesn't make it terribly likely that you're going to sway me to your point of view. "With a callback-based system, stacks are short, and you explicitly carry that state. You KNOW what state you're storing, a…

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.

Re: Experimenting with Node.js

#79

Post by _urga »

allertonm wrote: post #77
_urga wrote: post #76

Earlier quoted context omitted.

I agree with you that a synchronous programming interface is easier than an asynchronous programming interface. However, none of the systems you suggest make it possible to write code that can be run by both the server and the browser. If you were writing web applications, which represent the typical use-case for Node, then this would be a prerequisite.

It can hardly be a "prerequisite" given that most web applications built to date have managed to do without it. It's a convenience, at least intuitively, but in practice one has to wonder what parts of your code run in both browser and server and do async I/O.

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 convenience, or by not considering them at all.

Secondly, I can tell you from experience that a non-Javascript server-side framework can do the above but only with difficulty. Existing popular frameworks do not provide "convention-over-configuration" assistance in terms of straddling the network or exposing Model definitions to Javascript etc. They render interfaces on the server-side, rather than letting controllers and views interact on the client for example. Indeed it would not even be fair to expect these frameworks to meet the above requirements, simply because they were not designed to do so.

Eventually one must arrive at a realization that web applications (as distinct from "web sites") will mostly be written in the same language AND framework on both client and server. Fear not, this will probably be more fun.

Re: Experimenting with Node.js

#80

Post by allertonm »

_urga wrote: post #79
allertonm wrote: post #77

Earlier quoted context omitted.

It can hardly be a "prerequisite" given that most web applications built to date have managed to do without it. It's a convenience, at least intuitively, but in practice one has to wonder what parts of your code run in both browser and server and do async I/O.

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 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.

Post reply on HN