Seriously though, wired connections are out. Bluetooth is the thing.
Seriously though, wired connections are out. Bluetooth is the thing.
EDIT: and the less said about pairing difficulties the better.
EDIT2: From the downvotes it seems that many people have had a radically different experience from mine, which is good, because mine has been awful.
HTCOne-Dell: 1MB file will transfer ~50% of the time, pairing took several tries.
HTCOne-MBP: complete no-go, doesn't even pair.
Nexus6-MBP: paired first try, works reliably at a blazing 100kb/s.
Nexus6-Dell: doesn't even pair.
Nexus6-Fitbit: takes minutes to download a day's activity over bluetooth classic, stalls out completely 50% of the time. BLE doesn't seem to work at all.
MBP-Fitbit: requires dongle, synced once, has had 100% failure rate ever since.
Dell-Fitbit: requires dongle, 100% failure rate.
Compare to USB which delivers tens of MB/s in bandwidth with 100% reliability and no pairing process (RIP plug and play). I love the promise of bluetooth, but in my experience it has consistently fallen spectacularly short of that promise in every regard.All other bazillion USB devices ever made are not designed to deal with security, and exposing them over the internet will blow up spectacularly.
Which is why the devices have to announce they support WebUSB to be exposed to any web apps, and can even restrict their usage to specific domains.
Because there's no such thing as a XSS attack?
...and that's why we have Web Bluetooth, which is already in the Chrome Dev Channel.
Seriously, this is the moment where we should just stop, kill all existing browsers, and start from scratch.
This is NOT acceptable, and this is probably the dumbest thing I’ve ever seen.
WebBluetooth, WebUSB, WebGL?
God I hope that this shit will never appear on any of the websites I visit, as I’ll make sure to patch it out of my browser.
It's shoehorning everything into ancient technology ill-suited for any of these applications, which is not exclusively Google's fault of course. First HTML was augmented with Javascript, which was augmented with XHTTPRequest, which led to an increased usage of Javascript (Here's where Google comes in), which led to a lot of manpower being invested in optimizing the Javascript engines (trying to run a quirky dynamic language as fast as possible) and then augmenting the browser with "native" OS features like:
* Full-screen mode
* Clipboard control
* Native notifications, with background workers, etc.
* WebMIDI
* OpenGL
* etc.
Which is basically like building a second operating system on top of the already existing architectures. Google tried to further push people this way by coming up with Chromebooks, which in reality actually serve to reinforce my point, since most (not all!) users find them just not sufficient enough.
That's what they said about JavaScript, and look how that turned out.
This is pretty much the web 2012, or most of German-language web today still.
For browsergames, let’s just use the same paradigm as with apps instead: Bundle them via node+webkit, and integrate a "run locally" API into browsers that automatically downloads a program and runs it locally in a sandbox, but seperately.
In the long term, for games we’ll need to develop a different concept anyway.
But there’s a good reason why no one develops 3D games in PDF, despite PDF supporting 3D objects, scripting, and modification of the document via scripts.