That’s what people used to say about Java vs. C, right?
yeh, programming tribalism, only a natural reaction by some. Also why some still beat on about Java (or even C++) being slow.
I have already explained in another thread why JavaScript is harder to optimize at runtime and I have explained several times why Java can be faster than C/C++, it has nothing to do with tribalism. Dynamic typing drives the runtime optimizations a lot more complicated, it becomes even more complicated when you have to handle vendor-specific extensions.
I don’t think that people who use JavaScript are wrong by default, I have used JavaScript several times even though I’m not a big fan of this language and I give some arguments when I say that JavaScript will probably stay slower than Java.
It may be true that dynamic typing should make runtime optimizations more complicated, but do you honestly believe that it’s an insurmountable hurdle? My point was that, people used to generally believe that Java could never be as fast as “native” code, as there would always be overhead from the VM. Over time though the software improved: Hotspot, etc. Who’s to say that similar improvements won’t make dynamic language VM’s on par with (or at least make the difference negligible to) that for statically-typed languages?
I studied this problem in the lessons about the implementation of programming languages during my master degree, I think it is not a problem, there is no solution, you can use the same variable to store an integer, a string and after that an object of any kind, let’s face it. As a consequence, the automatic memory management has to track all these instances and to know in each context what the expected type is.
I see what you mean but the same kind of people never admitted that Java allocation and method calls could be faster.
It is not that simple. The future JVMs will have some new bytecode instructions specifically for dynamic languages, there are several ways of improving the performances of JavaScript. Anyway, even though JavaScript was twice slower than Java, it would not be a problem for most projects as when Java was twice slower than C, it was not a problem for lots of projects.
There is still some room for improvements. LuaJIT for example is significantly faster than V8 or JägerMonkey.
I expect that V8 will reach that level within the next 2 years. I don’t really expect that it will get as fast as Java though.
JavaScript is fast enough for the things I currently want to do. Even on those puny ARM CPUs it’s kinda nice.
That’s why Chrome and Firefox use ANGLE, which works perfectly fine 99% of the time. (It’s also super awesome to get Nvidia 3D Vision working with OpenGL on consumer graphics cards…)
Angle is cool.
Cas 
This may be a good time to note libgdx has an Angle backend. 
Silverlight hasn’t been ditched, but for most webapps MS are now pushing HTML5 over Silverlight. In the future I would find it very surprising if MS does not eventually support 3D in the browser, when all of their competitors are.
What does it prove? In the comments, the author makes a distinction between dynamic languages that allow static types and dynamic languages that do not allow static types, both are not implemented in the same way.
I agree with it too.
[quote=“oNyx,post:27,topic:35101”]
That’s what I meant.
That’s what I mean. JavaScript is currently fast enough for lots of applications and it will be enough for more and more applications in the future except a very few applications.
But the use of ANGLE will not encourage vendors to provide better OpenGL drivers 
My point to BoBear2681 was that it isn’t just about performance. What comment do you mean?
Oops, it’s not one of the author’s comment :-X
Wait… How is this achieved with only HTML and GL-bindings? I thought HTML was static? :clue:
HTML5 = some new elements, a few JS APIs, and detailed parsing specifications.
The last thing is by far the biggest part.
One of those JS APIs was Canvas. It’s a simple 2D API. Canvas also got a 3D context called WebGL. WebGL actually isn’t part of HTML5, but most people don’t really care about those fine details.
If you write a game using Canvas, HTML is basically only used for bootstrapping (and maybe some layout it if you want). You need some way to tell the browser where the Canvas should go, how big it is, and which scripts you need. That’s the HTML part. Well, you also use DOM events for input and Audio objects for sound, but the game itself is just pure JavaScript.
This is also done with same tech.