Hacker News new | past | comments | ask | show | jobs | submit login

What bothers me about asm.js is that no one really needs it. I mean don't get me wrong, Unreal III in Firefox is pretty cool, but very very few developers will seriously consider writing a production game for the browser. So then what are we left with?

FFT implementations? OCR? Real-time fluid mechanics? Who does these things in a browser? What JS needs is to finally standardize WebSockets (across the board), to seriously consider multi-threading (not this WebWorker nonsense), to implement optional type checking (like Dart), etc, etc.

The effort that's going into asm.js should go into building better JIT compilers. We seem to be forgetting that JavaScript is a web programming scripting language, not some general-purpose low-level esoteric programming language. There are so many improvements JS could make on the web-side of things (you know, where it's actually used) instead of on the "cool 3D Unreal III game-programming, bytecode-crunching, Jacobi-simulating"-side of things.




very very few developers will seriously consider writing a production game for the browser

Zynga, PopCap, Team Meat and a few others come to mind. If you meant 3D "AAA" titles, that just became reasonable a few weeks ago so you'll have to give me some time while the data points come in.

However much or little incentive those would have had in the past, I think it's only going to increase. If FirefoxOS catches on (and it seems to have already with manufacturers), any games will have to be "for the browser", as well as all applications.

FFT implementations? OCR? Real-time fluid mechanics? Who does these things in a browser?

The snarky answer would be "nobody, yet" but (much like commercial gaming) that's not even true. People have been doing this strength of computation in the browser since before it was reasonable to do it.

Worse, do you think leaving out this possibility is a good thing for us? I think asm.js is partly a product of benchmark trolling, but it really does open doors for us.

Forgetting B2G for the moment, because that argument is too easy to make, and doesn't apply universally anyway: shortly before the publication of asm.js I had jokingly suggested someone (plug: http://tapes.fm/) implement multiband master compression to a multitrack playback webapp, because it was a damn shame I couldn't reproduce the dynamics of the original tracks thanks to lacking master compression. But if you can do FFT it's suddenly worth doing now, in fact I am sure it will happen. Perhaps not on tapes.fm but somewhere.


The goal of things like asm.js is to make JavaScript a general purpose, low level programming language. I'm not sure why you consider it esoteric, though.

People don't do those things in the browser because asm.js (or some alternative) isn't widespread yet. When it is, they will.


Exactly. JS was never meant to be a general-purpose language. Using the right tool for the right job is a fundamental aspect of software engineering. If you use C for writing web-apps and JavaScript for writing operating systems, you're doing something very, very wrong.

The irony here is that JavaScript isn't even a very good language, anyway. So when lambdas are implemented in a language like C++11 (to the chagrin of many programmers that shun the unnecessary complexities of recent revisions of C++), that's one thing; but when we're trying to use JS for low-level programming, that seems very silly.

And as far as your second point is concerned, I beg to differ. Java has been able to run OpenGL in the browser for ages. Flash can also do hardware-acceleration. As can Unity3D. 99% of computers have either Flash or Java installed, and yet, no serious developer (barring maybe a couple of indies) would seriously consider Java/Flash as a serious platform. I don't think HTML5/asm.js will change that.


>JS was never meant to be a general-purpose language.

The original designers and implementers of the Internet, the Web and HTML probably never envisioned the myriad of ways those technologies would be used (abused?). So what?

>Using the right tool for the right job is a fundamental aspect of software engineering.

So tell me, what is the right tool to build a cross-platform application that runs on every system, without requiring native install (and with every other benefit of a typical 'web-app')?

>If you use C for writing web-apps ...

WHY?!? How can you even say that in light of the Unreal demo that Mozilla showcased, where you have a high-performance game running on a standard browser. Given that, you still see zero potential? I don't know if browser gaming will take off, but that's irrelevant. If the browser can run a high performance game, it tells me devs can make use of that processing power to build any sort of web application that traditionally would have needed to be native. You don't see the potential in being able to build a web-based Photoshop or AutoCad?

>The irony here is that JavaScript isn't even a very good language, anyway.

You're right, it isn't, so what? HTTP isn't the best protocol, and neither is TCP, but try replacing them with any 'superior' protocol. JavaScript, like HTTP, and TCP is ubiquitous, that's its strength.

>no serious developer (barring maybe a couple of indies) would seriously consider Java/Flash as a serious platform.

I consider both serious platforms for gaming and otherwise, even with the knowledge that they will be replaced by HTML/JS on the client.


> 99% of computers have either Flash or Java installed

If you define "computer" as being something that's not a "phone" or a "tablet", sure.

But people writing web content today sure care about those non-"computer"s...


People who write in other languages need it. It's not only about number crunching. It's about people leveraging their knowledge and experience in their languages to write client side scripts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: