5 ms·

One of these is not like the others: node.js is a nice, progressive step forward, not a leap that is discontinuous with what preceded it like WebGL and WebSocke

One of these is not like the others: node.js is a nice, progressive step forward, not a leap that is discontinuous with what preceded it like WebGL and WebSockets. And certainly, node.js did not enable this chat example to happen -- not in the same way that WebGL or WebSockets did. <rant>I am getting a little tired with the node.js cheerleading on HN. I've tried it and I don't see it as a huge leap forward from what can be done with Twisted + Python, or Go, or many other solutions. The major drawback is that you're writing in Javascript -- and maybe I have been doing something wrong, but any sufficiently complex JS app tends towards callback spaghetti, in my experience. (And I do like writing JS)</rant>

deleted 16y ago
[deleted]
- jessedhillon 16y ago
  > You could have done with AJAX what WebSockets does If you consider long-polling (the nearest approximation you can do with AJAX) the same as true bi-directional communication.
  - deleted 16y ago
    [deleted]
    - jessedhillon 16y ago
      Please show me how a server can send two consecutive messages to a long-polling client without requiring the client to make a request between the receipt of message 1 and message 2.
      - deleted 16y ago
        [deleted]
      - deleted 16y ago
        [deleted]
      - weixiyen 16y ago
        I'm not sure what you are replying to as it's been redacted, but just wanted to say that there's really nothing wrong with that technique. Developers tend to way overestimate the cost of a long polling request with minimal headers. Also the speed benefit of websockets over long polling is so trivial that it doesn't really matter.
        ericflo 16y ago
        I could not agree more with this comment.
        jessedhillon 16y ago
        A couple of posts were deleted on this thread, perhaps because the authors realized they were mistaken. The claim was that long-polling and WebSockets are bi-directional in the same sense, and mine was that one type of bi-directionality is simulated and has real limitations. It doesn't matter if the overhead is low: with long-polling, the server can't send a waiting message until the client requests them. With true sockets, the server can send messages as soon as they are available.
sthatipamala 16y ago
People are "cheerleading" node.js because they tried it, successfully built something with it and want to give proper credit to their stack. The existence/prevalence of node.js submissions does not imply that anyone thinks it any more technologically capable than Twisted, Go, Tornado, or eventlet. Node.js just happens to be simpler to install, have more easily accessible documentation and has more of a network effect going for it.
- jessedhillon 16y ago
  My point is that the proliferation of HN posts regarding node.js is not reflective or driven by a host of new and significant improvements that it brings to the table. I suppose one response is this shouldn't be surprising, since anything implemented after the 70s could have been done with C instead of language X. But my complaint is that it seems a lot of attention is paid to projects which are not actually doing new things with node.js, just things that have already been done with other technologies. Actually, this comment sums it up much better than my comment: http://news.ycombinator.com/item?id=1549023 http://news.ycombinator.com/item?id=1549023
  - slewis 16y ago
    I'd argue that being in javascript is an advantage rather than a disadvantage. Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser. I'm not saying javascript is the king of languages, just that we're limited to it because that's what's in the browser, and writing server code in the same language simplifies things.
    - udoprog 16y ago
      Server side logic is usually radically different. And given that you usually share information between the server and the client in a language agnostic manner (e.g. JSON) and that the client (browser) cannot be trusted with other than view logic, I see few cases where implementation specific code sharing contributes greatly. The server and the client has such different concerns that code sharing probably wouldn't contribute that much.
