Hacker News Reader

Comment by taeric | Hacker News Reader

This is neat and all, but I wonder if things are really better moving to "in the browser." The discussion is of "upwards of 60% as fast as native." Is this using the same amount of processing power as native, or is this "67% as fast as native, using 200% of the CPU as a native solution?"

I mean, I realize that processors and machines are only getting more capable. It seems silly to start requiring faster and faster processors to achieve what slower ones could have achieved. I would rather we just kept achieving more.

View on HN

For a high level managed language, 67% would be pretty godlike. There are some C programs that are less than 67% the speed of their own -O2 compilations. If 67% native speed winds up being the average efficiency, that's plenty good enough for the vast majority of computing.

As recent history has been teaching us, doing more with less has mainly to do with getting more mobile, distributed, and ubiquitous. We're quickly reaching the point where that means something even "smaller" than a web browser.

EDIT: Could WhatsApp be the 2nd coming of WAP?

You ignored my 200% mark, though. If I could run this demo in the browser and it pegs all of my cpus, compared to running the same demo "native" and having half my system capable of idling, I'm not sure I see the win. Even if it gets to 100% of "native." (I hate that it sounds like I am claiming that is the case here, as I really don't know.)

A game like this is a singular and extreme case. I can see a really big win for lots of business software. With browser deployment, lots of logistical problems just disappear. Heck, the notion of traditional corporate structure starts to disappear: Corporations exist because they can provide lowered transaction costs in specific contexts of production.

I'm not sure I see the win. Even if it gets to 100% of "native."

Even if Unreal engine FPS don't get to 100% of native, that doesn't preclude the disruption of lots of other software distribution models, including entire subgenres of games. But it goes much farther than just games.

How does this accomplish anything that Steam isn't already accomplishing, though? I have only bought humble bundles, and I already have a couple of hundred games on Steam. Tempted to buy more.

And I don't own a windows machine.

How does this accomplish anything that Steam isn't already accomplishing, though?

Browser based distribution has the potential to have better security than Steam currently has. Of course, Steam could implement those things as well. It could well be that Steam or something like it will win over the browser.

I don't see how a browser based distribution has the potential to be better as far as security. I don't think it is foregone it would be worse, mind.

What does a browser by in terms of added security? Encrypted connections did not spring in to being with ssl. And, doing a secured stateful connection seems easier/better than the stateless messages method of traditional http applications.

Please re-read. Browsers don't have exemplary security, but, what they have can be slightly better than simple code signing. Also, I say it's entirely possible that the other platforms to leapfrog them. The problem with current sandboxes for native code, is that they disarm the participants while empowering malicious code.

I am rereading. I am also asking for specific examples of how a browser has potentially better security than a custom application. Because, I just don't see it.

Unless you are trying to say that something in a limited sandbox of a browser has limited capability outside of said sandbox. But... how is that not just as true of any other sandbox approach.

Right now, native code security is pretty much limited to code signing and sandboxing. Browsers go one better than code signing with restriction of communication. Additionally, entire classes of exploits are made much harder because Javascript is a managed language.

> I'm not sure I see the win

For a user that can install a native build, the native build will run better. No doubt. But, most users in the world do not know how to install apps, and even if they did they shouldn't because of security concerns.

For that reason, game devs know that asking people to install a plugin or a native build will kill off most of the potential users of their game.

Instead, if you just give people a link to click and it jumps right into the game, that will maximize the amount of users able to play it. This is the main reason for the anti-plugin and pro-web movement in games.

Oh, so native programs are the boogey man now, huh? I don't know where this whole push for Everything Must Be JS comes from, all it does is waste electricity maxing out Core i7's running some raster demo from the 80s.

> But, most users in the world do not know how to install apps

That's a ridiculous claim.

> if they did they shouldn't because of security concerns.

Equally ridiculous. All the new shiny HTML5 tech is also bringing its load of security issues and an ever-increasing attack surface as the Web Browser slowly transforms itself into an OS.

There's a valid reason for running small games into the browser, but there'll never be a good reason to do that for a performance demanding game.

"67% of native speed" means that for a fixed CPU workload, it will take 1.5 times longer to run. Of course this depends a lot on the benchmark, some run better and some run worse.

Note also that this is on the CPU. On the GPU, WebGL is already extremely close to native GPU speed.

The fixed CPU workload makes sense. I mistakenly took it to mean they simply got within 67% of the framerate of native. Mayhap my misunderstanding is even deeper and those mean roughly the same thing.

