Web Apps set us back 20 years in pretty much every respect except ease of deployment (1992 - people are impressed that Wolfenstein 3D gets 60FPS on a 100MHz Pentium; 2012 - people are impressed that Wolfenstein 3D (in Javascript!!!!111omg) gets 15FPS without sound on an 8-core 3GHz box).

With the exponential rate of development I doubt it'll take a full 20 years to catch up, but it'll still be a while before we've completely reinvented all of the wheels...

But yeah, for the forseeable future, "look at how I re-implemented this ancient technology with modern foundations, and it only took half the time! (And 10% of the efficiency and 100x more RAM)" is all we have to look forward to :-(

Parity is the wrong measuring stick.

Web app performance will always be playing catchup with native, and while the performance gap may shrink (perhaps to the point of irrelevance) it will never be eliminated. The OS and device makers are making the rules.

The real future is in our increasing ability to recognize and build to unique platform advantages in integrated ways. Dismissing the web platform as merely 'distribution' minimizes the value of a universally accessible, instant connection to everyone. It allows for different kinds of experiences unrelated to native performance. As the performance gap b/w platforms decreases, we may see more rich experiences for a web audience that's interacting in realtime with native or console users, broadening what's possible for everyone.

I think this overlooks all the pluses of this new "medium". How did you get your copy of wolfenstein in 1992? Travel to the radioshack, get a stack of disks, feed them one by one into your trs80? Within seconds this morning I was playing this game - with a 1000 other people simultaneously. Amazing in my book.

It's not competing with 1992 distribution though, it's competing with 2013 distribution.

I just bought my son a digital edition of Diablo 3 the other day. It was far from smooth sailing.

You had a problem with it? I haven't tried Diablo 3 specifically, but I find in most modern distribution platforms like Steam (or similar utilities from Blizzard) you just buy, click, walk away for 2 hours, and when you come back the game is installed and ready to play. It couldn't be easier to install native apps! -- when every thing works correctly.

One particular thing I noticed about Diablo is that it was playable long before it actually finished downloading. Most of the maps, video and artwork was downloaded as I played the first few levels. Pretty cool.

But is Diablo 3 played in a browser? Thought so.

In exactly what way is this question a follow-on from the parent comment? The statement was, to paraphrase: "Purchasing and installing native applications can still suck, even with '2013 distribution'." IOW, all that's been saved in 20-odd years is the drive to the retail store, the drudgery of swapping floppies and (usually) the task of manually configuring a memory manager. We're far from an instant-on, pay-and-play world for native apps (and in some cases you still need to be connected to get moment-by-moment permission to run the app you "purchased"—the internet as dongle).

I could also be playing Wolfenstein or one of many, many games in about a minute via Steam.

Wolf3D was shareware, so the preferred method was simply to make copies of the floppy and distribute them to all of your friends. I remember having more games than I could play in ~1993.

I don't remember how I got it but I'm sure I didn't go to a store. It really wasn't that hard to get either through BBSs or copying from a friend. It went viral and everyone had a copy. BTW, by 1992 PC clones had won, trs80s were long gone.

A 100Mhz Pentium in 1992? More like a 25Mhz 486 if you were lucky, my friend made it run on a 286. And you'd get about 15fps, wolf3d used to give people brutal motion sickness.

Wolf3D is also an interesting example because the rendering is done in software (so your high powered HD video card doesn't help at all) and I guess a lot of development time was spent writing asm routines/hacks to take shortcuts with the necessary math.

To be fair, a lot of the reason that people are remaking these old games is because people like playing old style games and the people building these demos are probably doing it in a very small team (or even solo).

It should certainly be possible to remake Half-Life (maybe even HL2?) entirely in javascript/WebGL or make more sophisticated 3D games. But we won't see it until some bigger gamedev is willing to risk a fair chunk of change on the browser as a gaming platform.

A 286? LUXURY! We only had a 8086 with half a megabyte and we had to hook it up to a bicycle generator to get electricity for it!

8086, you were lucky!

What did you have? A TI-81 calculator?

> But we won't see it until some bigger gamedev is willing to risk a fair chunk of change on the browser as a gaming platform.

They are, just as they're active on mobile platforms - EA, Epic and Square-Enix are notable examples. But they don't bother with AAA games (much as they like to pretend they are and attach them to those franchises), instead they target the casual player, that spends up to half an hour on a game per time, and/or that gets addicted to addicting games (w/ microtransactions). And the formula works for them; low development cost (5 - 10 dev team), high returns. Epic's Infinity Blade (and sequel) are the highest grossing games (in terms of development cost versus returns) of all time, at least, for Epic.

A 486SX 33 in my case. Couldn't afford the math co-processor at the time. :)

My family's first computer was a 486DX33 w/ 8MB of RAM. I'm not sure if it was in 1992 or a bit later though.

"wolf3d used to give people brutal motion sickness."

Most FPS still give me motion sickness, but I distinctly remember throwing up with the first Wolfenstein.

This is a naive interpretation. It's easy to imagine that "application quality or capability" is some easily measured metric tied to easy to measure numbers (like FPS or megahertz). In reality for many applications performance is not the long pole, so moving them to the web adds many advantages. I find it weird that someone could make the claim that "web apps set us back 20 years" in 2013, when web apps have transformed the world economy so tremendously (google search, web mail, amazon, online banking and investing, etc.)

> (google search, web mail, amazon, online banking and investing, etc.)

The transformative power of all of those (excepting maybe GMail) was realized in the form of cgi-generated webpages (click, refresh). Performance is not a requirement for those applications, whereas it is very much a requirement for interactive games. 20 years might be a little too harsh, but only a little.

Performance is the most important feature. Also on web apps. https://www.google.com/search?q=%22performance+is+the+most+i... 2M hits on exact match can't be wrong.

The most impressive html5 game I've played so far with nice graphics, music, and most importantly pretty responsive feedback is 'Save the day' : https://turbulenz.com/games/save-the-day/play

The first time I played it, I had assumed it was a Flash game, and not html5, based on the quality of it.

Is that really an HTML5 engine?

It forced me to download a DMG containing "TurbulenzEngineInstaller.app" which itself contains "npturbulenz.plugin" and an "install_script" that installs that plugin into "/Library/Internet\ Plug-Ins/".

About as good as you can get plugin installation to be, I guess, but it's not what I'd expect from an HTML5 game.

The site offers to install a plugin as a fallback for browsers that don't appear to offer the required HTML5 APIs (mainly WebGL). This allows the JavaScript/WebGL games to run on a wider range of browsers (particularly IE and when required APIs are locked behind a developer switch.)

that game is totally awesome!

The medium is just waiting for the game devs now: remember back in 2004 when someone wrote a brilliant pretty-much-exact copy of Lemmings in the browser? Well, it's taken 9 years and the HTML5 buzzword to start getting game devs to start poking round in the space. Now that it's started we can move past all of the basic nostalgic tech demos and start writing some more innovative stuff!

[Edit: it's back online, woo! http://www.elizium.nu/scripts/lemmings/]

I thought that Emberwind port that Opera wrote/commissioned to show off their HTML5 support was pretty impressive already (and that was in 2010):

http://operasoftware.github.com/Emberwind/

This is how we get there. HTML5 is pretty fresh and it's games like this that let us understand it's capabilities and to improve upon them. I mean, this is a mini MMO implemented in HTML5. That's a pretty big step forward from Pacman in HTML5 already.

Yeah, I definitely agree that this is a big step from anything I've seen thus far.

This was more to kick off a discussion about "are we there yet?", and if not, what is still missing?

I mean, I know what I think is missing, but I've not tried building HTML5 games to understand if HTML5 is the bottleneck, or if other dependencies are the bottleneck.

Perhaps what's missing is a good reason for choosing HTML5 over traditional technologies when you're investing in a new project.

Pros:

Runtime is very widely available

Cons:

Relatively poor performance

Monetization strategy is not clear

Browser differences increase cost of development

You also have to mess with Javascript on some level, even if you are compiling down from something else.

People who are professional game developers have invested a lot in C++ , have a lot of experience in that area and tend to see Javascript as something for developing websites with.

So on top of the other problems you have persuade them that it's something worth spending the time to get proficient in.

If you're coming from a deep machine and C++ understanding, it's not that JavaScript is tough to become proficient in, but rather, that you of all people have every reason to fully comprehend why it's such an awful implementation choice for this proposed purpose. It's not as if the PC or mobile game market is suffering for lack of cross-platform browser-based compatibility, so why switch to a suboptimal tool?

Do you still have to deal with all of the DOM stuff in html5/javascript?

Yes and no. It's all still there of course. I imagine though if you want to build a game you don't use DOM elements for sprites etc. You just create a giant <canvas> element that you draw to as you would draw to a frame buffer in DirectX etc. You could use DOM elements for the UI though I guess.

Yep. If you examine the source of this game that's exactly how they handle the game itself.

Here is a link to html5 pacman if you're interested. It was DMCA'd on github, but it's here now: http://pacman.shaunew.com/

It's broken on chrome now for some reason, but works in IE9, Firefox, Safari and Wii-U.

We need to stop excusing games being slow because they're written in HTML5. They are still behind Flash games from 10 years ago.

They’re really not. Go look at anything on (for example) Turbulenz ( https://turbulenz.com/ ) and that’s as good as anything Flash has done.

All it did was blow up my browser's RAM usage to 2GB and then deliver ~2fps.

IIRC Flash did better.

If by "better" you mean "blew up my browser's RAM usage to 2GB AND maxed out an entire core" then that's consistent with my flash experience (on 64-bit Linux, which I realise is not exactly a first-class citizen)

I agree complaints like this are currently valid in some respects, but the good thing is that feedback loops like this will eventually result in the same efficiency we come to expect from flash games on HTML5.

Eventually, but not any time soon.

HTML5 just needs a better sound API (e.g., programmatic playback, midi) so that we can make better games/apps. Many games just fall back to Flash for their sound.

The Web Audio API has already shipped on Chrome, FF and even mobile https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specifica...

I'll just leave this here.

https://www.google.com/search?q=html5+midi

The support for this is questionable. It's barely acceptable in Chrome and even in Chrome it falls really short.

The timing is awful in a lot of cases which makes it pretty much unusable for anything but maybe background tracks. I've had audio clips that had to be played in a 50ms time frame fail to play back a third of the time on occasion.

I'd rather have no sound than buggy sound.

Thanks for your link, but I've investigated MIDI support in JS. I actually work on piano/guitar apps, and would love to build a high performing, low latency app that hooks up with a physical keyboard. If you know how this can be done, please let me know! The last time I looked into this, the best solution I could come up with was a Java applet. :-(

The way forward is going to be via the Google-led Web Audio spec, as well as the complementary MIDI device spec - it's not "there" yet, though, since these specs are still non-finalized. But I'm working on building up the playback capabilities as a side project. I made a "true" Soundfont2 + SMF playback engine for Flash/Haxe, which is open-source(zlib) and somewhat usable in real-world: http://spacecreeps.com/apps/triad-synth/index.html

Now I'm working on the next generation of it, since I was still learning my way around audio with that one and made a mess of the architecture. I'm starting off with a Web Audio-for-Haxe project( early stages, you can watch it here https://github.com/triplefox/hxAudio ) - I'll be building off of that to add the synthesis and MIDI parts, so that you have pretty much everything needed for the playback parts of an audio app; recording isn't on my radar yet - especially since the specs are very early still. It will be possible to compile out the lib to pure JS, so you won't necessarily have to be using Haxe if that's not your workflow.

Aaand one of those demos killed Safari

I've observed that people actually want old school style games but they en masse don't want to install emulators to play them. I think HTML5 is just a redeployment device to the time when computer games were just simple and fun.

> But I'm genuinely curious: at what point will we stop being fascinated by what can be done in HTML5

Go in any store that sells video games. Look at the backs of all the boxes. Find similarities.

With more and more "nativish" APIs being added to HTML5 (like the whole suite of mobile device APIs coming with Firefox OS), browsers are becoming functionally more and more similar to operating systems, just that the design is terrible for an OS. Unless browser design is revolutionized in and out, we will have to keep making compromises like this one. We need to integrate Web capabilities within the OS, not the other way round. That said, I'm off to play Bomberman now.

If you're interested in HTML5 games that don't feel like HTML5 games, I think that Kiwi Run is a great example. You can play it on the web here: http://www.icepopbeat.com/ but they also used Game Closure's devkit to deploy the game on iOS and Android; the performance looks great on all three platforms. As far as browsers though, I've only played it in Chrome :)

This is a pretty good start: http://play.goko.com/Dominion/gameClient.html

Or, you know, the less laggy and more functional http://dominion.isotropic.org/

I actually wrote a chrome extension to add a log to goko https://chrome.google.com/webstore/detail/goko-log-viewer/ka...

Post about some of the goko's issues http://www.roadtolarissa.com/speed-issues-with-gokos-online-...

I'm glad that it's done in HTML5, but man, if you try and dissect the code - it's insane. No wonder they had large amounts of bugs for quite some time.

Looks nice, and not only is the source code not minified/obfuscated, it's actually well commented.

We need to treat HTML5 games like games. We need to market them and release them and form a community around them, and then we need to release updates and make them moddable.

When will tools like Flash be created for HTML5/javascript? (with drawing tools, animation tools, etc)

Some stuff in that direction http://www.createjs.com/#!/EaselJS http://www.createjs.com/#!/TweenJS http://www.createjs.com/#!/SoundJS

sad that flash has so many issues (security, performance, etc) because there are some really nice compositional tools for creators in that ecosystem.

I think adobe is already making something like this. I'm not sure but I think its adobe edge?

Look into Red Ice, a local multiplayer HTML5 game played with Xbox gamepads.

I just don't get it - someone please smack me down and give me a convincing argument on how HTML5/CSS/JavaScript is a more innovative technology than Flash/Silverlight?

The only pro I know of is that it runs on IOS and flash does not (actually flash does run on JailBroken IOS). In 3 years IOS will power less than 20% of mobile devices. What then?

My big rub with HTML5/CSS/JavaScript and all this standards crap is that it moves sooooo slowly. I prefer innovation at whatever speed the minds of man can allow. Now we are restricted to creating frameworks built on top of (and limited by) HTML5 to create any kind of innovation (same with JavaScript) it makes me sick. I saw apps like this a decade ago written in Flash. I know that widespread compatibility is the reason that things like HTML5 win out, that and lazy developers who don't want technology to change/innovate because that would mean that they would have to learn something new more often.

What is my solution? I prefer the plug-in model. I think the spec that browsers should follow is one for an secure and OPEN Plugin architecture. If this concept was adopted, we would have a lot more (and better) options besides HTML, Flash and Silverlight to write web apps in. I think of it like this. Look at the iPhone, I picture every app you download as basically being a plug-in for IOS. Each can be written with their own completely different language and UI markup (and many are). Over 30% of IOS apps are not written in C/Objective C. There are a myriad of tools, frameworks and development environments which compile other languages and link them against the IOS libraries. This is how the web should be. That is more OPEN than following a spec that is publicly available, it gives inventors/innovators much more FREEDOM to make the world a better place.

We tried the plugin model back in the 90's. It was uniformly rejected by users and developers alike. Flash was pretty much the only plugin that managed to get wide enough adoption.

And flash is going the way of the dodo because innovation couldn't happen at top speed, because it was limited by a gatekeeper that insisted on keeping it closed.

The lacklustre support for Silverlight was a demonstration of how badly we were burned by flash.

While it's taking a long time to catch up, we're now free to expand the capabilities without being in a situation where a single party can hold everyone for ransom by refusing to support specific browsers or OS's.

There are many negatives to having HTML5/CSS/Javascript as the foundation, but they are dwarfed by the problems of the alternatives we've had to deal with.

First off, you are describing a plugin, I am not saying that the Flash plugin was not without it's problems. Only that it could do more than HTML5 can do today 8 years ago AND had almost universal penetration. Stepping back is my problem with standards and HTML5. I am not saying that Flash ever was the answer. I am merely using it as an example that proves that standards will always hold back innovation, and I think that an open plugin standard could yield the best of both worlds.

We tried the plugin model back in the 90's. It was uniformly rejected by users and developers alike.

This is just wrong. It was on 98% of desktops and there were over 1 million Flash developers. Mobile is what really hurt flash (actually IOS's rejection of it)

flash is going the way of the dodo because innovation couldn't happen at top speed, because it was limited by a gatekeeper that insisted on keeping it closed

It still managed to stay FAR in front of other web technologies which stood nearly at a standstill for over a decade. Closed is not what I am suggesting anyway. Sure someone can develop an plugin that is closed, but the plugin architecture itself will be open and adopted by all browsers who want to compete.

The lacklustre support for Silverlight was a demonstration of how badly we were burned by flash.

I disagree, I think that Microsoft's stagnation and terrible management of 95% browser share is what doomed any web UI tooling to come out of Redmond. Internet Explore was so riddled with bugs, so vulnerable to virii/malware and so stagnant that it became a stench in the mind of nearly every web developer. This was the biggest mistake IMO that Microsoft has EVER made. They could have pushed innovation and owned the search engine market at the same time. They will never get it back from Google now.

While it's taking a long time to catch up, we're now free to expand the capabilities without being in a situation where a single party can hold everyone for ransom by refusing to support specific browsers or OS's.

Having a standard for plugins in the browser would not allow this situation to happen. A lot has changed in the last 12 years. Sure Macromedia was the only one who made a viable plugin to fill up the Internet Explorer window with, but that would not be the case today. We would see open source and competing products popping up everywhere - Just like the JavaScript/CSS/HTML5 frameworks we are seeing pop up every month. These frameworks try to innovate past the limitations and cumbersome methods that the standards constrain us to. We would be a lot better off if there was an open and secure plugin architecture with access to a VM, Drawing and DOM API (Perhaps the HTML5/CSS/JavaScript implementation would even run on top of this API).

They could always use WebGL to get a 10x improvement in graphics for the same performance requirement.

They could. But then they would lose support for 30% of their users.

I already implemented webgl renderer, but it has some bugs. I will switch it on ASAP. Both 2d and webgl renderer has the same interface, but different kind of optimizations, so there's no point to use webgl without acceleration. If your browser can draw 20,000 rects in 500ms, then bombermine will use webgl.