I've seen a lot of stackoverflow questions regarding the other client side scripting languages

The Internet is being a very content-rich and dynamic place. HTML and CSS specifications are trying to bring the Web to the next level - we are getting WebSockets support which is real nice for full-duplex client-server munication, enabling some fascinating design patterns to emerge. Also, we have a working implementation of WebGL in JavaScript with which I've had a lot of fun thus far.

But this has brought up some concerns, at least for me. I'm a desktop programmer, C/C++/Objective-C - depending on the platform. Specifically, a rendering architect. JavaScript has served all of us marvelously, has it not? We've used it for getting basic user interactions with 2D linear websites, responding to simple events and bining all that with HTML and CSS.

Given the fact that the doors of realtime munication and GPU-driven visualization have been opened to the web, will this have any implications on JavaScript? I've seen the reactions to Dart and other attempts at pushing JavaScript out. JavaScript is weakly-typed, which sounds all sorts of alarms for me (considering the intense math library which hangs on speed, unnecessary runtime checking is not a fun time).

I've shifted a lot of the code to the GPU, but even then my in-house renderer is simply CPU-bound (the HD6990 can't be the problem, let alone the code which powers the desktop/embedded engine).

So, here is it out in the front:

• Code is lying naked because of the interpreter design. Rendering technology and solutions are worth a lot of money. It's the sole foundation of my pany and pays the bills. Obfuscation doesn't cut it (Do correct me if I'm wrong). I've always wondered, why isn't there an intermediate pilation process to a form of bytecode which can be processed by the VM?

• It is weakly typed. Juggling matrices, vectors, quaternions, arrays and all other sorts of data mon to highly-interactive applications just bloats processing with runtime checking. Even though it eventually goes to the GPU side, you still have to do a fair amount of work on the CPU side which is bogged down by JavaScript.

• Prototype-based paradigm will dampen efforts to port rendering code from major players who can push adoption of WebGL/WebSockets. (remember that a lot of it is driven by the CPU). Will the prototype-based paradigm persist as more and more users start demanding high fidelity 2D/3D content?

• WebSockets have proven to be a beautiful new addition to web gaming (BrowserQuest), not to mention dynamic websites, and will be driven by a lot of people in the future to develop awesome content ( my pany is running a little closed project that implements a small MMO in a 3D environment driven by WebSockets ).

So, do my concerns have any basis in reality?

Are there any new movements in regard to these problems?

If you offer any answers to the topic, could you also add a small paragraph of personal opinion? I know it's not the "way of the Stackexchange", but it doesn't harm since all the other questions are legitimate and answers can be based in fact.

I've seen a lot of stackoverflow questions regarding the other client side scripting languages

The Internet is being a very content-rich and dynamic place. HTML and CSS specifications are trying to bring the Web to the next level - we are getting WebSockets support which is real nice for full-duplex client-server munication, enabling some fascinating design patterns to emerge. Also, we have a working implementation of WebGL in JavaScript with which I've had a lot of fun thus far.

But this has brought up some concerns, at least for me. I'm a desktop programmer, C/C++/Objective-C - depending on the platform. Specifically, a rendering architect. JavaScript has served all of us marvelously, has it not? We've used it for getting basic user interactions with 2D linear websites, responding to simple events and bining all that with HTML and CSS.

Given the fact that the doors of realtime munication and GPU-driven visualization have been opened to the web, will this have any implications on JavaScript? I've seen the reactions to Dart and other attempts at pushing JavaScript out. JavaScript is weakly-typed, which sounds all sorts of alarms for me (considering the intense math library which hangs on speed, unnecessary runtime checking is not a fun time).

I've shifted a lot of the code to the GPU, but even then my in-house renderer is simply CPU-bound (the HD6990 can't be the problem, let alone the code which powers the desktop/embedded engine).

So, here is it out in the front:

