Comment by corresation | Hacker News Reader

Comment by corresation | Hacker News Reader

Parent Full thread

One of the things you need to remember

I have been building and architecting very rich web applications before most caught onto this web thing. I was an original tester of XmlHttpRequest back when it was a safe-for-scripting ActiveX "abomination". I recently made a ridiculously full featured stop-motion recording studio -- in the browser -- for my children after they were enamored by something similar at the Science Centre.

And JavaScript performance has not been -- remotely -- an issue for a long, long time. The facets that make these apps powerful are technologies like WebGL, Canvas, SVG, CSS, and so on. Things that I wouldn't imagine doing more than simple orchestrations in code.

People use JavaScript performance on a completely artificial benchmark like Sunspider as a proxy for real-world browser performance. Yet it is at most a minor correlation, and has incredibly little to do with causation of a good experience.

If you think I'm joking or overstating, turn off the JIT in your browser and use it for a day. Is your experience devastated? Can you even tell the difference?

There's a big difference between "my use case" and "all use cases".

Sure, JavaScript is fast enough for a lot of things.

But it's also too slow for many things that reasonable people would like to do on the web.

See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin).

pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time.

pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins.

Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful.

We're still far away from making JS speed covering all the important use cases.

Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.

> There's a big difference between "my use case" and "all use cases".

Yes. This is an appropriate response to a significant fraction of the complaints on this site and all other tech sites. I usually think of it as "your experience is not universal".

Given the direction of gaming and streaming, your mp4 example seems apt... I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal for both hardware, and software. Canvas+JS is likely to be the "thin" client structure or the future... I think if it were possible to do this in JS, we wouldn't need ignorant plugin points for DRM.. encrypted streaming could "just work" on any platform, not that I want more DRM.

I like that we are finally at a point, where legacy emulators in JS are a reality. I do think some attention to worker interaction, and perhaps locking say a canvas, or audio channel to a worker should be something able to be done.

I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal

Why is that an appropriate goal? How about a video element -- which the browser implements in the ideal manner (which is usually a thin layer over hardware decoding) -- that handles h264? Why in the world would you want to do that in JavaScript, besides as a "because I can" challenge?

Further your notion that DRM would "just work" is really unclear. I don't think you understand the concerns of the DRM folks if you think that you'll just do it in decrypt.js and all will be good.

I'd like to have a meet-up and invite all the dudes like you and all of the kind of dude that complains about how asm.js performance is still so slow that they don't see the point and will just keep writing "native".

You're wading into a discussion that is above you. Generally that isn't a good idea.

JavaScript proper cannot be a high performance language because of fundamental design choices. Asm.js, which I've referenced multiple times, undoes many of those choices, effectively becoming a completely different language (which is why you target it with C/C++ and LLVM, not by writing it directly). The notion that there are going to be legitimate video stream processing or h264 decoders in JavaScript -- that are more than a impractical "if you ignore normal considerations" demo -- is 0%. It makes no sense, and it is using the wrong tool, making everything into a nail because someone "knows JavaScript". This is doubly true on mobile where you want to make every instruction count.

All of the examples in here are a riot. Further gaming in HTML5 thus far has been "welcome to the 80s". It has gone nowhere. Nor has any other "pure JavaScript" high computing adventure. nodejs, which I love, is a wonderful asynchronous glue, but everyone knows that you dare not do any actual computations in it because...JavaScript.

> You're wading into a discussion that is above you. Generally that isn't a good idea.

Making assumptions about the knowledge of people you're responding to is cool though.

> Further gaming in HTML5 thus far has been "welcome to the 80s".

Oh, see I guess I was thinking Unreal 3 and Sauerbraten were released much more recently than that. Oops, silly me.

You're right, the browser should just only ever be for web pages, everything should just stay how it is now and all these damn kids should get off your lawn.

Oh, see I guess I was thinking Unreal 3

The Unreal 3 demo was an entirely different thing. Asm.js is a dramatic rethinking of JavaScript that tosses much of the language, and adds hacked typing metadata, to essentially act as a proxy for C. The single benefit that it brings over just going with C is that existing browsers can limpingly run it in crippled mode.

You're right

And then you boringly completely misrepresent my argument. You should tell the kids to get off your lawn, as you're busy trying to pretend everything is a nail because all you know is your hammer.

It's interesting you truncated my example which was pre-Asm.js but still managed to be playable.

They took a shortcut, sure. Historically JS performance hasn't supported that kind of application, and thus there are few modern or impressive 3d game engines written in it.

You were wondering why we want JS to be faster, there's your answer. I'm not sure what's left to explain.

You seem to be saying "Browsers shouldn't do X because they are too slow." "Barring X, browsers are plenty fast and don't need to be any faster." I'm not sure why you don't see that those cancel out. Also X seems to be a fairly vague set of applications, some of which have working demos.

Regarding "my" nails and hammers, I'm actually not a huge fan of much of the tech involved in modern browsers. I'm just not able to ignore what Mozilla and Google are accomplishing here nor the interest that it garners from developers as a cross-platform VM. Can we stop trying to insult me out of having a valid opinion?

If we want make this personal - personally, I don't really care about any platform besides the ones I use, and those (deliberately) tend to be easy targets for portable C/C++.

That's apparently too much work though; people want (to at least believe they have) a single target. The browser is coming to be an option for that, whether anyone likes it or not.

Reply on news.ycombinator.com