Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

travisglines.com

Post reply on HN
Print view View original

51–60 of 69 posts

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

#51

Post by demallien »

travisglines wrote: post #36
sthatipamala wrote: post #23

Earlier quoted context omitted.

What is the purpose of the large black Kaabah structure in the middle?

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.

I was just disappointed that the ratios don't appear to be 1:4:9

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

#52

Post by udoprog »

cloudhead wrote: post #48
udoprog wrote: post #38

Earlier quoted context omitted.

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.

Except in most cases validation cannot be complete on the client side, anything related to server side logic has to be additionally checked.

Validation is also two different concerns if you compare serverside vs clientside.

http://stackoverflow.com/questions/162159/javascript-client-...

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.

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

#53

Post by daveelkan »

anty wrote: post #39
daveelkan wrote: post #20

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

Sounds bloody hard!

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.

Good luck!

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

#56

Post by Flenser »

udoprog wrote: post #38
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.

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…

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.

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

#57

Post by gambler »

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…

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

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

#58

Post by Fester »

bambax wrote: post #37
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…

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…

Node.js is great because bash is ugly. Way to go indeed.

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

#60

Post by pjscott »

arethuza wrote: post #50
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.

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?

Post reply on HN