Live data from Hacker News

WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

travisglines.com

41–50 of 69 posts

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#41
post #34

Earlier quoted context omitted.

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 ne…

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

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#42
post #37

Earlier quoted context omitted.

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 client…

> 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 "s…

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

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#43

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

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

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#44
post #24

Earlier quoted context omitted.

[deleted]

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.

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#45
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.. :-)

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#46
post #34

Earlier quoted context omitted.

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? Wh…

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.

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#47

Earlier quoted context omitted.

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.

I could not agree more with this comment.

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#48
post #38
post #34

Earlier quoted context omitted.

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.

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 con…

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.

Re: WebGL + Node.js + WebSockets = A Web Technology Perfect Storm

#50
post #34

Earlier quoted context omitted.

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 ne…

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.

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.
Post reply on HN