Home/ Questions/Q 7774763
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T17:27:31+00:00

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

  • 0

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

The Internet is becoming 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 communication, 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 combining all that with HTML and CSS.

Given the fact that the doors of realtime communication 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 company 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 compilation 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 common 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 company 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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

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

    • JIT compilation 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.com/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 compiles work please see PyPy blog http://morepypy.blogspot.com/ (though not Javascript specific). They go to great detail explaining what kind of JIT optimizations modern computer 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.com/jeromeetienne/tquery

    Cheers,
    Mikko

    • 0