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>
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.
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.
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.
> Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser.
That's a fallacy, the environments have nothing in common, the coding styles and interactions don't either, the only things you're going to be able to meaningfully share are trivial helper libraries à la underscore..
> and writing server code in the same language simplifies things.
Why? How? Where? I see that assertion often, but I have yet to see it backed by anything but "because I said so".
Actually the environments have a whole lot in common. Templating, validation and data retrieval/storage for example can be done both client & server-side, depending on the situation.
A fallacy? Sharing code between client and server is easier when the two are in the same language than when the two are in a different language. How is that flawed reasoning?
One example: you can run the same input validation in the client as you do in the server if you can easily share code between the two.
But there is way more. Here's an example of an application that shares all of its data models between client and server:
http://tilemill.com/docs/models.html
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.
Except the client can act as a server once you start thinking about localStorage caching. Form/input validation is another thing which is really useful to have on both the client and server and benefits greatly from code sharing.
Basically: Client side validation is about user experience, Server side is about security. I'm hard pressed to believe you can get both with the same code.
I also don't see how localStorage is relevant to code sharing between client and server.
Rendering templated HTML on the server for serving the first page from cache and then using the same code to render subsequent pages on the client is one use I'd like to experiment with.
I definitely regard server side JavaScript as a strong advantage - doing client development in JavaScript, database development in CouchDB is feels wrong to be doing the server application component in something else.
Why does it feel wrong? JavaScript isn't that great a language; even if you use CoffeeScript, there are nicer languages out there, and on the server you have the option of using whatever language you want.
Using the same language on client and server can come in handy if you've got some non-trivial amount of code they can share in common. When I made a multi-user text editor (think Etherpad, but simpler), all the code for transforming the editing operations so that everybody's documents converge was written in a single JavaScript file, which I ran on both the client and the server, via node.js. That was great. That was fun. But if you don't have a situation like that, where's the advantage in using JS on the server?
Of course, the comment about it being "wrong" is completely subjective. I just really like JavaScript these days (and I've been paid to program in a lot of other languages - Lisp, C, C++, PostScript, Java, C#...).
> 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).
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.
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).
> 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?
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.
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.
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.
Yeah I tend to agree that the in the last year and half web technologies have exploded in capabilities. And looking at what was traditionally only possible on the desktop, that category is slowly starting to dwindle.
Part of my job has been to remake visualization software (for brain imaging research) on the web and aside from some really heavy stuff, WebGL has served me well. Javascript engines are getting so fast, I haven't had problem computation heavy tasks that much. Most of the time it's my code that's shitty.
Now my most limiting factor is the damn slow upload speeds I get in canada. If only I could get 2-3 Mbps up, I could do some great stuff.
WebSockets are really cool but we found the browser implementations unstable enough that we switched back to XHR for Tinkercad. Especially since the secure implementations were super shaky and we run all our traffic over SSL.
We also use Go and not Node.js for the backend so the only thing qualifying us for this perfect storm is WebGL.. :-)
I'd love to see a blog about your experience with using Go as your web server. Did you use the standard library, Web.go, or something else? There have only been a few deploy production web apps with Go so far, so the knowledge needs to spread.
For Tinkercad the http server is just a relatively simple transport layer, the magic happens with how the computation is distributed in the cluster. We'll blog about it once things settle down a bit, at this point we are just trying to soldier ahead with the beta. :-)
I love the demo for it's thought provoking stab in the brain. I love three.js and can't wait to tie it into my own app.
re: WebGL games. The clients will all be "open source" (as they're javascript). What effect do you all think that'll have on the future web-based gaming industry?
The most obvious problem is probably that it's way easier to develop bots/cheats for those games.
Since I'm currently developing a WebGL game I'm actively searching for ideas to detect that behavior.
The only solution I can think of is, to capture any data with timestamp coming from the client and applying some tests to it like "is the client sending more messages than a normal client" or more advanced: sending the input through a statistical filter to detect possible cheating and investigate from there on.
It might be an idea to think about the actual mechanics of the game once you've come up with a possible solution so that the game itself doesn't invite cheating behaviour or at least makes it easier to detect. i.e. Making it physically impossible to shoot faster than a specified rate or move too quickly/accurately, etc.
I'm not really sure what is wrong, but it might be that you lack OpenGL libraries. You might want to check out this page: http://learningwebgl.com/blog/?p=11
I figure I might as well let you know what you're missing. The guy coded up a 3D world in which you walked around as a square with text floating above your head. It reminded me of World of Warcraft and other MMOs, despite its graphics being far below those of Minecraft.
That should no longer be required. Some cards are blacklisted due to older drivers. Try updating your drivers to the lastest ones from NVIDIA or ATI. If that doesn't --ignore-gpu-blacklist might work but if your card is blacklisted it might crash your browser.
It can be really hard to get your bearings sometimes if things are all the same shape/size, especially if there isn't many people in the app. It needed a central location or gathering point so I figured why not throw a giant obelisk thingy in there?
Its fun watching what people say about it. They want to know why its there, why its black and if its real.
Hell yeah... that really felt like a bit of the future. Someone needs to make t-shirts with different color squares and the words "WHAT COLOR AM I?" over it.
That was far too amusing. I found it interesting that we grouped on one spot on the monolith. I ventured out away from everyone twice, once apparently with the same person.
<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>