I'm still not sure I see the compelling use case. The tooling to create games that target various platforms already exists. Does this really widen the ballpark?

Measuring performance by framerate is tricky actually - it usually maxes out, and it's an inverse value, etc. It's a good quick measurement perhaps ("game X gets 50fps in Y but 60fps in Z", then clearly Z is better) but it's not an accurate measurement in many senses (for example both could get 60fps but one might use less CPU cycles).

Measuring execution time for a fixed, deterministic non-stop workload is the best thing in my opinion.

Makes sense. I still have to squint to really see the benefit here. :(

The web has always had the best discovery mechanisms. The problem endemic to Steam and the App Stores has been poor discovery. Good discovery mechanisms mean better information flow in the market, which generally means more innovation and consumer benefit.

But if the walled gardens get really good discovery, they would win and deservedly so. As it is, they smell a bit too much like crony capitalism.

I just don't see it. The web does not have any better discoverability than any store front that proceeded it. What it has is a virtually free cost of entry.

Take the game 2048 that made headlines here. I didn't discover it because of some intrinsic discovery mechanism of the web any more than if I was to just keep watching the games page on amazon.

No, I found it because someone could pop it on github and share with all for free. And, it should be noted, in this case the game is based off of a riff of a popular iphone game. How did that game itself get discovered?

This is not to say that I hate HTML and all it entails. I make my living there. I do, however, find myself finally beginning to question the supposed benefits it is bringing to the table.

For my final point, consider that Steam is allowing me to play games that haven't seen release for years now. In some cases I miss out because I run linux, but their efforts are drastically increasing my ability to play current and past games in ways that I just do not see this approaching.

The web does not have any better discoverability than any store front that proceeded it.

You're kidding, right? (Maybe not old enough to remember the world pre-Google?)

I'm not kidding. I am definitely old enough to remember the world pre google. I am also old enough that my kids can discover a crapton of stuff walking the isles of walmart.

Even now, I am more likely to discover a good game walking down the wall of gamespot than I am surfing the web. If I really want some discoverability, I go for magazines or similar digital fare nowdays.

Seriously, when was the last time you used google to find a game. Because, I don't think I have ever even heard of someone doing this. What I have done is browsed the lucasarts website hoping for news of upcoming releases. Or pulled up arstechnica's game section to see what is current.

Or, more recently, subscribed to humble bundle to see what they have to offer.

I am not (and can not) claim that the internet has not helped find some games I otherwise would not have found. I assert that this is because it hooked up some developers with a distribution mechanism they did not have before.

And yet, even as I type that I know how bloody stupid it is. I am also old enough to remember dialing in to a BBS in Texas, as they were the closest I could find to download Doom, Jill of the Jungle, Commander Keen... It is not like there were no methods to get games created and distributed pre google.

Seriously, when was the last time you used google to find a game.

Seriously, Google's the first place I turn to to find anything but a game.

It is not like there were no methods to get games created and distributed pre google.

But it did and does seriously help people find almost everything. As far as discoverability of games, I'm not sure what the problem is. I think the sad truth is that most games that aren't the big hits and aren't beloved long tail cult classics just suck. That said, it's kind of hard to make sure your long tail cult classic gets traction in an app store, unless you have the help of an outside community, which is usually helped tremendously by the web and by search engines like Google. (Just as BBS helped back in those days.)

The same can be said for all development over the past 15-20 years. The reality is development time and cost is drastically lowered when intermediate developers can produce working software with minimal consideration toward optimization, lowering resource usage or decreasing overall package size.

And better tooling helps here more than anything else. The giant elephant in the room nobody likes to speak towards is that Flash dominated not because it was a great language, but because they had awesome tooling around it. This is doing very little to address that.

Now, the Unreal Engine is a great tool in and of itself. Having it target the browser is the questionable part to me.

If you look at the browser makers who primarily target operating systems other than their own (Safari doesn't count, as Safari for Windows is mainly a developer tool, not a product; and Opera doesn't count, as it's now based on Chrome, rather than being its own), they're pushing heavily for the browser to be the userspace, both in terms of shipping an OS based around their browsers (ChromeOS/FirefoxOS) and shipping apps to current OSes using their browsers rather than native code.

This demo may focus on the high-end graphics, but I doubt that's the reason anyone is investing effort into this. Mozilla wants cross-platform mobile games on Firefox OS, and Epic (I'm guessing) wants to be able to run games on Firefox OS/Chrome OS/Sailfish/Tizen/Ubuntu Touch/flavor-of-the-month that supports HTML 5, as a long-term hedging of bets. Not all of those explicitly support asm.js, but Chrome is going to get better at supporting asm.js even if it never gets to feature parity with Firefox, and the non-iOS world is likely to be running a derivative of Chrome or Firefox.

So, if you look at the four main browser vendors... Well, two of the four browser vendors, you will find that browser vendors would like to extend the reach of the browser.

Not sure how that is surprising.

The argument for wanting to target all of the platforms seems nice. Except the major tooling companies that want to target multiple platforms have already learned how. Seeing games come out on PC, Xbox, and Playstation is proof enough of that.

So, again, what does this buy that the tooling does not already support? Especially if you simply design things such that they can be cross compiled with C.

Regarding tooling, I agree Flash's tools were a huge benefit for it. The same is true for engines like UE4 and its competitors, they all focus a lot on tooling. When those engines are ported to the web, the tools are part of that.

Some tools might not just work, of course, like profiling tools or anything else that runs while the game executes on the target device, as opposed to the dev environment. But:

1. I have seen even things like profilers being ported together with the engines. Takes some porting but the result is you have the engine's normal full set of tools.

2. You have the in-browser tools as well - all modern browsers have profilers, debuggers, etc. And also they support source maps, which means they can see the original source code and not the hard-to-read compiler-output JS.

Right, but it is safe to assume there will always be native targets for UE4. So, how will the web target really be a benefit? I can't imagine the DOM inspector will really be that useful in designing a 3d game. Am I wrong?

The web target is mainly of benefit in getting to users, not in designing the game. For design, you would use the engine's normal tools for all targets anyhow, web included.

As I said elsewhere, I only take this if you are saying "users" and meaning "developers."

I can see the point, but I see access to the tools as way more valuable than this. And with the tools, I'm curious just how many more "users" developers will truly be able to aim for. One off demos not withstanding.

No, I meant users: You ship your game on the web, it reaches its users - the people playing it - directly. That's the benefit of the web.

I agree tools are important too, but the main benefit of the web is it is runs everywhere, and no one controls it.

How many games are there that run from links off the web that are actually making money? (Not being an ass. I seriously want to know if there are any numbers on this.)

I don't have business numbers, but there are huge amounts of successful games on the web, using Flash (for example FarmVille on Facebook, etc.).

The issue of course is that Flash has many technical issues, doesn't work in all browsers/all OSes, and so forth, hence the move to do the same games in HTML5.

azakia, a Flash App once requested my permission to turn on my Mac's built-in video camera and microphone.

Funny how I was just then commanded by G-d Almighty Himself to unstall my Flash plugin.

While Flash does require permission to enable video and sound input, I am dead certain that someone with a clue could find a way to do so without actually asking permission.

It's not like those who like to hang at Websites of Ill Repute are diligent about keeping their patches up-to-date.

67% native speed == 1.0/0.67 native processor requirement == 149% CPU compared to native solution.

Apologies for not responding. The post above talking about how this wasn't necessarily referring to frame rate basically hit my misunderstanding on the head.

Games performance is often GPU bound. If a driving language (C++, JavaScript of whatever else) is fast enough to compute application logic without delaying frames, it doesn't really matter if it is x% slower compared to some other language. GPUs in WebGL are programed using native shaders so there is no performance penalty for GPU computations.

Then explain the "within X% of native" from the link. If this demo is strictly limited by the GPU, then why isn't it as fast as native, period?

The X% from the link is not about performance of the demo, but about performance of asm.js: "In less than 12 months, optimizations have increased the performance of Web applications using asm.js from 40% to within 67% of native, and we expect it to get even faster". To me such number doesn't mean much, it most likely refers to some micro benchmark that achieved 67% of native performance.

Especially considering that asm.js isn't really using a JS execution engine. You can smuggle a low-level machine code via any mechanism. As I understand, without asm.js specific optimizations, it doesn't really work.

I know, it's a cute way to get some movement without the political nightmare of having to decide on a proper VM for the web. Since it's "just JavaScript", other browsers will run but be really slow, leading users to blame the browser. At least, I guess that's the idea. It's still a shame they have to resort to such tricks.

It is true that most other browsers don't have special compilers for asm.js, but they still tend to get pretty good performance out of it.

Of course they do! asm.js is a collection of everything in Javascript that optimizes on the current hardware. It's not the least bit dynamic, i.e. it is not Javascript.

And if you run that code in a non-asm.js browser, it'll still be compiled to native code if the application benefits from it.

Reply on news.ycombinator.com