Can we please not restrict APIs to https only ? My game system requires http because it serves pages from your home computer/console to your phone's browser on the local network
That's not really a solution either. You really expect your house guests or people visiting a museum or event to do a technical reconfiguring of their phone just to interact with the installation or game?
I would think that museum should be able to get a SSL cert.
But yeah, "SSL-only" kinda breaks the end-to-end principle since we have no mechanism to assign SSL certs to endpoints on demand. So it seems flawed on a conceptual level.
Most of these types of exhibits are created by art students and shown at events and happen to be run by museums. Neither the students nor anyone at the museum have any tech experience whatsoever. As the system is now it works for them. But when HTTPS is required they'll all be S.O.L.
I'm not really sure how that would help. Wouldn't all the phones be getting their DNS from the local router? How would that work without having each users have to configure DNS on their phones? Also how does running DNS server help? I don't expect people to know how to configure their router to point to some DNS server running on their local PC. Maybe I'm mis-understanding the suggested solution
The application redirects to <local https host>, and to make the certificate valid, have a wildcard *.example.com. With the DNS server you can have e.g. https://192-168-0-7.example.com/ resolve to 192.168.0.7.
All of this, of course, only if there are some desired HTTPS-only features in the browser.
It's a pain, and I've yet to find any good guides. I'm actually in a fix right now because I want to develop over localhost, but need this Flask site to work on HTTPS. I'm sure it's possible, but I have yet to find any guides or examples that make it straightforward. I love that we're moving towards security, but I wish it was easier...
Ah, right, and I forgot how much the mobile browsers' UIs suck for this. On desktop it's just "yeah, I know what I'm doing <click>". On mobile they invoke threats and hide everything under barely visible links.
It also requires people to buy a domain before they can host a website. This is already a bad idea, and it makes even less sense as IPv6 deployment picks up and more people use clever IPv6 addresses instead of hostnames.
It doesn't interface nicely with facilities provided by host OS.
Providing file IO to a fenced-off, per-origin part of the filesystem would allow people to roll their own data serialization and allow users and desktop applications to drop in/pull out files as they desire.
I wonder what they mean by scalable source maps? The last time they proposed an alternative to source maps they basically proposed shipping down an AST structure which was even larger. Current source maps already tax the debugger for large programs, so much so that for GWT we had to implement optimizations in the source map generator to avoid generating nodes that are not helpful for debugging but which cause bloat.
This all sounds great, but I didn't see anything about simple HTML5 Canvas performance. Firefox is in dead last when it comes to the 2d rendering performance. I can run our HTML5 games at a smooth 60 FPS on Chrome, Safari, Opera and IE, but only get 10-15 FPS on Firefox on the same computer.
It is not related to a specific platform, we've tested on many different computers and operating systems. We also get reports from users all the time saying the game is barely playable on Firefox but works great on any other browser they use.
Hey, I've been trying to look into this a bit. Which OS (or OSes?) do you see 10-15fps on? Because so far on Mac I'm not seeing any differences compared to Chrome, but I may just be missing it...
My main OS is OS X and this is where I've done the most testing, but we see similar performance degradation on Windows as well. We've tested on multiple Macs and Windows machines. It is almost as if no hardware acceleration is being used.
Firefox generally uses the same 2D vector APIs as the native host system for canvas (in particular, D2D on Windows). So this sounds like some kind of (possibly platform-specific?) bug.
Yes, it's part of the OpenWebApps[1] initative. As far as I know, however, there's no standard way to package them up with the runtime for shipping[2], except for XUL Runner (which does not target OpenWebApps). For Android, there's an APK packager[3][4].
This is wonderful news. When this takes hold (and assuming the driver situation improves), I'll be able to finally get rid of my home Windows game machine in favor of GNU/Linux.
64-bit Firefox is available in the Beta channel. It may "soft launch" in Firefox 40, but some features are still incomplete (like NPAPI plugin support).
One of the things Mozilla could do is to make Flash run better.
One of the few things Mozilla CANNOT do is to make Flash run better. Flash is closed source, proprietary software, owned by Adobe. Google did their own implementation (of at least the browser interface + sandbox), I supposed after signing plenty of NDA and handing money over. That's not something Mozilla can (or should) do as an open source project.
Whatever plans you will go looking for at Mozilla, you'll never find "improve Flash" in one of them, even as an option. It just isn't possible. It's like asking Mozilla to make Office run better.
They've offered Shumway as an interdependent re-implementation, but I'm guessing it has tons of compatibility issues as Flash isn't a standard.
You're probably better off just uninstalling Flash in Firefox, to be honest.
On the contrary, "improve Flash" is part of Mozilla's projects to reduce Flash and plugin problems in Firefox. (I'm a program manager at Mozilla coordinating some of this work. :)
We work with Adobe to identify and fix Flash crashes collected by Firefox's crash reporter. We've made NPAPI plugin initialization asynchronous to avoid Flash blocking page load. We're also prototyping a new plugin sandbox to replace Adobe's Flash sandbox (which is based on an outdated fork of the Chromium sandbox).
Here is more information about some of the plugin work:
Flash runs better in Chrome than it does in Firefox.
Therefore, either the Flash people are deliberately detecting that it's being run in Firefox and slowing it down, or Firefox is doing _something_ which has made it stutter intermittently on every PC that my wife plays Facebook games on.
Would you care to hazard a guess as to what might be going on?
Chrome's Flash plugin uses Google's Pepper plugin API (PPAPI) instead of NPAPI. So Google can more tightly integrate Flash and Chrome. I've heard from someone familiar with the code that Google's Flash "uses 110% of the documented Pepper API", meaning there is lots of undocumented or underspecified details.
I wish that alternative was confined to a plugin running in a rectangle on the page. Otherwise game theory incentives make every site add a megabyte of JavaScript to every article, and stop you from reading unless you load the whole megabyte.
The only reason flash is blockable is because other web technologies, primarily open ones, have limited the need for it. If no attempt was made to match the feature sets of closed, single vendor plugins like flash, realplayer, QuickTime, ActiveX etc, then the majority of the webapps and media sites would be made using those tools. I think the same is true for games now. Do you really want every game engine developer to have their own plugin, with all the security vulnerabilities that will entail?
It's disappointing to me that it's 2015 and we have yet to have a good solution for browser games. Flash is still your best choice by a huge margin.
4 years ago I was very bullish on HTML5. Flash was dying, HTML5 was the future! It was right around the corner! I think a lot of people agreed with me.
4 years later - what has changed? Decent webGL support but still driven by a terribly slow javascript runtime. ASM.js gets us halfway there but it's brittle and does't even run in Chrome so it's basically worthless for anything that isn't a tech demo. The audio API is also still very limited.
We've been trying to port our Unity mobile app to webGL for 6 months now and it's been nothing but pain. In hindsight, it was a mistake. I was bullish on HTML5 back in 2011 and I was bullish on webGL in 2014. I was wrong, again.
So, I'd like to have faith in these efforts, but as they say, "Fool me once, shame on you. Fool me twice, shame on me."
First off, HTML5 has come a long way – there are still areas that need work, but generally I've seen lots of great HTML5 games and the field has improved remarkably in the past 4 years.
WebGL support is now cross-browser. The JavaScript runtime is not terribly slow, and I don't know if you're a bit confused about ASM.js – it does run in Chrome, and pretty well too. However, it's likely to be displaced by WebAssembly going forward, if I understand correctly, and that will be cross-platform and cross-browser.
It'll take a little while, but we're on the way there! Unity's HTML5 examples are pretty good – http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
> I've seen lots of great HTML5 games and the field has improved remarkably in the past 4 years.
HTML5 has come a long way, but I'm talking specifically about non-trivial games. For that, it's quite difficult to use it in a "we are going to make money with this!" way. I have seen some success with people writing their whole game from scratch to work within the very limited scope of HTML5, but most of the time those games are still pretty simple. Even so, I will concede that maybe this statement is geared more towards people trying to do cross platform stuff.
> ASM.js – it does run in Chrome
ASM.js runs in Chrome but it's not accelerated like it is in Firefox, that's what I mean. I was not speaking literally.
That's a demo. It does not demonstrate the problems that real developers with real games and real codebases are having with webGL. For example, it does't do any network communication with a server.
And, this game is tiny. They have 14.5 mb of assets and 4 mb of javascript.
Our game (it's a Slot Machine so it's not like it's super complex) has 23 mb of data and 16 mb of javascript. This is much more realistic. You can't do a whole lot with only 4 mb of javascript.
Outside of games by Unity my personal experience for "Cross-Browser" JS game frameworks has been highly negative. I wanted to try making simple games with JS but most / all the frameworks demos I tried out didn't seem to work on "all" browsers. It wasn't a lag issue, the biggest thing was just getting it to become responsive to my keyboard, you'd think that would be trivial right / not considered an issue "in 2015"? Guess not.
We'll probably have to wait a few more years until Webassembly and the easier to use and faster Vulkan API comes to the browser as well.
I know they've been working on WebGL 2 (OpenGL ES 3.0-based) for a while, but if it doesn't ship within a year, they might as well scrap it in favor of a Vulkan-based API.
WebGL/OpenGL and Vulkan operate at different levels. I suspect that OpenGl and Vulkan will co-exist and it is likely that WebGL and a web Vulkan-equivalent will also co-exist.
The other thing that really sucks right now for game developers is that Chrome has disabled its NPAPI plugin support so you can't rely on the Unity webplayer anymore either.
As the CTO of a mobile/web game startup (using Unity), I'm really struggling on what to do here. We have been trying to launch on Facebook Canvas since late 2014 and so far the finish line isn't even in sight.
Browsers are quite capable with HTML5 and WebGL these days. We've built an entire MMO with hundreds of thousands of lines of hard-coded Javascript that runs fantastically for tens of thousands of users (most players don't even know it isn't flash). You can take a look at it at http://casinorpg.com.
http://docs.happyfuntimes.net
Either that or please suggest a viable workaround