Using the same technologies is natural.
I'd be in even just for the possibility for reflection/dependency injection.
WebGL is a huge bonus, but WebAssembly will also be important for a lot of web-based VR.
You can in almost all cases check for these semantics statically, and if not found, run a super fast path. This is the whole premise behind asm.js.
Heck, even C++ has plenty of features that have performance-hostile semantics. But the compiler checks for these and you don't pay the penalty if you don't use them.
Wasm will help, but I disagree that anything in the JS spec makes the _language itself_ inherently slower than any other language, if we disregard textual compilation overhead.
Until you can specify memory layout you'll never come near a proper gamedev engine, regardless of GC issues(which are also a problem).
(source: I used to work on professional game engines)
so aside from startup speed you get the same perf
So does every other language, where it matters is with objects. Until I can mark a whole object as a value type and fix it in memory relative to other objects then you'll pay a 10-50x slowdown for cache misses and the like.
But you don't even need to rely on that. JS has TypedArrays[0] which are basically just a chunk of memory you can read and write to.
Aside from some bounds checking, it's about as "low level" as you can get. Sounds like exactly what you are looking for.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
On the Java side I've used ProtoBuf for similar approach(using byte[] which does have memory placement semantics). While it helps, the bounds checking and accessors that you need still have a non-trivial cost both in branching and cache thrashing(len is usually stored for an array at a different location or at the head so data items near the mid/tail will still take a hit).
Realistically you can get within about 1/5th the speed of native using cache aware data structures and techniques. As always it matters if your use case needs that speed but choosing a JS/managed based tech-stack will always limit you from getting that last 5x perf improvement.
I'm deeply suspicious that you'll do better than something purpose built. Things like arena allocators for levels. Knowing how your scene-graph and animation traversal are really hard to get right and without direct control over SoA vs AoS and the like I don't see how you get within a factor of 10 to something written in native.
That's a bold statement right there.
I'm actually a huge fan of WASM, I think it gives you a great escape hatch to break out of these problems(much like JNI/etc in other managed languages).
But then you're no longer using the language. The performance-hostile semantics are still there, you're just not using that part of the language, and thus losing out on all their benefits.
You may be confusing layers here. asm.js as a compilation target is used the same way as LLVM- it is used to implement the source language's features, while simultaneously avoiding some of JS's.
There absolutely is.
If I write a program in a language that's fuzzy enough that a machine (which follows the specifications of the language) cannot definitely tell what I was asking it to do at compile time, there are compiled optimizations it can never rely on.
You make a good chunk of that back with JIT / predictive runtime compiling, but it's never going to be the same. At minimum, you're burning CPU and cache on your miss rate. To say nothing of the additional overhead of running JIT while executing in the first place.
As I understand it, this is the entire purpose of things like Vulkan / Webasm. (I realize they're primitive targets vs high level language, but same principle applies at any level of the stack)
Happy to have someone tell me I'm wrong, but the original quote flies in the face of everything I learned in language / compiler design.
I think however there is some fundamental communication issues talking about "compilers vs language". Optimizing compilers, by definition, rewrite your code into a "better" form. Even if you are writing C/C++ you probably don't really know what's happening at the register level. Heck, with todays CPUs I wonder if even assembly people know what's actually happening in the registers!
There have been comments to the same effect on HN before, but I look at language design as an API between humans and computers. Computers need as strict rules on how to execute a thing as possible: humans need something comprehensible. The ideal language finds ways you can increase the former without decreasing the latter (in ways they notice).
I'd complain the same way if it were a C++ project requiring Boost or something.
As for solid and well-understood... Douglas Crockford wrote a book on how "solid" Javascript is, called "Javascript: The Good Parts". One of his most common refrains about JS was "Javascript is The World's Most Misunderstood Programming Language". [0][1]
ES5 came out in 2009. ES6 was standardized after React came out.