Apple Proposing A New, Lower-Level Graphics API For The Web

[theriddick]

I was talking about Apple Desktop PC sales, and I don't think Apple will be giving that beneficial information away for free, if anything they will put a paywall up so high that only the rich can afford and Patten everything so no one can ever use it!

[GruenSein]

Quick question: why does everyone seem to want Apple implementing Vulkan? What does the Linux-crowd care? You are not even running their OS because *put the usual reasons ranging from valid to plain spiteful here*. Here is the hard truth for you: Apple doesn't care if you guys (as in the tech savvy Linux fellows) like them. They came up with Metal at some point and it got some traction because it came out for their mobile platform where it was needed and which makes up a large share of the mobile app market (talking about the people who actually spend money on doodle jump and whatever. I am well aware that in pure device numbers, Android is ahead). Chances are that all major engines will support it at some point. I think blizzard and unreal are already doing it. Sure, it would be nice for developers to have one API to rule them all but from apples point of view, there is hardly any need to warrant investing in it. On mobile, Metal is established and on the desktop/laptop they dont seem all too interested in gaming and such (unlike OpenCL which is used all over their remaining pro apps). Now they see some benefits in low level APIs for the web as well and are putting it up for debate. I really dont see the problem that seems to be rattling all the cages here.

[VikingGe]

Why does everyone seem to want Vulkan as an API for the web? Vulkan is about giving power to the developer, it is allowed to crash your system when used incorrectly, it's designed for performance-critical applications etc., but certainly not for a platform that can run arbitrary code without even asking you first. Any web-related API must be designed with security in mind, it should not allow undefined behaviour, and it sure as hell should not be able to exploit possible driver bugs. As others have mentioned, WebGL implementations are bad enough in that regard.

That doesn't mean that an implementation of such an API couldn't be based on Vulkan, in fact Vulkan does have stuff like robust buffer access, which is a bare minimum to even allow a secure implementation, but you simply cannot throw Vulkan as it is into the web and expect things to work out.

[linuxgeex]

I agree about the W3C part, but I sure hope browser vendors will actually follow it. They're not always following the W3C standard as of now, so...

To be fair to them, their role isn't just to implement the W3C specs. The browser vendors also implement new features requested by web developers, they get tested in the wild for a while, then they get submitted to the W3C, who in turn accept them for RFCs and ultimately adopt them or not... if they implement a great idea and W3C is slow to adopt then we see competing browsers also implement them and we end up with multiple proprietary browser prefixes for the same non-standard features, then it becomes a de-facto standard and that puts additional pressure on W3C to adopt. So it's not all bad. Newbie developers often hate on these prefixes and API differences before they come to understand that this is the browser vendors kindly giving them things they want long before they would have otherwise gotten them.

[Vistaus]

To be fair to them, their role isn't just to implement the W3C specs. The browser vendors also implement new features requested by web developers, they get tested in the wild for a while, then they get submitted to the W3C, who in turn accept them for RFCs and ultimately adopt them or not... if they implement a great idea and W3C is slow to adopt then we see competing browsers also implement them and we end up with multiple proprietary browser prefixes for the same non-standard features, then it becomes a de-facto standard and that puts additional pressure on W3C to adopt. So it's not all bad. Newbie developers often hate on these prefixes and API differences before they come to understand that this is the browser vendors kindly giving them things they want long before they would have otherwise gotten them.

I'm not saying they shouldn't listed to web developers and only follow the W3C specs, I'm just saying that quite a lot of browsers don't follow very basic W3C specs that are supposed to be followed.

[linuxgeex]

I'm not saying they shouldn't listed to web developers and only follow the W3C specs, I'm just saying that quite a lot of browsers don't follow very basic W3C specs that are supposed to be followed.

Could you cite some examples? I'm doing this for a living and haven't had that problem since the days of IE8... which "very basic" W3C specs are not being followed by "quite a lot" of browsers?