Overview of New JavaScript APIs Now Supported by Most Mainstream Browsers | Hacker News Reader

Overview of New JavaScript APIs Now Supported by Most Mainstream Browsers

sitepoint.com

62 pointsfagnerbrack19 comments

There's also a few less well supported but perhaps more exciting APIs just around the horizon, or already here hidden behind launch flags. I've been having fun with:

# Web Audio

Spectrograms and synths, this one is fairly mature, no IE support of course, but everything else supports it.

# MIDI

Mostly fun with knob and slider controls for various sideprojects. No support anywhere save Chrome.

# WebVR

Works surprisingly well, I find es6 to be much more friendly when validating random VR ideas than Unity or Unreal, which are basically the only other options. Requires a custom build of Chrome or dev Firefox, also works in Cardboard via polyfill.

# Gamepad API

Self explanatory, some games are just more fun with gamepads, now those games can be webgames. Works pretty much everywhere

# WebGL2

Transform feedback, more than one Render Target (deferred rendering with just one requires some extremely clever swizzling that's really not that fun to work with/implement), Instancing, Uniform Buffers and more. Tons of fun stuff that will bring the state of 3D graphics in the browser a lot closer to today. Behind a flag in Chrome, supported in Firefox.

I believe chrome's webGL 2.0 is about to be on by default if I'm reading this right; https://www.chromestatus.com/features/6694359164518400

# WebRTC

P2P communication (data, video and audio). Almost ready except for safari.

# WebBluetooth

Very experimental but some of the demo projects are really cool (control an AR drone quadcopter from a webpage).

Oh yeah, WebRTC! I forgot that one. I wrote a little multiplayer hovercraft racing game using WebRTC via peer.js last year. Super fun to explore programming networked systems in js.

Is there any way to do this without a central server coordinating the peer connections? I'd love to host something off a static site but I've not figured anything out yet.

You need something for the signaling part (sending the WebRTC offer, answer and ICE candidates to establish the connection).

It's not necessarily a «central server», if you can convince you users to send each other the info text-encoded via Facebook or any messaging system, it will technically work (but it won't be really ergonomic for you users ;).

I wonder if some people provide a SaaS solution for webRTC signaling. Quick survey: would you be willing to pay for it ?

My specific thing was somebody asked for a demo of a heatmap, I knocked up a page that heat mapped the pointer and wanted every user to aggregate to the map.

So no for such a demo I probably wouldn't be coughing up.

For a demo you can just code a 20-lines signaling server using websocket with nodejs or anything.

WebRTC is realy cool, but does not work in Safari.

Did cost us quite some time in a project.

> Almost ready except for safari.

Unfortunately, that's not that simple.

First of all, Edge doesn't implement the dataChannels, and FF and Chrome implements a slightly different version of the spec[1] (and neither implement the latest one) and things still break from time to time :(.

[1]: fortunately, it's still compatible with each other, but the API as a few little differences that varies over time.

While it's probably a very niche feature for the web, it would be nice if WebGL would also support double precision floats. But as far as I can tell, even when the hardware supports them, WebGL does not, and neither does WebGL 2.

Funny.

When I hear people talk about WebVR, it sounds like everything is working fine.

When I people hear about Vive/Rift, it sounds like there is still much to do, even with the fact that much better hardware is in place than with most WebVR testing.

Given how amazingly slow many websites are, to the point where I start to question whether the site is working at all and deeply regret the fault in my brain that just had to know why list item #7 will surprise me, I generally assume your average web developer does most of their work on some kind of super computer; that probably helps make VR epic ;P.

Little OT, but I think there might be something to the super computer claim. A friend of mine recently tried to convince me that he needs at least 24GiB of ram for web development. I guess you need to be able to run multiple VMs inside a VM now to write your standard 'database + interface' webapp nowadays. Such is progress. ; )

I can see how they get to 24 gbs. Running local db, server, a billion chromium instances (besides the browser and tabs and extensions, you have the editor and other apps running in atom), a couple other browsers to test in, maybe photoshop/ illustrator? Maybe?

Different contexts. WebVR 'works pretty well' because you can do everything that works in the WebGL in VR more or less.

VR as a whole has a long way to go.

No Safari support yet, but I'm really excited about the new Fetch API to replace XMLHttpRequest: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

I'd be a bit cautious about actually using these right now.

It seems like there are still a lot of people (particular in larger organisations) on Internet Explorer 8 or 9, and also a chunk of phones running Opera Mini.

So, sadly, no Flexbox for me just yet.

Not if you work for enterprise dinosaurs. For the rest of the world, using features like these is a good way to make upgrading seem worth the effort.

Reply on news.ycombinator.com