bambax 16y ago
I use node.js for batch processing: it's just fantastic. Instead of ugly bash scripts that are absolutely unreadable and therefore unmaintainable, I get to write beautiful Javascript and lightning fast JSON processing and transformation. This is an area where node.js really shines and that is not often mentioned. As for client-server development, I think the future is going back to the client. Instead of "dumb clients", what we have now are extremely powerful and fast clients. It's much cheaper to send raw data to the client and compute it there, since as a web developer you pay for server CPU, but not for client CPU. (Of course, it's a little wasteful since the computation happens many times instead of one; but you can always send the results back to the server for caching, if that worries you).
- masklinn 16y ago
  > I use node.js for batch processing: it's just fantastic. Instead of ugly bash scripts that are absolutely unreadable and therefore unmaintainable I am confused: if you don't like bash scripts why in science's sake did you keep using them instead of one of the billion alternatives out there? > This is an area where node.js really shines and that is not often mentioned. Because it's nonsensical. What makes node.js "shine" more at batch processing more than every other language on the planet?
  - bambax 16y ago
    > What makes node.js "shine" more at batch processing more than every other language on the planet? Because every other language on the planet is not Javascript...? - - - Edit: maybe I should clarify? The only other solution (that I know of) to write Javascript for the server is Helma; I've tried it and it kind of works but it's very clumsy. Is there another simple way to write JS on a Linux box? - - - Edit2: maybe I should not clarify.
- Fester 16y ago
  Node.js is great because bash is ugly. Way to go indeed.
weixiyen 16y ago
> but any sufficiently complex JS app tends towards callback spaghetti Callback spaghetti is quite easy to avoid. > and maybe I have been doing something wrong If you have callback spaghetti, regardless of the complexity of the app, you are most likely doing something wrong. > I don't see it as a huge leap forward from what can be done with Twisted + Python, or Go Of course not, but it's not hard to imagine that Node.js will have the biggest ecosystem in this space and with it comes advantages (and perhaps disadvantages).
- gambler 16y ago
  > Callback spaghetti is quite easy to avoid. That's what people say about most bad programming practices. "It's not the language, you can write good code in the language." This doesn't really help, though. The reality of programming is that different languages encourage different styles of programming. They shape the eco-system, the space of the solutions you will find for you problems. JavaScript lacks tools for managing complexity. I don't work with it a lot, but most of the JS code I've seen recently was, in fact, callback spaghetti (with arbitrary global state modifications). That's the ecosystem the language created. Hearing how it's avoidable doesn't make my life any easier when I work with such code.
- jessedhillon 16y ago
  This is subjective and anecdotal, but every large JS framework whose source I've examined shows this tendency towards spaghetti.

deleted 16y ago

[deleted]

jessedhillon 16y ago
> You could have done with AJAX what WebSockets does If you consider long-polling (the nearest approximation you can do with AJAX) the same as true bi-directional communication.
- deleted 16y ago
  [deleted]
  - jessedhillon 16y ago
    Please show me how a server can send two consecutive messages to a long-polling client without requiring the client to make a request between the receipt of message 1 and message 2.
    - deleted 16y ago
      [deleted]
    - deleted 16y ago
      [deleted]
    - weixiyen 16y ago
      I'm not sure what you are replying to as it's been redacted, but just wanted to say that there's really nothing wrong with that technique. Developers tend to way overestimate the cost of a long polling request with minimal headers. Also the speed benefit of websockets over long polling is so trivial that it doesn't really matter.
      - ericflo 16y ago
        I could not agree more with this comment.
      - jessedhillon 16y ago
        A couple of posts were deleted on this thread, perhaps because the authors realized they were mistaken. The claim was that long-polling and WebSockets are bi-directional in the same sense, and mine was that one type of bi-directionality is simulated and has real limitations. It doesn't matter if the overhead is low: with long-polling, the server can't send a waiting message until the client requests them. With true sockets, the server can send messages as soon as they are available.

sthatipamala 16y ago

People are "cheerleading" node.js because they tried it, successfully built something with it and want to give proper credit to their stack. The existence/prevalence of node.js submissions does not imply that anyone thinks it any more technologically capable than Twisted, Go, Tornado, or eventlet. Node.js just happens to be simpler to install, have more easily accessible documentation and has more of a network effect going for it.

jessedhillon 16y ago
My point is that the proliferation of HN posts regarding node.js is not reflective or driven by a host of new and significant improvements that it brings to the table. I suppose one response is this shouldn't be surprising, since anything implemented after the 70s could have been done with C instead of language X. But my complaint is that it seems a lot of attention is paid to projects which are not actually doing new things with node.js, just things that have already been done with other technologies. Actually, this comment sums it up much better than my comment: http://news.ycombinator.com/item?id=1549023 http://news.ycombinator.com/item?id=1549023
- slewis 16y ago
  I'd argue that being in javascript is an advantage rather than a disadvantage. Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser. I'm not saying javascript is the king of languages, just that we're limited to it because that's what's in the browser, and writing server code in the same language simplifies things.
  - udoprog 16y ago
    Server side logic is usually radically different. And given that you usually share information between the server and the client in a language agnostic manner (e.g. JSON) and that the client (browser) cannot be trusted with other than view logic, I see few cases where implementation specific code sharing contributes greatly. The server and the client has such different concerns that code sharing probably wouldn't contribute that much.

bambax 16y ago

I use node.js for batch processing: it's just fantastic. Instead of ugly bash scripts that are absolutely unreadable and therefore unmaintainable, I get to write beautiful Javascript and lightning fast JSON processing and transformation. This is an area where node.js really shines and that is not often mentioned. As for client-server development, I think the future is going back to the client. Instead of "dumb clients", what we have now are extremely powerful and fast clients. It's much cheaper to send raw data to the client and compute it there, since as a web developer you pay for server CPU, but not for client CPU. (Of course, it's a little wasteful since the computation happens many times instead of one; but you can always send the results back to the server for caching, if that worries you).

masklinn 16y ago
> I use node.js for batch processing: it's just fantastic. Instead of ugly bash scripts that are absolutely unreadable and therefore unmaintainable I am confused: if you don't like bash scripts why in science's sake did you keep using them instead of one of the billion alternatives out there? > This is an area where node.js really shines and that is not often mentioned. Because it's nonsensical. What makes node.js "shine" more at batch processing more than every other language on the planet?
- bambax 16y ago
  > What makes node.js "shine" more at batch processing more than every other language on the planet? Because every other language on the planet is not Javascript...? - - - Edit: maybe I should clarify? The only other solution (that I know of) to write Javascript for the server is Helma; I've tried it and it kind of works but it's very clumsy. Is there another simple way to write JS on a Linux box? - - - Edit2: maybe I should not clarify.
Fester 16y ago
Node.js is great because bash is ugly. Way to go indeed.

weixiyen 16y ago

> but any sufficiently complex JS app tends towards callback spaghetti Callback spaghetti is quite easy to avoid. > and maybe I have been doing something wrong If you have callback spaghetti, regardless of the complexity of the app, you are most likely doing something wrong. > I don't see it as a huge leap forward from what can be done with Twisted + Python, or Go Of course not, but it's not hard to imagine that Node.js will have the biggest ecosystem in this space and with it comes advantages (and perhaps disadvantages).

gambler 16y ago
> Callback spaghetti is quite easy to avoid. That's what people say about most bad programming practices. "It's not the language, you can write good code in the language." This doesn't really help, though. The reality of programming is that different languages encourage different styles of programming. They shape the eco-system, the space of the solutions you will find for you problems. JavaScript lacks tools for managing complexity. I don't work with it a lot, but most of the JS code I've seen recently was, in fact, callback spaghetti (with arbitrary global state modifications). That's the ecosystem the language created. Hearing how it's avoidable doesn't make my life any easier when I work with such code.
jessedhillon 16y ago
This is subjective and anecdotal, but every large JS framework whose source I've examined shows this tendency towards spaghetti.