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

Post by jessedhillon » Thu, Apr 07, 2011, 5:36 PM UTC

weixiyen wrote: post #43

jessedhillon wrote: post #11

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…

Post by slewis » Thu, Apr 07, 2011, 6:20 PM UTC

masklinn wrote: post #41

slewis wrote: 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…

Post by pauldix » Thu, Apr 07, 2011, 7:32 PM UTC

kaib wrote: post #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.. :-)

Post by arethuza » Thu, Apr 07, 2011, 8:31 PM UTC

pjscott wrote: post #60

arethuza wrote: post #50

Earlier quoted context omitted.

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

Post by kaib » Sat, Apr 09, 2011, 9:05 PM UTC

MatthewPhillips wrote: post #66

kaib wrote: post #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.. :-)

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.