• Code is lying naked because of the interpreter design. Rendering technology and solutions are worth a lot of money. It's the sole foundation of my pany and pays the bills. Obfuscation doesn't cut it (Do correct me if I'm wrong). I've always wondered, why isn't there an intermediate pilation process to a form of bytecode which can be processed by the VM?

• It is weakly typed. Juggling matrices, vectors, quaternions, arrays and all other sorts of data mon to highly-interactive applications just bloats processing with runtime checking. Even though it eventually goes to the GPU side, you still have to do a fair amount of work on the CPU side which is bogged down by JavaScript.

• Prototype-based paradigm will dampen efforts to port rendering code from major players who can push adoption of WebGL/WebSockets. (remember that a lot of it is driven by the CPU). Will the prototype-based paradigm persist as more and more users start demanding high fidelity 2D/3D content?

• WebSockets have proven to be a beautiful new addition to web gaming (BrowserQuest), not to mention dynamic websites, and will be driven by a lot of people in the future to develop awesome content ( my pany is running a little closed project that implements a small MMO in a 3D environment driven by WebSockets ).

So, do my concerns have any basis in reality?

Are there any new movements in regard to these problems?

If you offer any answers to the topic, could you also add a small paragraph of personal opinion? I know it's not the "way of the Stackexchange", but it doesn't harm since all the other questions are legitimate and answers can be based in fact.

• javascript
• websocket
• webgl

Share Improve this question Follow asked Apr 6, 2012 at 12:20 user1309389user1309389 1

• These are interesting issues. However, it feels like the wrong style of question for StackOverflow. It seems like a great fit for a blog post or Google+ conversation though. – Jamison Dance Commented Apr 6, 2012 at 12:46

Add a ment  | 

3 Answers 3

Sorted by: Reset to default 6

Your concerns are based on misunderstanding how Javascript run-times work and mostly have no basis in reality.

• All Javascript code is JIT'ed nowadays - intermediate bytecode language is not needed and was orignally seen possible hinderance of portability, which is the top virtue of web. Modern scripting like programming languages like Python, Ruby, PHP etc. work well even if the apps are not distributed as bytecode. Bytecode step is not needed, as code is JIT'ed in the end anyway. More material you can provide for JIT to work with, the better. In fact for Java they disabled bytecode optimizations in modern versions because it was confusing JIT piler.

• JIT pilation can optimize out dynamic typing issues, though they will never provide statically typed performance, but most likely will provide good enough performance. There are some issues though http://www.scirra./blog/76/how-to-write-low-garbage-real-time-javascript but Javascript implementations are getting better to work around these kind of issues. For example, Mozilla Audio team (which seem to be more like demo team...) is cranking out 3D demos just to have material to optimize their Javascript run-time.

• I don't see why prototype based approach would have any connection to high fidelity, they are two totally separate things

• Currently the alternative approaches like Google NaCL are not endorsed by other browser vendors and most likely never will, as Microsoft and Apple would not adopt Google-only technologies and Mozilla sees NaCL as threat to open web

For insight how modern JIT piles work please see PyPy blog http://morepypy.blogspot./ (though not Javascript specific). They go to great detail explaining what kind of JIT optimizations modern puter science applies on the code.

For what "web-like design patterns can achieve in 3D" please see tQuery which is jQuery like framework for 3D content https://github./jeromeetienne/tquery

Cheers, Mikko

• Javascript code is lying naked: it sounds like your question is about protecting "intellectual property". I think you are overestimating the protection that pilation provides. Compilation hides your algorithms only marginally better than good obfuscation; a good depiler will reveal most of what you are trying to hide anyways. Compilation and obfuscation only protect your from the curious not from people who are determined to steal your ideas. If you want to protect the form of your code, that's what copyright is for. I will also point out that one of the very reasons for the success of the web platform is in fact "view source". It is probably the greatest educational tool for somebody wanting to learn how to design great web sites and web applications. It is an amplification of the power of open source (lowering the barrier to being able to look at and modify the source).

• Javascript is weakly typed: True, but if you are going to do math operations on large datasets then you are going to use Typed Arrays which are fixed size and have elements with fixed types/sizes. In addition, type inference (in Firefox 9) significantly increases performance related to variable reference.

• Javascript is prototype based: prototype based inheritance is more expressive than standard class based inheritance and with a few sugar functions you can do pretty standard class based inheritance in Javascript: http://www.crockford./javascript/inheritance.html

• WebSockets: I don't think you asked a question regarding WebSockets. And yes, they are a great addition to the platform, particularly the newest iteration of the protocol and API which allows Typed Arrays and Blob data to be sent and received directly.

Opinion:

WebGL and Javascript performance are not yet to the level where you could port the latest AAA first person shooters. However, I might suggest that the real money to be made in the near future with 3D games is with casual web games. This has already proven true with casual 2D games on the web and WebGL is getting pervasive enough that it is ripe for successful casual 3D games.

Also, if you have a large investment in C/C++ 3D libraries, then you might consider Emscripten which is a piler that target Javascript and has surprisingly good performance.

I think this is very interesting, especially the obfuscation part. Me myself was in the console/desktop games industry for many, many years before I switched to the web like 6-7 years ago. At first, the view-source was very strange to me. But slowly I've e to love it and think differently about technology solutions.

True, it costs a lot of money to develop high-end tech and also true, it's very easy to copy your ideas and solutions. It's also true that you won't be able to copyright them or protect them in any way the moment you publish them. But is that really a problem? I think this inspiring talk...

http://www.ted./talks/lang/en/johanna_blakley_lessons_from_fashion_s_free_culture.html

...about how it works in fashion industry really nails it - to stay successful you need to be on your toes and keep developing. Whatever you put out is done and history, now what's next?

The advantage you still have is your tools and pipeline, which from my experience is more expensive and plicated than the actual rendering part. And that you already have an experienced team and game up and running, which you hopefully successfully monetize upon.

Also, a side note really, I feel the online-experience is more about the social aspects rather than the graphical, which in many ways reside server-side and thus protected.

Looking forward to your game!